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

71–80 of 127 posts

Re: We chose OCaml to write Stategraph

#71

Post by myaccountonhn »

phplovesong wrote: post #55
internet_points wrote: post #43

Earlier quoted context omitted.

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, wh…

Also IMO the dev tooling is better for OCaml. Far better compile times.

A big part of interacting with APIs (which I imagine Stategraph does) is just dealing with records, and working with records in Haskell is really annoying unless you bring in lenses which bring a lot of complexity.

Re: We chose OCaml to write Stategraph

#72

Post by stonemetal12 »

>One operation can't corrupt another operation's view of state because state is immutable by default.

How true is this in practice? I mean on the one hand sure Operation 2 doesn't seem some half modified state from Operation 1. On the other hand Operation 2 now has some stale state and makes the wrong decisions does the wrong thing because it didn't see Operation 1's changes.

Re: We chose OCaml to write Stategraph

#73

Post by pjmlp »

a-french-anon wrote: post #53
stefanos82 wrote: post #6

Earlier quoted context omitted.

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?

Kind of, given that V8 performance is never going to be as good as AOT compiled language, and JIT needs warmup time.

It is no accident that famous JavaScript tools keep being rewritten into C++, Dart, Go and Rust.

Re: We chose OCaml to write Stategraph

#74

Post by phplovesong »

myaccountonhn wrote: post #71
phplovesong wrote: post #55

Earlier quoted context omitted.

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, wh…

Also IMO the dev tooling is better for OCaml. Far better compile times. A big part of interacting with APIs (which I imagine Stategraph does) is just dealing with records, and working with records in Haskell is really annoying unless you bring in lenses which bring a lot of complexity.

Tooling was kind of bad previously. But dune has got really good. I like the new dune developer preview thing that is still in beta.

https://preview.dune.build/

Re: We chose OCaml to write Stategraph

#75

Post by jinwoo68 »

stonemetal12 wrote: post #72

>One operation can't corrupt another operation's view of state because state is immutable by default. How true is this in practice? I mean on the one hand sure Operation 2 doesn't seem some half modified state from Operation 1. On the other hand Operation 2 now has some stale state and makes the wrong decisions does the wrong thing because it didn't see Operation 1's changes.

That happens whether immutable or not. In the mutable world, you have to guard that using a mutex or something. In that case, operation 1 may be blocked by operation 2, and now you get a "stale" state from operation 2. But that's okay. You'll get a new state next time. The real problem occurs when two states are mixed and corrupted.

Re: We chose OCaml to write Stategraph

#76

Post by strongly-typed »

whobre wrote: post #41
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…

Using something you enjoy is fine, as long as you don’t forget the person who is going to maintain your code after you move on.

Imagine inheriting a project that was a joy for someone to work on instead of a slog.

Re: We chose OCaml to write Stategraph

#77

Post by blandflakes »

strongly-typed wrote: post #76
whobre wrote: post #41

Earlier quoted context omitted.

Using something you enjoy is fine, as long as you don’t forget the person who is going to maintain your code after you move on.

Imagine inheriting a project that was a joy for someone to work on instead of a slog.

Joy is probably an improvement on slog, but one person's joy is another's hell. I've inherited a lot of joyful projects that were an awful fit for continued maintenance because joyful meant using new, unproven, and unstable technologies.

Re: We chose OCaml to write Stategraph

#78

Post by yodsanklai »

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?

I personally find OCaml more pragmatic than Haskell.

Haskell has a steeper learning curve IMHO: monads are pervasive and are hard to understand, laziness isn't a common programming pattern and it adds complexity. I find type classes confusing as well, it's not always clear where things are defined.

I like that OCaml is close to the hardware, there are no complex abstractions. The module system makes it easy to program in the large (I love mli). If you avoid the more advanced features, it's a super simple language.

Re: We chose OCaml to write Stategraph

#79

Post by galangalalgol »

debugnik wrote: post #69
galangalalgol wrote: post #45

Earlier quoted context omitted.

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…

> you can code a segfault starting in ocaml5 It shouldn't, the OCaml 5 memory model bounds the reach of data races in both space and time. [1] Thread-unsafe code won't be correct when misused, but it will stay memory safe unless you reach for an additional escape hatch (or you find an implementation bug of course). [1]: https://ocaml.org/manual/5.4/memorymodel.html I'm much more concerned about the amount of poorly v…

You are right! As of 5.1.1 at least it catches the cross domain access I was using to smash things. From what I am reading it sounds like it didn't work in 5.1 I could go try it in godbolt to find out when it was fixed, but I kind of don't care. Very exciting, I like ocaml and was lamenting the changes.

Re: We chose OCaml to write Stategraph

#80

Post by baby »

I wrote the OCamlByExample and I can only say, good luck, I don't think OCaml is ready for production, and it's generally not a very user-friendly language, but IMO it's all about having fun first and if this is what makes it fun for you guys then you should do it!

Also with LLMs it's probably easier to just feed the compiler errors to an LLM and get something readable at the end.

Post reply on HN