Hacker News Reader

Comment by 3pt14159 | Hacker News Reader

I'm starting to long for a stack that doesn't constantly change. Just set the features and that's it. Security updates only after that. It feels like a constant grind keeping up with everything. Containers, clouds, programming languages, operating systems, frontend frameworks, transfer protocols, it seems like it takes so much effort to just build something and keep it going. That Python 2 is still around doesn't really surprise me. Many of the projects that were built upon it were built by non-developers (scientists, etc) that have no strong reason to keep everything current.

View on HN

Honestly: the Java environment is exceedingly good at that. Backwards incompatible changes are truly minimal, and only those that are strictly necessary are added.

And since Java 8 the language is pretty nice and offers good functional idioms.

Of course, major versions of libraries still change. But there's no match with the JS approach.

The downside is that also means a lot of the core APIs are a huge pain in the ass to work with, especially relative to something like Python, and the “solution” to this problem ends up being something like Spring which has to use so much reflection and metaprogramming to accomplish what it does that it also relies heavily on exceptions for control flow. So without even getting into the other issues, debugging becomes a lot more complicated than it would be otherwise.

Personally I would second Go as a good answer for this. It has its limitations, but it’s simplicity and it’s standard library more than make up for that from a pragmatic standpoint imo

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.

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)

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.

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.

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.

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

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.

I agreed until the disaster that was Jigsaw.

Maybe Jigsaw didn't impact you particularly hard, but you can't argue the JVM has a policy of minimal backwards incompatible changes given that debacle.

I work on Java at a really deep level, and I haven't had to interact with Jigsaw at all. What is it breaking for you?

A lot of things like older versions of Gradle (which at some point was a blocker to move to Java 9, but not now), Groovy (also fixed, but still has some warnings), which we use heavily for tests, several reflection-heavy frameworks (think dependency injection, annotation-processors etc), which to this day require some ugly hacks like --patch-module to "open" packages, JUnit tests (which also need the same hacks to work), even the location of resources loaded with class.getResource() had to be modified when modularizing a jar, so that resources go into the proper packages that are visible to the loader...

You seriously didn't suffer any of these?

No I didn’t experience any issues like that myself.

I’m a full time scala developer and have had basically no problems taking longer than a day to in moving to the LTS releases of 9+.

It’s probably pretty helpful that the scala ecosystem doesn’t depend much on non-well trodden parts of the JDK

Yet we have multiple versions of Java at work (8 and 11) because some (pretty large) third-party components don't support the newer versions yet. Plus for things that do work there are a bunch of irritating warnings and whatnot.

It's not "exceedingly good" at it, it's just alright. Go has done much better for us in this area.

Go has the whole gomodules thing, which I’m not a huge fan of. Go with vendored dependencies sounds really stable.

Pretty sure generics are coming, and this is going to change best practices, and cause re-writes.

go mod vendor is what you are looking for then

How are people adapting to Oracle’s licensing changes?

It's not really that big a deal in my experience. We switched to the Corretto[1] distribution of the OpenJDK from Amazon and it was seamless.

If you want newer versions of the JDK, you can get them directly from Oracle[2] still, or from alternatives like AdoptOpenJDK[3].

[1]: https://aws.amazon.com/corretto/

[2]: https://jdk.java.net/13/

[3]: https://adoptopenjdk.net

The biggest change I've seen is that people are using OpenJDK itself (rather than Oracle's official distribution) a lot more, not only from the official OpenJDK distribution, but also the new Amazon's Corretto version, Azul's Zulu (the one I use at work, which has been backporting lots of security improvements to Java 8, which is very useful!), RedHat's OpenJDK, and even AdoptOpenJDK, all of which are completely free and open source...

If you want to quickly and easily switch between distributions, I highly recommend https://sdkman.io/ - it lets you install and use any of the above mentioned JVMs with a simple CLI... e.g. `sdk use 13.0.1.j9-adpt` or `sdk use java 8.0.232-zulu`.

