Hacker News Reader

Comment by ilovecaching | Hacker News Reader

I understand why Java has to keep on chugging along, but I feel bad for the people that have to be a part of it. It's like watching people keep coal trains going while people are moving to cars.

Why? Besides being owned by Oracle, which is enough of a reason to never use Java ever again, it's also lost the niches that brought it into existence. Java no longer runs everywhere. Java on the web is dead, and you can now write ubiquitous apps in basically every language. There's no reason to deal with the JVM and it's domain knowledge when you can write a nimble Go app for your backend and a Javascript app that will run on mobile, web, or desktop. A VM language? You mean v8 sandboxing and web workers; WASM which lets me write C, C++, and Rust all of which can talk to Javascript APIs. All of my services are stateless and ephemeral. Crashing is expected, and I can use host monitoring tools instead of introspecting the JDK. On the cloud it gets even worse for Java. Why use a meaty framework like Spring when I want to just spin up a bunch of micro services, or have an API gateway kickoff a bunch of lambda jobs.

Java also took OO in so many terrible directions. OO defined by it's creator looks nothing like the enterprise OO that big business sold to commoditize programming, which now only exists as a ball and chain on legacy systems.

One day Java will be like Cobol. There's probably a lot of money for Java developers for many more decades, but god I do not envy anyone that has to do it.

View on HN

Java has evolved pretty far past its strict OOP roots. I haven't kept up with the last few versions, but it added lambda functions way back in Java 8, for example. There's definitely syntactic baggage holding it back in some ways, but it's added lots of features for more modern functional-programming styles (one mentioned in this release is expression-style switch statements).

More importantly, the JVM ecosystem is much bigger than Java itself. The JVM is a highly-optimized, cross-platform, garbage-collected environment on which people have built much more progressive languages that lack the syntactic baggage of Java: Scala, Groovy, Clojure, Kotlin. Clojure is one of the most popular and performant Lisps we currently have, and Scala is one of the closest things we'll get any time soon to a practical version of Haskell. Both of these projects got to avoid building their own garbage collectors, which is an enormous lowering of the effort barrier. And to top it all off, all of these languages' binaries are interoperable, which not only allows you to use different ones for different parts of the same system, but makes it much easier to gradually migrate your legacy codebase to a newer, better language.

I don't know if I'd start a new project in Java-the-language, but it's far from a Cobol situation.

It seems to be a popular notion that adding constructs common in FP is somehow a modernization of C++ or Java. FP isn't a set of features, it's a style of programming. It's actually a bad idea to try to retrofit a paradigm on top of an existing language. You should build tools that do one thing well, and if they no longer suit your style of programming, you should switch to a tool that is designed to fit your needs.

A lot of my reasoning was criticizing the JVM itself, not Java. VM languages add unnecessary complexity in the post container world where ephemerality and kernel APIs (containers) can give the same advantages, although I think Kotlin and Clojure and remarkably good languages.

>It seems to be a popular notion that adding constructs common in FP is somehow a modernization of C++ or Java. FP isn't a set of features, it's a style of programming.

And historically, nobody cared for that style of programming in its pure form (where "nobody" is in the casual sense: a few FP-lovers, but not the 95% of working programmers).

From 1960 to today it remains niche in its pure form, even the most popular language following it fully (e.g. Clojure or similar) is still a niche language.

We found out, on the other hand, that people care for mixing that style of programming with OO, imperative, reactive, and other styles.

And that's what modern JS, Java, C#, Rust, etc (even C++) give us.

And since FP is a style, it can be followed quite effectively in almost any language -- as long as it has some basic features, which, as you observed, Java has added.

Pedantically, you can't just redefine a term to suit your need calling something "pure" or "unpure". There are many other styles of programming that are data oriented and are a better definition for Rust and some circles of Javascript than functional, but ergonomics of composition and partial application leads to something far short of FP.

> We found out, on the other hand, that people care for mixing that style of programming with OO, imperative, reactive, and other styles.

Which is why you forgot to mention Scala, which shows us how great such a promise land can be when we try to please everyone.

> JS, Java, C#, Rust, etc (even C++) give us.

Out of the languages you mentioned, only certain circles of Javascript (React) and Rust are arguably functional as I mentioned above. Javascript has been a real exception to the rule in how its lack of real class support left a vacuum for some FP. C++, C#, Java, and the majority of Javascript are object oriented and always will be.

Pedantically, you can't just redefine a term to suit your need calling something "pure" or "unpure".

No, I think they are using those terms correctly. In FP, “pure” means absolutely no side-effects. So if you add an FP-style library to an existing imperative language, that’s “impure”.

That's not the context in which the word was used, but it's a fair point. I have worked professionally with Haskell, and while I am not good at it (my forte is Erlang which is what I would consider "close to functional"), other developers I have worked with were very good, and watching them code in non functional languages and listen to how they thought about solving problems is were I developed the idea that adding a few features doesn't make a language functional.

> And since FP is a style, it can be followed quite effectively in almost any language.

It's not black and white. FP is more like a spectrum, with pure functional programming more towards the opposite end, just before total functional programming. Put another way, adding lambdas to Java does not make it like Haskell. Even Scala cannot effectively be used as Haskell substitute, as some in that community eventually realised.

It remains to be see how much of FPs benefits (composition, abstraction, reasoning) can be fully realised in languages with rampant side-effects and mutation.

> It's actually a bad idea to try to retrofit a paradigm on top of an existing language. You should build tools that do one thing well, and if they no longer suit your style of programming, you should switch to a tool that is designed to fit your needs.

I categorically disagree. Nearly any program has pieces that benefit from OOP and pieces that benefit from FP and everything in-between. The most prevalent and useful languages support multiple paradigms (C++ is a mess for other reasons).

> The JVM is a highly-optimized, cross-platform, garbage-collected environment on which people have built much more progressive languages that lack the syntactic baggage of Java: Scala, Groovy, Clojure, Kotlin.

Apache Groovy has inherited all of the syntax of Java. When Jeremy Rayner built the Antlr 2 based syntax for Groovy back in 2005, he began with the syntax for Java, then added the Groovy-specific grammar to it. The latest version of Groovy still uses that syntax, so if Java has syntactic baggage, then Groovy has it too.

I'm picking Groovy will still have that baggage-laden syntax for a while yet. 2 yrs ago, Daniel Sun built an Antlr 4 based replacement grammar, but the Groovy project managers at Apache are taking their sweet time in rolling it along. They even had its optional preview removed from the version 2.6 beta of Groovy.

I wasn't aware of Groovy's roots, but that doesn't diminish the point. It elected to take on Java's baggage; the JVM didn't impose it.

