3 ms·

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 Kotl

by 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.

by avl999 5y ago

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.