Live data from Hacker News

We chose OCaml to write Stategraph

stategraph.dev

81–90 of 127 posts

Re: We chose OCaml to write Stategraph

#81

Earlier quoted context omitted.

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.

I have experienced many identical situations. Some people just love to tinker and over-engineer for the sake of stretching a muscle. It's unfortunate when that sneaks into a prod system that has to be maintained by others.

Re: We chose OCaml to write Stategraph

#82

Earlier quoted context omitted.

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

When there was no true concurrency, only preemption, eio was safe. Not now, you can still clobber things. Edit: i was wrong! Since at least 5.1 it catches the cross domain access and errors gracefully.

Eio didn't exist before multicore OCaml actually, it was designed for it.

Re: We chose OCaml to write Stategraph

#83

Earlier quoted context omitted.

> 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.

That makes a lot more sense: The earliest 5.x releases weren't stable at all despite the non-prerelease version numbers. I waited for longer than I wanted to before upgrading from the LTS to 5, but right now it should be ok to switch as long as the few regressions, like the GC pacing issue, don't affect you workload.

Re: We chose OCaml to write Stategraph

#84

Sorry for the large aside, but anyone knows the whereabouts of the Flambda2 project? Can't find the GH repo anymore, only this fork I didn't know about: https://github.com/oxcaml/oxcaml/

That's the repo, Jane Street has rebranded their OCaml fork to OxCaml (as in oxidised, Rust-like). From the readme:

> This is also the home of the Flambda 2 optimiser

Their plan is to use OxCaml as their experimental fork and work with upstream to port features from it. Labelled tuples and immutable arrays for example landed in OCaml 5.4 but were originally from OxCaml.

Re: We chose OCaml to write Stategraph

#85
post #39

I have worked with Haskell, Scala, and OCaml; they all bring the joy of programming into daily tasks, and OCaml has a fast compiler and a great module system. This makes it a really fun and effective language to use.

Scala has some quirks but I enjoyed it relative to more popular languages and its apparent stagnation makes me sad.

Re: We chose OCaml to write Stategraph

#86

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…

One of the great understated reasons for using 'cool' programming languages is that it allows a business to hire selectively for people for whom programming is a passion.

Re: We chose OCaml to write Stategraph

#87
post #21

Earlier quoted context omitted.

Yeah I get the sense that terraform change application is solved by just serializing all changes? The concurrent applies isn’t that big of a deal?

> The concurrent applies isn’t that big of a deal? That depends. There are many organizations (we talk to them) which have plans and applies that take 5 - 10s of minutes, some even close to an hour. That's a problem. We talked to one customer that a dev can make a change in the morning and depending on the week might have to wait until the next day to get their plan, and then another day to apply it, assuming there a…

> There are many organizations (we talk to them) which have plans and applies that take 5 - 10s of minutes, some even close to an hour. That's a problem. We talked to one customer that a dev can make a change in the morning and depending on the week might have to wait until the next day to get their plan, and then another day to apply it

That's us. Especially because our teams are distributed across NA/Eastern Europe/Japan. So getting a lock is a problem because you have to wait for someone else to finish, then getting the required reviews is a problem because you have to wait for people from other timezones to come on, then by the time you're ready to re-plan after the reviews someone else has taken the lock, then you have to wait for them,...

Re: We chose OCaml to write Stategraph

#88

I hope for the team to settle with a FLOSS license, so it becomes feasible to evaluate for everyone.

We're still figuring out what balance makes sense between openness and sustainability, and we'd rather take the time to get it right than rush into a license we'll regret later. The goal is for Stategraph to last a long time.

Best of luck. Hoping for AGPL :-)
Post reply on HN