What are your opinions on the future of back-end web development? Is the Java ecosystem going to wither away as more modern and better solutions are emerging and maturing?
If so, which language/framework and/or programming paradigm do you think will become the new dominant player and how soon?
Personally I would love to see Rust becoming a new standard, it's a pleasure to write and has a rapidly growing ecosystem, I don't think it's far away from overtaking Java. The biggest hurdle imo is big corporations taking a pretty big risk by choosing a relatively new language that's harder to learn compared to what has been the standard for decades.
Playing it safe means you minimize surprises and have a very large amount of people that are already experts in the language.
Taking the risk will definitely improve a lot of things given that you find enough people that know or are willing to learn Rust, but it also means that you're trading off Java flaws with Rust flaws. That's the case however with every big change, and Java flaws are a good enough reason to make a big change.
Java gets a bad reputation from proponents of FOMO/fad-driven development, but the whole Java ecosystem was built for the web. Anyone is hard-pressed to find a better tech stack than Java-based frameworks without resorting to hand waving and passing personal opinions as facts.
I love C# and the whole .NET Core ecosystem, but even I have to admit it's very hard to argue against java.
It may be an opinion, but pointing it out won't make me like java any more.
Just switch to Kotlin. You get all the benefits of Java with hardly any downsides. Modern language with modern features that is incredibly enjoyable to work with.
I don't see it withering away anytime soon. My entire career has been enterprise web development (which is why I roll my eyes at all the web dev rants). Every company I've worked at has used Java on the backend and some JS framework for the frontend. Java has only been improving in that time and getting much easier to write. I don't see companies taking an (in their view) unnecessary risk that makes it harder for them to hire and lose efficiency, at least in the short to medium term.
I think the only way that changes is if developers are interested enough to try Rust, or any other language, in their free time. If they like it enough, they'll suggest it at work. If enough developers are doing that, it'll slowly shift the local scene.
For me it has been the same except replace java with c#, I can argue that golang might soon be admitted into the "serious backend language club".
For how much crap people give java and c# they are languages you can get shit done in, fast , efficiently and stable.
I’m surprised no one has mentioned golang. We have the usual dichotomy of java and rust but there’s a very very good option for those who are worried about rust adoption.
I vastly prefer writing rust code but go on its own gets you very very similar performance at the cost of developer experience. I think sum types are the #1 requested feature so once that comes I’ll be a much happier boy.
I have not done much GoLang development, but I am working on automating some dependency updates for our kubernetes operator. The language may be good, but the ecosystem still feels immature.
Too many key libraries are on version 0.X with an unstable API. Yes, semantic versioning does say that you can have breaking changes in minor (and patch) releases as long as the major version is still 0, but that should be for pre-release libraries, not libraries ment for production use.
Too many key libraries are on version 0.X with an unstable API
Sounds like my rust experience but then again it'd be non-existing for some of them.
I think that .NET will be used more and more instead of Java, because C# is similar to it, but better¹. And there is also F# which is great too². Rust and JS³ might also get some more usage in backend.
¹The only thing missing is union type.
²And has union type :D.
³And that's unfortunate because I don't like JS.
I give typescript running a decent shot of being a major force in backend APIs. There’s a draw to being able to code the same language on front and backend. It’s got a stronger type system than Java in strict mode as well.
It also has quick boot time which can help in cloud functions that may eventually become the preferred method of APIs. No server or os to maintain and they are close to the customers location
Yeah, JavaScript/TS doesn't get a great rep being used on the backend. But I use it on quite a few of my projects, one of which gets thousands of requests per minute. I was skeptical of whether or not using Node on the backend would hold up, but the performance has been stellar.. pretty surprising, actually.
Thousands of requests per minute can mean many things so maybe you're referring to several hundred requests per minute, but one of our services at work gets 300 requests/second which is ~18K requests per minute and it's really not that much. We're using pretty cheap cloud services. Even thrice the traffic is pretty much a slow walk for your average production-grade web framework.
Web frameworks are built to support an insane amount of incoming requests, including node. The issue with node is the single threading and having to scale with worker threads AFAIK.
edit: our runtime is C#
The issue with node is the single threading and having to scale with worker threads AFAIK
People always say this but its not technically correct and can be misleading.
Technically, JavaScript runs single threaded but not Node.js itself and certainly not when using it on the backend in something like Express. IO operations and other things tooling libraries do can cause you to run out of a thread pool. But Node.js, when handling requests, gives you much of the benefit of multithreading without having to deal with multithreaded code.
Aaaahh so libuv actually runs a thread pool, TIL. I'm another victim of internet propaganda I guess 😅 . You know, I never actually checked libuv docs until now and they seem quite welt built.
The silliest thing I've just realized is that I knew that the first implementation of a web server in dotnet core was using libuv, and I still didn't think twice about the single threaded meme.
I think that India will be a major factor and there are many Java developers. C-level guys don't care about programming languages, they do care about cheap labor. So I don't think that Java is going to wither away anytime soon, at least on a global scale.
That is a bit dismissive of Java developers around the world. There are several of us still left and we are in key positions of power.
I don't think many large established companies will be taking the risk on newer languages, but there are plenty of new companies that will mature based on a foundation of writing their backend in Rust or some other new language.
Probably some Rust contingents will form on internal teams within large companies, and they will build new products or services in X new language.
Python is already popular so Mojo making that ecosystem much faster, safer and easier to deploy could be game changing when it's fully formed. There are also armies of existing Python developers out there for businesses to tap into and it's an easy language to pick up.
On their roadmap page, it looks like C++ interop is going to be a first class citizen too, further opening up the ecosystem to existing high performance libraries:
Integration to transparently import Clang C/C++ modules. Mojo’s type system and C++’s are pretty compatible, so we should be able to have something pretty nice here. Mojo can leverage Clang to transparently generate a foreign function interface between C/C++ and Mojo, with the ability to directly import functions:
from "math.h" import cos print(cos(0))In my opinion, Python is still missing one key feature: the removal of the Global Interpreter Lock, which is finally starting in Python 3.13.
Serverless.
Modern DBs (supabase, atlas, firebase) don't require much, if any, backend code.
I'm talking mainly about serious backends that perform complex logic, not just CRUD operations
FWIW, serverless doesn't mean "no backend". Serverless apps can still have backend code using edge functions. Serverless just means "much less backend".
Most backend code I've seen is boilerplate, or reimplementing functionality that already exists in the DB, and serverless libraries just remove the need to write that boilerplate at all.
Serverless will forever be stuck as a tech that's only good for majority async stuff because of cold boot speed, scaling costs, and general latency.
Good point. That used to be the case, but I think that's been a solved problem for a while. IIRC, most places cache functions for up to a day, so any site with reasonable traffic won't have to wait for boot.
Regarding scaling, one cool thing about serverless libraries is that some are open source and provide instructions on how to self-host.
My team is trying to shift away from Java towards a TS backend. Call us stupid but our current Java stack is a nightmare to work with.
Personally I would love for us to do a Go or Rust based backend, but we're basically a startup with a rotating set of employees so I don't see that happening
