4 ms·

Ugh, nooooooo, not Go. I'll stay on 1.x, thank you very much. I hope there will be a well maintained fork of 1.x.

by floatboth 7y ago

packetlost 7y ago
What's wrong with Go?
- floatboth 7y ago
  Weirdest toolchain in the world, at least among popular ones. Custom calling convention, custom (AWFUL) assembler, insistence on using syscalls directly on systems where the libc is the only officially public API (FreeBSD), bad portability as a result (I tried to add FreeBSD/aarch64, it was an awful experience, thankfully others have continued the work). Don't tell me about gccgo, it mostly copies the standard library from the main implementation, so it also uses syscalls directly. Just look at https://github.com/minio/asm2plan9s https://github.com/minio/asm2plan9s / https://github.com/minio/c2goasm https://github.com/minio/c2goasm — carefully read the readme and understand what this hack does. If the existence of this hack does not make you extremely angry at Go, I don't know what will. Oh and I don't like the language itself either. The anti-intellectual attitude of the designers sucks. "Screw anything discovered by PL research in the last 30 years, we just want everything like in the good old days with C but with GC and concurrency" is just silly. The "developers are too stupid to use smart features like generics" attitude is quite offensive. (I guess they are responding to the overwhelming demand for generics now, but it's not like they had a big change of heart, it's just caving to external pressure, not personally embracing the concepts)
  - api 7y ago
    > The anti-intellectual attitude of the designers sucks. "Screw anything discovered by PL research in the last 30 years, we just want everything like in the good old days with C but with GC and concurrency" is just silly. The "developers are too stupid to use smart features like generics" attitude is quite offensive. It's not anti-intellectual. It's just reasoning from a different set of premises. Go is remarkably productive. I've written extremely complex software in it and found that I rarely miss that stuff. I do agree that it needs some limited/minimal generics support for data structures and algorithms, but that's about all I would add. I think it shows that a lot of the stuff that's been explored in the last 30 years in languages just isn't necessary. Go is not a language for showing off how smart you are with esoteric language constructs. It's a language for getting things done with minimal cognitive load across the problem domain. http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer.html http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer.... Go is for people who have made it to at least apprentice hacker in that progression and realized that complexity is evil. Complexity should only be added when one is dragged kicking and screaming into it by the inherent complexity of the problem domain, and even then only after exploring ways of avoiding it. I applaud Go's designers for doing that at the language level. They're being dragged into generics after exploring all possible ways of avoiding generics, which is the right approach. They also bailed on an idea to add unnecessary syntactic sugar to error handling in Go because it isn't necessary. It saves a small amount of typing in exchange for increased cognitive load, and cognitive load is more expensive than keystrokes.
    - floatboth 7y ago
      I'd say `if err != nil {}` all the time is an awful lot of cognitive load. Heck, just `nil` turns everything into a minefield. Functional programming constructs rarely add complexity, they are excellent tools for handling and reducing it.
      - api 7y ago
        > is an awful lot of cognitive load. I disagree. It's a lot of text, but cognitively it's trivial to understand. A more terse language construct that moves logic around requires more thought to comprehend even if it takes up less space on the screen. Computers are fast. Screens are big. Our brains are overwhelmed and limited.

Ugh, nooooooo, not Go. I'll stay on 1.x, thank you very much. I hope there will be a well maintained fork of 1.x.

packetlost 7y ago

What's wrong with Go?

floatboth 7y ago
Weirdest toolchain in the world, at least among popular ones. Custom calling convention, custom (AWFUL) assembler, insistence on using syscalls directly on systems where the libc is the only officially public API (FreeBSD), bad portability as a result (I tried to add FreeBSD/aarch64, it was an awful experience, thankfully others have continued the work). Don't tell me about gccgo, it mostly copies the standard library from the main implementation, so it also uses syscalls directly. Just look at https://github.com/minio/asm2plan9s https://github.com/minio/asm2plan9s / https://github.com/minio/c2goasm https://github.com/minio/c2goasm — carefully read the readme and understand what this hack does. If the existence of this hack does not make you extremely angry at Go, I don't know what will. Oh and I don't like the language itself either. The anti-intellectual attitude of the designers sucks. "Screw anything discovered by PL research in the last 30 years, we just want everything like in the good old days with C but with GC and concurrency" is just silly. The "developers are too stupid to use smart features like generics" attitude is quite offensive. (I guess they are responding to the overwhelming demand for generics now, but it's not like they had a big change of heart, it's just caving to external pressure, not personally embracing the concepts)
- api 7y ago
  > The anti-intellectual attitude of the designers sucks. "Screw anything discovered by PL research in the last 30 years, we just want everything like in the good old days with C but with GC and concurrency" is just silly. The "developers are too stupid to use smart features like generics" attitude is quite offensive. It's not anti-intellectual. It's just reasoning from a different set of premises. Go is remarkably productive. I've written extremely complex software in it and found that I rarely miss that stuff. I do agree that it needs some limited/minimal generics support for data structures and algorithms, but that's about all I would add. I think it shows that a lot of the stuff that's been explored in the last 30 years in languages just isn't necessary. Go is not a language for showing off how smart you are with esoteric language constructs. It's a language for getting things done with minimal cognitive load across the problem domain. http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer.html http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer.... Go is for people who have made it to at least apprentice hacker in that progression and realized that complexity is evil. Complexity should only be added when one is dragged kicking and screaming into it by the inherent complexity of the problem domain, and even then only after exploring ways of avoiding it. I applaud Go's designers for doing that at the language level. They're being dragged into generics after exploring all possible ways of avoiding generics, which is the right approach. They also bailed on an idea to add unnecessary syntactic sugar to error handling in Go because it isn't necessary. It saves a small amount of typing in exchange for increased cognitive load, and cognitive load is more expensive than keystrokes.
  - floatboth 7y ago
    I'd say `if err != nil {}` all the time is an awful lot of cognitive load. Heck, just `nil` turns everything into a minefield. Functional programming constructs rarely add complexity, they are excellent tools for handling and reducing it.
    - api 7y ago
      > is an awful lot of cognitive load. I disagree. It's a lot of text, but cognitively it's trivial to understand. A more terse language construct that moves logic around requires more thought to comprehend even if it takes up less space on the screen. Computers are fast. Screens are big. Our brains are overwhelmed and limited.