I would guess that Oracle's JVM popularity has gone down from around 75% of Java users, to something like 20% after the changes, even though I don't actually have the numbers.

> Honestly: the Java environment is exceedingly good at that.

I would argue that the .NET Framework is way better. The way you can have multiple versions installed side by side and have the framework pick the correct one to run is awesome. Granted, you can do something similar with the JVM by mucking around with env vars, but it's not the same thing.

Well, .Net Framework is analogous to Python 2.7. It will never receive anything but compatibility, security, and bug fixes going forward according to MS.

The Future is .Net Core.

Just for the sake of redundancy:

Python 2.7 is not getting any kind of updates including security and bugfixes.

Not really. The newer open versions still don't match Oracle JDK 8. Wanna bundle a JVM with your app so your users don't have to worry about the Java runtime? Well, you can't do that anymore. Wanna use JavaFX? You have to jump to Java 11 and hope your dependencies don't fail with module packaging errors. Do you use Scala? GLHF.

Standing still in the Java ecosystem is fine. Keeping on with the advances is painful and exhausting. The Java tech stack is awesome when it works, but to solve issues you have to go so deep into the tech stack that I'm starting to think it just can't be done unless you're at least a mid-sized company with JVM specialists on the payroll. Not developers, but systems people.

> Wanna bundle a JVM with your app so your users don't have to worry about the Java runtime?

Why would that be the case?

> Wanna use JavaFX? You have to jump to Java 11 and hope your dependencies don't fail with module packaging errors.

Dependencies which still fail with module errors are basically abandoned and should probably be replaced. But even for those there's an escape hatch if you really want to continue using them, so that seems to be a non-issue?

> The Java tech stack is awesome when it works, but to solve issues you have to go so deep into the tech stack that I'm starting to think it just can't be done unless you're at least a mid-sized company with JVM specialists on the payroll. Not developers, but systems people.

I've worked either directly or indirectly with so many companies of all sizes using Java without any dedicated JVM specialists I'm pretty sure you're doing something very, very wrong with all the problems you seem to have.

> Why would that be the case?

I have a desktop Java app with platform-specific installers (.msi, .deb, .dmg). The Windows and Mac installers include a Java runtime, so the user doesn't have to worry about installing an external runtime. I'm forced to use Oracle JVM, because it's the only Java distribution that includes the tools needed. There's ongoing development on a tool that should bring these and more related features to the open JVMs, but it's not done yet.

> Dependencies which still fail with module errors are basically abandoned and should probably be replaced. But even for those there's an escape hatch if you really want to continue using them, so that seems to be a non-issue?

The issue is that the upgrade path isn't smooth. I have to upgrade everything at the same time, because what works on Java 11 doesn't work in Java 8, and viceversa. It makes everything way harder than it should be, if there was a clear migration path.

> I've worked either directly or indirectly with so many companies of all sizes using Java without any dedicated JVM specialists I'm pretty sure you're doing something very, very wrong with all the problems you seem to have.

What I do falls into a niche. It's not "very wrong" but it's uncommon. The main issue is that Java was a non-issue, a stable platform to build upon. But the recent Oracle license change forced us to move to fully open versions of Java that do not have the same features, do not bundle the same libraries, and do not have documentation detailing all these differences.

I'm not asking for a community to finish whatever feature I need, or for a company to make what I need free to use. I'm just trying to explain my own problems caused by Oracle forcing us to move to open distributions of the Java platform.

That's a lot of FUD spewing.

It's my own personal and professional experience. Yours may differ, but please don't call it FUD.

> The newer open versions still don't match Oracle JDK 8

I'm currently working on a web service that was written under Java 8.

For giggles, I just ran the end-to-end tests suite under Java 8, 11, and 13. The only error I got was an incompatibility with Google's Error Prone linter, which I was able to fix with one line change.

This represents a few hundred thousand lines of production code that works just fine under every important JDK in use today.

