Ask HN: Which Tech Stack has still maintained its charm?
18 comments
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.
Write code, build binary, ship binary.
It's incredibly simple and old school. No kubernetes, docker, cdns, etc.
Write code, build binary, ship binary.
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.
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.
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.
This is mine as well; I haven't worked with Go professionally in a few years, but have very fond memories.
I still think RubyOnRails is the goat to super quickly create a great prototype that can eventually scale to large scale production.
In terms of ethos, Ruby has stayed pretty much the same since the late 2000s, which is a great thing.
> ...charm?
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.
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.
> don’t pollute
WaitGroups, Mutexes and spawning channels for things you could just ‘await’.
WaitGroups, Mutexes and spawning channels for things you could just ‘await’.
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.
I've been using Turbo Pascal and it's derivatives since the 1990s.
Lazarus is cross platform and fast. The GUI tools are unmatched.
Lazarus is cross platform and fast. The GUI tools are unmatched.
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.
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.
JavaScript - not hard to get productive, opportunities to go deep are still there.
SQL, as hard as folks try, it's not going away.
Also Ruby on Rails too.
SQL, as hard as folks try, it's not going away.
Also Ruby on Rails too.
> SQL, as hard as folks try, it's not going away.
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 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.
Charm? Django and Rails.
Future? JavaScript. Or Python or Ruby or C# or anything else you're productive in, if you prefer.
Future? JavaScript. Or Python or Ruby or C# or anything else you're productive in, if you prefer.
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.
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.
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.
Market demand:
- high-performance, low-latency data processing skills
- out of the box thinking and "I can do it" attitude
Charm:
- Java lives its second life now with JVM, OpenJDK and GraalVM.
Shameless plug - just released a Java platform for building enterprise apps as an opensource project: https://github.com/openkoda/openkoda
- high-performance, low-latency data processing skills
- out of the box thinking and "I can do it" attitude
Charm:
- Java lives its second life now with JVM, OpenJDK and GraalVM.
Shameless plug - just released a Java platform for building enterprise apps as an opensource project: https://github.com/openkoda/openkoda
LAMP (or LEMP) stack.
Throw in a PHP framework (probably Laravel for rapid development) and use server side rendering.
Maybe add in Redis for caching too.
All hosted on a single Digital Ocean droplet.
Throw in a PHP framework (probably Laravel for rapid development) and use server side rendering.
Maybe add in Redis for caching too.
All hosted on a single Digital Ocean droplet.
Numpy for numerical computing?
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.
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.
Rather than maintained, C# and F# have gained given how the tooling and developer experience turned out in the modern versions.
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.
If the client wants Java, I always go with https://quarkus.io/ or hilla.dev. GraalVM allows you to create native executable images.
React server component.
phoenix liveview
Can you bet on something for the future?