[Cthulhu_]

I'm currently "betting" on Go for making a back-end (just a REST API + sqlite database) that will last a decade; I'm betting on the tooling to stay backwards compatible or with minimal changes in the codebase; I'm betting on the readability of my own code for the next decade, and I'm betting on the language + tools to continue to be developed whilst sticking to their original goals.

Generics is going to be fun.

[gonzo41]

I can't tell if you want generics or not? I've been thinking about the topic for a while and sort of think Go doesn't need em. It's less a technical reason but more a cultural reason. The language shipped without them as a feature. So why deprecate that feature and make lite-version of Java/C#.

[dhagz]

A decent chunk of new Go developers are former Java developers. (I'm not being disparaging here, I came over to Go from Java!) I think the idea of "accept interfaces, return structs" doesn't sink in very well and isn't as readily apparent as it could be.

When I have a function that takes a struct, and I need it to take a different struct for the same argument due to whatever, that to me screams "make an interface", but I hadn't been programming Java very long before my team started using Go - I've now been writing Go professionally longer than I have Java.

[RandoHolmes]

> I'm betting on the tooling to stay backwards compatible or with minimal changes in the codebase

This is actually why I'm pretty bullish on things like RoR, Laravel, et al.

The sheer speed at which they go to a new version that breaks BC is actively making the web less secure. I've lost count of how many times I've found a new client with this software that's been working for years but suddenly broke, only to realize it's on an OS that's EOL, using a version of the framework that's EOL and a version of the language that's EOL. And now it's my job to bring it up to speed.

And typically the hardest part of that? The 3rd party dependencies that are either abandoned and don't support the newer versions of anything, or have moved onto Python 3 and no longer support Python 2.

It's why I vastly prefer something like asp.net core. I know in 5-10 years the code will probably just work with the latest version, and if there's an incompatibility, it's going to tend to be relatively small.

[lukeramsden]

> This is actually why I'm pretty bullish on things like RoR, Laravel, et al.

Do you mean bearish? I think you do as I was confused for about half of your comment before I realised

[RandoHolmes]

Sorry, you're correct. I meant bearish.

That's what I get for posting pre-coffee :(

[vbsteven]

The same reason why my default stack is still Java/Kotlin with Spring and Hibernate. A stable environment, stable runtime that is guaranteed to not change too much and has a culture of backwards compatibility.

[gonzo41]

How are you liking Java with all the versions that are dropping. Are you still on 8? Correto? Or are you keeping up? and do you see the value in the features that are dropping.

[vbsteven]

Java is moving a lot faster now with the new 6 month release cadence but you don't need to follow every release. Sticking to LTS releases is fine for projects that require longevity.

Some projects are still using 8 and will be until their EOL date. New projects start on the latest LTS release (11).

[john-shaffer]

java.time is really nice, so I use Java 11 (2018) on my servers. If not using java.time, Java 8 (2014) or later is fine. But I use Clojure, not raw Java. I haven't had any issues with upgrading. If a server works with 8, it works fine with 11 (in my experience).