| > 3. Enough of a type system to catch typos, but not enough to bog you down in mental gymnastics on how to solve every problem perfectly. And definitely not enough to slow down builds and your iteration/test cycle. I think the second part (not enough to slow down builds and your iteration/test cycle) is a false dichotomy between "languages that have 'advanced' type systems" and "language that compiles fast". OCaml has a more "advanced" type system than Go, and still compiles really fast. My understanding is that both have influence from Pascal and its descendants, and Pascal made some tradeoffs to ensure fast compile times. For example, OCaml has no forward definitions. I used the word "advanced" here but I'm not sure if it's the correct one, as in I don't want to imply that one is better than the other. Maybe "fuller" could work too, but it sounds very weird to me. Complete maybe? To continue on why I think OCaml is a good choice, replying to your points: 1. Sensible defaults are definitely missing in some parts, though with frameworks like Dream (https://aantron.github.io/dream/) this is less of a problem. There are small things missing in Go, like CSRF prevention. Where you have a point is that you don't have a big transition from "writing Go code" to "using a framework", which is a problem that can lead to analysis paralysis in other languages. With Go, you can just start with Go. 2. No ecosystem churn: This is a bit of a hard one. I feel like "churn" in OCaml is closer to the one in Go, adding things that are actually needed and after having a good understanding of the problem. For example, OCaml is adding multicore, and doing it in a backwards-compatible way. I feel like the approach is a lot like generics in Go: existing code will continue to work, code that went around this feature before will probably need to be rewritten, but that's for the better. 4. This is the big one. Concurrency in Go is a pleasure. You can write direct-style code, maybe put a channel or a waitgroup or something and everything just works. This is a point where OCaml is not as good as Go. Concurrency works with colored functions/monads (they're the same thing), like in many other languages, or just plain old threads. Multicore may allow people to build a preemptive multitasking runtime, just like in Go, but it's not there yet. For the other stuff: Dev tooling is not as "intergrated" as with Go, probably not as good, but the language server, package manager and build tool are all good. The debugger is a pleasure to use, and having a shell/toplevel/REPL is great. Performance is great. Not as good as Go (though it does beat it in a few benchmarks on the multicore branch for HTTP servers), but still better than almost all of scripting languages, especially the popular ones. As for OSes, it's mostly good on Linux. The windows support is so-so, the mac support too. Lastly, for the learning experience, it's hard to say. I find it harder to learn something in OCaml, in that it forces me to understand what I'm doing more than with other languages. This can be frustrating at times, but also deeply rewarding. |