5 ms·

The only reason why I am looking at Golang is because of its fast startup and low memory usage. I prefer the Java ecosystem and Kotlin specifically; how is the

The only reason why I am looking at Golang is because of its fast startup and low memory usage. I prefer the Java ecosystem and Kotlin specifically; how is the JVM's progress in this area for serverless, etc?

threeseed 4y ago
There is GraalVM native image [1] which works well. And libraries like Quarkus [2] that leverage it that can launch in < 0.016s with < 12MB of RAM. [1] https://www.graalvm.org/22.0/reference-manual/native-image/ https://www.graalvm.org/22.0/reference-manual/native-image/ [2] https://quarkus.io https://quarkus.io
- dschulz 4y ago
  unfortunately, compilation times are not so good.
  - msgilligan 4y ago
    Well, you do most of your compilation, test, and debug under the JVM and only do final test (and possibly debug) with native compilation.
FlyingSnake 4y ago
How is the generics story going in golang? I wonder if it brought a major paradigm shift in the way Go is written.
- dgunay 4y ago
  It is definitely better than before, but doesn't really change the game much. It has severe limitations. My biggest hope when generics were announced was that we'd finally get an alternative to writing `if err != nil` 10+ times per function, but it doesn't support generic method type parameters. That alone kneecaps it severely by making type-safe method chaining useless in most scenarios (unless you never need to map to another type, ever, I guess. Lucky you.)
- zinclozenge 4y ago
  It's pretty rare you need to write anything generic unless you're writing a library, or library like functionality.
- bbkane 4y ago
  I don't know about a paradigm shift, but the craziest use of them I've seen is https://github.com/jhbrown-veradept/gophercon22-parser-combinators https://github.com/jhbrown-veradept/gophercon22-parser-combi... . I watched the talk, thought I understood it "enough", then completely fell on my face trying to write a JSON parser. Could be me though, maybe I should try it again now that it's been a few months
vbezhenar 4y ago
Not good. Java needs set of microservice libraries reimagined from the ground up. Optimized for size and RAM consumption. Optimized for GraalVM compilation (it's bad, but it's not that bad, libraries make it that bad). Also preferably including new tool for building because Maven and Gradle are bad. I'm in the same boat. I love Java, but I hate Java ecosystem. I hate golang, but I love its ecosystem. And I think that it's possible to write golang-like ecosystem for Java. After all there're people who wrote deno and bun to oppose node.js. Hopefully vaja will appear.
- fidgewidge 4y ago
  That's what libraries like Quarkus, Helidon etc are.
- kaba0 4y ago
  > Java needs set of microservice libraries reimagined from the ground up Which has pretty much already happened. Maven and Gradle are not bad at all, hell, Gradle is probably one of the few build tools that can actually handle more complex tasks correctly. Sure, that fancy new build tool definitely is more ergonomic to use for that hello world with 3 dependencies listed, but can it actually be used for generating locale files and whatnot? Not everything is running the compiler. Java’s ecosystem is one of the best and I can claim that quite objectively.
carimura 4y ago
Check out Project Leyden [1] in OpenJDK for work being done in this area. [1] https://inside.java/tag/leyden https://inside.java/tag/leyden
ActorNightly 4y ago
Golang is many times well better designed than Java ever will be. Java has fundamental issues with the language (which is the reason Groovy and Kotlin exist in the first place). If you want performance, stick with Golang. If you want rapid prototyping/dev, go with Python, 3.11 is much better in performance than older versions.
- pjmlp 4y ago
  Yeah, their design of enumerations is tip top.