The problem isn't usually with the runtime itself, but with all the ecosystem and tools around it. This becomes very apparent when venturing beyond web services and you start depending on those tools.

> The newer open versions still don't match Oracle JDK 8.

Oracle JDK 8 contained some small parts that were proprietary. And they mostly had the proper package name. You took the risk.

> Wanna bundle a JVM with your app so your users don't have to worry about the Java runtime? Well, you can't do that anymore.

You mean, bundling a JVM exactly like all JetBrains IDEs currently do?

> Wanna use JavaFX? You have to jump to Java 11 and hope your dependencies don't fail with module packaging errors.

JavaFX is a bit of a strange thing, and yes, it can be painful. And some modules struggle with the new module system. The module system is a breaking change, and in fact it took quite a while.

> Scala

That's a problem with the Scala compiler AFAIK, not with Java.

> Oracle JDK 8 contained some small parts that were proprietary. And they mostly had the proper package name. You took the risk.

I did not. Some libraries I depend on did.

> You mean, bundling a JVM exactly like all JetBrains IDEs currently do?

Yes. I'm researching how they do it. Previously it could be done with one command. Jetbrains use their own patched JVM and have JVM experts on their payroll. What they do goes way beyond my current skills.

> That's a problem with the Scala compiler AFAIK, not with Java.

From a JVM point of view, Scala is just one more library. The problem with Scala right now is that it doesn't support the module system. This means yet another dive at a lower level to try to fix any issue that appears.

Except, you know, fundamental stuff like how many cores does the JRE think it is running on.

The dance over that as we've gone from 8 to 9 to 10 to 11 is mind boggling.

As I get older and crankier I find simplicity and stability become a lot more interesting than reinventing the same wheels over and over again.

This is probably why I’ve come to appreciate Rich Hickey’s talks more and more as years go by.

I think Clojure is a good fit when it comes to stability as per their own development guidelines [1]:

The Clojure development team values a measured and thoughtful approach to language evolution with a strong emphasis on maintaining backward compatibility.

[1] https://clojure.org/dev/dev

To anyone who's interested in this topic, I strongly recommend this talk from Rich Hickey about "giving something to somebody that they can use and making a commitment": Spec-ulation (https://www.youtube.com/watch?v=oyLBGkS5ICk)

Go has a compatibility promise from 2012 that they've upheld for now seven years. They are still discussing whether to change something in Go 2.

https://golang.org/doc/go1compat

> They are still discussing whether to change something in a backwards-incompatible way in Go 2.

FTFY

Fortran from the 1980s is still supported...

Hell, I fixed something in Turing last week. My eyes are still bleeding.

You misspelled the 1960s.

And yet almost no one chooses to write new Fortran code for applications. We rely on a few ancient critical widely used libraries like BLAS, accessed from non-Fortran programs.

This is not true, there are niches where Fortran is still dominant for new code.

Also for BLAS, the underlying code is usually no longer Fortran.

Fortran from the 1960s is still supported. Almost all modern Fortran compilers support syntax that was deprecated decades ago.

They probably do not want to end up with a Perl 6 situation. I meant Raku, the language formally known as Perl 6.

I came to say this. I learned Go in the early years and have come back after not touching it in years and it all still sounds eerily familiar and a lot of the basics I learned are still relevant to what I do.

Go is good at being Pythonic in some senses too. Some would say to a fault.

Use C.

Standardized since the 80s, it has had only minor, backwards compatible revisions in 99 and 11.

According to the TIOBE index, it's the second most popular language in the world. It works on almost any platform imaginable and it has decades of tooling available for it.

Of course it doesn't have any of the good new things developed recently, but if it's stability what you look for, then I don't see a better option.

Or Perl. Perl takes backwards compatibility very seriously. There was a lot of gnashing of teeth a while back on whether to make newer versions actually change the default behavior finally to some new features could be opt-out instead of opt-in. An by new features, I mean stuff like "use strict", which has been best practice for a couple decades now, but the change would cause problems for existing scripts that didn't turn that feature on.

