I have been happily using a pure Go stack. That includes Go's built in templates, and web server. I compile the entire application into a single binary and rsync it to the server. Then I restart the systemd service which picks up the new binary.<p>It's incredibly simple and old school. No kubernetes, docker, cdns, etc.<p>Write code, build binary, ship binary.
> ...charm?<p>I say Go. It works nicely with old school tooling (editor, tags, grep) and a command line. That's a charm for me.<p>Advanced tooling is available. You can take 1 step further with LSP integration. Or 2 steps further with a Jetbrains IDE. But you are not forced down the path of advanced tooling just to get by like you are with Java/C#.<p>> Can you bet on something for the future?<p>I say Go. The future may be parallel processing. Goroutines are easy way to harness that power and don't "pollute" other code around them like async C# does.
Say what you want about C but it's been practically the same for the past 25 years, and it remains useful today for embedded development. People will be using C for many more decades.
This is a pretty abstract question with an even more abstract descriptive summary.<p>Charming tech stacks in my understanding are fun to use and productive the same time.
Still in demand tech stacks are well hung things that still are relevant.
Hard to find skills are barely common.
Betting on something for the future is not something that really falls in any of these categories.<p>So, still relevant, well hung, versatile tech stacks I would also bet on for the future are C#, Python and SQL (e.g. Postgres).<p>More modern and less hung alternatives would be Rust, Go and TypeScript / Javascript (and some of the more modern Boilerplates / Frameworks).<p>Still relevant, woth learning and hard to find is LISP.<p>Mojo (as possible python successor) would be something I'd bet for the future unless something goes really wrong - but that has to be proven.
JavaScript - not hard to get productive, opportunities to go deep are still there.<p>SQL, as hard as folks try, it's not going away.<p>Also Ruby on Rails too.
I just use go and call it a day for backend at least.<p>I have tried a bunch of frameworks across various languages. Sometimes it’s just better to keep it simple and boring. It’s fun to see stuff just work and perform the same at bigger scale with literally little changes on my end.
In Germany I often come across MEAN Stack: Mongo, Express, Angular and Node.JS.
Also Java Spring, ASP.net and MySQL is still in use heavily here.
Agencies and E-Commerce mostly have PHP backends and React frontends including Next.JS.<p>Hard to tell what the future holds, but those technologies will be around for longer.
Adoption within the industry is much slower that you’d anticipate.<p>Personally I’d go with the GoX-Light-Stack (just made that up): Go + SQLite backend and HTMX frontend.
Market demand:<p>- high-performance, low-latency data processing skills<p>- out of the box thinking and "I can do it" attitude<p>Charm:<p>- Java lives its second life now with JVM, OpenJDK and GraalVM.<p>Shameless plug - just released a Java platform for building enterprise apps as an opensource project: <a href="https://github.com/openkoda/openkoda">https://github.com/openkoda/openkoda</a>
LAMP (or LEMP) stack.<p>Throw in a PHP framework (probably Laravel for rapid development) and use server side rendering.<p>Maybe add in Redis for caching too.<p>All hosted on a single Digital Ocean droplet.
Numpy for numerical computing?<p>TBH it does what it does well, and I rarely see a need to reach for an alternative.<p>Specifically - its greedy, single-machine, numerical array computing. If I need something distributed, evaluated lazily, or data frame oriented I reach for a different tool.
I used .NET for about ten years since v1.1. After an almost ten-year break I'm developing with it once again, and finding the ecosystem much improved and even more of a pleasure. Wouldn't bet against .NET and C# given the evolution so far.
c#, dotnet with blazor webassembly; for a new project I was hired to rework on for downsizing a 20user Salesforce SAAS app having around 30 tables everyone is happy with the performance. It is 2nd version of the rewrite which started of as a next.js app.