- skitter 4y ago
  Go has it's own fundamental problems. Something very basic that turns me off is what happens to the original slice when appending to a it (done by calling append(slice, item) and using the result). Does it get modified? It may or it may not. Either one would be useful, but this way nobody else can hold a reference to the slice because it becomes useless to them.
  - ActorNightly 4y ago
    Every language has idiosyncrasies. The issue with Java is that right off the bat you are presented with bloat. Just to have a main function requires a class (and people realize this is wrong, which is why Kotlin and Groovy fixed this). Want a build system? You have to learn a whole another language essentially, like ant/maven/or gradle. Want to have logs? You have to use a library that has its own xml configuration files that specify behavior, in their own format. Oh and that library may have glaring vulnerabilities where logging something results in FETCHING CODE FROM THE INTERNET AND EXECUTING IT, BY DESIGN. Same goes for most any other public library that is widely used. Oh and btw, its bad practice in making your class members public, you should make them private. But its also bad practice in writing getters and setters - instead use a library that hacks the AST and writes functions there that are not visible in the code, for which you need special plugins for every IDE to recognize. I honestly don't know how people deal with this and remain so ignorant to it to continue using Java.
- AtlasBarfed 4y ago
pjmlp 4y ago
Depends if you want to pay for one of the commercial offerings for AOT compilation that have existed for 20 years, or rather go with the free beer offerings from GraalVM and OpenJ9.
quectophoton 4y ago
I don't know serverless, but recently-ish (few months ago) I was testing Java memory usage on a tiny program. Something like: public class Main { public static void main(String[] args) throws InterruptedException { for (int i = 0; i < 60; i++) { System.out.printf("%d\n", i); Thread.sleep(1000); } } } After spamming as many flags as I could find (literally listing all possible flags and seeing what looked like a high number, and lowering it), I could only get this program to use 307MB VIRT and 40MB RES memory. Unfortunately I didn't save the flags I used. That's more or less on par with the equivalent Node.js program on my PC (Node.js actually uses a bit more RES memory, 44MB). So I guess as long as you can (and want to) spam a lot of flags, it's feasible to lower memory usage. Disclaimer: Not a Java dev.
- lenkite 4y ago
  If you really want low memory consumption, you can use Graal native image https://www.graalvm.org/22.0/reference-manual/native-image/ https://www.graalvm.org/22.0/reference-manual/native-image/ If you want a lean, native-compilable microservice framework, there is Quarkus: https://quarkus.io/ https://quarkus.io/
- papruapap 4y ago
  In my experience Java performance worse than Node when used with memory cap. I am not an Java expert though, maybe there is a flag I missed.

threeseed 4y ago

There is GraalVM native image [1] which works well. And libraries like Quarkus [2] that leverage it that can launch in < 0.016s with < 12MB of RAM. [1] https://www.graalvm.org/22.0/reference-manual/native-image/ https://www.graalvm.org/22.0/reference-manual/native-image/ [2] https://quarkus.io https://quarkus.io

dschulz 4y ago
unfortunately, compilation times are not so good.
- msgilligan 4y ago
  Well, you do most of your compilation, test, and debug under the JVM and only do final test (and possibly debug) with native compilation.

FlyingSnake 4y ago

How is the generics story going in golang? I wonder if it brought a major paradigm shift in the way Go is written.

dgunay 4y ago
It is definitely better than before, but doesn't really change the game much. It has severe limitations. My biggest hope when generics were announced was that we'd finally get an alternative to writing `if err != nil` 10+ times per function, but it doesn't support generic method type parameters. That alone kneecaps it severely by making type-safe method chaining useless in most scenarios (unless you never need to map to another type, ever, I guess. Lucky you.)
zinclozenge 4y ago
It's pretty rare you need to write anything generic unless you're writing a library, or library like functionality.
bbkane 4y ago
I don't know about a paradigm shift, but the craziest use of them I've seen is https://github.com/jhbrown-veradept/gophercon22-parser-combinators https://github.com/jhbrown-veradept/gophercon22-parser-combi... . I watched the talk, thought I understood it "enough", then completely fell on my face trying to write a JSON parser. Could be me though, maybe I should try it again now that it's been a few months

vbezhenar 4y ago