The rule has generally been that you can take a 20 year old Perl script and it will still just run. This has its own complications though, as it makes it harder to advance the language, and then people feel it's being left behind (the Perl 6 stuff came after that feeling developed).

It's a longstanding problem in language design and communities, stability vs advancement.

Unless it uses CPAN stuff, or calls out to external tools. Those are often needed for key functionality, and they get stale much faster than perl itself.

The old versions of modules are available, if you don't happen to have the exact same code present.

Core modules are all I would worry about, but I'm pretty sure those are held to the same standard as far as backwards compatibility.

One or two modules might have been ejected from core or moved into core, but those should be easily found on CPAN as well.

In the end, getting something working from scratch on a newer Perl that has a lot of CPAN dependencies (as opposed to just updating Perl) might be a little annoying in that you have to track down all the module versions, but it's far from impossible, or even all that hard.

For example, the CGI module[1], which was a core module but historically seen as fairly bad (at least as of now, and at least in some of its uses, it supported a wide set of use cases), it was removed from core and housed on CPAN. If you follow the link provided and check the past versions (dropdown as part of the module path and name), you'll see there are many versions shown, possibly every public version, and going back to 1998 for CPAN, and 1995 for 1995 for the BackPAN. Each of those is visible as an item with it's documentation at the time and the module available to download and use. You can also access the CPAN testing matrix[2], and if you dig around you can actually find the results for some tests back in 1999.[3]

If I was responsible for getting some old Perl app to run on a more modern system, I would by much more worried about the OS changing in a complex way than I would about getting the Perl code to run again as expected. Which is to say, I wouldn't be worried much at all.

1: https://metacpan.org/release/CGI

2: http://matrix.cpantesters.org/?dist=CGI+4.44

3: http://matrix.cpantesters.org/?dist=CGI%202.55

Lots of CPAN stuff is just plain Perl code, so the, "it just works" keeps working, too. It's to the point where a lot of "competing" Perl modules that try to solve the same problem have similar/same API's (but under the hood, rely on different things) - sometimes that is to solve the, "Well, the more popular choice went off and did something interesting in $VERSION+1, but we like the old way"

Also, if you desperately need an older version, you can usually install that older version rather than the newest.

Anyways, there's things you can do. I still work on code I started in my dorm room (in the 90's). Cranky CPAN modules aren't too big of a problem.

SaaS modules too, a lot of services have their API modules and examples provided in various languages. Perl is often not one of them. In some cases where it is, it's out of date or plain old broken. As an example (which is understandable, no hard feelings) I had to edit the SendGrid modules to fix a bug when I tried, and there were issues on GitHub that have been ignored since before it became officially unsupported in 2016.

I usually use Python these days when dealing with SaaS apps since the ecosystem is much better, and I want to learn it anyway.

To me, C is a tale of the perils of maintaining backwards compatibility: there are lots of parts of C, and particularly its standard library, that should never be used because there's no way to do so safely, but can never be removed and so inevitably new code will continue to be written that uses them.

What is there? I'm thinking of gets() which was actually removed from the standard. Other functions, you can absolutely use them correctly, even if it's not a great idea. I don't think a large percentage of C bugs comes from the standard library.

If you depend on some functions in the standard library, it's super-easy to replace them. They're leaf dependencies.

Anyway, C has about the smallest standard library you can have. And if we're talking about it's benefits in terms of compatibility, we're probably talking about the fact that it doesn't introduce new syntax / language features each other week.

Elixir 1.9 came out. No future core language changes are planned. There are no intentions of creating an Elixir 2.0. There will still of course be regular improvements and updates, but the core language is basically set. Read about it here:

https://elixir-lang.org/blog/2019/06/24/elixir-v1-9-0-releas...

If Elixir wasn’t an option for me, Clojure would be my next option. Clojure seems like it has a similar philosophy, and builds on a dynamic immutable core.

