lambda_foo

The type system for effects is an ongoing research effort. For now you get unhandled effect exceptions at runtime.

With Multicore OCaml we gained thread sanitizer support and a reasonable memory model. Combined they give you tools for reasoning about data races and finding them. https://ocaml.org/manual/5.3/tsan.html

Strongly agree, plus OCaml has an expressive type system that lets you build abstractions that just aren’t possible with Go. The original article gives poor reasons for choosing Go.

With OCaml 5 supporting effect handlers I expect MirageOS will go in that direction. It’ll make for more readable code than LWT.

My own repo in the OP :-)

It's really fascinating the different little evaluators that exist in DWARF. I started writing one for the DWARF expression format (https://github.com/tmcgilchrist/durin/pull/7) that I'm integrating with a debugger and free-monad/effect handler style code to lookup the missing data to provide for the Requires* callbacks.

Then there is the line number evaluation, which I haven't started on.

Building a Debugger by Sy Brand (https://nostarch.com/building-a-debugger) is an awesome book if you want to learn more about this. It covers DWARF 4 and you build a full debugger in C++17 for Linux/x86_64. Can't recommend that book highly enough!

It is heavily WIP at the moment so I haven't published to opam just yet. You'll need to compile from source if you want to try it out. I'm filling in examples as I need them and publishing code when it isn't too terrible to look at.

Author here, a bit cringe to see your WIP project posted here.

My motivation for writing this from scratch is to simultaneously understand DWARF 5 in all its gory details, develop tooling to support my work on the OCaml compiler, and to build a source debugger in OCaml. The performance or lack of isn't a focus right now, I'm sure it doesn't compare to gimli-rs for performance but it does fully support DWARF 5 which gimli-rs doesn't (missing debug_info section support https://github.com/gimli-rs/gimli/pull/807).

Currently I'm working on the read support, and various bits of tooling around understanding Call Frame Information and simulating the DWARF expression evaluation. I'm unhappy with the tooling GDB/LLDB provide for displaying and debugging this information, I've personally spent far too much time staring at CFI expressions and walking memory looking for where it goes wrong. In the OCaml compiler we have few people that understand or work on this area.

Why have the OP in the loop at all if he’s just sending prompts to AI? Surely it’s a wonderful piece of performance art.

Pretty much. I guess it’s open source but it’s not in the spirit of open source contribution.

Plus it puts the burden of reviewing the AI slop onto the project maintainers and the future maintenance is not the submitters problem. So you’ve generated lots of code using AI, nice work that’s faster for you but slower for everyone else around you.

The fact that Itanium had register windows was such a strange choice. I thought they had been shown to not be worthwhile like branch delay slots in MIPS. Basically hangovers from the early constraints of hardware implementations.

Thanks for sharing, I had no idea about this project.

Could you share some more details about where this project is used? Links to those open positions for OCaml developers would be interesting too, not for myself :-)

Using DAP with VSCode and OCaml's bytecode debugger (https://github.com/hackwaly/ocamlearlybird) works reasonably well already. My blog post above can be modified to work with VSCode, but I'm primarily an Emacs user. The main issue with Emacs and DAP is the DAP modes are not very polished.

The missing piece for OCaml is debugging native code, the compiler doesn't emit enough DWARF information and debuggers like LLDB or GDB, need to be modified to understand OCaml's DWARF information. Even there DAP with LLDB/GDB works, it's just the debugger doesn't have enough information to work well. You end up working with debugging assembly or C (if it's parts of the runtime). I've written up a PR documenting native debugging here https://github.com/ocaml/ocaml/pull/13747.

David Christiansen did a more recent experience report from 2019 about using Dependently Typed Haskell at Galois.

https://davidchristiansen.dk/pubs/dependent-haskell-experien...

The video is on YouTube somewhere. Having used Haskell and some dependently typed Haskell around the same time, I thought it was a fair assessment of state of play.

Even if Oracle tried, SPARC performance was terrible and their value for money was too. We benchmarked a finance system (Transaction Processing) where we needed 3x the SPARC hardware to keep up with Intel/Linux. Once they bought Sun I couldn't see any future where they made it work with keeping SPARC alive. Best case was keeping Solaris on x86 since that had genuinely better features (Zones and DTrace in particular).

Sure, you will need to write a major mode but honestly it's not that hard to get syntax highlighting working. If you follow something like https://www.masteringemacs.org/article/lets-write-a-treesitt... plus using M-x treesit-explore-mode it took me 1 day to get treesitter support for OCaml, starting from knowing nothing about how Treesitter works with Emacs to a semi-decent highlighting and indentation setup. The indentation was harder to get working, but all up 300 lines of elisp including whitespace and comments.

There is a pretty complete wasm_of_ocaml port to the Eliom web framework here https://github.com/ocsigen/eliom/pull/767

It seems like it’s a relatively easy swap from js_of_ocaml to WASM. That’s the option I’ve chosen for my experiments.

They are targeting two different intermediate representations in the compiler. wasm_of_ocaml is a fork of js_of_ocaml that consumes OCaml bytecode and emits Wasm instead of JavaScript. Compared to wasocaml that uses the FLambda-based backend for OCaml’s native code compiler.

Time will tell if both survive, they are both under active development. IMHO target different use cases.

Shout out to https://github.com/samuelkarp/runj which aims to provide OCI compatible runtime for FreeBSD jails. We are working on a Jails based sandbox implementation for running OCaml builds on FreeBSD, https://github.com/ocurrent/obuilder. If runj gets more support then it would be a good alternative to the various iocage/ezjail/etc solutions or the raw Jails implementation we have right now.

It's not clear to me why you'd choose OCaml over Haskell. I understand that OCaml isn't lazily evaluated like Haskell and has a simpler to understand compiler which gives a better understanding how the code will perform at runtime. But why as someone new why would I choose OCaml over Haskell?

From my perspective it seems like there is more activity and research going on in Haskell.

Nice to see others with the same attitude. It's a thing of beauty to see a room cleared of clutter and reduced to the bare minimum of furniture/stuff.

We follow a very similar process in our house. If it hasn't been used in 6 months or so it goes out the door. Either to charity or ebay.