4 ms·

Sounds like you just want a statically typed language, because you've been scarred by Python. I'm sorry that you had to deal with what sounds like poorly mainta

by kubb 5y ago

Sounds like you just want a statically typed language, because you've been scarred by Python. I'm sorry that you had to deal with what sounds like poorly maintained medium or large Python code base. After you get some experience with Go, you might want to explore other modern statically typed programming languages (I suggest Kotlin and Rust). When you know the strengths and weaknesses of each, you'll be able to pick the best one for the job. And the concepts learned often translate from one language to the other, which will make it easier to pick up new ones in the future.

avl999 5y ago
Rust does not solve the problems that I deal with in the kind of work I do. I have no interest in picking up Kotlin. Java/Go/C# solve all the problems that Kotlin solves without the interop headaches and I pick between them for production code depending on the team and the platform we are targeting. For the projects that I am working on right now I specifically want Go because of its faster startup time than Java/C# and the ability to spin up 10s of thousands of threads without breaking up sweat which is needed for the sort of work I currently do.
- kubb 5y ago
  The constraints of fast startup + "green threads" + easy deployment are actually a sound argument for using Go. The simplicity of the language isn't. Kotlin and Rust also have the "green threads" [1] that Java lacks, both of them can also produce a native binary giving you fast startup. So the claim that "Java solves all the problems that Kotlin does" is not completely true. Finally both Kotlin and Rust can let you write safer concurrent code, because their type systems actually can enforce constraints on what's shared between threads, and what's immutable and safe to accesss. Go gives you nothing in the type system, but there is a thread sanitizer. [1] Here's a Kotlin program that spins up 100K coroutines: https://github.com/Kotlin/kotlinx.coroutines/blob/master/kotlinx-coroutines-core/jvm/test/guide/example-basic-06.kt https://github.com/Kotlin/kotlinx.coroutines/blob/master/kot...
  - vips7L 5y ago
    Here's a Java program that spins up 1 million virtual threads: https://webtide.com/do-looms-claims-stack-up-part-1/ https://webtide.com/do-looms-claims-stack-up-part-1/
    - kubb 5y ago
      Yes, Loom is an exploratory project to enable this, as far as I know, it is not a part of the mainstream Java release yet.
  - throwaway894345 5y ago
    > The simplicity of the language isn't. There’s a pretty strong consensus among people who have used Go professionally (irrespective of whether or not they liked the language on balance) that the ability to look at any project and immediately understand it is a Good Thing, and this property follows directly from the language’s simplicity. That doesn’t mean it outweighs all other criteria—we can say that there is a tradeoff between readability and expressability or something like that—but it absolutely follows that simplicity is a merit. To boot, some other things that I would prioritize well above any particular type system feature set (at least features in excess of what Go provides) include: ecosystem, reproducible build tooling, general tooling, performance, a solid standard library, friendly community, static compilation by default, easy learning curve. Note that “tooling” must also be simple to be a boon—I don’t want to have to learn a DSL to script my dependencies, wire up test targets, build static artifacts, etc.
hu3 5y ago
Why am I not surprised that such low level of passive-aggressive attacks on Go are coming from a Rust enthusiast. I don't understand this stance. It's as if they feel threatened by Go when in reality Go doesn't even try to compete in Rust's niche. They sit distant appart in many spectrums. It's hardly constructive comparing these two languages due to their different objectives. Yet there's this constant belittling of Go as if it was a menace to Rust somehow. In professional environments, this kind of emotionally loaded tribalistic judgement has not place. Much less in engineering. This problem has even been acknowledged by a moderator on HN: https://news.ycombinator.com/item?id=26732757 https://news.ycombinator.com/item?id=26732757 > Here's a take: Go is a language for engineering managers who occasionally contribute a ten liner. You can learn just enough in between your many meetings to make a simple change. You can feel proud and happy with how easy it was for you to contribute. And you can dump the verbose, repetitive drudgery onto the people below you in the org chart, it's their job to deal with this after all. But in a language that you can easily understand, you'll make sure to push for that.

by kubb 5y ago

avl999 5y ago

Rust does not solve the problems that I deal with in the kind of work I do. I have no interest in picking up Kotlin. Java/Go/C# solve all the problems that Kotlin solves without the interop headaches and I pick between them for production code depending on the team and the platform we are targeting. For the projects that I am working on right now I specifically want Go because of its faster startup time than Java/C# and the ability to spin up 10s of thousands of threads without breaking up sweat which is needed for the sort of work I currently do.

kubb 5y ago
The constraints of fast startup + "green threads" + easy deployment are actually a sound argument for using Go. The simplicity of the language isn't. Kotlin and Rust also have the "green threads" [1] that Java lacks, both of them can also produce a native binary giving you fast startup. So the claim that "Java solves all the problems that Kotlin does" is not completely true. Finally both Kotlin and Rust can let you write safer concurrent code, because their type systems actually can enforce constraints on what's shared between threads, and what's immutable and safe to accesss. Go gives you nothing in the type system, but there is a thread sanitizer. [1] Here's a Kotlin program that spins up 100K coroutines: https://github.com/Kotlin/kotlinx.coroutines/blob/master/kotlinx-coroutines-core/jvm/test/guide/example-basic-06.kt https://github.com/Kotlin/kotlinx.coroutines/blob/master/kot...
- vips7L 5y ago
  Here's a Java program that spins up 1 million virtual threads: https://webtide.com/do-looms-claims-stack-up-part-1/ https://webtide.com/do-looms-claims-stack-up-part-1/
  - kubb 5y ago
    Yes, Loom is an exploratory project to enable this, as far as I know, it is not a part of the mainstream Java release yet.
- throwaway894345 5y ago
  > The simplicity of the language isn't. There’s a pretty strong consensus among people who have used Go professionally (irrespective of whether or not they liked the language on balance) that the ability to look at any project and immediately understand it is a Good Thing, and this property follows directly from the language’s simplicity. That doesn’t mean it outweighs all other criteria—we can say that there is a tradeoff between readability and expressability or something like that—but it absolutely follows that simplicity is a merit. To boot, some other things that I would prioritize well above any particular type system feature set (at least features in excess of what Go provides) include: ecosystem, reproducible build tooling, general tooling, performance, a solid standard library, friendly community, static compilation by default, easy learning curve. Note that “tooling” must also be simple to be a boon—I don’t want to have to learn a DSL to script my dependencies, wire up test targets, build static artifacts, etc.

hu3 5y ago

Why am I not surprised that such low level of passive-aggressive attacks on Go are coming from a Rust enthusiast. I don't understand this stance. It's as if they feel threatened by Go when in reality Go doesn't even try to compete in Rust's niche. They sit distant appart in many spectrums. It's hardly constructive comparing these two languages due to their different objectives. Yet there's this constant belittling of Go as if it was a menace to Rust somehow. In professional environments, this kind of emotionally loaded tribalistic judgement has not place. Much less in engineering. This problem has even been acknowledged by a moderator on HN: https://news.ycombinator.com/item?id=26732757 https://news.ycombinator.com/item?id=26732757 > Here's a take: Go is a language for engineering managers who occasionally contribute a ten liner. You can learn just enough in between your many meetings to make a simple change. You can feel proud and happy with how easy it was for you to contribute. And you can dump the verbose, repetitive drudgery onto the people below you in the org chart, it's their job to deal with this after all. But in a language that you can easily understand, you'll make sure to push for that.