That being said I like writing code that can feel “done”. No “I wish I could refactor this object hierarchy to make it easier to use, etc” notions in the back of my mind. Not every piece of code is like that, but enough.

Surprisingly enough, PHP is a good example of environment that doesn't break backward compatibility much.

About the only change that had a significant impact on projects I worked on was removal of the 'mysql' DB extension (replaced by 'mysqli' and 'PDO'). For an older project I created a few shim functions and it still works just fine.

While frameworks come and go, the core of the language is highly backward compatible. The choices made early on were in the UNIX style, so they were right.

To quote an earlier post[1],

There is something to be said about PHP's staying power. The early versions of the language weren't considered "right". Except maybe they were right for the problem at hand.

The way I see it was PHP captured the vector of change, and left ample room for future developments. Both internal changes (hello, bytecode; hello, JIT), language level features (hi there, namespaces), and runtime level features (oh hai, countless built in classes and functions).

Moreover, unlike many framework that shone brightly and burned out quickly (Rails?), PHP captured the essence of the environment: HTTP is stateless, and URLs aren't uniformly routable from either end, and well-formed HTML/XML/JSON is just a subset of tag soup.

Worse is better.

[1] https://news.ycombinator.com/item?id=19536132

If your timeframe goes back to PHP4, this most certainly isn't true. Just one glance of https://www.php.net/manual/en/reserved.keywords.php should prove this - every new keyword is a backwards incompatible change. And I mention this because I used to support software that used, as a variable name, something which became a reserved word...

as a variable name, wouldn't it have been prefixed with $ ?

the XML parsing was probably the biggest BC change I hit between 4 and 5.

I think I'm misremembering and they were method names. I believe it was clone, in fact.

Can't relate with that... I'm still hosting some WordPress websites for clients from a few years ago. I'm afraid to upgrade PHP versions because many things broke in the past. True, it's not the WordPress core but the plugins that usually break, but I can't think of a single client of mine that doesn't have at least 3 plugins installed.

Ditto. I just did a project upgrading hosted websites to the latest PHP from PHP 5.6. These are already sites that vetted past the obvious issues of the mysql and mcrypt APIs going away, and these sites were all maintained in at least the last 4 years (I host sites that haven't been touched for over a decade, they aren't getting upgrades).

Even with these "cherry picked sites", we had about a 30% failure rate dealing with the new PHP. Ranging from total non-function of some random CMS, to mostly errors printing all over every page due to some deprecated or change of code behavior in the site templates.

Nowhere on the level of Python 2 to 3 but every minor version upgrade of PHP breaks Drupal core (and some contrib as well) one way or another. It's OK, we love the new features :)

Try Common Lisp. The language has an ANSI standard, published in 1994. So the base has been stable and fixed for the past 25 years. A lot of Lisp code that old or even older works perfectly fine on a current CL implementation.

Not only that, the "Common" in Common Lisp is a reference to a standardization of several existing dialects, so a lot of Lisp code from the 1960s and the 1970s will run without any modifications.

Lots of people say Java but of the more fancy and convenient (and correct, cough I’m obviously biased cough) ways to do development, I can’t stress enough how amazing it has been to watch release after release of Clojure consisting of mostly trivial changes or library additions.

The language is arguably complete and any syntactic changes you could wish upon yourself are doable in form of a library because it’s a lisp.

And all that piggybacks on top of already quite stable java ecosystem.

Can’t get much better than that.

The world keeps moving, if you don't want to move with it then pick something that has already stopped.

Maybe C? Cobol? Ada? Fortran? Though even those languages have modern flavors & updates...

We make progress because we learn, not just new technology, bu new approaches to old problems. When I see an "old" programmer who keeps writing C89 code because "it still works", it is painful to see them rejecting decades of learnings about how to write better software.

> I'm starting to long for a stack that doesn't constantly change.

I looked up "engraving marble" to find an example of the above, but no luck there: They use lasers for that now.

I think Python 2 had hit the perfect balance of "just enough but not too much" which I'm very deeply worried that Python 3 is going to deviate from.