No idea that Groovy was designed by the guy of Antlr fame... Pretty humbling TBH.

Check out Kotlin though. It's seriously great and doesn't share lost of the performance penalties of Groovy

> doesn't share lost of the performance penalties of Groovy

That's a bit of a myth these days. Groovy may even be more performant than Kotlin when used with static compilation.

Groovy with static compilation is very fast and memory efficient. In most cases it is equal to Java. Though you are supposed to use Java and Groovy together for maximum performance and developer productivity. Groovy is not a replacement for Java, but rather an extension

What makes Groovy unsuitable as a replacement for Java, if the performance is now comparable?

For the masses, imho, all round Groovy just isn't polished enough and is too complex. We are bringing someone up to speed now and there is an enormous amount to teach. There are a range of pitfalls that you have to alert them to. Mind you, a lot of other Java replacements are like that (eg. Scala).

Particularly though, the static compilation is just not comprehensive enough. It tries to do type inference but it's limited and invariably you end up having to add type casts in ugly places to convince it that expressions are valid. Occasionally it actually flat out refuses to compile something valid and you have to find a different way to do it. Sometimes it compiles with one version of groovy and then is broken in the next. It works great though to selectively add to hotspots of code and in other places to speed them up and define them better.

Having said that, we are essentially using Groovy as a java replacement and for our team I think the above costs are well worth it. This is partly because we have a heterogenous application that is partly dynamic in its nature and Groovy's dynamic scripting ability is amazing for this. The fact we can code our whole back end in the same language makes it super easy and well integrated.

The new parser is available in the Groovy 3 alphas.

The Apache project managers removed the new parser from the Groovy 2.6 betas over 6 months ago after officially canceling it and saying Groovy 3 would be the next release. But no real work has been done on Groovy 3 since then. I'm guessing they really intend releasing version 2.6 some time in the future. Perhaps they'll say "Groovy 3 is still far off and Groovy needs another release, so let's resurrect Groovy 2.6". Don't expect to see Groovy 3 move beyond alpha version anytime soon.

thank you for this comment. it brings a lot of light on the ecosystem

I'm not sure if you're trolling so I'll try to keep this short.

Java is old, it's crufty. Yes.

But it's extremely fast compared to anything but Go, C#, and "low level" languages nobody wants to touch for web stuff.

The JVM is also extremely reliable. I've seen apps run for years straight.

And the tooling is better than basically anything. Profiling, debugging, realtime code generation and modification. Libraries for anything you can imagine. ~4 solid IDE's.

Java's OO is fine, and all the nightmare patterns died years ago. You only see them because Java has been around for so long. Modern frameworks like Vert.X or DropWizard are fairly nice to work with. Even Spring Boot isn't too bad.

But Spring is dated and not often used for new projects.

The JVM has extremely powerful built in monitoring API's that put any other language I know of to shame.

WebWorkers are trash compared to Java's nice threading model. It even supports CPU optimized Atomics.

There's nothing unusual about writing microservices in Java. V8/Node is just as "big" a virtual machine as the JVM except JS runs ~5x slower and takes 5x more ram.

You can also write Lamda in Java.

There's many valid critisicms of Java but yours are largely invalid

> But it's extremely fast compared to anything but Go, C#, and "low level" languages nobody wants to touch for web stuff.

Fast is a poor word to talk about benchmarks between languages. Memory, throughput, latency are the things we should be talking about. There’s also trade offs where predictable scaling of latency under massive load is important (Erlang, Elxir), or spending less memory and starting up quickly in order to scale horizontally is important (Golang), or speed of development is important (PHP, Python), or correctness is important (Haskell, Rust). Java is rarely the winner in any area in favor of being well rounded, but as we should be using tools that meet at least the broad requirements it is always possible to make a better choice than Java.

> I’ve seen apps run for years straight.

This is why Java is dated. I am an Erlang developer, which is known for being hot reloadable and running forever. It turns out this model is actually juxitposed to Kubernetes and severless, which both presuppose letting processed crash at the host level and starting and stopping quickly. This also gets into the tooling argument because profiling in Java would rather the VM be long lived.

> The tooling.

I too have an operating system with great tooling, it’s called Linux. My knowledge of tooling is more broadly applicable, I can introspect any binary and attach probes to the kernel with bpf. Profiling for a VM is table stakes because you’re on your own. Not only do you have to figure out what’s going on in the JVM you also need to duplicate your effort to figure out how the JVM is running on the host.

> Java OO is fine.

OO in general is not fine.

> OO in general is not fine.

I smell a zealot or a troll.

Please elaborate on how OO is fine. OO hides state, which makes reasoning about cache, and therefore performance very difficult, which is why most game programers take a data oriented approach. It hides state but gains none of the advantages of Erlang because all of the implementations forgot to make state only mutable through explicit message passing. Inheritance isn’t an abstraction because you inherit both code and state, which requires explicit knowledge of the intervals of the parent. It’s a code pasting tool. As OO tries to model arbitrary patterns in nature it’s also difficult to reason about the graph of objects apposed to the linear flow of data in FP. Pretty much all of the OO languages are walking back OO features at this point and trying to add type classes (contracts) or functional pieces, mapping and filtering a la linear data transformations.

These are actually all fairly common problems so I'm not sure why this is drowned out in gray...

The over-zealous tone may annoy some people. Also, he/she could have gotten the same point across more effectively without implying that Erlang and FP magically solve all problems.

I actually agree with you here that OO is overused. Java has added quite a bit of FP in recent years though.

Lombok makes immutable data classes trivial. Improved interface support for default methods make it possible to largely ignore OO if you don't want it.

FP is mostly a community effort at this point, but solid. Java Streams are decent for basic stuff like map/filter but RXJava is extremely powerful if you want the complexity it comes with. Vavr is nice for adding more FP types too

True, class inheritance is so hard to get right that is just better to avoid it. Lots of coupling and spaghetti code because of this, but to be fair, you also see this on other languages, like python, php and even JS.

> It hides state but gains none of the advantages of Erlang because all of the implementations forgot to make state only mutable through explicit message passing.

Smalltalk is exactly like that - other objects' state is only mutable through explicit message passing. It's also widely considered the penultimate pure OO language.

> Pretty much all of the OO languages are walking back OO features

About the only feature I can think of for which this is somewhat true is inheritance, and that's because we realized that aggregation is often a better model, and can be easily supported by the language to be no more verbose. But it doesn't fundamentally change OO - it was never about inheritance first and foremost; I mean, prototype-based OO doesn't even have that conceptually.

> and trying to add type classes (contracts)

In most OO languages, these typically naturally evolve out of interfaces.

> functional pieces, mapping and filtering a la linear data transformations.

