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.
It's incredibly simple and old school. No kubernetes, docker, cdns, etc.
I love this stack and using it for my personal blog. But that gets very low traffic. Are you using this in production and at what level of traffic including DB writes etc. Would you be able to share some numbers if possible ?
I have two SaaS products using this stack, and my personal site. The SaaS products get decent traffic (millions of requests every month, thousands of requests per-minute). I use Postgres for everything and I have no complaints.
I'm no Google, but it has been holding up very well (I've never had any issue with CPU, memory or anything). My simple release strategy does come with potential downtime, but the shutdown and start up are so fast it's very minimal.
How do you release a new version of your service/app? Do you aim to do zero-downtime deployments? If so, how?
The biggest issue I find is that doing zero downtime deployments on the same machine/server is a bit pita because of the port used by the service (cannot have a canary and a primary service running at the same time on the same port)
Honestly, I don't aim for zero downtime deploys. I simply don't care if I have a few seconds of possible service interruption during a deploy.
If I did, I'd keep it simple. I use Nginx in front of the Go server. I'd likely use the Nginx server as a load balancer and replace each Go service one at a time to have no downtime. It doesn't matter how many ports you use as long as Nginx knows the port range. It will distribute the incoming requests to the Go processes.
edit:
For those wondering why I use Nginx. It's where I terminate SSL and I also use it for simple gzip/compression/caching for outgoing resources.
I don't use Caddy or anything else. I've used Nginx for many years and it just... works.
I say Go. It works nicely with old school tooling (editor, tags, grep) and a command line. That's a charm for me.
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#.
> Can you bet on something for the future?
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.
Mutexes are for thread safety, channels are for communicating between threads and waitgroups is an alternative to Promise.allSettled (in JS anyway, not enough experience with C# or other await impls), except you don't need to load up the promises first and then fire them. Wat.
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.
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.
So, still relevant, well hung, versatile tech stacks I would also bet on for the future are C#, Python and SQL (e.g. Postgres).
More modern and less hung alternatives would be Rust, Go and TypeScript / Javascript (and some of the more modern Boilerplates / Frameworks).
Still relevant, woth learning and hard to find is LISP.
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.
I love SQL. The only thing that can become a pain is switching between dialects, especially on an older DB version. I was stuck on MySQL 5.7 a few years ago at a previous company, and not having access to window functions or CTE was just a headache. We started a new product and I made sure our new DB was MySQL 8 or whatever was recent at the time and my queries were so much easier to write.
The quality of life improvements to SQL in various DBs has been made it an absolute joy.
I just use go and call it a day for backend at least.
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.
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.
Personally I’d go with the GoX-Light-Stack (just made that up): Go + SQLite backend and HTMX frontend.
TBH it does what it does well, and I rarely see a need to reach for an alternative.
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.
It's incredibly simple and old school. No kubernetes, docker, cdns, etc.
Write code, build binary, ship binary.