Python 3 is barely different in my experience and it's been about 10 years at this point.

I do enjoy some of the "new" features of python 3.

I used `async` as the name of a function decorator in some Python3.4 code, which then broke in 3.6 which introduced `async` as a keyword.

What was the level of effort to remediate that?

sed 's/async/whatever' ...

Probably around 4-6 hours of work all told.

We had to come up with a new name, do a find/replace, review the changes, test, fix a couple of issues because the replace wasn't perfect/complete, update the dev documentation, make a new patch release, and then create packages for the various supported platforms. Oh and looking back over it now, the filename had to be changed too, because apparently you can't use a keyword as a module name in Python either. So where the documentation linked directly to that file, that had to be updated as well.

[1] https://github.com/saulpw/visidata/issues/164

[2] https://github.com/saulpw/visidata/releases/tag/v1.2.1

Some of the syntax changes are barely different (print statement a function instead of a keyword, good) but a lot of new things are added that I would consider to be syntactic sugar (walrus operator, for example) that threaten to detract from the two biggest things that drew me to Python: clean syntax and obvious understandability.

Python allows imperative code with side effects in imported modules, as well as the "else" statement for "for" loops, so Python has never guaranteed obvious understandability.

Sure there are plenty of things that aren't perfect in Python, but I think it was the best of all viable candidates that came closest to that goal.

Not very different, but fallout from the Unicode switch is quite a headache.

I generally run with LANG=C, and run into Python3 issues regularly as a result.

Also, if you have to support 'async' code that someone wrote, that could be a heavy load as well.

> I'm starting to long for a stack that doesn't constantly change

Come on over to Javaland, it's nice, warm, and the sun is always shining!

With the exception of the Java 8 -> Java 11 transition (skipping the non-LTS versions), things are pretty stable. You don't have to use any new-fangled features if you don't want... and your Java 3 code compiled nearly 20 years ago will still run just fine on modern JVM's.

> Come on over to Javaland, it's nice, warm, and the sun is always shining!

My oracle predicts much worse weather.

> My oracle

Funny joke, but Oracle is all but out of the equation at this point.

They've stepped back and become yet another JVM vendor that takes OpenJDK source and compiles it into a binary for users, sprinkled with some special sauce here and there, and just happens to charge for support.

That puts them in line with Azul, IBM, Amazon, AdoptOpenJDK Project, SAP, Red Hat, and a ton more.

You get your pick of JVM vendors now... That's a fantastic thing for Java.

Python 2 (the OP topic) from 2000 still works too.

Running code is the easy part. Writing it is the hard part.

And if running on a VM is your standard, my old DOS programs still run on DOSBox :-)

Clojure has had only a single backward breaking change since its creation in 2008, it took 10 full years before being introduced, and it was a pretty minor one at that.

Java and the JVM themselves value backward compatibility, and I'd say Clojure takes it a notch above that.

I guess I have missed that. What was the change?

When they added clojure.spec. It started validating macros at compile time. If you were previously using an illegal syntax, but that somehow didn't cause any issues, those would now throw a compile time error.

Overall it was for the best, since prior to that it was just weird code that had a bit of a undefined behavior since it wasn't using the macro in the proper way. But it still meant we had to go and fix a few of them so they compiled again. Though in the process we realized that we were misusing the macros to begin with.

One day tech historians are gonna look back at this era and shake their heads at all the time, energy, and talent being wasted by people just trying to keep up with tech trends for the sheer purpose of remaining employable.

I don't think it's that bad. I've never heard of someone who got fired because they didn't know the latest JS framework.

Also, new tech trends are not just hot air, there's also a lot of innovation happening. You just have to see through the hype and wait until the dust settles.

There is also the situation that someone gets hired for their tech skills, but the thing that keeps them in a job is their ability to pick up the domain. The tech choices are often point in time decisions which are irrelevant to any outcome. The domain knowledge builds is worth more than any framework knowledge.

