My favourite is “all the boilerplate” then they come up with go’s error checking where you repeat the same three lines after every function call so that 60% of your code is the same lines orlf error checking over and over
When you handle all your errs the same way, I’d say you’re doing something wrong. You can build some pretty strong err trace wrapping errs.
I also think it’s more readable than the average try catch block.
Yeah, that’s the other thing - it does become easier to accidentally fail to deal with errors and the go adherents say they do all of that verbose BS to make error handling more robust.
I actually like go, but there’s so much BS with ignoring the pain points in the language.
I wouldn’t say so. They are inexperienced. They don’t know where the bottleneck of most of the modern software is (it’s io in 80-90% of cases) and how to optimize software without rewriting it to C++
How are they ignorant? It’s a known fact that java is slow, at least slower than some others. Sure, it’s still fast enough for 95% of use cases, but most code will run faster if written in, say, C. Will have 10x the amount of code and twice as many bugs though.
Java is indeed slower than C, Rust, in some cases than Go.
But that doesn’t mean that
code will run faster if written in, say, C
Again, like 80-90% of production code are bounded by disk/network io operations. You will gain performance from using C in embedded systems and in heavy calculations (games, trading, simulations) only.
Which is exaxtly what I said, that it’s fast enough for most use cases.
In theory though, you will “gain performance” by rewriting it (well) in C for literally anything. Even if it’s disk/io, the actual time spent in your code will be lower, while the time spent in kernel mode will be just as long.
For example, you are running a server which reads files and returns data based on said files. The act of reading the file won’t be much faster, but if written in C, your parsers and actual logic behind what to do with the file will be.
But it’s as you said, this actual tiny performance gain isn’t worth it over development/resource cost most of the time.
the jvm brings enough bugs to outweigh any benefits there…
it is relatively fast, but it’s slow in that it takes up a bunch of resources that could be doing other things…
i decline your invite to debate the merits of java and jvm… i will instead walk my dog through this beautiful park here…
but, it’s all been said on top level comments on this post.
it’s trash, and honestly, even if it was perfect, sun microsystems has ruined any potential benefits.
My favorite is “Java is slow” said by someone advocating for a language that’s at least 10 times slower.
My favourite is “all the boilerplate” then they come up with go’s error checking where you repeat the same three lines after every function call so that 60% of your code is the same lines orlf error checking over and over
When you handle all your errs the same way, I’d say you’re doing something wrong. You can build some pretty strong err trace wrapping errs. I also think it’s more readable than the average try catch block.
You still need to add error handling to every call to every function that might raise an error
And god help you if you forget those 3 lines somewhere and you silently have database failures or something else.
Yeah, that’s the other thing - it does become easier to accidentally fail to deal with errors and the go adherents say they do all of that verbose BS to make error handling more robust. I actually like go, but there’s so much BS with ignoring the pain points in the language.
Those who say such things are straight ignorant
They’re basically fashion victims.
I wouldn’t say so. They are inexperienced. They don’t know where the bottleneck of most of the modern software is (it’s io in 80-90% of cases) and how to optimize software without rewriting it to C++
How are they ignorant? It’s a known fact that java is slow, at least slower than some others. Sure, it’s still fast enough for 95% of use cases, but most code will run faster if written in, say, C. Will have 10x the amount of code and twice as many bugs though.
Java is indeed slower than C, Rust, in some cases than Go.
But that doesn’t mean that
Again, like 80-90% of production code are bounded by disk/network io operations. You will gain performance from using C in embedded systems and in heavy calculations (games, trading, simulations) only.
Which is exaxtly what I said, that it’s fast enough for most use cases.
In theory though, you will “gain performance” by rewriting it (well) in C for literally anything. Even if it’s disk/io, the actual time spent in your code will be lower, while the time spent in kernel mode will be just as long.
For example, you are running a server which reads files and returns data based on said files. The act of reading the file won’t be much faster, but if written in C, your parsers and actual logic behind what to do with the file will be.
But it’s as you said, this actual tiny performance gain isn’t worth it over development/resource cost most of the time.
the jvm brings enough bugs to outweigh any benefits there…
it is relatively fast, but it’s slow in that it takes up a bunch of resources that could be doing other things…
Please name a few
i decline your invite to debate the merits of java and jvm… i will instead walk my dog through this beautiful park here…
but, it’s all been said on top level comments on this post.
it’s trash, and honestly, even if it was perfect, sun microsystems has ruined any potential benefits.
Have a good walk at least
You cannot get rid of garbage collectors, but you can always compile your java into binary to reduce the memory footprint.
sea lion
Bullshit.