Hacker News: Bilirubino

New comment by Bilirubino in "Ask HN: What less-popular systems programming language are you using?"

Bilirubino — Sat, 08 Mar 2025 21:33:51 +0000

As I commented above, Int32 and Int64 are part of the standard library since at least 4.X Ocaml versions (we are now in 5.3). So normally all them are available when you install any distribution of Ocaml. Note that there is also a type named nativeint (which, I think is the kind of int that you were looking for in all your comments and post) and it is part of the standard library, so in summary:

Int type (the one you dislike for systems programming)

Int32 type (part of the standard library, one of those you were looking for)

Int64 type (part of the standard library, one of those you were looking for)

Nativeint (part of the standard library, maybe the one you were looking for)

The library stdint is other option, which can be convenient in some cases but for Int32 and Int64 you don't need it also for Nativeint you don't need it.

New comment by Bilirubino in "Ask HN: What less-popular systems programming language are you using?"

Bilirubino — Sat, 08 Mar 2025 21:20:21 +0000

The modules Int64 and Int32 and part of the OCaml standard library. You mentioned that it is needed dune or Janestreet in your comments to have this functionality. They are part of the standard library. Really, they are part of Ocaml core developments. Actually, for example, you even can use the library big-arrays with these types and int8, int16, signed, unsigned... even more you have platform-native signed integers (32 bits on 32-bit architectures, 64 bits on 64-bit architectures) with Bigarray.nativeint_elt as part of the standard library so all these types are there.

You also mention that Int32 and Int64 are recent, however these libraries were part of OCaml already in the 4.X versions of the compiler and standard library (now we are in the 5.3).

Note that in OCaml you can use C libraries and it is quite common to manage Int32, Int64, signed etc...

New comment by Bilirubino in "Ask HN: What less-popular systems programming language are you using?"

Bilirubino — Sat, 08 Mar 2025 21:02:49 +0000

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.

New comment by Bilirubino in "Ask HN: What less-popular systems programming language are you using?"

Bilirubino — Sat, 08 Mar 2025 20:47:55 +0000

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.

New comment by Bilirubino in "Ask HN: What less-popular systems programming language are you using?"

Bilirubino — Fri, 07 Mar 2025 15:27:33 +0000

The reason of F# guys did things different from OCaml is not because system-level programming but because F# is a language designed for the .NET ecosystem which imposes specific type constrains. F# language was not specifically designed for systems-level programming.

Again, the semantics of Int is different but the semantics in OCaml of Int32 and Int64 is the same/standard. So you have 3 types: int, Int32 and Int64 and it is an static typed language.

New comment by Bilirubino in "Ask HN: What less-popular systems programming language are you using?"

Bilirubino — Fri, 07 Mar 2025 15:19:52 +0000

The situation is that OCaml is giving you all the options:

(a) int has 31 bits in 32-bit architectures and 63 in 64-bit architectures (which speed up some operations)

(b) the standard library also provides Int32 and Int64 modules, which support platform-independent operations on 32- and 64-bit signed integers.

In other words: int is different but you always have standard Int32 and Int64 in case you need them.

It seems therefore that the use for system-level programming should not be decided for this (although the fact that it is a garbage collected language can be important depending on the case, note that still its garbage collector has been proved one of the fastest in the comparisons and evaluations done by the Koka language team of developers).