This is not contradictory to OO in any way. Again, Smalltalk has had "select" (filter) and "collect" (map) from the get go.

Minor question: what does the word "penultimate" mean in your comment?

Not only do you have to figure out what’s going on in the JVM you also need to duplicate your effort to figure out how the JVM is running on the host.

Isn't that true for all other languages you mentioned? python, erlang, php, golang bundles a runtime, etc..

It’s a spectrum. Java is at the very end with Erlang. I have a lot of domain specific knowledge of The Beam. Go on the other hand has a very lightweight runtime.

Very true. Newer languages seem to be moving back towards native binaries. The promised advantages of JIT compilation have faded with improvements to compilers and profile driven optimization.

Go and Rust are interesting to follow. A highish and low level language both using lightweight runtimes

Java would take the cake in almost anything speed measure you mentioned. Golang is the only one comparable in memory throughput and latency. Java with async IO like Vert.X can do higher concurrency than Erlang. As can Go.

IMO Java is the most well rounded language, but I'm not trying to convince you of that.

Also there's nothing with java that stops threads from being restarted. In a modern web framework it's virtually impossible to crash the JVM. You just crash a thread, at most (usually the framework catches the exception and it doesn't even do that). Java is also hot reloadable if you use the right framework.

Your tooling argument doesn't make much sense IMO. You can attach to a Go binary but that's about it. Attaching to a VM or interpreter will tell you almost nothing. I would wager you haven't used a Java profile if you're making these arguments. It's vastly superior to anything but maybe C#

Can do higher concurrency is a nonsensical phrase. Please show me your benchmarks versus Erlang at 10M web socket connections.

You’re not understanding what I’m talking about when I say restarting. I’m talking about the JVM process. I also just said hot reloading is counter to modern practices.

You’re not understanding what I told you.

Newer versions of Java cache compiled classes. The startup time is maybe 10 seconds for something big running Java 11.

You can also compile AOT for some performance loss at runtime but zero startup time. Android has been doing this forever but you can also do it on a PC using Graal.

And yes Java will destroy Erlang at concurrent connections if you use an async framework like Vert.X or fibers using Quasar/Comsat. It has lower per thread overhead than Erlang and runs code faster in general.

Both Java and Erlang will max out Linux TCP connections before running out of steam so this is kinda academic though

If you want to build systems at scale you want to use a lot of commodity boxes, not a few huge or 'special' machines.

I don't drool over the raw horsepower of each of my individual boxes.[1] All I care about is that I can cost effectively create a cluster of them to serve the application's needs.

Because of this, even if Java could not handle as many concurrent connections, you might still chose it over this fabled 10M socket erlang server you keep talking about.

You might chose Java because:

* It is well understood and has a lot of mature libraries surrounding it.

* You can easily hire people to work on it.

* It is a stable language.

And so on...

I would summarize your original post like this: "I don't like Java, I prefer other things," which is fine as far as it goes, but then you basically say: "Therefore, everyone should also prefer the same things I do," which does not follow.

[1] I never particularly cared how many fps I can get on my machine, and I'm not that chuffed about my machine's geekbench score. IMHO this obsession with hardware metrics beyond diminishing returns is mostly a gamer thing.

> There's many valid critisicms of Java...

Yes there are.

...but the parent assertion that Java will one day be like cobol; no longer taught in intro to CS course (where now we see python), considered bloated and legacy, and not picked for new projects (where we see the rise of languages like kotlin eating into what was once the primary growth for the language with mobile apps) and encumbered by problematic licensing issues...

Seems quite valid.

You have to live in a bubble right now not to get the feeling Java is stumbling, and there’s no indication to me that the overall direction of the language is positive right now.

...I’m sure there are still years ahead for earning a good living as a java developer, don’t get me wrong, but that’s a different issue.

I agree that the future looks bright for Kotlin and C# .Net Core especially. I'm also a big fan of Typescript but JS derivatives are missing many nice things like threading.

But I disagree that Java is like Cobol. The syntax and general situation is extremely similar to C++. There's still tons of work being done on it, but it's a mature language that will be around for decades. IMO it's still the best language to run on the server for a multitude of reasons.

Like COBOL in the sense of its purported future niche in the industry, not in the sense of syntax and language power.

Yes perhaps that's true. I ask you to consider some c++ to java conversions though. Usually the syntax is almost identical, whereas COBOL is clearly terrible

May be I am living in a bubble... it's always hard to tell from inside the bubble. But this is not my impression at all. All of the major tech companies have major Java footprint which is not going anywhere. This is not only the older tech companies (FB, Goog, Amazon etc.). Even newer companies like AirBnb, Uber rely heavily on Java. Startups often start with fancy esoteric languages but eventually do come around to java/c++/python once they need to really scale. I am not sure what exactly gives you the impression that Java is like Cobol.

Agree, and yeah Java is peaking "uncool". But I don't care. Call me old fashioned but the damn thing works so good I can forgive a multitude of sins

I see the same in major enterprise companies I and my peers have worked in. Java is being used for a lot of large greenfield projects I am aware of.

Yes, the enterprise bubble where Java, .NET, C++ and JavaScript rule.

I mostly agree, except:

> But Spring is dated and not often used for new projects.

Spring Initialzr (https://start.spring.io) is used millions of times per year.

Fair enough. The Java ecosystem is huge and I try to keep up but many things slip through the cracks, you'll find many in my furious comment history on the thread.

Thanks, looking it ip

No worries. I feel where you're coming from.

Spring Boot is all but dated. I could name you countless huge companies using Spring Boot to write new applications that will be used by millions of people per day in Austria alone.

Serious question: Isn't Java still one of the default languages if you are choosing a "safe" language to build and maintain a large piece of software? Considering how long it's been around and how many libraries exist for it now, i've generally viewed it as a language that's:

- fast enough for most things without a lot of pitfalls/gotchas

- easy enough to read for most developers

- easy enough for most developers to pick up if they've never used it, even if they aren't exactly enthused by the idea of doing so

- supported enough that you'll never be the only person who is debugging something

- widely used enough to never be alone when you are trying to use it in unsupported ways

- has commercial support from multiple companies

Basically all the things that a lot of "enterprise" companies love.

Edit: formatting

All of those points are also true for C#, which imho fixes a lot of Java's problems and is a much nicer language. With .Net Core maturing you even get the "runs everywhere" factor (at least everywhere you care about, i.e. Win+Linux+Mac), and Microsoft is a much better vendor than Oracle.

I'm very happy to see .NET Core getting more stable and mainstream (I miss my days of working in C# even though I don't miss Windows) but I think running it on Linux for backend microservices still counts as fairly off-the-beaten-path compared to the safe, "no one ever got fired for doing X" choice of using plain ol' Java.

Yes, albeit with noticeably weaker libraries/ecosystem.

You can still have a more modern language i.e. Scala, Kotlin on the JVM whilst not abandoning the unparalleled array of libraries that the Java ecosystem offers.

As someone that works with both stacks since their inception, there are tons of platforms with Java compilers, where .NET Core isn't even a thing today, and there are tons of .NET libraries that will never leave .NET Framework.

So it isn't like just exchanging one for the other like that.

I'm finding library support quite good for .NET Core tbh. Not perfect, but it's not at all a barrier to adoption.

Try to port any commercial component library to it like Telerik and friends, ODP.NET, WCF, EF 6, Forms, WPF.

.NET Core 3.0 will fix some of the compatibility issues but not all of them, for example EF 6 will only be partially supported (VS DB tooling is not being updated for Core).

Yeah .NET Core 3.0 will address some of that, not all. I suppose for any brownfield development looking at switching across those things are the potential blockers at the moment. Especially things running EF where EF Core doesn't have a particular feature just yet. But EF Core development is cracking on at a good pace.

Telerik and the likes I'm not so fussed about personally. I suppose DevExpress is another one on that list. I think front end component libraries like Prime-ng/PrimeReact are probably the way to go for the future of UI development for Line of Business applications.

Overall I reckon in a couple of years there won't be much of those blockers left at all.

I gotta ask what in particular "problems" C# solves over Java, and I'm not talking about J2SE 1.4. Having dipped into C#, it feels like the designers resented OOP and reusable code. C# is not the new kid on the block and is almost 20 years old now.

Over that 20 years, C# has been continuously improved with language features added at a faster rate than Java. Some examples: * properties * LINQ * async/await * dynamic types * better generics * inferred typing - `var` * null conditional operators * custom iterators - `yield` * pattern matching

Also, .net is more of a “pit of success” language — Java with all its legacy baggage requires a lot more knowledge to avoid mistakes.

so... properties that require a steeper learning curve, a system that's worse far worse than JPA+Spring Data (or you could use the hibernate in both languages - a java development), another word for var/let, I'd disagree about generics, var/let again, I wonder what rust devs would say about these null inline conditionals that require more knowledge, and... yield is actually neat if also not another non-traditional baggage thing to learn. Anyhow, I guess my take is that Rust is a better language than C# in all the ways that C# might be better than Java and more... Except that C# is a lot like Java and is the language of choice if you use Unity - so it does have a big awesome ugly library that Java does not have. Really we should feel sorry about all the Unity baggage C# devs get to deal with. Then there's Microsoft land, which has not inspired me of code quality and can't get out of VB think.

Hibernate is an ORM. LINQ is just what the name says it is language integrated query. Linq is understood by the compiler, translated into expression trees at run time and then any third party provider can translate it to the destination language. You can pass Hibernate expressions around and depending on context, they can get translated to regular IL when working with Lists, Sql when working with RDMSs or MongoQuery when working with Mongo, etc.

> it feels like the designers resented OOP and reusable code

Can you give some examples, that wouldn't be equally applicable to Java?

Polymorphism and inheritance by default?

You mean the fact that methods aren't virtual by default?

As Hejlsberg explained, the problem with virtual-by-default is that every time one of your public methods calls another public method on the same object, it makes it that much more complicated to reason about your invariants. If the called method is non-virtual, then you're in full control, and you know exactly what happens. But if it can be overridden, then you need to define a contract for overriders to follow, and you can't assume that it does anything other than what's expressed in that contract (in particular, you can no longer call that method without ensuring that all class invariants hold, even if it's expensive). Furthermore, the overriders often also need to know which other methods on the class do or do not call this method.