If you are successfully (i.e. the business or product keeps being developed) you still need to be aware of the internal weaknesses of your original choices and the external opportunities of updating to something more modern. The challenge is in managing the transition which is a skill in itself.

> I've never heard of someone who got fired because they didn't know the latest JS framework.

Sure, but I've worked with a number of individuals who have either resigned (on their own), or have been let go, solely because they had no desire or interest in keeping up with their craft.

I think that's effectively the same thing, though.

Ultimately, the notion of not wanting to stay abreast of the current industry trends is neither something I can relate to, nor is it something I see as being compatible with one's employability.

How many haven't been hired because they didn't know the latest JS framework?

Reinventing wheels isn't innovation, particularly if the reinvention isn't round.

If we are talking client side JS I think they're just trying to solve the problems that desktop had solved ages ago. And they keep smashing heads in a process.

My general rule is that I don't even think about learning a new technology until at least two years after I first heard about it.

I assume that I hear about new stuff fairly early in their adoption, since I try to keep up with these things, so if it's still a thing two years later, it might have enough staying power to be worth learning. After that it still takes a while for me to get around actually learning the things.

Go and Rust are languages that have been on my todo list for a while now, for example, but I still haven't touched a JS framework because I haven't seen one with staying power yet.

Do you think React can be going away any time soon?

Java is fairly stable I've found.

Just get away from javascript and once in 20 year platform language changes like swift and most platforms don't have that much churn.

Delphi still lets you build programs that used to run on Windows 3 with minimal changes, and definitely anything 32-bit.

It's part of the value proposition: the language and libraries are planned for forward compatibility and stability for use ten years in the future, as well as now.

Actually there were some problems (very long procedures I think would be one example). Other then that compatibility shines.

To save others the same DDG search I did -> Delphi is a Pascal language IDE that compiles to native Windows binaries. Apparently there is this thing called Lazarus that is a free version of it?

FreePascal is language/compiler and Lazarus is an IDE. Lazarus IDE runs on all major platforms and produces native code. Suitable for anything starting from system code and up to complex GUI apps.

You want to find a stack that's small / concise / organized enough that you could support it if you needed to.

It's ideal if it has a stable community, but it should be a small group of core devs, so they don't have time to change things that aren't broken. It helps if the community has a culture of stability.

In my experience, FreeBSD and Erlang fit this bill. You may need to manage some small changes now and again when upgrading between releases, but generally the most apparent changes are things you were doing before work better. And you can run a fleet with rather divergent versions, as long as you're careful not to use new features (it helps to make sure your dev environment matches your most out of date hosts)

> I'm starting to long for a stack that doesn't constantly change. Just set the features and that's it.

I hear every day: don't change a thing in D, just add these two features.

Have you tried Fortran?

C also shows excellent stability and backwards compatibility.

Cobol is also quite stable, but IDK about the quality of open-source tools for it.

The problem of stability is that you are pinned to the moment when the interfaces were defined and committed to, and this moment goes further and further into the past. Quite often this means that you can't use the new things which give advantage to your competitors.

I feel like pure Ruby meets this. I've been using Sinatra for years, it's been basically the same that entire time, and the language feels pretty stable in my usage (some nice added things, like stabby syntax and `.then`, but those are really just sugar).

Rails is so-so.

I think the only option there is C. It hasn't changed much for a long time, for better or worse.

I think you are looking for COBOL.

Python 2 is 19 years old.

Python 3 is 11 years old.

11 years is a long time to married to the bugs of the past.

20 years is a long time to be married to a fixed language.

FORTRAN?

Sounds like mathematics.

Can't you just ignore those comments?

Then how do you improve?

Currently there is no all encompassing theory for the design of languages or anything. So there's no prove-able way to design a language that can always be improved and always be backward compatible.

I imagine that such a language would be incredibly simple. Minimal syntax and all sugar and conveniences would be built with libraries.

Reply on news.ycombinator.com