3 ms·

Minimalist would love go. It is hard to over engineer when there's no inheritance, no meta classes, no properties, iterators, decorators and such. I've seen pr

by wg0 3y ago

Minimalist would love go. It is hard to over engineer when there's no inheritance, no meta classes, no properties, iterators, decorators and such. I've seen pretty convoluted code bases otherwise that showcase the engineering muscle of the individual and how they can employ almost every single language feature even to a very narrow business domain.

masklinn 3y ago
> Minimalist would love go. That is an assertion which makes no sense to me. Go is not a minimalist language, it's a restrictive one. Although it made different choices, it's in the same vein as Java, and certainly no Forth, or Smalltalk. > It is hard to over engineer when there's no inheritance, no meta classes, no properties, iterators, decorators and such. None of that has anything to do with over engineering?
- logicchains 3y ago
  >None of that has anything to do with over engineering? Most over-engineering in the wild overuses inheritance. That's why we see more monstrous "enterprise" code in Java and C# than languages like Go and Rust that lack inheritance.
  - kaba0 3y ago
    > That's why we see more monstrous "enterprise" code in Java and C# than languages like Go and Rust that lack inheritance. Rust has a completely different niche, and maybe wait a bit before claiming anything like that about Go - it is not being used for that kind of enterprise systems just yet.
- bitshiftfaced 3y ago
  I'm not sure here how you differentiate minimalist from restrictive. I've always considered Go to be minimalist in terms of available tokens to the programmer: https://github.com/e3b0c442/keywords/blob/main/chart.png https://github.com/e3b0c442/keywords/blob/main/chart.png
  - masklinn 3y ago
    > I'm not sure here how you differentiate minimalist from restrictive. The flexibility of the language and its syntax. The more constructs are syntactic, the less minimalistic it is, and Go is a very syntactic language. > I've always considered Go to be minimalist in terms of available tokens to the programmer: https://github.com/e3b0c442/keywords/blob/main/chart.png https://github.com/e3b0c442/keywords/blob/main/chart.png No language on this chart has even a passing resemblance to minimalistic. I don't think anything does when it reaches double digit keywords. For reference, I believe Smalltalk has 6. And forth is more complicated because it doesn't really have keywords at all, and barely any syntax, instead it has assembly-coded / runtime-provided words (~functions) and variables. SectorForth (https://github.com/cesarblum/sectorforth/ https://github.com/cesarblum/sectorforth/) is down to 8 builtin words, 2 IO words, and 5 variables (milliforth packs those behind a word instead). And so far 2 of the words have been found unnecessary / redundant.
  - xigoi 3y ago
    Minimalism isn't about irrecoverably lacking features, but about allowing you to build any feature you want from a small set of primitives.
- yencabulator 3y ago
  You've been presented with some minimalist Scandinavian design furniture and your argument is a true minimalist would never have furniture...
  - masklinn 3y ago
    > You've been presented with some minimalist Scandinavian design furniture your argument is a true minimalist would never have furniture... You're not making any sense, and you're not providing any sort of argument either.
- wg0 3y ago
  What restrictive and how? Whole cluster orchestrators have been built with go (k8s, nomad), whole databases have been built with go (cockroachhDB), whole authentication systems have been built with go (zitadel, authelia), whole web servers have been built with go (Caddy, Traefik), whole DNS servers have been built with go (CoreDNS), whole key value stores have been built with go (etcd), some encryption has been built with go (age) so how it is restrictive and why didn't it restrict all those use cases? Not to mention, if you every spawned a container, there are 99.9% chances that somewhere go was involved along the way. There are other run times around (rust comes to mind) but none is production ready. Point is - restrictive should have restricted. It hasn't Minimalist isn't restrictive. EDIT: Added docker and restrictive not the same as minimal.
  - masklinn 3y ago
    > What restrictive and how? The language is restrictive, in that you can't "play" with the language, it has a very fixed syntax / structure and no real way to make your own, much like Java or C#: no macros, limited runtime reflection (to say nothing of wholesale manipulation), control structures are heavily syntactic, etc... Hell, the designers built in a bunch of collections and behaviour (and special syntax) around those collections because they either did not want to or could not be arsed to make the language able to express them. > Whole cluster orchestrators have been built with go (k8s, nomad), whole databases have been built with go (cockroachhDB), whole authentication systems have been built with go (zitadel, authelia), whole web servers have been built with go (Caddy, Traefik), whole DNS servers have been built with go (CoreDNS), whole key value stores have been built with go (etcd), some encryption has been built with go (age) so how it is restrictive and why didn't it restrict all those use cases? That has nothing to do with anything? Literally all you're stating is "the language is turing complete therefore it can't be restrictive". > Minimalist isn't restrictive. No, it's not. And neither is the reverse. And go is restrictive, not minimalist.
  - kaba0 3y ago
    Your comment only proves that one can write useful software with a restrictive language.
dlock17 3y ago
Iterators are coming. But I think taking very long on adding features such as generics and iterators has a positive effect of repelling the ones who over engineer the most. And because this is HN, I have to mention of course you can over engineer current Go as well. But it's not "fun".
- diarrhea 3y ago
  Generics and iterators are over-engineering territory? Oh man…
