Should I Learn Java in 2018(e4developer.com)
e4developer.com
Should I Learn Java in 2018
https://www.e4developer.com/2018/06/09/should-i-learn-java-in-2018/
164 comments
> but its actually 5-10x slower than Java and uses 5-10X more memory
I am definitely against the "Java is slow" claims and think they are mostly rediculous but so is this claim.
Saying "uses 5-10x more memory and 5-10x slower" goes against every benchmark I've ever run and my understanding.
Mostly because JavaScript runs on several JITs (V8, JavaScriptCore, SpiderMonkey, Chakra) with different performance goals and characteristics and so does Java (which runs very differently with Art compared to HotSpot for example). Not to mention things like Graal :)
Slowness isn't a property of the language it's a property of the runtime. Usually performance is dominated by things like the speed of the packages used and standard library and not even the compiler.
There is no 5-10x factor _either way_ between JavaScript and Java VMs, not to mention you can run JavaScript on the Java VM anyway so that comparison doesn't hold in that regard either.
I am definitely against the "Java is slow" claims and think they are mostly rediculous but so is this claim.
Saying "uses 5-10x more memory and 5-10x slower" goes against every benchmark I've ever run and my understanding.
Mostly because JavaScript runs on several JITs (V8, JavaScriptCore, SpiderMonkey, Chakra) with different performance goals and characteristics and so does Java (which runs very differently with Art compared to HotSpot for example). Not to mention things like Graal :)
Slowness isn't a property of the language it's a property of the runtime. Usually performance is dominated by things like the speed of the packages used and standard library and not even the compiler.
There is no 5-10x factor _either way_ between JavaScript and Java VMs, not to mention you can run JavaScript on the Java VM anyway so that comparison doesn't hold in that regard either.
>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 many optimizations used by strongly typed languages won't work. Even in toy benchmarks its clear that Java has a performance lead https://benchmarksgame-team.pages.debian.net/benchmarksgame/... . It's slower than java on every test.
You don't see the memory difference because these toy benchmarks don't allocate much. Node/JS will always use more memory for storing objects, sometimes far more because it isn't strongly typed. In Java, an array of ints will use 32 bits * size plus some fixed bytes. In Javascript, each item in the array can use 2-3x the max "size" of the number, because the runtime can't figure out what type it should be.
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 many optimizations used by strongly typed languages won't work. Even in toy benchmarks its clear that Java has a performance lead https://benchmarksgame-team.pages.debian.net/benchmarksgame/... . It's slower than java on every test.
You don't see the memory difference because these toy benchmarks don't allocate much. Node/JS will always use more memory for storing objects, sometimes far more because it isn't strongly typed. In Java, an array of ints will use 32 bits * size plus some fixed bytes. In Javascript, each item in the array can use 2-3x the max "size" of the number, because the runtime can't figure out what type it should be.
> You don't see the memory difference
You'll see the memory difference if you compare Java with C++: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Except for one benchmark, where memory requirements are likely determined by the implemented algorithm, Java consumes in order of magnitude more memory across the board.
You'll see the memory difference if you compare Java with C++: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Except for one benchmark, where memory requirements are likely determined by the implemented algorithm, Java consumes in order of magnitude more memory across the board.
> … Java consumes in order of magnitude more memory…
Not for reverse-complement.
Not for k-nucleotide.
Not for binary-trees.
Not for mandelbrot.
Not for regex-redux.
The others show the default JVM memory allocation mas o menos.
Not for reverse-complement.
Not for k-nucleotide.
Not for binary-trees.
Not for mandelbrot.
Not for regex-redux.
The others show the default JVM memory allocation mas o menos.
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.
Java's usage will never compare to compiled languages without GC because it has to cache a bunch of code in RAM and the garbage builds up between collection cycles. It's pretty bad compared to something like C for sure :)
Depends how well they end up implementing value types.
System programing languages int the 90's with GC faired pretty well in this area.
Naturally they had much more control over GC, how value types were handled and manually allocation on unsafe modules.
System programing languages int the 90's with GC faired pretty well in this area.
Naturally they had much more control over GC, how value types were handled and manually allocation on unsafe modules.
> 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.
PHP7 isn't a slow language at all - it's much faster than previous versions actually. There are servers like aerys [1] that easily handle 10,000 concurrent requests on reasonable hardware. The reason sapi (read "regular") PHP isn't "faster" is because caching and the ease of deploying more servers makes it less of a priority to stakeholders.
Like I said - this is more dependent on the libraries used than the language.
> In Javascript, objects are stored as a map of key->value pairs, and aren't strongly typed.
This is also not true - JavaScript objects are stored through a technique called "hidden classes" akin to a C like struct in most modern runtimes [2].
> This design requires more overhead for type checking and many optimizations used by strongly typed languages won't work.
This is also false, JIT engines store run time information about the object (see hidden classes above [2]) and use that to optimize by type. V8 does this a lot and monomorphic functions are much faster [3]. Inline caches (ICs) really help there.
> It's slower than java on every test.
All those programs are poorly written and are running outdated versions of both Java and Node.js. Moreover they do not represent a workload people have in any reasonable way. I think that regardless it is possible Java is faster in a lot of workloads. I wouldn't use Java nor Node.js for any of the above programs there.
> Node/JS will always use more memory for storing objects, sometimes far more because it isn't strongly typed.
See [2] and [3] - that's not how it works.
> In Java, an array of ints will use 32 bits * size plus some fixed bytes. In Javascript, each item in the array can use 2-3x the max "size" of the number, because the runtime can't figure out what type it should be.
V8 has explicit handling for arrays of SMIs (small integers) with bailout semantics. JavaScript runtimes figure this out - feel free to ask for V8 source references. Also see my answer here on a library I maintain (bluebird) https://stackoverflow.com/a/24989927/1348195
[1] https://github.com/amphp/aerys [2] https://richardartoul.github.io/jekyll/update/2015/04/26/hid... [3] https://mrale.ph/blog/2015/01/11/whats-up-with-monomorphism....
PHP7 isn't a slow language at all - it's much faster than previous versions actually. There are servers like aerys [1] that easily handle 10,000 concurrent requests on reasonable hardware. The reason sapi (read "regular") PHP isn't "faster" is because caching and the ease of deploying more servers makes it less of a priority to stakeholders.
Like I said - this is more dependent on the libraries used than the language.
> In Javascript, objects are stored as a map of key->value pairs, and aren't strongly typed.
This is also not true - JavaScript objects are stored through a technique called "hidden classes" akin to a C like struct in most modern runtimes [2].
> This design requires more overhead for type checking and many optimizations used by strongly typed languages won't work.
This is also false, JIT engines store run time information about the object (see hidden classes above [2]) and use that to optimize by type. V8 does this a lot and monomorphic functions are much faster [3]. Inline caches (ICs) really help there.
> It's slower than java on every test.
All those programs are poorly written and are running outdated versions of both Java and Node.js. Moreover they do not represent a workload people have in any reasonable way. I think that regardless it is possible Java is faster in a lot of workloads. I wouldn't use Java nor Node.js for any of the above programs there.
> Node/JS will always use more memory for storing objects, sometimes far more because it isn't strongly typed.
See [2] and [3] - that's not how it works.
> In Java, an array of ints will use 32 bits * size plus some fixed bytes. In Javascript, each item in the array can use 2-3x the max "size" of the number, because the runtime can't figure out what type it should be.
V8 has explicit handling for arrays of SMIs (small integers) with bailout semantics. JavaScript runtimes figure this out - feel free to ask for V8 source references. Also see my answer here on a library I maintain (bluebird) https://stackoverflow.com/a/24989927/1348195
[1] https://github.com/amphp/aerys [2] https://richardartoul.github.io/jekyll/update/2015/04/26/hid... [3] https://mrale.ph/blog/2015/01/11/whats-up-with-monomorphism....
A lot of Javascript's optimizations are fragile, as in they don't always hold true, so there's overhead determining if the assumptions still apply.
For instance, Javascript's hidden class optimizations are disabled as soon as someone "breaks" the assumption by doing something like accessing a variable using a dynamic array index rather than dot notation.
Javascript runtimes also try to infer types as you say based on how objects are used, but this is also a fragile optimization. For instance, if you use an assumed "int" in a string-like way the runtime re-assigns the tagged type. And it's hard to know whether you (or the library you're using) does so.
Those programs might not represent a real workload but TechEmpower's framework benchmarks are closer. https://www.techempower.com/benchmarks/#section=data-r16&hw=...
On most of those benchmarks the fastest JS framework is ~5X slower than the fastest Java framework.
And yeah the array optimizations are related to what we both mentioned above, but again the optimization is not durable. It only works sometimes, and incurs its own overhead.
For instance, Javascript's hidden class optimizations are disabled as soon as someone "breaks" the assumption by doing something like accessing a variable using a dynamic array index rather than dot notation.
Javascript runtimes also try to infer types as you say based on how objects are used, but this is also a fragile optimization. For instance, if you use an assumed "int" in a string-like way the runtime re-assigns the tagged type. And it's hard to know whether you (or the library you're using) does so.
Those programs might not represent a real workload but TechEmpower's framework benchmarks are closer. https://www.techempower.com/benchmarks/#section=data-r16&hw=...
On most of those benchmarks the fastest JS framework is ~5X slower than the fastest Java framework.
And yeah the array optimizations are related to what we both mentioned above, but again the optimization is not durable. It only works sometimes, and incurs its own overhead.
> For instance, Javascript's hidden class optimizations are disabled as soon as someone "breaks" the assumption by doing something like accessing a variable using a dynamic array index rather than dot notation.
This is definitely not true.
> For instance, if you use an assumed "int" in a string-like way the runtime re-assigns the tagged type. And it's hard to know whether you (or the library you're using) does so.
Also not true - if you assign an integer to a string the engine will still use optimized code - the caveat is different and in megamorphic functions - if your function can accept lots of types that's problematic.
> On most of those benchmarks the fastest JS framework is ~5X slower than the fastest Java framework.
All of those benchmarks are dependent on the underlying library and not the language at all.
> And yeah the array optimizations are related to what we both mentioned above, but again the optimization is not durable. It only works sometimes, and incurs its own overhead.
That's not really how a JIT works and Java is also a JITd language on some runtimes (and the same person wrote both JITs originally - Lars Bak). The overhead is constant and low for the optimizations. The Java JIT compiler does a ton of such assumptions and bailouts as well to elide creating and allocating objects.
This is definitely not true.
> For instance, if you use an assumed "int" in a string-like way the runtime re-assigns the tagged type. And it's hard to know whether you (or the library you're using) does so.
Also not true - if you assign an integer to a string the engine will still use optimized code - the caveat is different and in megamorphic functions - if your function can accept lots of types that's problematic.
> On most of those benchmarks the fastest JS framework is ~5X slower than the fastest Java framework.
All of those benchmarks are dependent on the underlying library and not the language at all.
> And yeah the array optimizations are related to what we both mentioned above, but again the optimization is not durable. It only works sometimes, and incurs its own overhead.
That's not really how a JIT works and Java is also a JITd language on some runtimes (and the same person wrote both JITs originally - Lars Bak). The overhead is constant and low for the optimizations. The Java JIT compiler does a ton of such assumptions and bailouts as well to elide creating and allocating objects.
> and are running outdated versions of both Java and Node.js
That does not seem to be true —
java version "10.0.1" 2018-04-17 versus "Java SE 10.0.1 is the latest feature release for the Java SE Platform"
http://www.oracle.com/technetwork/java/javase/downloads/inde...
— or not-very out-of-date —
Node js v10.5.0 versus 10.6.0 Current
https://nodejs.org
That does not seem to be true —
java version "10.0.1" 2018-04-17 versus "Java SE 10.0.1 is the latest feature release for the Java SE Platform"
http://www.oracle.com/technetwork/java/javase/downloads/inde...
— or not-very out-of-date —
Node js v10.5.0 versus 10.6.0 Current
https://nodejs.org
> All those programs are poorly written…
Please contribute your own much better written programs —
https://salsa.debian.org/benchmarksgame-team/benchmarksgame/...
Please contribute your own much better written programs —
https://salsa.debian.org/benchmarksgame-team/benchmarksgame/...
Hmm. Just checked memory use on some services we run on Go, Node, and Java. I'm not part of the Java team but results:
Go: 40M Node: 64M Java: 4GB
Any Java service I've seen in production has similar numbers. Coupled with the incredible startup time it's hard for me to see why you'd pick it in 2018.
Go: 40M Node: 64M Java: 4GB
Any Java service I've seen in production has similar numbers. Coupled with the incredible startup time it's hard for me to see why you'd pick it in 2018.
>Go: 40M Node: 64M Java: 4GB
This benchmark is completely useless unless you have 3 identical servers with identical algorithms using identical API and models with identical work load. so... why would you waste time writing them?
Also, these [1] benchmarks which are more reliable, because we know what servers they're run on and we can inspect source code, unless, of source, you can prove your statement.
[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
This benchmark is completely useless unless you have 3 identical servers with identical algorithms using identical API and models with identical work load. so... why would you waste time writing them?
Also, these [1] benchmarks which are more reliable, because we know what servers they're run on and we can inspect source code, unless, of source, you can prove your statement.
[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
If you tell your Java application server "here you have 4GB, use it as you wish" it will happily comply and trade memory for performance.
In most of the cases it's just a matter of setting a few Java runtime startup parameters.
In most of the cases it's just a matter of setting a few Java runtime startup parameters.
It's disrespectful to take 4GB if you don't need it. This should never be the default...
It's the default because in any garbage collected language you can delay taking out the trash as long as you want... as long as you have memory. The most efficient thing to do is never run the collector at all.
JS does frequent GC cycles because its unacceptable to let a webpage eat all the ram. Not sure why Go collects so frequently. Java's default IMO is the most reasonable of the three. If you have a server with 4gb the best choice is to let the garbage collector use all of it
JS does frequent GC cycles because its unacceptable to let a webpage eat all the ram. Not sure why Go collects so frequently. Java's default IMO is the most reasonable of the three. If you have a server with 4gb the best choice is to let the garbage collector use all of it
Read the comment again:
> If you tell your Java application server "here you have 4GB, use it as you wish"
> If you tell your Java application server "here you have 4GB, use it as you wish"
JVM uses as much memory as you allow. Use `-Xmx39m` to beat Golang.
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.techempower.com/benchmarks/#section=data-r16&hw=...
(I added filters to limit to Java+Go+JS+Python and limited DB to Postgres and Mysql)
Java and Golang lead the pack, with JS a distant second and most Python frameworks hanging out near the bottom
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.techempower.com/benchmarks/#section=data-r16&hw=...
(I added filters to limit to Java+Go+JS+Python and limited DB to Postgres and Mysql)
Java and Golang lead the pack, with JS a distant second and most Python frameworks hanging out near the bottom
>IMO almost nobody is writing microservices with spring boot because its so gigantic.
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.
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.
> My guess
So you actually haven't tried to run an application with those libraries, and you don't even know what libraries that particular application is using, and here you are speculating about something you don't know and/or understand.
So you actually haven't tried to run an application with those libraries, and you don't even know what libraries that particular application is using, and here you are speculating about something you don't know and/or understand.
I've used Spring and he's probably right :) . But there's better choices these days. Any Spring micro-services out there are probably by a team that knew Spring well and didn't want to learn a more suitable framework
Whats different about the equivalent libraries in other languages?
Spring is huge... The closest competitor might be Rails
Also, https://github.com/cxxr/better-java with recommendations for learning how to write modern Java.
While the gist of that page is nice, there are many many flaws with it. I could enumerate them all, but suffice to say don't just take the author's word for using Optional parameters or always prefer Guava immutable collections or any of that. Much of it is wrong or at least debatable.
Nice! I think it may be slightly out of date though. For example, you don't need Tuples library if you use Apache commons because it has Tuple support. Also, Javaslang has been renamed Vavr. Still a solid article though
How efficiently does Java run when compiled to the browser platform? (e.g. WASM)
(The browser is an important target these days, so imho this question must be addressed; besides, I want to be able to use the same code on the server as on the client; and sadly, the JVM isn't guaranteed to work in every browser).
(The browser is an important target these days, so imho this question must be addressed; besides, I want to be able to use the same code on the server as on the client; and sadly, the JVM isn't guaranteed to work in every browser).
I'm really excited for WASM, it should be nearly as fast as native code. Java and native code aren't far apart though, so I would say 1.5-2x faster generally
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).
It should be able to... Hopefully Go and Java will be some of the first GC languages to target WASM, and we'll find out :) . Personally I'm more worried about the size of the GC getting added to the binaries than how fast it is.
AssemblyScript already does it, if I am not mistaken.
If the Javascript garbage collecter can do it then I don't see why not.
The JS GC can run in native code, in a separate native thread with shared memory access, and it can use things like memory barrier instructions, which have no equivalent in WASM yet.
If you want a low stress good paid job, where you would be able to rush home at 5pm, then yes.
If you are looking for excitement, learn $hype_of_the_year and join a startup, but be ready to learn $hype_of_the_next_year soon.
If you are looking for excitement, learn $hype_of_the_year and join a startup, but be ready to learn $hype_of_the_next_year soon.
> If you want a low stress good paid job, where you would be able to rush home at 5pm, then yes.
Those aren't exclusive, you can do something exciting, join a startup, learn $hype_of_the_year and still work for a place that understands that burning out employees is stupid.
It's perfectly reasonable to work for a place that is both exciting and doesn't make you sacrifice your personal life because they acknowledge that it's bad for business.
Those aren't exclusive, you can do something exciting, join a startup, learn $hype_of_the_year and still work for a place that understands that burning out employees is stupid.
It's perfectly reasonable to work for a place that is both exciting and doesn't make you sacrifice your personal life because they acknowledge that it's bad for business.
You're right. I wish more startup CEOs agreed with you.
I work with TypeScript, Golang and Java and I find Java the most exciting. There are a few or several libraries for everything, each of them well polished, new great features coming to Java language and JVM every 6 months, great support on every platform, many build tools to choose, that are easy to use. Things like GraalVM, local type inference, Jigsaw, SpringBoot and Jenkins make Java top language you can use these days.
I played around with ES6 and TS for a year and coming back to Java was not pleasant. The functional aspect of JS/TS is something I cannot get on Java, even with streams on Java 8. Just doesn't feel right.
Try RxJava or JINQ! I believe RxJava was actually first, RxJs being a port of that, if you would believe it :) .
Oddly enough most of the startups around where I am at have been based on Rails. Some people use Node as well. That’s about as $hype_of_the_year as it gets here.
I think Rails/NodeJS are the most popular choices for startups everywhere in the world. Both technologies are made for lean development.
Node.js is 9 years old and is also very stable with a large ecosystem. It's far from "hype train" in 2018 and it's more the mature technology - though it's still moving fast forward with new tools and paradigms it's very stable.
There's an argument to be made that Java positions are the easiest to fill with lower waged visa or offshore workers, meaning that you have to maintain an extremely high proficiency, move into management, or be under constant threat that your job will be outsourced.
I think it might be the other way round these days. Java programmers are outsourced because they're so expensive. Javascript seems like the best target now for low-skill outsourcing. Much lower barrier to entry, and arguably a much more forgiving language
I think you're right when it comes to the lower tier of JS developers, but IMHO there are a lot less middle tier devs per-capita in JS than Java. Proficient fullstack JS is a very in-demand skillset right now, and if you're an expert you can find a new, high paying job, in just about any mid-tier tech town in 48 hours.
I'm in a startup using Java.
Startups, assuming SV internet flavor startups, their tech stack is pretty standardized nowadays.
Python/Ruby/Node/Java, could cover like 99% of them maybe. Don't really see where the excitement is.
Python/Ruby/Node/Java, could cover like 99% of them maybe. Don't really see where the excitement is.
I never got the "Should I learn X" posts. The answer is yes to all the "Should I learn X" questions so it's very hard to have a discussion.
Learning another language is _significantly_ easier than learning the first one or two - not to the point of being a master but to the point of being competent.
Should I learn OCaml? Yes, you learn from knowing a functional language and Scala (combines functional and OOP well) and Clojure (a lisp) and C++ (resource management is important) and most of these languages.
Should you learn Node.js? Also yes - it is popular, most of the FE tools are written with it - it's fun to use (subjectively) and it's popular and reasonably fast.
Also Go, Rust, Swift and a bunch of other languages - languages are like philosophies and knowing them helps you understand what you're actually doing better often.
I never understood developers that only know 1-2 languages since it severely limits how you _look_ at problems.
Learning another language is _significantly_ easier than learning the first one or two - not to the point of being a master but to the point of being competent.
Should I learn OCaml? Yes, you learn from knowing a functional language and Scala (combines functional and OOP well) and Clojure (a lisp) and C++ (resource management is important) and most of these languages.
Should you learn Node.js? Also yes - it is popular, most of the FE tools are written with it - it's fun to use (subjectively) and it's popular and reasonably fast.
Also Go, Rust, Swift and a bunch of other languages - languages are like philosophies and knowing them helps you understand what you're actually doing better often.
I never understood developers that only know 1-2 languages since it severely limits how you _look_ at problems.
You're taking the question very literally. Implicit in it is should I learn Java over X given I'm constrained by time and opportunity cost.
Yes, we'd love to learn all the things given infinite resources.
Yes, we'd love to learn all the things given infinite resources.
It's implicit - but my criticism here is mostly that once you know one development stack learning others is significantly easier.
Learning Java is something that a backend developer can likely do in a week - and so is learning Node.js after knowing Java.
Learning Java is something that a backend developer can likely do in a week - and so is learning Node.js after knowing Java.
Knowledge of a language is a scale and not a binary yes / no question.
Being passingly familiar with a language is a week exercise, putting it on your resume / CV and saying you're ready to write production quality code is different.
For Java specifically:
- How does the JVM memory model and other internals work?
- How comfortable am I with the standard library?
- What are the idioms and design patterns used by professionals in Java?
- Performance pitfalls that are tribal knowledge with concurrency / threading, etc?
If the scale of language knowledge is 0-10, getting to 3, where you're familiar with the syntax, common language features and a few APIs is a week's exercise after you've used a few languages (in the same family -- I'm not going to be passingly familiar with Haskell in a week).
Being passingly familiar with a language is a week exercise, putting it on your resume / CV and saying you're ready to write production quality code is different.
For Java specifically:
- How does the JVM memory model and other internals work?
- How comfortable am I with the standard library?
- What are the idioms and design patterns used by professionals in Java?
- Performance pitfalls that are tribal knowledge with concurrency / threading, etc?
If the scale of language knowledge is 0-10, getting to 3, where you're familiar with the syntax, common language features and a few APIs is a week's exercise after you've used a few languages (in the same family -- I'm not going to be passingly familiar with Haskell in a week).
People who ask this question are implicitly asking:
"Given the difficulty/time requirements of learning something and the salary/technology trends of our industry, does it make sense to invest in the mastery of abstraction X?"
The time I have outside of my sprint is really limited, so getting expert guidance on whether knowing Rust will benefit me more than knowing Java is in fact extremely valuable to me.
"Given the difficulty/time requirements of learning something and the salary/technology trends of our industry, does it make sense to invest in the mastery of abstraction X?"
The time I have outside of my sprint is really limited, so getting expert guidance on whether knowing Rust will benefit me more than knowing Java is in fact extremely valuable to me.
That's a good point - it is highly dependent on what languages you already know from beforehand. If you know JavaScript already then it makes sense to learn a language that is not garbage collected, has no mutations or is not managed.
I would pick up Rust or Clojure before Java in this regard for example - though learning new languages gets way easier the more you learn.
I would pick up Rust or Clojure before Java in this regard for example - though learning new languages gets way easier the more you learn.
Well, yes and no.
Sure, it would be best if you learn all of them, but that's just impossible and not terribly useful.
What "Should I learn X" is implicitly "Given limited lifespan, will learning X, pay off for me".
Both in the literal sense like a well payed job and in the sense of making you a better programmer, which kinda depends on your previous experiences (e.g. learning Lisp dialect is kinda worthless, if you already know another Lisp dialect, learning C# pays less if you already know Java and F#).
Sure, it would be best if you learn all of them, but that's just impossible and not terribly useful.
What "Should I learn X" is implicitly "Given limited lifespan, will learning X, pay off for me".
Both in the literal sense like a well payed job and in the sense of making you a better programmer, which kinda depends on your previous experiences (e.g. learning Lisp dialect is kinda worthless, if you already know another Lisp dialect, learning C# pays less if you already know Java and F#).
Me neither, I have always beem against the 'X Developer' mantra of siloing oneself into a language corner.
Learning another language is _significantly_ easier than learning the first one or two
Learning the syntax, sure. But to be productive at a commercial level in any language these days is about knowing your way around the ecosystem, libraries, tooling etc, and that takes a significant investment of time, and the knowledge is highly perishable.
3-4 languages is probably the most it’s reasonable to maintain and to claim as an actual skill.
Learning the syntax, sure. But to be productive at a commercial level in any language these days is about knowing your way around the ecosystem, libraries, tooling etc, and that takes a significant investment of time, and the knowledge is highly perishable.
3-4 languages is probably the most it’s reasonable to maintain and to claim as an actual skill.
> the knowledge is highly perishable.
This is a very important point: many consultants get exposure to something like that 3-4 language list but most of that knowledge often stale or biased by past projects. This frequently ends up being actively harmful if they’re recommending something which they think they understand but the weightings are no longer correct. I’ve seen that the most in web projects (“you realize we no longer care about IE8, much less 6?”) but it’s pervasive because the cost of learning any two things well enough to do a deep comparison is higher than most places are willing to pay.
This is a very important point: many consultants get exposure to something like that 3-4 language list but most of that knowledge often stale or biased by past projects. This frequently ends up being actively harmful if they’re recommending something which they think they understand but the weightings are no longer correct. I’ve seen that the most in web projects (“you realize we no longer care about IE8, much less 6?”) but it’s pervasive because the cost of learning any two things well enough to do a deep comparison is higher than most places are willing to pay.
This is so overblown. We bring in folks regularly with no experience in our language much less the ecosystem and invariably they’re totally productive in a month or so
Sure, if you work at it full time you could be up to speed in a month, say 200 hours of work. That’s more than a casual investment of time if it’s on top of a full time job as well.
And if you go away from it and come back in 6 months or a year you’ll have to do it over again, some stuff you’ll forget if you don’t use and some stuff will have moved on.
And if you go away from it and come back in 6 months or a year you’ll have to do it over again, some stuff you’ll forget if you don’t use and some stuff will have moved on.
I have been developing backend systems in Java, professionally, for the past 15 years.
You should not base your career choice of being Java programmer or not solely on Java's popularity.
There are genuine good reasons to learn niche technologies especially if you like them more. I think if you genuinely like something you are much more likely to succeed in that field and it is better for you no matter the size of the field.
Choosing niche technology means you will have less options when changing jobs but, remember, you only need one good offer.
Here's my thought about Java:
Java development is for a specific type of programmer that will most likely work for large corporation and more often than not on some unsexy backend system.
Java is uniquely suited to be language of choice for the enterprise for many reasons which I will not go into right now.
These companies are currently extremely hungry for Java developers. This also means you will not only have no problem finding a job, you should be able to command good starting price compared to about anything else (except maybe React).
Java is becoming better work environment, not worse, with every passing year. It has excellent tooling (IntelliJ IDEA being in my mind best IDE in the world except for Emacs with Slime). Excellent frameworks and support libraries (Spring Framework + satellite frameworks). Excellent support and portability (if you can install Java in particular major version it WILL work). Excellent build systems (Gradle being my choice). And it is also quite efficient with resources if you do it correctly and don't make bad choices -- JVM is actually very fast and the only major drawback is startup speed and memory upkeep which are not an issue for typical enterprise service.
Major drawbacks:
It is not particularly good language in itself, but that's what I get for learning Lisp. It got a bit better recently (recently in this case is past few years).
It is suited to particular types of projects which tend to be unsexy, enterprise services. If you become Java developer you probably will not be working on games, on exciting IoT projects, beautiful UIs, AI, and other exotic stuff. You will be doing backend systems and hopefully be paid well.
Oh, and you will be working with a lot of people that barely can write a loop. That's that. I said it...
You should not base your career choice of being Java programmer or not solely on Java's popularity.
There are genuine good reasons to learn niche technologies especially if you like them more. I think if you genuinely like something you are much more likely to succeed in that field and it is better for you no matter the size of the field.
Choosing niche technology means you will have less options when changing jobs but, remember, you only need one good offer.
Here's my thought about Java:
Java development is for a specific type of programmer that will most likely work for large corporation and more often than not on some unsexy backend system.
Java is uniquely suited to be language of choice for the enterprise for many reasons which I will not go into right now.
These companies are currently extremely hungry for Java developers. This also means you will not only have no problem finding a job, you should be able to command good starting price compared to about anything else (except maybe React).
Java is becoming better work environment, not worse, with every passing year. It has excellent tooling (IntelliJ IDEA being in my mind best IDE in the world except for Emacs with Slime). Excellent frameworks and support libraries (Spring Framework + satellite frameworks). Excellent support and portability (if you can install Java in particular major version it WILL work). Excellent build systems (Gradle being my choice). And it is also quite efficient with resources if you do it correctly and don't make bad choices -- JVM is actually very fast and the only major drawback is startup speed and memory upkeep which are not an issue for typical enterprise service.
Major drawbacks:
It is not particularly good language in itself, but that's what I get for learning Lisp. It got a bit better recently (recently in this case is past few years).
It is suited to particular types of projects which tend to be unsexy, enterprise services. If you become Java developer you probably will not be working on games, on exciting IoT projects, beautiful UIs, AI, and other exotic stuff. You will be doing backend systems and hopefully be paid well.
Oh, and you will be working with a lot of people that barely can write a loop. That's that. I said it...
> 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...
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 that companies frequently forgo any sane process to check whether the person is actually qualified to do the job. With tools available like CoderPad and the likes there should actually be no excuse to do this but I guess somebody high in HR would be very unhappy seing how few actual Java developers they are able to hire after applying it.
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 that companies frequently forgo any sane process to check whether the person is actually qualified to do the job. With tools available like CoderPad and the likes there should actually be no excuse to do this but I guess somebody high in HR would be very unhappy seing how few actual Java developers they are able to hire after applying it.
I don't know where you are from but most universities in the U.S. teach Java or C++ as primary language. Pretty much everybody in our school used Java as their interview language and due to the leetcode grinding culture, the interviews are not definitely easy. The companies you talk about sound like they suck.
It is easy to write that the company sucks, but the problem isn't that easy.
When you work as a manager for the company and you are presented with a new project you can't say you will not do it. In many companies this will mean you are expected to hire people and to get it out the door.
In most companies incentives are against "we will ACTUALLY only hire best people".
When you work as a manager for the company and you are presented with a new project you can't say you will not do it. In many companies this will mean you are expected to hire people and to get it out the door.
In most companies incentives are against "we will ACTUALLY only hire best people".
Usually true for graduate hires but lateral hires of experienced devs are more uneven in quality. Where I work, campus recruits are like geniuses, while some experienced engineers are just buzzing through. I remember one of them told me he never used github, after working for 6 months, when we have github enterprise in our own company
> If you become Java developer you probably will not be working on games, on exciting IoT projects, beautiful UIs, AI, and other exotic stuff. You will be doing backend systems and hopefully be paid well.
Games and IoT projects need backends as well, and it's not that unusual for those to be written in java.
Games and IoT projects need backends as well, and it's not that unusual for those to be written in java.
> Java development is for a specific type of programmer that will most likely work for large corporation and more often than not on some unsexy backend system.
There is always a rule to every exception. I am in startup that uses Java. We are creating medical device software that runs on Linux. We have a JavaFX application that connects to a PostgreSQL database on Docker. The application also uses an embedded Jetty server to expose a series of HTTP endpoints as well as a websocket. We use Jogl to work with OpenGL to render 2d graphics to the screen.
This is by far the coolest project I have worked on.
There is always a rule to every exception. I am in startup that uses Java. We are creating medical device software that runs on Linux. We have a JavaFX application that connects to a PostgreSQL database on Docker. The application also uses an embedded Jetty server to expose a series of HTTP endpoints as well as a websocket. We use Jogl to work with OpenGL to render 2d graphics to the screen.
This is by far the coolest project I have worked on.
That’s why I stopped programming in Java as a CS student. I actually really liked the language and the direction it’s going in but looking at the environment of most Java jobs, I thought it was probably not for me.
I went to Github’s trending page for a bunch of different languages and after looking at the projects there, I decided to fully invest myself into C++ instead because I felt like that’s where the most interesting projects were. Maybe a bad way to decide your career path idk
I went to Github’s trending page for a bunch of different languages and after looking at the projects there, I decided to fully invest myself into C++ instead because I felt like that’s where the most interesting projects were. Maybe a bad way to decide your career path idk
Java or .NET are going to be prevalent in any mid-size or larger nascent organization. There's absolutely no reason why you wouldn't at least embrace it in your tool belt. It's proven technology. It may not be 'fun', but making stable business systems last is the point here - not building fun tech for the sake of building fun tech. (Wrong audience here, I know)
Kotlin or Clojure would be a bit more fun to learn, still be able to benefit from running on the JVM.
As much as I like Clojure (and Clojurescript) whenever I want to actually get things done, I have to switch back to the simple Java jax.rs based backend and either native Android, or ReactJS based web front end.
I am kinda sick of spending days fighting with half-backed tools that would eventually give me a better and more productive workflow, just to get to the "almost there with only a few missing things" and finally giving up.
That being said, I have a high hopes for Flutter for the front end mobile development. From what I have seen from quick playing with it, it's as friction-less as it can get.
I am kinda sick of spending days fighting with half-backed tools that would eventually give me a better and more productive workflow, just to get to the "almost there with only a few missing things" and finally giving up.
That being said, I have a high hopes for Flutter for the front end mobile development. From what I have seen from quick playing with it, it's as friction-less as it can get.
Sure but to truly appreciate either you’ll need to slog through a bunch of POJOs and EnterpriseAwareTranformationalFactoryBeanFactoryCreationTemplate classes first.
+1 for clojure
One annoyance with Java(and Kotlin too) is that it's pretty much the only language left that you really ought to use a specialized IDE with while pretty much every other language(including C#) you can get adequate support in VS Code or Emacs.
I think its the other way, there are only a few languages with as superb IDE support as Java. AFAIK its just C++, Java and C#.
You can get shitty support with just syntax coloring for anything and anywhere of course.
You can get shitty support with just syntax coloring for anything and anywhere of course.
Couldn't agree more. A powerful IDE with rich, intuitive, self-discoverable, user friendly design tools, debugging and refactorisation is as important to me than the language itself.
And I'd say a third thing that matters as much as IDE and syntax is the wealth of libraries. Not just common things like consuming a rest API. But also specialised things like dealing with spreadsheets, music, whatever your domain cares about.
And I'd say a third thing that matters as much as IDE and syntax is the wealth of libraries. Not just common things like consuming a rest API. But also specialised things like dealing with spreadsheets, music, whatever your domain cares about.
That gap is closing – e.g. VS Code has refactoring, definition lookup, linting, etc. support for Python, JavaScript, TypeScript, Rust, etc.
It’s still not what the top IDEs can provide but it’s way more than syntax highlighting and since everything is open source it’s improving a lot faster than the commercial market.
It’s still not what the top IDEs can provide but it’s way more than syntax highlighting and since everything is open source it’s improving a lot faster than the commercial market.
VS Code isn't that bad from my experience. I tried working on a small project with VS Code (as opposed to working with Intellij as I usually do for my job) and I didn't miss that much.
Might be that as complexity grows you need more and more IDE features to deal with it, but that's a symptom of older codebases being in Java more than it's a fault of the language itself, right?
Might be that as complexity grows you need more and more IDE features to deal with it, but that's a symptom of older codebases being in Java more than it's a fault of the language itself, right?
The annoyance is the lack of productivity when going back to the 80's style of programming.
Using IDEs since mid-90's, and I used to know XEmacs quite well.
Using IDEs since mid-90's, and I used to know XEmacs quite well.
VS Code support for Java ain't bad
Author says Java was relatively new in 2007 although introduced in 1995... I’m not sure what is meant.
Java is many things: the language? The vm? The ecosystem?
I keep hearing that Java is fast, and indeed hotspot is but every system I encounter that’s written in Java is sluggish.
I keep hearing that Java lost its abstractwidgetfactoryfactoryfactory fetish, and I think it’s improved in the last 15 years, but it’s still horrible.
My view:The language is meh; acceptable syntax, reasonable performance. The ecosystem is bleh - only if you really love bureaucracy.
Java is many things: the language? The vm? The ecosystem?
I keep hearing that Java is fast, and indeed hotspot is but every system I encounter that’s written in Java is sluggish.
I keep hearing that Java lost its abstractwidgetfactoryfactoryfactory fetish, and I think it’s improved in the last 15 years, but it’s still horrible.
My view:The language is meh; acceptable syntax, reasonable performance. The ecosystem is bleh - only if you really love bureaucracy.
> I keep hearing that Java is fast, and indeed hotspot is but every system I encounter that’s written in Java is sluggish.
Counterpoint: ElasticSearch and Solr are excellent, reflecting many hard years of work by the Lucene team. (I say that as someone who last wrote serious amounts of Java in the 90s)
Java’s problems are cultural and the experience really depends on whether you’re over in enterprise land with that insatiable complexity fetish or somewhere else where people are serious about getting anything done. The big risk to me these days is Oracle since they’re prone to milking their IP now at the expense of its long-term future.
Counterpoint: ElasticSearch and Solr are excellent, reflecting many hard years of work by the Lucene team. (I say that as someone who last wrote serious amounts of Java in the 90s)
Java’s problems are cultural and the experience really depends on whether you’re over in enterprise land with that insatiable complexity fetish or somewhere else where people are serious about getting anything done. The big risk to me these days is Oracle since they’re prone to milking their IP now at the expense of its long-term future.
There are plenty of reasons to learn a language - but Java in particular is a great learning tool. Whilst I don't enjoy developing in it (or its derivatives), I think that it's a great language to help people clearly understand control structure and polymorphism.
To this day, my experience continues to be that students who had a CS degree that included Java have significantly better fundamentals than those whose programme didn't. Whilst that's purely anecdotal, I'll definitely continue to skew this way until I see otherwise.
To this day, my experience continues to be that students who had a CS degree that included Java have significantly better fundamentals than those whose programme didn't. Whilst that's purely anecdotal, I'll definitely continue to skew this way until I see otherwise.
Yes, you want to learn Java in 2018. It's still a go-to language in many corporations, though not super-glamorous. Even if you do not plan on taking on any such job in the near future, it's good to know it - at least cursory. Perhaps especially because it has similarities to languages like C# and Objective C, which are also corporate heavy languages (thought the former more than the latter). It might not be used in the next startup, but it's still one of the most important get-a-job language to know.
yeah, also in 2019 and 2020. it's only getting better and better. the echosystem is amazing. I think you should focus on 3 languages:
1. Java for stable heavy big projects with lot of develpers. 2. Typescript for frontend lifting. 3. Python for machine learning and data analysis.
Master those 3 and general programming and system design concepts this is what i'm working on.
1. Java for stable heavy big projects with lot of develpers. 2. Typescript for frontend lifting. 3. Python for machine learning and data analysis.
Master those 3 and general programming and system design concepts this is what i'm working on.
That's exactly the three languages I use and for those exact reasons. I'll sometimes throw in R for data analysis as I find the ease of importing/editing poorly formatted excel (most business scenarios) to be the easier than python (more of a personal preference than anything)
> Should I learn Java? This is a question that just keeps coming up.
Really? Java has a verbose but bland syntax, relatively fewer surprises, to 'learn' it, should be straightforward. I don't think this should pose as a problem to average dev at all.
Really? Java has a verbose but bland syntax, relatively fewer surprises, to 'learn' it, should be straightforward. I don't think this should pose as a problem to average dev at all.
Agree. Even if you don't plan to be an expert Java developer it is still useful to learn it, and the effort should not be huge. Especially not for someone with experience in other languages. It really isn't a difficult language to learn up to a level of basic proficiency. It should not be more than one or two weeks of effort to be able to create useful things if you know what to look for.
The effort of learning new programming languages often seems to be hugely over-estimated.
The effort of learning new programming languages often seems to be hugely over-estimated.
But learning the syntax is only a small part of learning a language. Knowing your libraries is a huge part of being productive. How do I do rest queries, cryptography, filesystem manipulations, serialization, spreadsheet manipulations, images manipulations, web frameworks, interaction with the OS, multi-threading debugging, UI, etc. Outside of staying within an ecosystem (JVM / .net), you need to rediscover all these from scratch, get bitten by all the gotchas, etc.
Exactly. Most people are proficient in 1/2 languages maybe, but in many cases, it is pretty common to be in a situation where you need ramp quickly to just understand stuff and make modest changes to the code when necessary. Don't really understand why people seem to make a big fuzz about it like it is a huge commitment.
Unpopular opinion stated, programming language as a skill by itself will gradually lose its importance in job market. Companies, specially big ones, will hire for domain experts, rather than language specialists.
Unpopular opinion stated, programming language as a skill by itself will gradually lose its importance in job market. Companies, specially big ones, will hire for domain experts, rather than language specialists.
I don't think the syntax is the difficult part, it is the tooling/IDEs/ecosystem/blah.
I think this is true with most languages that have been around for more than 10 years (except for python... python is a great beginner's language IMHO)
As is true most other languages, tbh. Java isn't the hardest one either, with Eclipse/IntelliJ/Maven/blahblah, it takes time to configure, but fairly established.
Yes, by all means learn Java. It's not as hip as Go or JavaScript, nor as versatile as Lisp. Learn it because it's still a valuable utility language for writing networked services (especially large ones) and it has HUGE library support. Learn it for the hell of it. And don't be swayed by its reputation; Java in 2018 is asymptotically approaching Kotlin (which you may also want to learn, as long as you're on the JVM).
It's the defacto standard language at Amazon. There's no specific requirement that teams write code in Java and all the high level infrastructure makes no presumptions, but there's great internal support for it.
And Amazon hired Gosling, so interpret that as you will.
And Amazon hired Gosling, so interpret that as you will.
>...so interpret that as you will.
Probably 'just in time' as this a Java thread.
Probably 'just in time' as this a Java thread.
Ryan Gosling really has it all
Java - just like JavaScript has a lot of inertia which won't be going away anytime soon.
Anecdata: my seven person college social circle consists of one front-end dev(me), one systems dev working in C++ and Go, one all-around programming handyman, one sort of dev-ops and three backend devs who work exclusively in Java.
Large non-IT companies and their respective IT departments are first and foremost interested in technologies that work and can be easily staffed. Java fits the bill for now.
Anecdata: my seven person college social circle consists of one front-end dev(me), one systems dev working in C++ and Go, one all-around programming handyman, one sort of dev-ops and three backend devs who work exclusively in Java.
Large non-IT companies and their respective IT departments are first and foremost interested in technologies that work and can be easily staffed. Java fits the bill for now.
Java itself is pretty fast and wonderful, at-least the modern versions. It’s the libraries and the ecosystem. Java folks typically over engineered things with layers and layers of abstraction in the name of “enterprise”.
Writing a web app in Django/express vs tomcat/jboss you’d feel the pain. It would take forever to start, chew an insane amount of memory and nodejs runs circles around it.
There aren’t that many things where Java is a great usecase. If you want serious perf, then you’d go C/C++/rust. Perf with nicer abstractions would be Go. Dynamic languages? Javascript and Python.
Yes Android uses Java heavily but even Google got sued left and right by Google. Oracle simply gives Java a really bad rep.
Java is still heavily used by banks and enterprisy companies but I’d bet C# has equal penetration. C# is just designed much nicer, it’s like java but a great user experience and similar perf. With .NET being OS, i’d bet on C# to have bright future. MS invests a lot more into it than Oracle into Java.
So to answer your question if you should learn Java. Absolutely go build a simple Android app or a simple cli app. I wouldn’t count on it being the only tool in the toolbox.
If you have limited time and you want to make a choice on what to learn. I’d say Javascript and Python. Those are in good demand nowadays.
Writing a web app in Django/express vs tomcat/jboss you’d feel the pain. It would take forever to start, chew an insane amount of memory and nodejs runs circles around it.
There aren’t that many things where Java is a great usecase. If you want serious perf, then you’d go C/C++/rust. Perf with nicer abstractions would be Go. Dynamic languages? Javascript and Python.
Yes Android uses Java heavily but even Google got sued left and right by Google. Oracle simply gives Java a really bad rep.
Java is still heavily used by banks and enterprisy companies but I’d bet C# has equal penetration. C# is just designed much nicer, it’s like java but a great user experience and similar perf. With .NET being OS, i’d bet on C# to have bright future. MS invests a lot more into it than Oracle into Java.
So to answer your question if you should learn Java. Absolutely go build a simple Android app or a simple cli app. I wouldn’t count on it being the only tool in the toolbox.
If you have limited time and you want to make a choice on what to learn. I’d say Javascript and Python. Those are in good demand nowadays.
Sun would have sued Google as well, if they still had the money to do it.
Oracle is so bad, yet no other company was bothered to rescue Sun, not even IBM which backpedaled on their proposal.
And mostly importantly, Google, after what they had done.
Oracle is so bad, yet no other company was bothered to rescue Sun, not even IBM which backpedaled on their proposal.
And mostly importantly, Google, after what they had done.
Yes, by all means.
Then you can learn $FLAVOR_OF_THE_YEAR to get you exciting gigs while maintaining proficiency in $OLD_FAITHFUL to keep you employed as you learn $FLAVOR_OF_NEXT_YEAR.
Then you can learn $FLAVOR_OF_THE_YEAR to get you exciting gigs while maintaining proficiency in $OLD_FAITHFUL to keep you employed as you learn $FLAVOR_OF_NEXT_YEAR.
I just yesterday managed to compile a little utility program of mine in java using openjdk 10 and then via https://github.com/moditect/moditect link together linux and windows binary packages which run on both platforms without a JVM and weigh in at ~35mb. It impressed me that something like that is now possible with Java.
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 modularity that they are trying to achieve has been available in Node since 2009, while all the language features that they are trying to implement are already there in a Typescript in a much better form.
The Java ecosystem did not manage to produce a good frontend development solution, and that was its downfall.
Things like JSF and later GWT did not deliver on the promise of abstracting away the browser for non-frontend developers, and the result is that you have to be both a frontend developer (HTML/CSS/Javascript ) and a Java developer in order to build UIs in Java.
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 modularity that they are trying to achieve has been available in Node since 2009, while all the language features that they are trying to implement are already there in a Typescript in a much better form.
The Java ecosystem did not manage to produce a good frontend development solution, and that was its downfall.
Things like JSF and later GWT did not deliver on the promise of abstracting away the browser for non-frontend developers, and the result is that you have to be both a frontend developer (HTML/CSS/Javascript ) and a Java developer in order to build UIs in Java.
> Why use two languages and two different ecosystems for the backend and for the frontend, when we can use only one?
Why use a hammer and a screwdriver when you could just use the hammer?
Do people really make blanket decisions like this for their projects instead of properly evaluating what the project's actual needs are?
Why use a hammer and a screwdriver when you could just use the hammer?
Do people really make blanket decisions like this for their projects instead of properly evaluating what the project's actual needs are?
> The Java ecosystem did not manage to produce a good frontend development solution, and that was its downfall.
Most people writing Android apps are doing it in Java. The switch to Kotlin was as much about Sun and Google as it was about Java being outdated.
Most people writing Android apps are doing it in Java. The switch to Kotlin was as much about Sun and Google as it was about Java being outdated.
A language with no built-in multi-threading capabilities is unlikely to suit every backend. Running multiple copies of the same lightweight process works quite well for stateless http interaction (request -> database -> response), but it's a lot of overhead to cross process boundaries every time you want to run something in another thread.
I also have a question about the loss of mindshare. What new technologies are unaccessible from Java, but are accessible from at least 2 other languages (one of which is TypeScript / JavaScript)? A loss of mindshare would likely mean smart people aren't around to build libraries / integrations to the latest hotness.
My background: Originally a Java developer, now mostly Clojure. Also a Javascript (mostly react) developer.
I also have a question about the loss of mindshare. What new technologies are unaccessible from Java, but are accessible from at least 2 other languages (one of which is TypeScript / JavaScript)? A loss of mindshare would likely mean smart people aren't around to build libraries / integrations to the latest hotness.
My background: Originally a Java developer, now mostly Clojure. Also a Javascript (mostly react) developer.
>I think that its time that the enterprise switches to full stack Typescript as a much better solution for developing enterprise software.
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)
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)
Why Typescript and not just JS? Static typing for a dynamic language in a dynamic environment while using many npm libraries that can return anything unexpected? You'll need tons of testing to be sure.
Typescript is highly overrated, proper testing makes the difference, not Typescript IMHO. Btw, Typescript is Microsoft, just as Github is soon, and I really having a hard time to get rid of the aversion I have for that company.
Typescript is highly overrated, proper testing makes the difference, not Typescript IMHO. Btw, Typescript is Microsoft, just as Github is soon, and I really having a hard time to get rid of the aversion I have for that company.
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.
streams, type inference, lambda expressions, an official REPL: big changes, which effectively targeted some of the biggest pain-points in earlier Java.
And more is coming:
Fibers, pattern matching, continuations, value types, low latency garbage collector …
Fibers, pattern matching, continuations, value types, low latency garbage collector …
Which I wholeheartedly agree, you won't find much sympathy with most of the people here on HN. Business recognized the value of Java long time ago (the bigger the project the better Java for it is, you will find tons of experienced devs for it, long term tested stable libs for just about anything required, very robust live monitoring and debugging, great dev tools, solid performance etc etc etc), and will remain around for very long time (unless Oracle would do something horrible, but why should they).
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.
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.
Any fears of oracle stewardship?
https://www.google.com/amp/s/www.infoworld.com/article/32841...
https://www.google.com/amp/s/www.infoworld.com/article/32841...
Yes, but not there. Don't use Oracle Java. That article only applies to Oracle Java. I personally would not recommend anyone relying any Oracle owned software (e.g. even Graal) but have no problem recommending community owned software like the JDK/JVM. Of course it's just a recommendation, sometimes we don't always have a choice.
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.
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.
No, as it has given a lot to the Java community since Java 6, when no other company bothered to actually acquire Java.
I was at the tail end of the Java-first code teaching approach - the Stanford open courseware I was following in 2013 was largely built on top of Java. Stanford switched those courses to Javascript a couple of years later.
Java has definite advantages over its scripting cousins when it comes to learning the OOP paradigm, program patterns/anti-patterns and typing. You can't really get away with not knowing any of it in Java (as opposed to Python), but the language is still fairly newbie-friendly (as opposed to C++). Additionally, Java 8 is a fairly decent introduction to functional programming for people who've never worked with it before.
All that said, right now I wouldn't start a new codebase in Java unless I really, really had to. Learn your fundamentals through Java, then get comfortable in something else and code your projects in that instead.
Java has definite advantages over its scripting cousins when it comes to learning the OOP paradigm, program patterns/anti-patterns and typing. You can't really get away with not knowing any of it in Java (as opposed to Python), but the language is still fairly newbie-friendly (as opposed to C++). Additionally, Java 8 is a fairly decent introduction to functional programming for people who've never worked with it before.
All that said, right now I wouldn't start a new codebase in Java unless I really, really had to. Learn your fundamentals through Java, then get comfortable in something else and code your projects in that instead.
Java is old, and it may not be fashionable, but it’s still so widely used that every other JVM language is just a drop in the bucket by comparison. It’s not particularly difficult to learn either. Seems like it would be good for your career even with all the warts the language and APIs have.
I wrote this in 2014 and think it's still reasonably relevant: https://mcconnellsoftware.github.io/java-golden-handcuffs/
I quite like modern java. With spark java, lambdas and all the helpful jars it’s really not a bad language. Plus you get native lucene and almost every other thing you could want is already written
In fact the only thing I wish for with it is fast syntax highlighter in Java like pygments for python or chroma for Go. The pygments/jython implementation is too slow and there is no the else mature out there.
It’s also useful to know career wise. It may not be the new hot thing but it’s likely to be around 20 years from now and a little stability in languages and tools is something to be thankful for.
In fact the only thing I wish for with it is fast syntax highlighter in Java like pygments for python or chroma for Go. The pygments/jython implementation is too slow and there is no the else mature out there.
It’s also useful to know career wise. It may not be the new hot thing but it’s likely to be around 20 years from now and a little stability in languages and tools is something to be thankful for.
You should learn Java if you want to get a job programming in Java (e.g. a very large proportion of programming jobs).
Was hopping to see more mentions of Android development... I’m currently weighing building an app in Kotlin or Java
IMO to use Kotlin effectively you need to know Java, so to answer to the article title for you is yes. But I would probably use Kotlin for the actual development due to Android Java being versions behind and version fragmentation.
Java has the best IDEs on earth. And the best tooling too.
To hell with Java. Learn it if you have to, but thankgod it's no longer mandatory skill on the market.
How reliable is the TIOBE index?
C having 7% year over year growth seems hard to believe.
JS is shrinking and smaller than Visual Basic.NET?
C having 7% year over year growth seems hard to believe.
JS is shrinking and smaller than Visual Basic.NET?
Totally J++ is the wave of the future!
[deleted]
What are the best (and least painful) resources to learn (modern) Java?
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.
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.
> SBT is hellish though
Agreed, ignore it, stick with Maven.
> the added complexity that Scala has imposes a lot of cognitive overhead.
That's just FUD and memes. Scala is more consistent than Java and much more consistent than Kotlin, which makes it much easier to concentrate on what your code is actually doing.
(This is why you will see some very complicated functions and datatypes written in Scala - it's only really practical to write a complicated function or datatype in a simple language, because otherwise the language will sap too much of your attention. But that's a reflection of those functions and datatypes; if you don't need a complicated function or datatype, don't use it. The language itself is simple)
> 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.
Not true. Kotlin codebases that do the same thing look worse than Scala codebases or have subtle misbehaviours waiting; Kotlin has a huge number of ad-hoc special cases e.g. nullables, async, continuations are all special language features. Kotlin's ability to do error handling/validation is actually worse than Java's (no checked exceptions and no adequate replacement if you want to actually report the details of failures).
Agreed, ignore it, stick with Maven.
> the added complexity that Scala has imposes a lot of cognitive overhead.
That's just FUD and memes. Scala is more consistent than Java and much more consistent than Kotlin, which makes it much easier to concentrate on what your code is actually doing.
(This is why you will see some very complicated functions and datatypes written in Scala - it's only really practical to write a complicated function or datatype in a simple language, because otherwise the language will sap too much of your attention. But that's a reflection of those functions and datatypes; if you don't need a complicated function or datatype, don't use it. The language itself is simple)
> 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.
Not true. Kotlin codebases that do the same thing look worse than Scala codebases or have subtle misbehaviours waiting; Kotlin has a huge number of ad-hoc special cases e.g. nullables, async, continuations are all special language features. Kotlin's ability to do error handling/validation is actually worse than Java's (no checked exceptions and no adequate replacement if you want to actually report the details of failures).
[deleted]
> the added complexity that Scala has imposes a lot of cognitive overhead
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.
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.
Before going multi module and needing special control on the build process and having a LOT of code, what exactly hellish do you think someone and a beginner at that will encounter? I have been writing it professionally for 5 years and I find it ok.
SBT is a monster for beginners and experts alike. Haoyi (Ammonite creator) wrote a pretty good article about it [1]
[1]: http://www.lihaoyi.com/post/SowhatswrongwithSBT.html
[1]: http://www.lihaoyi.com/post/SowhatswrongwithSBT.html
For starters, it's build time is rather slow, produces really fat jars of I recall well, and I find the whole code as configuration SBT files complex and easy to get wrong.
Maybe take a look at Mill, a new Scala build system by Li Haoyi (Scala.js). Previous discussion: https://news.ycombinator.com/item?id=16775545
you can use maven with Scala without too many headaches.
"spaghetti monster that Scala can sometimes be" -> I'd like too see an example of a Java snippet that in Scala you can express only with a higher degree of spaghettosity.
Do it. There’s a ton of things you can learn just conceptually and a lot of Amazon for example is built on it so there’s them for jobs and tons of other enterprises that would employ you.
maybe consider cobol instead?
Well, you do have a point in that COBOL jobs are safe places where you don't have a lot of need in staying up to date with the freshest tech, leaving more time for other things in live than code, same as it goes for many JavaEE shops.
However, lots of banks are rewriting their COBOL code in Java, so you might end up writing some Java anyway.
However, lots of banks are rewriting their COBOL code in Java, so you might end up writing some Java anyway.
COBOL developers are highly sought after and well compensated due to the number of legacy systems still around. Many COBOL developers are nearing retirement, so if you are young and know COBOL you will be attractive. Almost no new development though, it is almost exclusively maintenance.
Learn Kotlin! It's a lot of fun. And gradle is a nice build system.
Unpopular opinion: Java is a Flash of the backend.
Bashing Java is unpopular?
I can see how comparing server-side Java to Flash would be an unpopular opinion (since it doesn't make any sense at all).
<engage irony>
Not at all, you should learn a more macho language like C++, where you can suffer, acquire scars, loose countless hours to weird template errors, learn the intricacies of writing code that has to compile on different compilers that don't agree on the syntax or semantics of the language, fight with crappy tooling, use IDEs that barely manage to do auto-completion, encounter all kinds of bizarre hardware and OS behaviour that the Java runtime shields you from, resulting in code that doesn't compile or run anymore every 6 months when part of your compiler or library toolchain changes, and acquire skills that are largely useful only as bragging rights
Not at all, you should learn a more macho language like C++, where you can suffer, acquire scars, loose countless hours to weird template errors, learn the intricacies of writing code that has to compile on different compilers that don't agree on the syntax or semantics of the language, fight with crappy tooling, use IDEs that barely manage to do auto-completion, encounter all kinds of bizarre hardware and OS behaviour that the Java runtime shields you from, resulting in code that doesn't compile or run anymore every 6 months when part of your compiler or library toolchain changes, and acquire skills that are largely useful only as bragging rights
Please don't do programming language flamewars here.
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 used to be painful, but there's a ton of tools that make it easy to use if you know where to find them. Some, like Lombok, get rid of a majority of the "cruft" by enhancing the language itself. Awesome Java is a treasure trove of useful stuff. https://github.com/akullpp/awesome-java
The combination of speed, flexibility, and robustness can't be found anywhere else, Although Go is slowly catching up.