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

We chose OCaml to write Stategraph

stategraph.dev

Post reply on HN
Print view View original

51–60 of 127 posts

Re: We chose OCaml to write Stategraph

#51

Post by phplovesong »

laszlojamf wrote: post #4

I don't really get what's special about OCaml with these points they raise? Wouldn't almost any strongly typed language do? Wouldn't TypeScript also tick all these boxes? EDIT: I wouldn't choose TypeScript either for this type of use case, but not for the reasons they state, that's my point

Typescript (javascript) is kind of a joke compared to what ocaml brings to the table.

Ocaml has a top in class typesystem, a "faster than Go" compiler and (in 2025) good tooling. It allows you to say fuck it and write a while loop if you need to. Hell you can even do OOP. Also it has an incredible module system and full type inference. It also has an effect system, and good concurrency features (ocaml 5).

I cant say many other languages that has all the same features.

Re: We chose OCaml to write Stategraph

#52

Post by mattgreenrocks »

sausagefeet wrote: post #19
criddell wrote: post #13

Earlier quoted context omitted.

The first comments here are people reading this as if the authors are saying only OCaml can do this. They aren't.

Exactly! OCaml is the language I like to solve problems in, and I'm excited to solve problems in, so that's why Terrateam uses OCaml (I'm the CTO). You can do a lot (but not all) of this in Go, or TypeScript, but I don't get excited about those languages. Certainly I'll use them if I have to (our UI is written in Svelte) but building your own company is a grind, and using OCaml makes the grind just a bit more excitin…

Industry is just starting to come around to it, but I've never been more happy programming than when using a strongly-typed language with sum types. What most people fail to understand is that fighting the type checker is almost always a feature, not a bug. It is training you to write code in a way that it understands, which forces your thinking to be less sloppy, even on non-happy paths.

Sum types enable much higher levels of expressivity of what valid states are while still being statically analyzable. Any new PL lacking them, IMO, is making a huge unforced error. They don't apply for every situation, but they do handle a large amount of day-to-day programming concerns.

Side note: OO is oft-maligned in OCaml, but I really appreciate that they included it anyway. I much prefer languages that give you a set of tools to use in whatever situation you find yourself in.

Re: We chose OCaml to write Stategraph

#53

Post by a-french-anon »

stefanos82 wrote: post #6
koakuma-chan wrote: post #3

Is any of this OCaml specific? You can check all boxes with TypeScript.

Does TypeScript emit machine code? OCaml gives you this option, if you need it.

Well, TS transpiles to JS which then runs on Node, aka V8, a native JIT compiler. So yes, I guess?

Re: We chose OCaml to write Stategraph

#54

Post by greener_grass »

galangalalgol wrote: post #45
greener_grass wrote: post #27

Earlier quoted context omitted.

Define functional? Even Haskell is not functional in the strictest sense. It has unsafe IO. It can throw exceptions. Functions may not halt.

Fair. Agda, gallina, f* maybe? My point was that without any escape hatches or magic you can code a segfault starting in ocaml5. That may be true of haskell? It is true of rust too, though the only known way to do it isn't something that is likely to happen by accident and is tracked as a bug. In ocaml5 if you use domain, it is down to experience skill, and some luck to be sure you used atomic when necessary. I'm a b…

Shouldn't most application programmers in OCaml be reaching for EIO or some other well-tested abstraction?

Re: We chose OCaml to write Stategraph

#55

Post by phplovesong »

internet_points wrote: post #43
jacquesm wrote: post #5

Earlier quoted context omitted.

It's the combination with concurrency that makes this a hard problem. And OCaml excels at solving that sort of problem. OCaml and Erlang are the only two languages that I'm aware of that have a really clean way of doing this, in most other languages there is always some kind of kludge or hack to make it work and at best you're going to do something probabilistic: it seems to work, even under load, so it probably is g…

What advantage does OCaml have over Haskell here? I find software transactional memory in Haskell so simple to work with that I have lost all fear of concurrency, but what am I missing out on?

Its mostly about practicality. Haskell is kind of pain when you need IO, as in when you go there there is no way out.

Ocaml is more practical, and less punishing (you can do IO without monads), but the most important diffrence is performance. Haskell is VERY hard to make predictable because its lazy. Ocaml is strict so general system performance is much easier to predict.

But they are sibling languages in my book, while i still prefer ocaml over haskell.

Re: We chose OCaml to write Stategraph

#57

Post by phplovesong »

galangalalgol wrote: post #20
gregwebs wrote: post #8

Earlier quoted context omitted.

Functional programming is immutable by default. TypeScript and many other typed languages don't really stop you from clobbering things, particularly with concurrency. Rust does. But immutability with GC is a lot easier to use than Rust if you don't need the performance of Rust.

But what is functional besides haskell? Purescript? Elm I guess. Ocaml is not. It has for loops even. You can write pure functional ocaml but people don't. It mattered a lot less when it didn't have true concurrency, but now clobbering things in ocaml is quite possible.

FP has nothing to do with mutability. You seem to lack a basic understanding what the common FP languages are, and what FP actully is.

Re: We chose OCaml to write Stategraph

#58

Post by lo_zamoyski »

hardwaregeek wrote: post #7

I like OCaml and have written the "why we chose XYZ language" posts. Most of the time the real answer is "we like it and it makes us feel good to use it". Like the answers aren't wrong per se but they're more post-facto justifications. And that's perfectly fine! I think we should normalize saying that tech stack choices are subjective and preference-based. We're not robots. The social and aesthetic parts of a stack m…

> I think we should normalize saying that tech stack choices are subjective and preference-based. We're not robots. The social and aesthetic parts of a stack matter to people

I would just like to distinguish "subjective and preference-based" from "social and aesthetic" and also clarify some notions.

1. The social is objective. We are social animals. It is essential to what it means to be human. We need social relations to grow and develop and to become more human.

2. The aesthetic is objective. We confuse taste with beauty, and this is perhaps the legacy of influence of certain philosophical traditions on our thinking. Beauty has to do with the fullness with which some thing instantiates a form and realizes some end/good. So, when it comes to artifacts like programming languages, a beautiful language will satisfy some human purpose more perfectly than a less beautiful language. Taste is a matter of subjective disposition to beauty. Someone with bad or poor taste might prefer the inferior over the superior, for example, or fail to discern between the two.

We sort of create mystery about preference here, as if they were just arbitrary, immutable, inexplicable brute facts. But preferences can be more good or less good or even bad. Note the relation between preference and taste.

> We're not robots.

3. Typically - and I do not accuse you of this - this is meant to mean that what makes us human compared to robots is that we have emotions. But it isn't that. Many animals have emotions. What makes us distinct as human beings is the intellectual and the rational, which robots (as computational instruments) are not.

4. Post hoc rationalizations may not stand behind the actual motivations, but the content of the rationalization may remain true and valid nonetheless.

Re: We chose OCaml to write Stategraph

#59

Post by phplovesong »

IshKebab wrote: post #14
laszlojamf wrote: post #4

I don't really get what's special about OCaml with these points they raise? Wouldn't almost any strongly typed language do? Wouldn't TypeScript also tick all these boxes? EDIT: I wouldn't choose TypeScript either for this type of use case, but not for the reasons they state, that's my point

OCaml has a much stronger type system than Typescript. The real question is "why not Rust?". I've used both a fair bit and OCaml's only major advantage IMO is compile time. That doesn't seem compelling enough to put up with the downsides to me.

Rust has too many footguns. Ocaml is usually more safe.
Post reply on HN