Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OCaml as my primary language

xvw.lol

Post reply on HN
Print view View original

81–90 of 296 posts

Re: OCaml as my primary language

#81

Post by myaccountonhn »

manoDev wrote: post #71

I'm sure there's merit to the language, but the syntax seems absolutely alien to me. Some attempt to look like verbose imperative code, a bunch of semicolons, and for some strange reason, hate of parenthesis. Real life sample: let print_expr exp = (* Local function definitions *) let open_paren prec op_prec = if prec > op_prec then print_string "(" in let close_paren prec op_prec = if prec > op_prec then print_string…

That code is probably some of the hardest you'll encounter in Ocaml, but for me its quite obvious what it does and easy to read because I've worked with GADTs before. If you haven't then its you'll need to study and understand them to understand the code.

I actually really like the syntax of OCaml, its very easy to write and when you're used to it, easy to read (easier than reasonml IMO).

Double semicolons are afaik only used in the repl.

Re: OCaml as my primary language

#82

Post by [deleted] »

ackfoobar wrote: post #35
loxs wrote: post #23

I migrated from OCaml to Rust around 2020, haven't looked back. Although Rust is quite a lot less elegant and has some unpleasant deficiencies (lambdas, closures, currying)... and I end up having to close one one eye sometimes and clone some large data-structure to make my life easier... But regardless, its huge ecosystem and great tooling allows me to build things comparatively so easily, that OCaml has no chance. A…

> the end result is seriously faster Do you have a ballpark value of how much faster Rust is? Also I wonder if OxCaml will be roughly as fast with less effort.

[deleted]

Re: OCaml as my primary language

#83

Post by jasperry »

loxs wrote: post #23

I migrated from OCaml to Rust around 2020, haven't looked back. Although Rust is quite a lot less elegant and has some unpleasant deficiencies (lambdas, closures, currying)... and I end up having to close one one eye sometimes and clone some large data-structure to make my life easier... But regardless, its huge ecosystem and great tooling allows me to build things comparatively so easily, that OCaml has no chance. A…

Your comment makes me think the kind of people who favor OCaml over Rust wouldn't necessarily value a huge ecosystem or the most advanced tooling. They're the kind who value the elegance aspect above almost all else, and prefer to build things from the ground up, using no more than a handful of libraries and a very basic build procedure.

Re: OCaml as my primary language

#84

Post by benreesman »

simonask wrote: post #62
benreesman wrote: post #43

Earlier quoted context omitted.

[flagged]

This is one of the wilder conspiracy theories to me, and that says a lot in 2025.

The RESF is not a conspiracy theory, its a known thing. Especially on HN: https://news.ycombinator.com/item?id=14178950

Re: OCaml as my primary language

#85

Post by ackfoobar »

sunnydiskincali wrote: post #67
ackfoobar wrote: post #5

> Sum types: For example, Kotlin and Java (and de facto C#) use a construct associated with inheritance relations called sealing. This has the benefit of giving you the ability to refer to a case as its own type. > the expression of sums verbose and, in my view, harder to reason about. You declare the sum type once, and use it many times. Slightly more verbose sum type declaration is worth it when it makes using the…

> This has the benefit of giving you the ability to refer to a case as its own type. A case of a sum-type is an expression (of the variety so-called a type constructor), of course it has a type. datatype shape = Circle of real | Rectangle of real * real | Point Circle : real -> shape Rectangle : real * real -> shape Point : () -> shape A case itself isn't a type, though it has a type. Thanks to pattern matching, you'…

> The moment you start ripping cases as distinct types out of the sum-type, you create the ability to side-step exhaustiveness and sum-types become useless in making invalid program states unrepresentable.

Quite the opposite, that gives me the ability to explicitly express what kinds of values I might return. With your shape example, you cannot express in the type system "this function won't return a point". But with sum type as sealed inheritance hierarchy I can.

> C#/Java don't actually have sum-types.

> They're pretty much the same

Not sure about C#, but in Java if you write `sealed` correctly you won't need the catch-all throw.

If they're not actual sum types but are pretty much the same, what good does the "actually" do?

Re: OCaml as my primary language

#86

Post by the__alchemist »

noelwelsh wrote: post #33

I saw a talk by someone from Google about their experiences using Rust in the Android team. Two points stuck out: they migrated many projects from Python, so performance can't have been that much of a concern, and in their surveys the features people liked most were basics like pattern matching and ADTs. My conclusion is that for a lot of tasks the benefit from Rust came from ML cicra 1990, not lifetimes etc. I feel…

I'm with you. I think some of the nicest parts of rust have nothing to do with memory safety; they're ways to structure your program as you mention.

Re: OCaml as my primary language

#87

Post by the__alchemist »

benreesman wrote: post #84
simonask wrote: post #62

Earlier quoted context omitted.

This is one of the wilder conspiracy theories to me, and that says a lot in 2025.

The RESF is not a conspiracy theory, its a known thing. Especially on HN: https://news.ycombinator.com/item?id=14178950

It's real, and as someone who loves rust, it's embarrassing, and difficult to avoid. The OSS embedded rust users in particular are nuts.

Re: OCaml as my primary language

#88

Post by UncleOxidant »

manoDev wrote: post #71

I'm sure there's merit to the language, but the syntax seems absolutely alien to me. Some attempt to look like verbose imperative code, a bunch of semicolons, and for some strange reason, hate of parenthesis. Real life sample: let print_expr exp = (* Local function definitions *) let open_paren prec op_prec = if prec > op_prec then print_string "(" in let close_paren prec op_prec = if prec > op_prec then print_string…

I mean, I guess it depends on your background, but that code looks pretty nice compared to how it would look in a language without pattern matching and ADTs. This is why the MLs excel for things like parsers, interpreters, and compilers. Beauty is in the eye of the beholder, I guess. I suspect that if you gave it a bit of time it would start to really grow on you - that's how it was in my case. At first: "WTF is this weird syntax?!", a few weeks in "oh, this makes a lot of sense, actually", a few years "Yeah, I'd much rather write this sort of thing in OCaml (or an ML in general)"

Re: OCaml as my primary language

#89

Post by Taikonerd »

troupo wrote: post #72
noelwelsh wrote: post #33

I saw a talk by someone from Google about their experiences using Rust in the Android team. Two points stuck out: they migrated many projects from Python, so performance can't have been that much of a concern, and in their surveys the features people liked most were basics like pattern matching and ADTs. My conclusion is that for a lot of tasks the benefit from Rust came from ML cicra 1990, not lifetimes etc. I feel…

OCaml also needed the brief but bright ReasonML moment to add/fix/improve some of the syntax IIRC and work on user-friendly error messages. But this should've definitely happened much much earlier than it did.

I would say ReasonML also needed more follow-through. It seems like the OCaml community hasn't really rallied behind it.

Re: OCaml as my primary language

#90

Post by ackfoobar »

jasperry wrote: post #74

Question about terminology: Is it common to call higher-order function types "exponential types" as the article does? I know what higher-order functions are, but am having trouble grasping why the types would be called "exponential".

A first-order function type is already exponential.

A sum type has as many possible values as the sum of its cases. E.g. `A of bool | B of bool` has 2+2=4 values. Similarly for product types and exponential types. E.g. the type bool -> bool has 2^2=4 values (id, not, const true, const false) if you don't think about side effects.

Post reply on HN