Either you have a stable platform, and it reflects the state of the art form the year of its inception, or you have a platform that keeps on improving, but this means you need to change your code along with it, to keep up with the improvements.

You can't have it both ways,

OTOH current JVM can still correctly run bytecode compiled by Java 1.0.1 (or maybe even earlier), so the backwards compatibility is indeed excellent.

Not necessarily. Java currently ships two date libraries, for example: java.util.Date and java.time.*. There are some duplicating classes like Vector from the old times and ArrayList from new times. There are two I/O frameworks: old I/O (File, FileInputStream, etc) and nio (Path, FileSystem, etc). While I don't like the particular way Java did that, basically you just have to ship all old versions and keep them working and ship new versions with some adapters to ease migration.

> Either you have a stable platform, and it reflects the state of the art form the year of its inception, or you have a platform that keeps on improving, but this means you need to change your code along with it, to keep up with the improvements.

> You can't have it both ways,

You can have a continuously improving platform with full backward compatibility, and all the improvements that aren't just efficiency of established operations are opt-in.

I am not a go programmer but I would love to revisit this conversation but with golang twenty years from now. Please correct me if I am wrong but I believe golang is essentially complete, right? and golang programmers like golang?

> Please correct me if I am wrong but I believe golang is essentially complete, right

I'm confident every programming language thought it was complete at some point... but eventually it's users demand some new "hot" feature and then you're back to releasing new versions again.

The C programming language just had a release in June 2018, C18. For a language released 47 years ago... and it's a pretty basic language compared to most other languages.

Fortran was released 62 years ago, and just released Fortran 2018 in November of 2018.

Go is not complete. But it does not evolve by revolution as of now.

Complete is hard to define, no language stops evolving. But Go language is perfectly suitable for large projects, and is pretty much my Go-to nowadays. (Pun intended)

Java 8+ is so easy to work with I think it bores a lot of people so they go looking for something more. Spring boot + jooq is easy to work with and breaking changes are slow.

I'm also coming around on Go. The simplicity was a turn off at first, but now that I've used it to implement a graphql server I like the simplicity. I don't want to have to be a programming language researcher to quickly get work done. IMO Go delivers in that mission.

Java is paid platform without clear pricing, licensing and patents.

Many (most) JDK distributions are free for all usages and fully open source.

Can you give some references for the patents issue you mentioned?

So you agreed pricing and licensing is not clear? If still not, here is the source https://upperedge.com/knowledge-center/documents/oracle-podc... As for the patents I don't have a source quickly available. Pricing and licensing are already bad enough. If I sell java based software, customers have to worry about licensing from Oracle. If I sell SaS I have to worry for what and how to pay. Those factors are big risks.

If you're using something like Spring or Spring-Boot (highly recommended!!!) - you rarely, if ever, are going to be debugging Spring's code... any issues are going to be in your code.

With Spring-Boot you can even start treating Spring and friends like a "Black Box", and stop caring about how it does what it does.

Could not agree more with Spring-boot recommendation! It's an amazing toolbox and combine it with streams and function interfaces, programming in Java is pleasant again

personally i loath blackbox systems, regardless of how well the docs are written. i want to know how it does things...even if only to satisfy my curiosity.

It's not blackbox in that you can't look inside... it's blackbox in that you can choose to ignore it and be just fine.

Springboot takes an opinionated approach to a lot of things, but always lets you override it and do whatever you want wherever you want.

I suppose that's more of a greybox...

ah, yes! point taken.

You can use Spring without all that magic. I, personally, hate Spring Boot and would never use it, exactly because of all that magic. But Spring itself is perfectly fine and I can control every single bit of it with explicit configurations.

For us, springboot gave about 90% of what we wanted out of the box. The 10% that we wanted customized (special authentication related things or transparent multitenant database switching with repositories etc), it let us override and do what we wanted it to do. It certainly is a lot of magic, but nothing that cannot be deduced if you are familiar with Spring, and/or look at the source.

I used to be opposed to all the "magic"... but after you write a few MVC projects with Hibernate backends, etc... why keep having to do that all from scratch each time?

You end up making your own framework that has all that in it, so that you just change a few things here and there and can start getting to the business logic that much quicker.

Then you realize you're maintaining all of that code... when you'd much rather maintain the business logic bits...

Which leads to using Spring Boot and letting them maintain everything else.