[IshKebab]

I want to like OCaml but OPAM is just so bad... and tooling is super important (it's one of the reasons Go is popular at all). Windows support is also an afterthought. There's no native debugger as far as I can tell. This is before you even get to the language which definitely has its own big flaws (e.g. the lack of native 64-bit integers that MrMacCall mentioned.

The syntax is also not very friendly IMO. It's a shame because it has a lot of great ideas and a nice type system without getting all monad in your face. I think with better tooling and friendlier syntax it could have been a lot more popular. Too late for that though; it's going to stay consigned to Jane Street and maybe some compilers. Everyone else will use Rust and deal with the much worse compile time.

[Taikonerd]

> The syntax is also not very friendly IMO.

Very true. There's an alternate syntax for OCaml called "ReasonML" that looks much more, uh, reasonable: https://reasonml.github.io/

[Bilirubino]

The OCaml syntax was discussed a long time ago between the developers and the whole community and the agreement was that the community is happy with the current/original syntax. ReasonML was created for those developers more familiar with Javascript, but it was not very successful in attracting new developers as they usually look more at the semantics of the language along with the syntax (and that is where OCaml's type system shines). Strictly speaking, there is a long list of ML family languages that share many properties of OCaml's syntax. However, what is a ‘reasonable’ syntax is open to debate. Javascript and Python were not mainstream languages when Ocaml was developed and it made much more sense to create a syntax in line with the ML family of powerful languages available at the time. Once you program a bit in OCaml syntax is not a problem, learning to program in a functional paradigm and getting the most out of it is the real challenge.

[mbac32768]

> (e.g. the lack of native 64-bit integers that MrMacCall mentioned.

They exist, I think you just mean `int` is 63-bit and you need to use operators specialized `Int64.t` for the full precision.

[MrMcCall]

How can you access the full 64 bits if "one bit is reserved for the OCaml runtime"? (the link is in the my original post's thread)

[ravi-delia]

The usual int type is 63 bits. You can get a full 64 bit int, it just isn't the default.

[MrMcCall]

The docs say, "one bit is reserved for the OCaml runtime", so doesn't that mean that one of the bits (likely the high bit) are unavailable for the programmer's use?

I mean, I understand "reserved" to mean either "you can't depend upon it if you use it", or "it will break the runtime if you use it".

[ravi-delia]

So the "one bit" you refer to is what makes the standard int 63 bits rather than 64. If you could do things with it it would indeed break the runtime- that's what tells it that you're working with an int rather than a pointer. But full, real, 64-bit integers are available, in the base language, same goes for 32.

[MrMcCall]

And that means that the OCaml runtime is not compatible with systems-level programming.

If something is "available", it should mean that it can be used to its full capacity. One of those bits are definitely not available.

[lapinot]

https://ocaml.org/manual/5.3/api/Int64.html

[MrMcCall]

I see, now. From that doc:

> Performance notice: values of type int64 occupy more memory space than values of type int

I just couldn't even imagine that a 64-bit int would require MORE memory than an int that is one bit less (or 33 bits less if on a 32-bit architecture).

It really makes absolutely no sense discussing OCaml as a possible systems-level programming language.

[dgan]

Why opam is bad? Compared to what? Could you elaborate

[IshKebab]

1. I've found it to be extremely buggy, often in confusing ways. E.g. there was a bug where it couldn't find `curl` if you were in more than 32 Linux groups.

2. It has some kind of pinning system that is completely incomprehensible. For example you can do `opam install .`, which works fine, and then `git switch some_other_branch; opam install .` and it will actually still install the old branch?? Honestly I've never figured out what on earth it's trying to do but me and my colleagues have had constant issues with it.

> Compared to what?

Compared to good tooling like Cargo and Go and NPM and uv (if you give it some slack for having to deal with Python).

It's better than Pip, but that doesn't take much.

[Bilirubino]

In my case I have not found opam buggy at all, and I never find it confusing but this last point may be personal taste. The bug you commented is something I have never experimented with opam in linux or Mac OS and I am sure if you report the developer will check about it.

The point 2 you mention, I don't understand the issue. There is an opam switch which works for me perfectly, no issues at all. Please, like any other tool it is better to read the manual to understand how it works.

Cargo and opam is not something comparable, probably next generation of dune could be, but at this moment it is make no sense compare two utilities that are so different. Compare with pip, julia package manager, etc is fine. Personally, I like more opam than npm and pip.

[dgan]

Interesting, thanks, I have been using opam, but since I am lal alone and by myself, I never hit the cases you mentioned

[fuzztester]

>The syntax is also not very friendly IMO.

Why do you think that the syntax is not very friendly?

Not saying you are wrong, just interested to know.

[satvikpendem]

Have you tried esy?