3 ms·
> Though I have to say, I don't really see what Go buys you over something like OCaml, which is still very explicit (in many ways more so than Go) while still p
by Kamq 3y ago
> Though I have to say, I don't really see what Go buys you over something like OCaml, which is still very explicit (in many ways more so than Go) while still providing powerful abstraction facilities.
I mean, the thing it provides is that it doesn't provide powerful abstraction facilities. There's a fundamental limit to how bad the code can get. You can wind up with really gronky code, but you can't experience the horrible abstraction collapse that is experienced in extension heavy OO programming or certain flavors of functional programming.
You also can't get the heights of truly amazing abstractions, but that's a trade-off a lot of devs are willing to make.
Edit: I should clarify. The above reasoning is generally only true for enterprise projects. I'm a pretty big advocate for go in enterprise settings for the above reason as well. But in my own time, when I'm programming for fun, I tend to go with elixir/common lisp/scala or something else fun.
- wtetzner 3y ago> I mean, the thing it provides is that it doesn't provide powerful abstraction facilities. There's a fundamental limit to how bad the code can get. Right, and I'm suggesting that Go isn't an improvement over OCaml in that regard. The abstraction facilities on OCaml are very explicit/non-magical. It basically comes down to parametric polymorphism (which I think Go finally has now? Or will soon?) and the module system/functors.
- Kamq 3y ago> The abstraction facilities on OCaml are very explicit/non-magical. I'm talking about PPXs when I talk about magic in ocaml.