GaryNumanVevo 3y ago
Really? It's the Go is great if you're staying within the simple confines of the designer's vision, but if you ever need anything beyond that, you have to write some unidiomatic go code that no one will be able to parse. Just look at any JSON parse library, look at struct "annotations" as this massive kludge for injecting struct metadata, etc. I've been programming in Go professionally for 6 years, and it covers 80% of usecases well, but that last 20% is really tricky

by wg0 3y ago

masklinn 3y ago

> Minimalist would love go. That is an assertion which makes no sense to me. Go is not a minimalist language, it's a restrictive one. Although it made different choices, it's in the same vein as Java, and certainly no Forth, or Smalltalk. > It is hard to over engineer when there's no inheritance, no meta classes, no properties, iterators, decorators and such. None of that has anything to do with over engineering?

logicchains 3y ago
>None of that has anything to do with over engineering? Most over-engineering in the wild overuses inheritance. That's why we see more monstrous "enterprise" code in Java and C# than languages like Go and Rust that lack inheritance.
- kaba0 3y ago
  > That's why we see more monstrous "enterprise" code in Java and C# than languages like Go and Rust that lack inheritance. Rust has a completely different niche, and maybe wait a bit before claiming anything like that about Go - it is not being used for that kind of enterprise systems just yet.
bitshiftfaced 3y ago
I'm not sure here how you differentiate minimalist from restrictive. I've always considered Go to be minimalist in terms of available tokens to the programmer: https://github.com/e3b0c442/keywords/blob/main/chart.png https://github.com/e3b0c442/keywords/blob/main/chart.png
- masklinn 3y ago
  > I'm not sure here how you differentiate minimalist from restrictive. The flexibility of the language and its syntax. The more constructs are syntactic, the less minimalistic it is, and Go is a very syntactic language. > I've always considered Go to be minimalist in terms of available tokens to the programmer: https://github.com/e3b0c442/keywords/blob/main/chart.png https://github.com/e3b0c442/keywords/blob/main/chart.png No language on this chart has even a passing resemblance to minimalistic. I don't think anything does when it reaches double digit keywords. For reference, I believe Smalltalk has 6. And forth is more complicated because it doesn't really have keywords at all, and barely any syntax, instead it has assembly-coded / runtime-provided words (~functions) and variables. SectorForth (https://github.com/cesarblum/sectorforth/ https://github.com/cesarblum/sectorforth/) is down to 8 builtin words, 2 IO words, and 5 variables (milliforth packs those behind a word instead). And so far 2 of the words have been found unnecessary / redundant.
- xigoi 3y ago
  Minimalism isn't about irrecoverably lacking features, but about allowing you to build any feature you want from a small set of primitives.
yencabulator 3y ago
You've been presented with some minimalist Scandinavian design furniture and your argument is a true minimalist would never have furniture...
- masklinn 3y ago
  > You've been presented with some minimalist Scandinavian design furniture your argument is a true minimalist would never have furniture... You're not making any sense, and you're not providing any sort of argument either.
wg0 3y ago
What restrictive and how? Whole cluster orchestrators have been built with go (k8s, nomad), whole databases have been built with go (cockroachhDB), whole authentication systems have been built with go (zitadel, authelia), whole web servers have been built with go (Caddy, Traefik), whole DNS servers have been built with go (CoreDNS), whole key value stores have been built with go (etcd), some encryption has been built with go (age) so how it is restrictive and why didn't it restrict all those use cases? Not to mention, if you every spawned a container, there are 99.9% chances that somewhere go was involved along the way. There are other run times around (rust comes to mind) but none is production ready. Point is - restrictive should have restricted. It hasn't Minimalist isn't restrictive. EDIT: Added docker and restrictive not the same as minimal.
- masklinn 3y ago
  > What restrictive and how? The language is restrictive, in that you can't "play" with the language, it has a very fixed syntax / structure and no real way to make your own, much like Java or C#: no macros, limited runtime reflection (to say nothing of wholesale manipulation), control structures are heavily syntactic, etc... Hell, the designers built in a bunch of collections and behaviour (and special syntax) around those collections because they either did not want to or could not be arsed to make the language able to express them. > Whole cluster orchestrators have been built with go (k8s, nomad), whole databases have been built with go (cockroachhDB), whole authentication systems have been built with go (zitadel, authelia), whole web servers have been built with go (Caddy, Traefik), whole DNS servers have been built with go (CoreDNS), whole key value stores have been built with go (etcd), some encryption has been built with go (age) so how it is restrictive and why didn't it restrict all those use cases? That has nothing to do with anything? Literally all you're stating is "the language is turing complete therefore it can't be restrictive". > Minimalist isn't restrictive. No, it's not. And neither is the reverse. And go is restrictive, not minimalist.
- kaba0 3y ago
  Your comment only proves that one can write useful software with a restrictive language.

dlock17 3y ago

Iterators are coming. But I think taking very long on adding features such as generics and iterators has a positive effect of repelling the ones who over engineer the most. And because this is HN, I have to mention of course you can over engineer current Go as well. But it's not "fun".

diarrhea 3y ago
Generics and iterators are over-engineering territory? Oh man…

GaryNumanVevo 3y ago

Really? It's the Go is great if you're staying within the simple confines of the designer's vision, but if you ever need anything beyond that, you have to write some unidiomatic go code that no one will be able to parse. Just look at any JSON parse library, look at struct "annotations" as this massive kludge for injecting struct metadata, etc. I've been programming in Go professionally for 6 years, and it covers 80% of usecases well, but that last 20% is really tricky