4 ms·

> I prefer Go over Lisp on the cover because I prefer the explicit, low magic code of Go with all its boiler plate and using my brain power on business problems

> I prefer Go over Lisp on the cover because I prefer the explicit, low magic code of Go with all its boiler plate and using my brain power on business problems not what makes me more productive or feel better / clever while doing my work. This seems like a false dichotomy. Boilerplate-heavy code is the opposite of focusing on business logic. Incidental complexity ends up being intertwined with business logic everywhere. More powerful languages allow programmers to do clever tricks and make a mess, but they don't require it. Those languages also allow programmers to abstract away incidental complexity and expose business logic more clearly. I think the future of programming languages is going to be in finding a balance that allows powerful abstractions while still making the semantics as clear as possible. 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. It even competes with Go on the compile-time front.

LanceH 3y ago
Go hits that niche of "read from a queue/endpoint, write to a queue/endpoint", and there is an awful lot of that going on. It's just practical for getting (some kinds of) work done. > I don't really see what Go buys you over something like OCaml Easy installation on windows for one.
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.
    - wtetzner 3y ago
      I guess I have a hard time seeing how PPXs are worse than `go generate`.
      - Kamq 3y ago
        My understanding is that PPXs allow arbitrary AST manipulations, which allow syntax extensions, whereas `go generate` just allows code generation.

LanceH 3y ago

Go hits that niche of "read from a queue/endpoint, write to a queue/endpoint", and there is an awful lot of that going on. It's just practical for getting (some kinds of) work done. > I don't really see what Go buys you over something like OCaml Easy installation on windows for one.

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.
  - wtetzner 3y ago
    I guess I have a hard time seeing how PPXs are worse than `go generate`.
    - Kamq 3y ago
      My understanding is that PPXs allow arbitrary AST manipulations, which allow syntax extensions, whereas `go generate` just allows code generation.