In practice, this is so much hassle that not even the Java standard library does that. For example, given ArrayList, if you override add(), does that affect addAll()? The docs don't say. So in practice, the only things that are safe to override is what the docs say are safe to override... which is to say, exactly like "virtual", except it's not enforced by compiler. Overriding random methods often works, but is a hack not dissimilar to using Reflection to access non-public members - even if it works, you're relying on implementation details of the class.

Maybe it's less of a C# thing, and more of a Unity thing - but I'd say that Unity has some major architectural anti-patterns - which may just be to appease the ease of a the awesomeness of a wysiwyg type game engine.

The problem with C#, which I think is a fine language, is the small(ish) size of the ecosystem and the refusal of the ecosystem to deviate away from non-MS endorsed libraries and frameworks.

It's the ridiculously large JVM ecosystem that makes Java awesome, not the language.

Yeah, I definitely feel this some days. I've just moved over to C# from Java because I'm bearish on Oracle as a vendor in general, I find C# great and impressed with Microsoft's efforts as a vendor with what they've done with .NET Core.

I have love for Java, but I gotta say it mostly is because the ecosystem is pretty fantastic. So much open source stuff for so long means it's all just there and it all just works. There are some gaps though.

.NET ecosystem isn't bad. It's pretty good. There are some phenomenal libraries. But sometimes the gaps are painful. The lack of an open source (read FREE) integration framework is a big one for me. There is BizTalk but that's commercial and probably expensive. Same with scheduling libraries. HangFire looks great but it's paid. A lot of the really high quality stuff you have to shell out for which when you're just hacking in your own time is not feasible. That being said there are open source libraries and some of them aren't bad. Lots of great stuff in general.

Completely agree, except that MS was so crazy hostile to OSS that they scared off all the serious guys a decade ago. I wish them the best. The CLR has some compelling features that make it objectively better than JVM on so many levels.

But the lack of ecosystem is killing them. And has been forever. The new MS CEO is great in my mind but it will take many years to turn the ship around. Devs don't forget.

