121–130 of 165 posts
Earlier quoted context omitted.
Ok, but I'm worried about the garbage collector, and if it can run concurrently without interrupting the program (as a native JVM would do it).
If the Javascript garbage collecter can do it then I don't see why not.
IMO the enhancements of Java over the last few versions have been very well chosen. I can't think of another language which has improved so much, and with so little hassle to developers. streams, type inference, lambda expressions, an official REPL: big changes, which effectively targeted some of the biggest pain-points in earlier Java.
But good luck convincing people who can't sit calm for 15 minutes without checking their cell phone that some 20+ year old ecosystem is good enough for them.
if you learn Scala, you'll learn also Java as side effect
SBT is hellish though and the added complexity that Scala has imposes a lot of cognitive overhead. With Kotlin, you always end up writing cleaner Java and don't risk erring on the side of unneeded entanglement in the spaghetti monster that Scala can sometimes be.
Scala definitely gives you enough rope to hang yourself, but in my experience this is no different than any other programming language. It's not like e.g. annotation processing tricks popular in the Java world are that easy to grasp.
Scala has some advanced language constructs, but they are commonly used in the same way for the same problems instead of the ad-hoc hacked-together solutions you get in languages not offering enough support.
Earlier quoted context omitted.
>Slowness isn't a property of the language it's a property of the runtime This is true to an extent, but look at the time and money poured into PHP and how slow it still is after all these years. Language design choices have a huge effect on how fast the runtime can be. In Javascript, objects are stored as a map of key->value pairs, and aren't strongly typed. This design requires more overhead for type checking and m…
Other benchmarks from the same group do show the memory usage and both node and Java are quite bad, as expected. Node is spectacularly bad at some, using 1.8 GB vs Java's 384M or C++'s 155M for example.
> Concern 5: Java is too slow/consumes too much memory It's sad that this is still a thing. Compared to more trendy languages like Python and Javascript, Java is very light on memory. JS is known for being fairly fast and "light", but its actually 5-10x slower than Java and uses 5-10X more memory. And the whole "lightness" of it is a lie. Javascript's run-time is probably bigger and more complex than the JVM. Java us…
Also, https://github.com/cxxr/better-java with recommendations for learning how to write modern Java.
Earlier quoted context omitted.
> Oh, and you will be working with a lot of people that barely can write a loop. That's that. I said it... It's funny although it's true. I'm not a programmer, but that's the profile of the Java developers that worked in my team. Sad, really...
I have worked for a number of companies, big and small, and this is recurring thing. If you are a person looking to get good salary by becoming programmer but you are not really interested in programming, Java is most likely to be your choice. You will never advance, but that's fine. If you are bad enough you will just change company and get your salary from another. There is so much pressure to find Java developers…
I think that its time that the enterprise switches to full stack Typescript as a much better solution for developing enterprise software. Why use two languages and two different ecosystems for the backend and for the frontend, when we can use only one? It makes hiring a lot easier too. Let's face it the Java ecosystem is stagnated and has lost a tremendous amount of mindshare in the last 7 years. The level of modular…
We use TypeScript for our frontend (Angular 5), I find it better than plain JS but the language has some weird paradigms, NPM is driving me crazy. Our backoffice is in C#, and i will never trade the safety of C# for TypeScript.
>The Java ecosystem did not manage to produce a good frontend development solution, and that was its downfall.
Agree. (haven't done Java since ages, but the support of java EE in GlassFish/Jboss/Tomcat was a mess too)
Earlier quoted context omitted.
My guess is that it won’t work with less than 1GB bc of spring boot, hibernate and all the rest of Java enterprise “microservice” goodness.
IMO almost nobody is writing microservices with spring boot because its so gigantic. Hibernate isn't bad on memory use on its own. There's a raft of more sane choices these days like Play, Dropwizard, Vert.X etc.. They all use far less resources. Spring Boot is huge because it has to support a decade of obsolete junk, its far more than just a REST app framework. Checkout TechEmpower's framework benchmarks https://www…
I've encountered plenty of spring boot microservices in my work and, from what I hear of other companies, it's not particularly rare.
Most of the time, if you have a team that's productive in Spring, a manager or lead will be happy to spend some extra memory and get more features shipped.
Any fears of oracle stewardship? https://www.google.com/amp/s/www.infoworld.com/article/32841...
My concerns with Oracle stewardship is more about their business practices concerning the trademark, (lack of) distribution of the TCK, treatment of alternative impls, litigation concerning perceived misuse, installer software bundling, etc.