[hardwaregeek]

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 matter to people

[lawnchair]

Definitely agree. Most teams don't choose a language for purely rational reasons, and we're not pretending we did.

We like OCaml, it makes us excited to build. We know the language deeply, which means we can reason about performance and behavior before we run the code. We can onboard new engineers quickly because the type system forces clarity.

The runtime is simple enough that we can predict what it's doing. So yes, part of it is that OCaml feels good to use. But that feeling comes from years of watching it make complex systems simpler to reason about, not harder.

[svara]

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.

[BenGosub]

I think that in some cases where OCaml was chosen, like Docker or some parsers, the choice was obviously not evangelical. But I agree that in most cases it is a post-facto justification.

[yahoozoo]

Docker?

[BenGosub]

Docker virtualization is written in OCaml

[criddell]

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

[sausagefeet]

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 exciting, and that's an edge.

[mattgreenrocks]

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.

[xedrac]

I've used a lot of Rust and Haskell over the past few years (I consider OCaml to be similar), and I think the benefits go beyond just user preference. But I think it's something that requires experience with "must not fail" systems failing in production, and then seeing how these languages make that failure impossible. The level of freedom and confidence that brings is amazing. And yes, that also makes them more fun to use.

[epolanski]

> I think we should normalize saying that tech stack choices are subjective and preference-based.

True but I don't think this is the correct way to frame it, because it sounds unprofessional.

The correct, and understandable way is:

- the language has properties that fit the software

- the language has properties that fit the development process

- it boosts morale of development team

- the team has the required skillset

Then it's not only a preference, but a conscious engineering choice made of evaluating the different pros and cons of various alternatives.

[lo_zamoyski]

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

[ab5tract]

I’m sorry but there is no way you can demonstrate a universal aesthetic. Your opinion of other people’s tastes does not reflect on their taste — it reflects on yours.

[lo_zamoyski]

> I’m sorry but there is no way you can demonstrate a universal aesthetic.

What do you mean by "aesthetic", because I've already made the distinction between objective beauty and subjective taste. If my explanation is true, then it follows that there is an objective ordering of beauty (of at least two kinds: with respect to the same form/end, and between forms and ends). Then, there's the question of how competent someone is at recognizing this order. And finally, there are contingent factors that will affect expressed volitional preference as a function of factors like attainability or character flaws or whatever.

Making beauty a matter of purely subjective response makes it more mysterious and nonsensical, not less.

> Your opinion of other people’s tastes does not reflect on their taste — it reflects on yours.

How do you know this? You haven't demonstrated this claim. I've at least explained the basis for mine.

I claim that on the contrary, yes I can. I can claim that someone who thinks rape or murder are beautiful has objectively deranged tastes, because these acts are intrinsically ugly.

[whobre]

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.

[strongly-typed]

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

[blandflakes]

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.

[whalesalad]

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.

[lenkite]

Parent developer's Joy is the inheriting developer's Despair. A project is successful when the parent developer is Bored.

[bsder]

There are things that are objectively a "bad fit".

As long as you steer away from those, the "good" choices are mostly interchangeable--use what you prefer.