I realize I’m asking a biased group, but I figured I would ask anyway, since everyone here presumably knows OCaml and most probably have some notion about Go.
Whenever I think about Go and the main benefits of the language, these things come up:
Small, simple langauge with abstractions that make it a suitable alternative to so-called “scripting” languages.
Unlike aforementioned scripting languages, static typing and explicit error handling make it more reliable at runtime.
Good performance (again, relative to aforementioned scripting langauges)
Super fast compiler
statically linked binaries
Great abstractions and libraries for writing network services.
To me, all of this stuff sounds very much like OCaml, except that OCaml is better in almost all of these areas.
OCaml is simple. I will grant that it is not as simple to learn as Go, but it is certainly an attractive alternative to dynamically typed, interpreted languages with a similar “light weight” feel for the programmer—even moreso than Go. It even has an interactive interpreter.
OCaml has a superior type system to Go and is even more reliable at runtime (because nil). Granted, OCaml does have runtime exceptions, but they can be mostly avoided by using something like Base.
Also good performance.
Also super fast compiler. Perhaps it takes OCaml a little longer to compile an entire program, but incremental compilation makes it up.
Also statically linked binaries. I will admit that cross-compiling is possibly easier with Go.
OCaml is also awesome for writing network services because of its Unix friendliness and all the awesome libraries from MirageOS and friends.
In addition, OCaml has the benefit of being a functional language, having a more flexible and descriptive type system, having global type inference and not being inspired by C in any perceptible way.
What do you think? Is there ever a time when an OCaml programmer would prefer Go for a project?
I don’t use Go, but I think it can make a lot of sense if you need
libraries. The Go ecosystem, when it comes to network services, is much
bigger (and robust) than the OCaml ecosystem.
Languages (and libraries) aren’t chosen in a vacuum. I obviously am biased in my preference for OCaml, but I won’t hesitate to choose Go if working in a project where most people on the team are familiar with the language, and the problem domain has good support within Go (network services is one common example that comes to mind).
EDIT: I’ll add that if for some reason I needed http/2 or Quic for some application today Go would be a better choice than OCaml at the moment since their ecosystem has more options in this space that are robust and well tested.
Context matters a lot. The reality is, languages are almost never chosen for technical merits. It is certainly a factor, but social reasons play a much larger role. Python vs Ruby, from where I stand they are almost indistinguishable but there are heated arguments trying to rationalize one vs the other.
So, for myself? No, I’d never choose Go over Ocaml. I’d probably figure out how to write my own QUIC libraries for Ocaml. But I enjoy writing Ocaml. I enjoy the (small) ecosystem we have. I think for its warts, Ocaml is a great language. It makes me a little happy to sit down and write Ocaml.
But I’m sure if we got a Go person head to head for 8 rounds with an Ocaml person, things like the syntax being ALGOL and thus friendlier would come up as a big selling point of Go. And the ecosystem. And the size of the community.
I worked for a year for a company that used Golang extensively; my job involved maintaining and extending a large Golang system. I then spent a few years consulting on blockchain projects written in Golang. My answer to your question is:
Well, if you need to do it to get paid, then do it.
I can find no other reason for using Golang. It’s a congeries of clever tricks glued-together with toilet paper and baling wire to look like a language design.
I won’t go thru the list of idiocies I encountered while working on Golang, but basically, the argument for Golang comes down to one of those motte-and-bailey switcheroos: the marketing is that it’s a wide-spectrum systems-programming language, but when you run up against the many problems, the answer is that it’s meant only for scripting, so why did you use it as if it were a systems-programming language?
For static cross compilation and static builds maybe.
I left Go some years ago for it’s unreliable sponsor and modern (=volatile) ecosystem and shifted to OCaml for a crypto-heavy web project (ActivityPub). I miss the convenient cross compile, but otherwise am quite happy here. And the community here is welcoming, friendly and competent.
for sysadmin-level code, with little in the way of complex libraries (other than what comes with Golang), sure, Golang will be better. And that’s partially b/c OCaml doesn’t do a good job there – the support for interacting with UNIX and the network isn’t very good. I’m a systems-jock (that’s how I made my living for decades), and this is just a fact.
For anything that requires writing complex libraries, Ocaml will be better.
Golang is a faster Python. That’s all. But hey, it’s also why lots of orgs choose it: because they understand Python, and they think “oh, this is a faster Python”. Sure, makes sense.
Yeah. If you expect to grow your company, you need to be able to hire people who know your tech stack, and the last thing you want to do is to waste money writing libs that already exist in other languages. It’s a pretty simple risk/benefit/effort evaluation.
Yeah, OCaml excels in some domains. But if you’re not writing in that domain, you’re taking a bigger risk than you have to.
I absolutely love OCaml, tho, not saying otherwise. It’ll be interesting to see if Reason/ReScript will make it. Those systems can easily reuse libs from the general JS ecosystem, so the risk is lower.
Maybe so? Rewriting libs that exist in other languages doesn’t seem to have hurt Jane Street any, but I don’t know how applicable the Jane Street story is to any other company or what the cost-benefit analysis is of them having used OCaml for almost everything.
I do think there are cases where OCaml’s type system provides material benefits in terms of runtime reliability, but perhaps these cases are not as frequent or significant as I am inclined to think?
Maybe, but how do you compare this to using a more general code quality tool that also checks for a number of other metrics, like test coverage, code duplicates, churn rate, complexity, tainted strings (XSS, SQL injection if you do web dev), unneeded conditionals? How many such tools are available for Go vs OCaml? If I google for “continuous integration go” vs “continuous integration ocaml”, which has most results?
I remember back at the beginning of the popularization of test-driven development, when people were raving over Ruby-on-Rails, and someone noted that a large proportion of the unit-tests in RoR projects were there b/c of Ruby’s lack of strong static typing. Certainly my recent experience with a large and complex Python project (Qiskit-Terra) confirms that observation.
Sure, code quality tools and methodologies can find problems, can substitute for strong static typing.
As someone who spent decades in the CobolJava slave galleys, I’d rather have the strong static typing, thanks.
Triggered! Not really, but I’m definitely not the kind of person who considers numbers of Google search results when considering a technology. One tool that fits the project requirements is quite enough. I realize it is not always the case that OCaml has even one tool for any given task—but it usually does.
On the contrary @dimitris! I have no choice! I use Python for almost all of my work because it is what we use and occasionally sneak in OCaml for little helper tools that nobody else will ever use. I’m generally interested in programming languages out of personal curiosity, but I have no hope of using anything but Python at my current job. At least you can use type annotations these days (and check them).
It’ll be interesting to see if Reason/ReScript will make it. Those systems can easily reuse libs from the general JS ecosystem, so the risk is lower.
Not really, but I’m definitely not the kind of person who considers numbers of Google search results when considering a technology. One tool that fits the project requirements is quite enough. I realize it is not always the case that OCaml has even one tool for any given task—but it usually does.