Sure but to truly appreciate either you’ll need to slog through a bunch of POJOs and EnterpriseAwareTranformationalFactoryBeanFactoryCreationTemplate classes first.
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.
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.
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.
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.
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.
> 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.
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 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.
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.
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.
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.
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.
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.
> 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).
> 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.
> 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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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).
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#).
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.
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.
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.
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.
> 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 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.
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
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.
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.
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
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
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.
>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.
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.
Who the heck wrote the Java service you are referencing? Anectdotal, at best, or the result of poor development effort. Incredible startup time? Is it Websphere-based, perhaps? Are you comparines apples to apples? I mean, I haven't seen many Node-based or Go based services that do very much in comparison to what our Java based ones handle--pulling in mountains of data from multiple sources in Cassandra, streaming it through Kafka to make it available to a cluster of processing nodes as well as making it available via our APIs. Are your Go service comparably sophisticated?
There is no way my company could have gotten better results using Node, we have played around with Express and wanted to try writing some microservices using Javascript. Basically, it sucked big time. The speed wasn't there, the tooling wasn't there.
And Go sounds great, and maybe it will be in timne, but the infrastructure, tooling, and libraries just aren't that evolved yet. With Java, you can get things done and have reliable services that run without drama. Also, unlike Node and Go, you can easily hire people who can work on the code, write tests, and support the deployment and monitoring of the system. If I chose to write the same thing in Go and anything went wrong, I'm looking at getting fired, and rightly so since so much of what we produce has implications beyond the language/runtime used.
> 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.
>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.
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 :)
> 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
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.
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.
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.
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).
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
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.
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.
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.
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.
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
> 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.
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.
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)
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.
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.
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.
>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)
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.
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.
164 comments
[ 2.4 ms ] story [ 210 ms ] threadI 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.
However, lots of banks are rewriting their COBOL code in Java, so you might end up writing some Java anyway.
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.
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.
Python/Ruby/Node/Java, could cover like 99% of them maybe. Don't really see where the excitement is.
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.
[1]: http://www.lihaoyi.com/post/SowhatswrongwithSBT.html
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).
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.
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.
The effort of learning new programming languages often seems to be hugely over-estimated.
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.
And Amazon hired Gosling, so interpret that as you will.
Probably 'just in time' as this a Java thread.
Using IDEs since mid-90's, and I used to know XEmacs quite well.
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?
You can get shitty support with just syntax coloring for anything and anywhere of course.
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.
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.
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.
Yes, we'd love to learn all the things given infinite resources.
Learning Java is something that a backend developer can likely do in a week - and so is learning Node.js after knowing Java.
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).
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#).
"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.
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.
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.
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.
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.
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.
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.
In most of the cases it's just a matter of setting a few Java runtime startup parameters.
> If you tell your Java application server "here you have 4GB, use it as you wish"
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
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.
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
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.
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/...
There is no way my company could have gotten better results using Node, we have played around with Express and wanted to try writing some microservices using Javascript. Basically, it sucked big time. The speed wasn't there, the tooling wasn't there.
And Go sounds great, and maybe it will be in timne, but the infrastructure, tooling, and libraries just aren't that evolved yet. With Java, you can get things done and have reliable services that run without drama. Also, unlike Node and Go, you can easily hire people who can work on the code, write tests, and support the deployment and monitoring of the system. If I chose to write the same thing in Go and anything went wrong, I'm looking at getting fired, and rightly so since so much of what we produce has implications beyond the language/runtime used.
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.
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.
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.
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....
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.
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.
Please contribute your own much better written programs —
https://salsa.debian.org/benchmarksgame-team/benchmarksgame/...
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
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.
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.
(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).
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.
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
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.
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.
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.
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.
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.
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.
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?
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.
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.
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)
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.
Fibers, pattern matching, continuations, value types, low latency garbage collector …