Not good. Java needs set of microservice libraries reimagined from the ground up. Optimized for size and RAM consumption. Optimized for GraalVM compilation (it's bad, but it's not that bad, libraries make it that bad). Also preferably including new tool for building because Maven and Gradle are bad. I'm in the same boat. I love Java, but I hate Java ecosystem. I hate golang, but I love its ecosystem. And I think that it's possible to write golang-like ecosystem for Java. After all there're people who wrote deno and bun to oppose node.js. Hopefully vaja will appear.

fidgewidge 4y ago
That's what libraries like Quarkus, Helidon etc are.
kaba0 4y ago
> Java needs set of microservice libraries reimagined from the ground up Which has pretty much already happened. Maven and Gradle are not bad at all, hell, Gradle is probably one of the few build tools that can actually handle more complex tasks correctly. Sure, that fancy new build tool definitely is more ergonomic to use for that hello world with 3 dependencies listed, but can it actually be used for generating locale files and whatnot? Not everything is running the compiler. Java’s ecosystem is one of the best and I can claim that quite objectively.

carimura 4y ago

Check out Project Leyden [1] in OpenJDK for work being done in this area. [1] https://inside.java/tag/leyden https://inside.java/tag/leyden

ActorNightly 4y ago

Golang is many times well better designed than Java ever will be. Java has fundamental issues with the language (which is the reason Groovy and Kotlin exist in the first place). If you want performance, stick with Golang. If you want rapid prototyping/dev, go with Python, 3.11 is much better in performance than older versions.

pjmlp 4y ago
Yeah, their design of enumerations is tip top.
skitter 4y ago
Go has it's own fundamental problems. Something very basic that turns me off is what happens to the original slice when appending to a it (done by calling append(slice, item) and using the result). Does it get modified? It may or it may not. Either one would be useful, but this way nobody else can hold a reference to the slice because it becomes useless to them.
- ActorNightly 4y ago
  Every language has idiosyncrasies. The issue with Java is that right off the bat you are presented with bloat. Just to have a main function requires a class (and people realize this is wrong, which is why Kotlin and Groovy fixed this). Want a build system? You have to learn a whole another language essentially, like ant/maven/or gradle. Want to have logs? You have to use a library that has its own xml configuration files that specify behavior, in their own format. Oh and that library may have glaring vulnerabilities where logging something results in FETCHING CODE FROM THE INTERNET AND EXECUTING IT, BY DESIGN. Same goes for most any other public library that is widely used. Oh and btw, its bad practice in making your class members public, you should make them private. But its also bad practice in writing getters and setters - instead use a library that hacks the AST and writes functions there that are not visible in the code, for which you need special plugins for every IDE to recognize. I honestly don't know how people deal with this and remain so ignorant to it to continue using Java.
AtlasBarfed 4y ago

pjmlp 4y ago

Depends if you want to pay for one of the commercial offerings for AOT compilation that have existed for 20 years, or rather go with the free beer offerings from GraalVM and OpenJ9.

quectophoton 4y ago

I don't know serverless, but recently-ish (few months ago) I was testing Java memory usage on a tiny program. Something like: public class Main { public static void main(String[] args) throws InterruptedException { for (int i = 0; i < 60; i++) { System.out.printf("%d\n", i); Thread.sleep(1000); } } } After spamming as many flags as I could find (literally listing all possible flags and seeing what looked like a high number, and lowering it), I could only get this program to use 307MB VIRT and 40MB RES memory. Unfortunately I didn't save the flags I used. That's more or less on par with the equivalent Node.js program on my PC (Node.js actually uses a bit more RES memory, 44MB). So I guess as long as you can (and want to) spam a lot of flags, it's feasible to lower memory usage. Disclaimer: Not a Java dev.

lenkite 4y ago
If you really want low memory consumption, you can use Graal native image https://www.graalvm.org/22.0/reference-manual/native-image/ https://www.graalvm.org/22.0/reference-manual/native-image/ If you want a lean, native-compilable microservice framework, there is Quarkus: https://quarkus.io/ https://quarkus.io/
papruapap 4y ago
In my experience Java performance worse than Node when used with memory cap. I am not an Java expert though, maybe there is a flag I missed.