Best example I can think of (was a C# guy for years). Resharper has been around forever. But it costs a lot. This is par the course for C#. I can get the same thing in Java by pulling in a few linters with Maven, and it's all free. Because MS scared away everyone that was afraid of licensing fees (ie most academics, the sharpest devs out there), there's nothing comparable.

Same with C# port of Quartz and so many others. They killed off the real rockstars among us that create the majority of libraries that everyone else uses.

Can it be fixed? I hope so. The CLR is great and Oracle sucks. But for now there's a good reason Java is dominant

Resharper is $139 a year for a personal license and the price goes down 20% after the first year and 40% year after that. You can also pay monthly.

They also have a perpetual license. If you cancel after the first year, you can keep using the version that was current 12 months ago.

But the one thing missing in Java is anything like LINQ. I don’t mean the syntax I am referring to the idea of LINQ -> expression trees -> third party providers that translate LINQ to another language (sql, Mongo Query, etc.).

It's not built in to the language, but JOOQ and QueryDSL come fairly close.

I do miss LINQ though. The Java options are all clunkier because the type system isn't nearly as flexible

I can't tell from looking at the examples, but can I do things like pass around arbitrary expressions:

  Person.Get(p => (p.Age > 65 && p.Sex == "M") || (p.Age > 63 && p.Sex == "F"))

and have a method

  public List<Person> Get(Expression<Func<Person,bool>> expression)

and have that expression interpreted correctly at run time by separate providers?

You get full compile time checking and IDE supported autocomplete.

Yes. But it's done in a different way than C#. C# supports fields and field references so you can pass them directly to a function.

The Java code "looks" like they do the same because they generate code to simulate method references instead. It's pretty clever and Javas code generation support for Annotation Processors is excellent and makes it possible to do this in a cross-ide cross-build-system way

LINQ and JOOQ/QueryDSL all work on plain data objects with fields. But with Java you do it on a pseudo object generated from your existing classes

That's really interesting.

All of these years I've been beating up on Java for lack of something akin to LINQ. I guess I'll have to find something else to complain about.....

IMO LINQ is still better because of how integrated into the language it is. JOOQ and QueryDSL were basically designed to replicate it as much as possible but not nearly to convenience levels of LINQ + Entity Framework

> Isn't Java still one of the default languages ?

Yes.

There is no need to engage the GP - let him rant about Go and JS. Java is still huge, for both legacy and new projects.

For context - I started as a C/Kernel dev. I also spent 2 years with Java on mission critical backend code. Both have their uses.

> it's also lost the niches that brought it into existence

Applets, JavaBeans, and CORBA. What a loss.

> Besides being owned by Oracle, which is enough of a reason to never use Java ever again,

That stopped being an issue years ago. OpenJDK is a thing, you know?

> Java on the web is dead,

I don't think you have any idea about the hundreds of millions of lines of Java that power the web as you know it today.

The rest of your post is filled with equally uninformed claims but I'm going to stop here.

> Java on the web is dead,

>> I don't think you have any idea about the hundreds of millions of lines of Java that power the web as you know it today.

Presumably they meant Java in the client, not the server.

"Presumably they meant Java in the client"

Android?

They are talking about his https://en.wikipedia.org/wiki/Java_applet

Which were absolutely everywhere at the turn of century.

So, yeah...if you are only thinking about web applets, which died over 20 years ago, and ignoring Android, which runs on most of the world's phones, I see why you might think "Java is dead."

Thanks to WebAssembly it is back.

http://teavm.org/

The web client specifically

Java on the web is a reference to applets running in the browser.

Yes, Oracle, the company that sues people for breathing the same air owning Java is an issue.

Maybe I am uninformed, but you haven't made a good case that there's any truth to that.

Do you know anything about Java? I'm not trying to be insulting. Java has its problems, but your points are so far off the mark. Applets haven't been a thing for 20 years and I'm not sure they were a thing then either. Do you know people make web apps in Java and there's a ton of quality open source libraries out there?

I developed Java (Swing, Spring, JavaFX), managed tomcat deployments, good stuff.

I think my question is, do most Java developers really know what goes outside of their window? Every language has a good story for web apps these days. The web is ubiquitous. You can write in Phoenix, Cowboy, Rails, Sinatra, Express, "net/http", Django, Laravel, Flask, Rocket... Java is literally middle of the pack at best. So that's not a compelling reason to use Java. So then we have to look at the rest of Java. Is there anything else in there that would make it better for web dev than a simple Go/Ruby/Python/Javascript/Rust/Elixir app? No? Ok, then let's not use Java. Java excels at being mediocre at everything, but the best at nothing.

We rather enjoy the state of the art IDEs, JIT and GC compilers from Java and .NET, while slowly enjoying watching hipster startups rewrite their stacks when customers come flooding in.

Ask Twitter how their Rails apps is holding on.

> Java is literally middle of the pack at best

A warm JVM is faster than a greased millenium falcon.

Worked on a project to replace all Applets in a large enterprise product just a couple of years ago.

There is a lot of software running in this world. Some of it is very long lived.

Oracle owns the Java name and its implementation.

Other open implementations exist from Amazon, IBM, Microsoft, Zuul etc. And they are all using the JDK name which isn't owned by Oracle.

If Oracle were to die or become aggressive the Java ecosystem would just move on and not skip a beat.

Our company (on the scale of running it's own private cloud) has switched over to OpenJDK. Oracle is a non-issue for us

For people actually working with JVM and the languages on top of it, nobody really is worried about Oracle. The way the licensing is set up, they just don't have enough power to coerce people to use their version. It would kind of be like the SCO case if they came after it. I think they went after Google for Android simply to protect their IP, and that one they even "lost" (which detracts also from their possible future lawsuit on enforcing Java licensing)

As a believe in free and open source software, I think this is a very head in the sand approach. Any portion of Java, even if it's just a certification being open source is enough to run away from it when there are so many alternatives that are better languages and completely open source.

OpenJDK is GPLv2. I know of only a handful of other, popular languages with a license as copyleft as that.

I liked CORBA! I'll take it over whatever lackadaisical JSON silliness we have today.

Amen. Its a sad state of affairs when the middleware we had 25 years ago was faster and more robust that what we have now.

>>> That stopped being an issue years ago. OpenJDK is a thing, you know?

Well, that's seeing the glass half full.

OpenJDK was complete garbage in the java 6-7 era, less than 5 years ago. Pretty much every major java software was requiring to install the Oracle JDK. Nobody would accept a bug or a support issue if it happened with the OpenJDK, which was the first question to be asked. And that wasn't fear mongering, java applications that worked perfectly fine just didn't work on the OpenJDK.

It is better now. I personally haven't seen an OpenJDK JVM crash in a while.

Yeah this was a problem for 6 & 7, but I've run plenty of code in production on OpenJDK 8 without issue. I think Java 8 was the first version where OpenJDK was the reference implementation so that likely helped a great deal.

That stopped being an issue years ago. OpenJDK is a thing, you know?

If Oracle's ridiculous interpretation of API copyrights holds up, they have a kill switch for OpenJDK.

Just like Google's ridiculous interpretation of the licenses of others being worthless.

https://www.youtube.com/watch?v=ZYw3X4RZv6Y&feature=youtu.be...

So far I did not find anything comparable to replace Java for website server language. Go is a terrible extremely verbose language without vital features. JavaScript on Node is limited by single-thread and JavaScript itself is a terrible language (along with other dynamic languages like PHP, Python, Perl, Ruby). Rust is awesome, but I don't think that it'll be ever usable for mediocre developers, therefore it can't be a safe choice for ordinary project.

The only reasonable alternative is C#. But it has to go a long way to reach Java's level of stability and trust on non-Windows servers.

Bit of a Go fan here so just wondered if you'd qualify what you mean by: > without vital features

Vital features is double speak for any Java feature that isn’t in Go.

Beating a dead horse here - but Streams and Generics are now what I personally consider vital features. Code is much more compact and elegant with the proper application of these two features.

Error handling via exceptions and generics are things that I can't live without. Go moves in that direction, as far as I understand, generics are expected in the next versions of Go and error handling somewhat improved, so may be it'll be good enough after few years, but I just can't write current Go after Java, it's like running with chained legs.

Other than what the other posters mentioned, you have things like annotations in Java that allow for cool features such as validation and constraints, and auto translation between types. This is extremely verbose and error prone in golang because no such mechanism exists.

Assuming you meant specifically the Java language, Kotlin for JVM may also be a good option. Solid set of language features that puts it at least on par with C#, and allows you to write more DRY code than you can with Java language. As with any JVM language, you get all the benefits of the JVM. IDE support is great (at least with IntelliJ IDEA). It's an officially supported Android development language, putting it further into the mainstream. Also, as with other non-Java JVM languages, releases are not tied to JVM releases (I still use Java 8 for my Kotlin projects, while using the latest Kotlin version).

For browser or Node.js, TypeScript is the way to go IMHO. Node.js and it's ecosystem have it's issues, but TypeScript is quite nice and a considerable improvement over JavaScript, while being close enough to JS where it fits nicely into the ecosystem. Only downside is that it adds a compile step that can potentially grow to be time-consuming.

Yeah, I mean all Java ecosystem and I, personally, prefer Kotlin too.

Kotlin is a drop in replacement for Java these days. I've switched a few projects now and mix Java and Kotlin during the transition. IMHO Kotlin is a breath of fresh air if you are coming from either Javascript or Java. Typescript is close but it is still javascript and it has a few inherent limitations because of that. Kotlin-js is basically a dropin replacement for that as well.

LASR 14 hours ago [dead] [-]
> JavaScript itself is a terrible language (along with other dynamic languages like PHP, Python, Perl, Ruby)
You know, I used to think that languages had a single axis of Good. And each language sat at a certain point in that one dimension.
After several years each of experience writing large web applications using C++, Java, C#, JS, Python, Ruby and Go, that mental model of languages being good, bad or terrible seems incredibly naive now.
But overall, if someone were to ask me to write a web app today, I would probably use Python server-side and break it down into microservices. Client-side, probably just pure js + HTML5 APIs.
Why? Because I don't have the time to argue about languages being better or worse. I am too busy writing code that does useful things.

In a high-skill rockstar team, dev time is by far the most expensive resource. In a startup environment, using your dev time wisely is the difference between a unicorn and a failed business. Nobody gives a fuck if your route handler executes in 1ms or 20ms. I'll gladly pay the 20x hosting costs if that will get my feature out to customers a week earlier.

i don't know why this comment was downvoted so much. i fully agree with every point that LASR makes. if you disagree, i'd like to see your counterpoints please.

It's fascinating reading a post like this because I feel exactly the same from the opposite perspective.

I feel bad for people trying to write in other languages and manually re-inventing dozens of features the JVM ecosystem just gives you for free. In many ways, the whole container-push has been essentially people trying to achieve what the JVM already gave you (isolation, cross platform, etc etc). I still don't see anything equivalent that doesn't impose huge burdens of complexity (which java does have but it's a known quantity with two decades of maturity).

That's how much people hated writing Java. Also, Erlang would like to have a word with you.

> That's how much people hated writing Java.

or, they are more concerned with shiny new tech rather than using a mature and well-tooled out stack that doesn't sound sexy. I for one, don't need sexy tech - i want my app's domain to be the shining star, not the tech stack.

> the whole container-push has been essentially people trying to achieve what the JVM already gave you (isolation, cross platform, etc etc)

Google did containers in Borg many years ago, and many of its servers are written in Java.

Yep, WAR and EAR files with J2EE servers.

When I stopped caring about POSIX.

I'm using Java every day to deliver software that works to people who want solutions to their problems. It's interesting and enjoyable. No need to feel bad for me or any of the other folks happily solving real world problems in Java!

The Java Platform is state-of-the-art in compilation technology, GC, and monitoring/management; nothing else comes close on almost any one of those, and certainly not on all of them combined. The alternatives you mentioned are all "good enough" for some use cases, but are technologically years behind the JVM. Some people are fine driving a Hyundai, but others want to drive a Ferrari. Besides, if you need to write some serious software that has to be performant and manageable and that you're going to need to depend on for years and years, there really aren't that many alternatives. That's why Amazon and Netflix and Google and Apple and Twitter choose Java to run all/most/many of their backend. Such large companies tend to use Java more on new projects as they grow (that's the case with Facebook and GitHub).

It is true that for smaller, less demanding software, there are many alternatives, but except for a very short period (~2000-2005) Java never dominated that kind of software. Early on people used VB, FoxPro and Delphi for that stuff, and later PHP, Python and Node.

There's definitely alot of 'enterprisey' java code out there but that has more to do with the way people code than the language is now. Functional programming(.sort, .map etc) introduced in Java 8 allows more concise code and less boilerplate.

Even with Rust, Go, and .Net core out there it's really hard to beat Java's battletested libraries/frameworks and excellent tooling. Java is still very relevent today and will probably still be for a very long time.

Battle tested and tooling really aren't compelling arguments anymore, Java is very middle of the pack in both regards. Go is running as the basis of the next generation infrastructure in Kubernetes, Prometheus, Docker, Terraform... Elixir has revived Erlang, which now has great tooling in mix and is well known for being highly reliable. Go, Javascript, and Rust all have real package managers (even Go with mod) that are bundled with the language and come with auto formatters, vetting tools, etc.

Also, funcitonal programming is a style of programming, not a collection of features. Just because you have a map and sort method and a hacked in lambda syntax doesn't make Java anything less than OO. Multi-Paradigm usually means one paradigm with a bunch of extra crap in there to make bike shedding easier.

> Just because you have a map and sort method and a hacked in lambda syntax doesn't make Java anything less than OO.

Maybe not fully functional programming, but something that's quite pleasant to work with to be sure.

If you're really that much of a language snob then you should checkout kotlin. It has seamless integration with Java and has the _best_ ergonomics I've encountered language wise.

Go can't even get it's packaging story straight and once again doesn't have generics which makes 'functional' programming a no Go;)

Generics have nothing to do with functional programming.

I actually really like Clojure (really I just love Lisp).

Go also has modules now.

Pervasive use of HOFs is kinda difficult without generics or some equivalent.

> Go is running as the basis of the next generation infrastructure in Kubernetes

And it requires acres and acres of generated code, a custom runtime dynamic type system, whacky module names for compatibility instead of a reliable build system like maven, to make the thing work at all. Kubernets is a multi-megaSLOC advertisement for the virtues of Java as an ergonomic experience.

If it had remained in Java it could be incrementally ported to Kotlin. God, what I wouldn't give for that.

That's an impressive rant and can't disagree with some of it, but you're nearly a decade behind in your assessment of java in the Enterprise. New deployments of EJB apps have dropped precipitously (never should have existed), and Java still enjoys wide Enterprise use.

Part of the reason big businesses were able to abuse enterprises with their abominable Java server stacks is because corporations were slow to trust open source. But developers persisted and open source became too compelling to ignore, creating the upward pressure to embrace it and break the bloated and overpriced enterprise app server's stranglehold. This likely prevented the demise of Java that you suggest has happened.

In fact, when it comes to enterprise these days, you're pretty much either a Java or a .NET shop.

The large majority of enterprises I work with use both, depending on the use case.

The Java ecosystem is still there and still rich. It didn't go away or stop growing because golang was released.

You'd rather use wasm to write c to talk to javascript apis? Your case against Java might be more compelling if it wasn't so gross itself.

You're only rich if everyone else is poorer than you. At the point Golang, Javascript, Ruby, and Python (these are just the ones I use) have huge completely open source ecosystems. Java's ecosystem is no longer a convincing argument that we should ignore everything else about the language and it's place in the current line up.

No, they are all rich. But I would really hesitate to compare java to js, python, ruby, etc. They aren't as interchangeable.

I use all those languages too. Use the right tool for the job. Don't be dogmatic. And don't disparage others.

Would I start a new project in Java? Probably not. But I might reach for other jvm languages that were mentioned elsewhere. I'm definitely not too cool to work on an existing Java project. It's fine.

Don't conclude that someone is being dogmatic without compelling arguments. Java is a technology, it's ok for it to be superseded by changes in the landscape. I also never said that people should stop using Java, I simply said I felt bad for the people that had to work with it given that it's obsoleted by improvements in sandboxing, package management, and language design.

This seems a bit uncharitable.

I still use Java a lot for application servers[1] and enjoy it.

I've also used Go, but I wouldn't want to try and implement, say a non trivial REST server with it.

I don't have the time to code everything from scratch, or to use an immature Go library or framework for example, when there are perfectly good ones in the Java world.[2]

Perhaps it might be best to just see languages as tools, and that each language has a purpose.

Java is old, so what? Lots of people derive value from it, and it's very stable.

You might be glad that banks use it, instead of immediately jumping on whatever languages you mentioned above. At least it manages to do boring things like keep you accounts relatively safe from hackers.

[1] https://www.dropwizard.io/1.3.9/docs/

[2] And yes, for that kind of application, unchecked exceptions are way more convenient than thousands of lines of if err != nil all over the place. And annotations in Go are an afterthought and it shows.

The JVM powers Kotlin, Scala, and Clojure, which are all as sexy as golang.

way sexier actually

Why use a meaty framework like Swing

I'd suggest updating your misconceptions regarding Java before posting Yet Another Tirade about it.

E.g. the Javascript module/npm ecosystem is an absolute mess compared to any sane package/project description system, yet few people would disqualify JS for it.

>I understand why Java has to keep on chugging along, but I feel bad for the people that have to be a part of it. It's like watching people keep coal trains going while people are moving to cars.

Yeah, those poor devs with a rock solid, best of class, platform to write code on, with tons of libraries and tooling.

>Java no longer runs everywhere

It still runs everywhere where it matters. Nobody really cared if it could run on crappy smart tvs and other such BS SUN tried to push it. 99% of Java use has been for server work and enterprise development, and it remains there.

And on mobile, well, Android uses basically Java with a name-change.

>Java on the web is dead

Java on the web (Applets) was DOA, and has been dead for over 15 years. It's not gonna make any difference now.

>and you can now write ubiquitous apps in basically every language

Which again is neither here, nor there. People have been using Java as a very strong language for backend systems, application server side work, and enterprise stuff. And those deploy on at most one OS 99% of the time.

They don't use Java like e.g. Electron or QT. The only Java apps that are like that and are mainstream are basically IDEs.

>There's no reason to deal with the JVM and it's domain knowledge when you can write a nimble Go app for your backend and a Javascript app that will run on mobile, web, or desktop

Whatever.

>A VM language? You mean v8 sandboxing and web workers; WASM which lets me write C, C++, and Rust all of which can talk to Javascript APIs

How hipster. Meanwhile others do real work on Java, with finetuned GCs, mature libraries, and so on. I'm not sure where you've seen all this "WASM and Rust", as both are not even blips in production compared to Java adoption -- and wont be for a while, if ever.

>All of my services are stateless and ephemeral

Mine don't care much for the latest fads, so there's that.

>On the cloud it gets even worse for Java. Why use a meaty framework like Swing when I want to just spin up a bunch of micro services, or have an API gateway kickoff a bunch of lambda jobs.

I'm not ever sure what Swing has to do with a Cloud java deployment. Perhaps you meant Spring, but even so, it doesn't make sense.

And of course with Java you can always use something like Vert.x, which tops the performance charts for microservice work -- so much so, that the others are not even on the radar.

>Java also took OO in so many terrible directions.

2010 called, they want their arguments back.

Also, not sure if you've noticed, but Java is still in the top 3 of most in demand languages (along with JS and Python).

Perhaps your ideas about its death are premature, if not deluded?

> Whatever.

You have me convinced.

Well, for better counter-arguments you first need better arguments.

(And of course you skipped all the non-whatever points where you didn't have anything to respond).

We should print out copies of this comment, and laminate them, and give them to anyone who thinks that comments on HN are good, as an educational resource.

Limiting personal freedom is what the enterprise Java ecosystem is all about.

This is why people are calling you a zealot.

I think you meant Spring, not Swing, when talking about cloud frameworks.

And from this it seems to me you are somehow biased against the java ecosystem without hands-on experience to base your opinions on.

Edited, it was a slip of the tongue.

> Java also took OO in so many terrible directions

Java basically copied (and cleaned up a bit) C++ OOP of the time. Don't blame Java for any bad direction, it was following rather than leading.

I blame them both. No I don't really, there's historical context there, I only blame people who continue to push OO after 2020.

There are a huge number of Java programmers who know very little if anything outside of it, who've geared their entire careers towards learning the Java ecosystem and don't want to learn anything else.

There are also thousands of companies which are focused on Java, Java, and more Java. Many schools are also geared towards churning out more Java engineers, and people who don't yet know Java want to learn it because there are still so many Java jobs around.

That's a lot of inertia to overcome.

Maybe this is where Kotlin fits in.

Im loving it, i analyze and fix issues across a lot of platforms and languages and for me java is probably the least troublesome of them all. you will see a lot of good practices and standards established that when trouble hits which i find rarer in java its usally also easy to deal with. Not gonna mention other names but i find the practices and maturity of a lot of more hip languages lacking a lot still.

Two things (among many) you will be missing when targeting WASM vs JVM: Garbage collection and mature profiling tools. Each of these is bigger than many language features in my experience for writing production software. I would gladly write Java 1.0 if it was the only way I could have them. But in fact I can choose anything from Scala to clojure.

"One day Java will be like Cobol." I heard that one two decades ago about Java.

I wanted to ask him how he felt about UNIX

Two decades ago, Java was 3 years old.

It's still true, though, but it's a compliment. Most languages have no hope of ever becoming the next COBOL. For Java, it is practically a certainty, even if Oracle were to pull the plug on it this very moment. It's too big and too important to die.

Well I wish predicting future is this easy , as of now the place where I work we use lot of spring (Spring cloud) completly microservice and it is only reason I believe java is still alive. Spring makes things lot more easy for us atleast. But I have to agree with you regarding Oracle May be you will be interested in this article https://spring.io/blog/2019/03/07/has-there-ever-been-a-bett...

Ironicaly I'm the other way around. Java is a pretty good platform, save the GC pauses.

However I really dont see what benefits Spring brings. Spring Boot is great for prototyping and trivial apps, but for big systems you really want to break it apart. DI is better done with ServiceLocators. Some of the smaller libraries like Spring Shell, Spring Mobile are junk. And I still see lots of XML config that you dont know if they'll fail until you try to run them.

"Spring Boot is great for prototyping and trivial apps, but for big systems you really want to break it apart."

Any practical advice for making this happen? I have a Spring Boot system I wrote and am responsible for, but now I just want the pain to stop.

You need to take the library approach. It's much like react vs angular. With angular, and spring, you get a ton out of the box but much is mediocre.

Like React, you can out together your own "best of breed" java stack. It just takes a lot more work.

Look to replace one component at a time. For DI Guice or Dagger2. For REST Vert.X or Jersey. Logging Logback. Metrics, DropWizard Metrics. OAuth ScribeJava. Hibernate for Spring Data.

Take a look at the "awesome java" repos and choose your poison.

I'll warn you now that while you can end up with something far better you lose the coherency of Spring. Of your organization doesn't have a good "apprentice" setup all the new devs will be utterly and hopelessly lost. And good luck finding a Dev that knows 20+ libraries vs "Spring".

Rolling the libs was worth it for us but probably not a lot of eng orgs

If you're just looking for a drop-in Spring replacement you can't go wrong with DropWizard. It's a solid combo of best-of-breed libraries and has quiet support/adoption by many huge companies

I am not sure what else are you looking for, Spring boot/cloud has pretty much all you need to build any application.

I know Spring and Spring boot are very popular, but I don't understand why. The Spring Boot home page says, "Spring Boot makes it easy to create stand-alone, production-grade Spring based Applications that you can "just run"."

What does that mean? What does Spring Boot give me that Tomcat doesn't?

What code are you writing that Tomcat runs? Are you coding against the servlet spec? Or are you using something like dropwizard?

Tomcat is a servlet container that implements various Java EE specifications, such as the servlet spec, jsp spec, etc.

Spring encompasses many different libraries. The most widely used is probably Spring MVC, which builds on top of the servlet spec to make building web applications easier. After that Spring Security is probably most widely used, which adds things like auth, CSRF tokens, etc. Spring Data and Spring Cloud are also somewhat popular. There are many more Spring libraries, but I have little to no experience with them.

You can really give or take what you want here. You can use Spring MVC with Spring Data, or Hibernate, or JPA, JDBC, or whatever you want really. One place I worked used Spring MVC with home grown security and ORM layer.

Spring Boot brings "convention over configuration" to Spring. Because Spring is so configurable it can take a lot of boilerplate. Spring Boot removes much of that boilerplate for certain use cases and has, generally speaking, more user friendly defaults.

Spring Boot also runs off a server embedded in the jar. That's why you can "just run" it. You create a "Main" method. You can choose from several embedded servers, including Tomcat. But this isn't exactly special for Spring Boot because you could do this even if you didn't use Spring Boot.

Thanks - that's a good overview :)

Most of my apps just code against the servlet spec with a JDBC connection to a MYSQL database, sometimes with JSP. Perhaps because most of my business logic lives on the client I've usually found that plain servlets + plain JDBC calls were sufficient

Although I've found it pretty straightforward to configure servlets in Tomcat I can see that Spring MVC makes it a little easier. Maybe the introduction of a framework 'Model' is also an advantage - I'll investigate further.

Regarding Spring security - would I use this package if I was implementing a "Login with Email/Password or Facebook or Google" feature to a website?

One nice thing about Spring Boot is that you can mix and match. You can assemble stuff very quickly using the starters, or you can use your own stuff. Pretty much any level of abstraction is supported -- Spring Data spans the range from "thin convenience wrapper over JDBC" (JDBCTemplate) to "completely autogenerated RESTful endpoints based on JPA models" (Spring Data REST). In web land you can use raw servlets up to fully-dressed domain objects. Whatever you want, Spring can either fill in the gap or politely yield the floor.

Not forgetting that dependency injection -- the original core feature -- is just the bee's knees.

I work for Pivotal, but not on Spring. But I've definitely grown to appreciate it more and more over the years. I deeply miss it when mucking about in Golang.

I only need to run a few different applications and they require very little boilerplate to get this to work. Spring just gets in the way and makes simple things complicated.

You know, libraries. Java as a language is pretty bad but the number of good libraries available is insane. You are not coming anywhere near with other languages with this. Also, many of the big data stack applications have Java as a primary language so the libraries are pusblished as Java libs first. As it was several times on HN people do not only chose languages they chose ecosystems.

As the world around Java advances, people need libraries for different things. The question is, of all those libraries, how many of them do I actually need, which ones are maintained, and is it worth the cost of Java. Many languages, like Go, have first class seat in cross platform cloud and containerization that is hard to beat.

Though I also have sympathy for those stuck in it, I kind of wish it would die just so I didn't have to be afraid anymore that I'd one day get stuck with having to use it after a sad sequence of bad luck ending with having to take a job in desperation.

Reply on news.ycombinator.com