5 ms·

> It does nothing better than any of the existing mainstream languages... Why say this? Even if you don't like Go it's objectively false. What languages are yo

by kbd 8y ago

> It does nothing better than any of the existing mainstream languages... Why say this? Even if you don't like Go it's objectively false. What languages are you comparing it to, Java? C++?

meddlepal 8y ago
Java and Python. It's two closest peers. Go does not compete with C or C++ in my mind because of GC. The ONLY thing it does better is packaging because of its standalone native binaries. But most folks using Go are writing software for servers and those are predominantly Linux x86_64... so ¯\_(ツ)_/¯
- AsyncAwait 8y ago
  > Java and Python. It's two closest peers. See, I don't particularly enjoy Go, but that's because of its weak type system, which Python is no better at. Still, I understand that a lot of people enjoy Python, so good that it exists. Java is too verbose. I'd had understood if you have said Kotlin, but Java is not that much better, (yes, it has generics, but I myself prefer the way they're implemented in Rust/Swift). I feel like your examples are not much better than Go and in some ways may be worse, (concurrency?). If you have said Rust, Swift, Scala, Kotlin...I still wouldn't want Go to die, but at least could get behind the argument.
  - meddlepal 8y ago
    I like Kotlin and I write a lot of Kotlin for personal stuff, but I think it is a niche language in the backend/server space and hardly qualifies as mainstream outside Android. Python with PEP484 is pleasant. The concurrency story in Java is great already and it is going to improve once Project Loom is integrated. I fail to see how Java is significantly more verbose than Go. At least not the core libraries. The ecosystem is a mess but getting better. Java 11 with `var` for local variable inference is pretty much on par with Go in terms of verbosity. Rust brings a lot of new things to the table but its main competitor IMO is C and C++. I've done very little Rust but what I have seen I like (though there are some things I dislike too... like lack of keyword args... a minor nit I suppose). Scala is a shit show to maintain with some teams.
    - AsyncAwait 8y ago
      > Python with PEP484 is pleasant. Not yet, I use types as an important form of documentation, so the vast majority of the library ecosystem would need to adopt optional types before I'd consider it so. > Java 11 Not may people actually write Java 11 at work, most are stuck with 8, or even 6. Java 11 is basically even less mainstream than Kotlin right now, as not even Android supports it. > is pretty much on par with Go in terms of verbosity Yeah, but on par is not good enough, it has to be significantly better for your argument to work. Yet I don't see you calling for the eradication of Java. Also, gofmt makes it significantly easier to get familiar with a foreign Go codebase. Not a thing in the Java world. And not having to suffer the JVM startup time + having static binaries is indeed a real win for some. > Scala is a shit show to maintain with some teams. Yeah, it's a kitchen sink. Kotlin I like a lot better in this regard. But then everything can be a shit show with some teams. P.S. Rust is getting rather good for writing web servers and with things like rocket.rs & aync/await, I think it'll be a real contender.
      - meddlepal 8y ago
        > significantly better for your argument to work. No you misinterpreted my point. It has to be significantly better than what already exists at the time of creation. Java was this to C++ in the 90s and early 2000s. Go is not that language.
        AsyncAwait 8y ago
        Go can serve as a sort of Java to people who don't want the JVM. There's no rule that says only one language is allowed in a particular space. Go has several strong points and several weaknesses, which are to be addressed in Go 2. Java didn't have lambdas until 8 and now it does. Its generics implementation is not what I'd like to see. Still, it certainly has its place. Go has been used to implement widely used technologies like Docker & k8, so it seems to have found its justification for existing as well.
virmundi 8y ago
What would you say Go does objectively better? I think you might say threading. Maybe? The JVM can be tuned to get similar performance. Where it fails to get similar threading performance, it has better tuning in general. Simplicity of the language? Maybe? It's simple, but I think it's too simple. One of my issues with Go is that it's hard to tell what implements what. VSC support is a little hit or miss. The fact that I have to use an IDE, or extension pack in VIM/Emacs, to figure this out is terrible. I like that in C++, Java, Python, C#, and Typescript I can clearly see which things a current struct implements. It makes code navigation easier. The lack of generics makes certain natural, and I mean natural as in how the majority of other languages do things, solutions to problems hard. Do you want a set, i.e. a unique collection of things? Use a map, but keep in mind that equality is at the whole struct level so one field being off and you have logical duplicates. You can't make structs immutable. Community lead structural design? Most Go apps appear to be transaction scripts where the database connection is created at the handler and explicitly passed down or perhaps buried in a Context. This makes testing hard. You have to mock/stub the DB interface to test business logical. If I want to introduce interfaces that wrap the DB away, I'm told by the community that I'm "overthinking things" or I'm not a true gopher. Produces a binary? I agree.

by kbd 8y ago

> It does nothing better than any of the existing mainstream languages... Why say this? Even if you don't like Go it's objectively false. What languages are you comparing it to, Java? C++?

meddlepal 8y ago

Java and Python. It's two closest peers. Go does not compete with C or C++ in my mind because of GC. The ONLY thing it does better is packaging because of its standalone native binaries. But most folks using Go are writing software for servers and those are predominantly Linux x86_64... so ¯\_(ツ)_/¯

AsyncAwait 8y ago
> Java and Python. It's two closest peers. See, I don't particularly enjoy Go, but that's because of its weak type system, which Python is no better at. Still, I understand that a lot of people enjoy Python, so good that it exists. Java is too verbose. I'd had understood if you have said Kotlin, but Java is not that much better, (yes, it has generics, but I myself prefer the way they're implemented in Rust/Swift). I feel like your examples are not much better than Go and in some ways may be worse, (concurrency?). If you have said Rust, Swift, Scala, Kotlin...I still wouldn't want Go to die, but at least could get behind the argument.
- meddlepal 8y ago
  I like Kotlin and I write a lot of Kotlin for personal stuff, but I think it is a niche language in the backend/server space and hardly qualifies as mainstream outside Android. Python with PEP484 is pleasant. The concurrency story in Java is great already and it is going to improve once Project Loom is integrated. I fail to see how Java is significantly more verbose than Go. At least not the core libraries. The ecosystem is a mess but getting better. Java 11 with `var` for local variable inference is pretty much on par with Go in terms of verbosity. Rust brings a lot of new things to the table but its main competitor IMO is C and C++. I've done very little Rust but what I have seen I like (though there are some things I dislike too... like lack of keyword args... a minor nit I suppose). Scala is a shit show to maintain with some teams.
  - AsyncAwait 8y ago
    > Python with PEP484 is pleasant. Not yet, I use types as an important form of documentation, so the vast majority of the library ecosystem would need to adopt optional types before I'd consider it so. > Java 11 Not may people actually write Java 11 at work, most are stuck with 8, or even 6. Java 11 is basically even less mainstream than Kotlin right now, as not even Android supports it. > is pretty much on par with Go in terms of verbosity Yeah, but on par is not good enough, it has to be significantly better for your argument to work. Yet I don't see you calling for the eradication of Java. Also, gofmt makes it significantly easier to get familiar with a foreign Go codebase. Not a thing in the Java world. And not having to suffer the JVM startup time + having static binaries is indeed a real win for some. > Scala is a shit show to maintain with some teams. Yeah, it's a kitchen sink. Kotlin I like a lot better in this regard. But then everything can be a shit show with some teams. P.S. Rust is getting rather good for writing web servers and with things like rocket.rs & aync/await, I think it'll be a real contender.
    - meddlepal 8y ago
      > significantly better for your argument to work. No you misinterpreted my point. It has to be significantly better than what already exists at the time of creation. Java was this to C++ in the 90s and early 2000s. Go is not that language.
      - AsyncAwait 8y ago
        Go can serve as a sort of Java to people who don't want the JVM. There's no rule that says only one language is allowed in a particular space. Go has several strong points and several weaknesses, which are to be addressed in Go 2. Java didn't have lambdas until 8 and now it does. Its generics implementation is not what I'd like to see. Still, it certainly has its place. Go has been used to implement widely used technologies like Docker & k8, so it seems to have found its justification for existing as well.

virmundi 8y ago

What would you say Go does objectively better? I think you might say threading. Maybe? The JVM can be tuned to get similar performance. Where it fails to get similar threading performance, it has better tuning in general. Simplicity of the language? Maybe? It's simple, but I think it's too simple. One of my issues with Go is that it's hard to tell what implements what. VSC support is a little hit or miss. The fact that I have to use an IDE, or extension pack in VIM/Emacs, to figure this out is terrible. I like that in C++, Java, Python, C#, and Typescript I can clearly see which things a current struct implements. It makes code navigation easier. The lack of generics makes certain natural, and I mean natural as in how the majority of other languages do things, solutions to problems hard. Do you want a set, i.e. a unique collection of things? Use a map, but keep in mind that equality is at the whole struct level so one field being off and you have logical duplicates. You can't make structs immutable. Community lead structural design? Most Go apps appear to be transaction scripts where the database connection is created at the handler and explicitly passed down or perhaps buried in a Context. This makes testing hard. You have to mock/stub the DB interface to test business logical. If I want to introduce interfaces that wrap the DB away, I'm told by the community that I'm "overthinking things" or I'm not a true gopher. Produces a binary? I agree.