ocaml-containers VS fish-shell

YMMV. Există extensii: Base, Containers. Pentru I/O ai Lwt sau Async.

It focuses on Jane Street's alternate standard library, Base, which means you're not quite learning OCaml, you're learning a distorted dialect of it that is mostly the same but with a lot of unique, opinionated design decisions chosen by Jane Street developers to suit their company's workflow. If you want to use Base you pretty much have to opt in to its way of doing things and pulling in a lot of extra code, so I think it's better to learn OCaml first, then learn Jane Street's way, especially since OCaml's stdlib has grown and improved a good bit since the time when Base was made and RWO originally written. Plus there's also containers now, which is a stdlib extension that lets you cherry-pick the things you want in a more self-contained way that builds on what OCaml provides instead of trying to replace it.

Fortunately, there is Containers which gets the argument ordering right.

Instead of either, you might be interested in Containers. It's more like an extension of the OCaml stdlib where you can cherry-pick what you want to use instead of having to go all-or-nothing. Adds a lot of useful things but not in the opinionated "let's make OCaml a different language" way that Base does.

Same can be said of containers, which extends the stdlib rather than replaces or changes it. It's not fragmentation, it's a "batteries included" utility library that works with the stdlib.

I'm not a fan of some of the opinionated things it does and find it bloats the executables a bit much for my liking, but it is coherent and nicely made. I was looking into trying Batteries instead but someone suggested containers and it seems more modular and an extension of the stdlib rather than a replacement, which is more to my liking.

For writing a self-contained library, people generally stick to stdlib (and occasionally some lightweight stdlib alternatives, e.g. containers - https://github.com/c-cube/ocaml-containers). Personally, I use containers a fair bit for libraries, but not as a full stdlib replacement.

Reminds of the note at the bottom of Fish's releases. It's there because the build system cannot determine the current version for some reason. Hopefully that will go away now that they have switched to a different language / build system. The custom tarball is used by Arch Linux at the very least.

https://github.com/fish-shell/fish-shell/releases/tag/3.7.1

https://github.com/fish-shell/fish-shell/issues/7772#issueco...

https://gitlab.archlinux.org/archlinux/packaging/packages/fi...

A recent practical example of the former: the fish shell re-wrote incrementally from C++ to Rust, and is almost finished https://github.com/fish-shell/fish-shell/discussions/10123

An example of the latter: c2rust, which is a work in progress but is very impressive https://github.com/immunant/c2rust

It currently translates into unsafe Rust, but the strategy is to separate the "compile C to unsafe Rust" steps and the "compile unsafe Rust to safe Rust" steps. As I see it, as it makes the overall task simpler, allows for more user freedom, and makes the latter potentially useful even for non-transpiled code. https://immunant.com/blog/2023/03/lifting/

And this discussion from November has an update on the progress: https://github.com/fish-shell/fish-shell/discussions/10123

We're using bash as our terminal shell for now (it is standard in many distros) but it is not the only one out there. If you want to test out zsh, fish or oh-my-zsh, you will see that there are a few differences and the features are usually the main differentiator. Try that, poke around.

They have a variety of reasons to move to rust, as outlined in their original rust discussion[1]. Mostly around finding other contributors, and adding an async/parallel mode they're comfortable with.

[1] https://github.com/fish-shell/fish-shell/pull/9512