Content on HN about the holy trinity of programming languages, text editors, and operating systems generally favors less popular options with more mystique. Anything about Java is probably going to be largely neutral or negative, while a piece on Common Lisp might be much more positive, even though Java is a far more successful programming language in most ways.

I don't think that this bias is a bad thing. It's nice to read about cool technologies that you might not use in your day job. But anyone using HN to decide on the right tool for a project should carefully consider other sources of information as well.

Assume for the moment that all languages are equal. (They aren't, but ignore that for the moment.) If you say something good about Java, there are a lot of people here who have used Java, and some of them have bad impressions that they came to through some pain.

But if you say that Common Lisp is great, there are fewer people who have really used it, so fewer people who have used it and didn't like it. And since fewer people got into it unless they really wanted to, it's easier to say "You didn't really understand it, then, or you would have liked it." The number of people who can say "No, I really got it, and I still didn't like it" is relatively small.

So far, that's just demographics. But then you get into the language itself. Java isn't an exciting language. It's not fun. It's kind of corporate and bland. There aren't many people who are really enthusiastic about Java - nor does Java give them reason to be.

That's true, I also think Java is most people's job, and your job is never as exciting as your side project. That said, I am quite excited about Java and maybe especially advancements in the JVM even though part of my job is in Java.

GraalVM is doing some amazing things with polyglot support and native compilation.

Java's project Loom is trying to bring fibers in a really nice way to the language.

It is slowly working on bringing value types and inline types as well.

And it's got a few cool GCs being experimented on, as well as a nice foreign memory API.

Java recently got really nice improvements, multi-line strings, text blocks, local type inference, a shell, running code from source scripts and switch expressions.

My favorite thing about Java (well, I guess more of the JVM ecosystem) is that there is a battle tested, production ready canonical package for just about anything that you could imagine. And that there is a battle tested, canonical way to get that package onto your system and into your build .

But leaving OCaml for F# is a bit like leaving Scheme for Common Lisp. Most of the underlying ideas are largely the same.

Moving from OCaml to C++ or Go would be a drastic and surprising change, but it's not nearly like that.

Not really sure that's a close comparison. From a language semantics perspective, yes, OCaml and F# are very similar. But F# has access to all of .NET, so you aren't going to be at a loss for libraries -- which is probably the biggest challenge in using OCaml in production, as discussed in the OP.

Isn’t it more like leaving Scheme for Clojure?

It's (way) more like leaving Scheme for Clojure.

OP here. I don't mean this to be negative, this is just my ongoing developer blog to keep the Dark community appraised about what's going on.

There's some really great stuff about OCaml. I don't think we could have gotten through the first 2 years without OCaml, we repeatedly made very large scale changes to what our product was and how it worked, and that would have been 10x harder in something else.

I actually think OCaml stands to be in a great place in the next few years with the work being done by core community members. See https://twitter.com/patricoferris/status/1323330884515356672.

so if you already had experience with Rust/etc, why did you decide to choose OCaml?

Also why not to choose F#/Mono (and now .NET core) for example?

I wouldn't say I had experience with Rust, tbh (1 day in 2010 doesn't count!)

I don't remember considering F#, so probably just never occurred to me.

thanks for sharing, I find this really informative.

Expecting open source developers to write a well-tested proprietary SDK for a vendor is going to be hard ask. If you need that and unwilling to do/fund the work yourself, just stick with vendor supported languages.

I would turn this around. As a guy who was doing OSS here and there (and still got burned out by doing only a little) I completely sympathize that nobody should ever expect people to do important work for free. Absolutely.

At the same time, it's a good response when somebody muses in a saddened manner "I wish my favourite language was more popular". Then I can spring out of the bush and tell them why it isn't. This doesn't mean I expect the OSS community around the language to serve me -- of course not! But it's a good explanation on why language X isn't more commercially popular.

I want to see more negative sentiment rust and go posts.