Rails is awesome, and so is Django. I’ve built mission-critical apps in both and still do with Python. That said, I’d love to switch to Go for building large monoliths since it has a tighter type system and better concurrency constructs.
The problem is, Go community has never really filled that gap. I love Go, but the whole "Go doesn’t need a Rails or Django" mindset is part of why it hasn’t taken off in this space. Building networking tools and CLIs in Go is great, but when it comes to quickly building a full-stack web app, I still reach for Rails or Django. So this whole "X is dead" doesn't apply to Rails at all.
With tools like ogen[1], one can take a single OpenAPI document and generate server code with a static router, request/response validation, Prometheus metrics, OpenTelemetry tracing, and more out of the box.
It can also generate clients and webhooks. Authentication is just declaring a SecurityScheme in the OpenAPI document then implementing a single function. The rest of the backend is just implementing a single interface. Unlike oapi-codegen, there is no need to tinker with routing libraries or middleware for authentication and logging.
Pair this with sqlc[2] and SQLite's `pragma user_version`, and you get type-safe database code and database migrations for free. I will concede that adding SQLite is a manual process, but its just two imports added to main.go.
Frontend is entirely your choice. Go's standard library provides good enough text templating that I don't miss ERB or Django-style templates. Using the standard library's `embed` package, one can easily embed static assets into a single binary, so deployment can be as simple as `go build` and moving the binary.
I have a hard time using languages besides Go for developing backends, because the code generation tools make Go as convenient as frameworks like Quarkus while staying lightweight and fast.
Exactly. I don’t want to waste time on trivial decisions like which frontend tool to use or what templating engine to pick. This is exactly why Go isn’t great for building full-stack apps. Every app in Go looks different because you have to assemble all the parts yourself.
In contrast, RoR or Django provides a nice rubric to get you up and running quickly. That said, I still like Go when I need to spin up a microservice with a well-defined scope.
I was looking for a mature, complete and powerful statically typed stack as well. ASP.NET was my clear answer (not Go or Rust).
There's a lot of noise coming from Microsoft to sell their new products (this year: Aspire.NET). But don't be mislead by this noise: .NET Core (C#, ASP.NET Minimal API or MVC, EF Core) is more batteries included and reliable than most other options. The only gripe I have is the need to get into the OOP and DI mindset ("create custom implementations of some abstract classes and put them into DI and the framework calls your implemented methods magically" kind of stuff). Takes some time, but not a big deal for experienced devs (and younger ones can learn faster anyway :-)).
The problem is finding fresh blood who want to write C#. RoR or Django is a much safer choice in that regard. This OO/DI stuff has fallen out of fashion (whether that’s good or bad, I don’t know) and very few enjoy working with these constructs anymore.
That's true. Once upon a time when I was intern I was charmed with ASP .NET.
Couple of years later I had opportunity to work with Django. Everything looked so batteries included, felt hackable and syntax was friendlier to me (Only exception ORM).
Unfortunately project got on hold and I was moved to write new service in ASP .NET.
Holding mental model of Dependency Injections, everything OOP, boilerplate produced is cumbersome, CamelCase...
It's a top-heavy market because the industry-wide growth and momentum was 2001-2008. Since that period, the available alternatives for entry into a dev career have increased. Python/Ruby/JavaScript tend to be what most juniors are encouraged to focus on. There are new waves of C# enthusiasts, but the growth in dev overall has drowned it out.
Could be, but the wave is against OO languages, and unfortunately, juniors often show unwarranted disregard for the paradigm. We’ve had good interviewees who flat-out told us they weren’t interested in working with any Microsoft stack—including C#, .NET, and Azure—and they definitely weren’t the only ones. Betting on Python, JS, and Go is way safer, and many new startups reflect that.
I'm surprised you've had trouble finding juniors in this market. What sources were used to build the candidate pool? I'm even more surprised to hear that finding Ruby juniors was easier.
One can argue it goes against some of the Go principles, but it's a really nice stack for solos or small teams without dedicated SREs. And as you grow you can BYOC & deploy it yourself or completely rewrite your API layer using Go stdlib.
You would still need NextJS or Remix/RR7 for the front-end, but one nice thing is that it would auto-generate the client SDK in TypeScript which makes integration a breeze. And while I personally prefer Remix/RR7 for frontend, Encore has integration with Vercel PR feature which is really hard to beat.
I’m a big fan of Django and Go as well but the only thing in the Go ecosystem that I’ve found that comes close is beego: https://github.com/beego/beego
But it still needs to mature quite a bit before I’d be comfortable saying it’s anywhere near Django or Rails
I’m working on a project in go right now, and I’m really, really enjoying it, but I really do not disagree with you. AI has helped me overcome those framework hurdles. The codebase feels extremely clean to me.
My gut still says rails for customer facing, Django for internal tooling or data work.
Ruby has Sorbet if you want to add typing. And better concurrency constructs for Ruby are in the final stages of being backed with Fibers. For example, Falcon is the new Ruby web server that’s built with Fibers. It’s not quite ready to replace Puma but Fibers are coming along.
The author of Stanza language has this insightful article on the viability of a programming language for creating a powerful framework like Ruby on Rails [1]. Surprisingly there's no Go and Java equivalent, either it's the incompetence of the programming languages (can't) or the programmers (won't), or both.
I've had to do some maintenance on Rails apps in the past, coming from my Java background, and it was painful as hell. It's just what you're familiar with. I can take my Java and Spring Boot, both of which I'm very familiar with, and write an article like that to wonder why Ruby has not something awesome like Spring Boot. But I don't do that, because it'd be equally embarrassing. Spring Boot for me is super productive, has a lot of batteries included, and is a dream to work with, hence I have no desire to play with Rails. Had I stumbled into Rails development, as a career path, I'm sure it'd talk about this the opposite way.
OTOH, Java almost made me quit and choose a different career. I’ll work with anything but Java. I’ve worked with Python, JS, Ruby, and Go, and I’ve been fortunate enough to avoid working with OO languages. To each their own.
No, it is absolutely not “what you’re familiar with”. Is there a “spring” command that generates controller + view + test for you? That does migrations? Can you say “install spring” and get everything you need to start without stitching dozens of scattered spring artifacts?
I’m not even going to talk about one of the most verbose languages out there locked into OOP, made dynamic with thousands of annotations and held together by a DI framework.
Spring is an industrial factory that is good for huge teams, because it acts as a straight jacket.
You're embarrassing yourself as much as the article I was responding to by speaking in these absolutes. I have no doubt you worked on a ("huge") team that made all the wrong choices around Spring, or something like that, and by no means will I claim that OO is the best paradigm, though Java has adopted enough from other paradigms to give you at least some alternatives ways todo things. And I have worked in my share of dysfunctional projects, but I'm currently working on a small team that is highly productive with Spring Boot, and we wouldn't want it any other way.
There are plenty of Spring Boot starter dependencies that you can pull in to do some of the things you're mentioning. Can you say "install spring"? Yeah, I think so, there's the Initializer that comes in different modalities. Migrations, you ask? Not sure what kind, but Flyway or Liquibase are some popular dependencies, which are natively supported by Spring Boot. Again, it's all a breeze, as I'm sure Rails is too.
I get that there are poor workplaces making Spring applications a hellscape, and some of those folks escape to go do (let's say) Rails. Others may decide that Java and Spring are fundamentally fine, but need to be used in better ways and then they do so, we're not all idiots (not suggesting that you said so).
My point was that Rails and Spring prioritize different things.
And while you can end up with roughly equal result with both, the path can be drastically different. Never wanted to suggest that whoever uses Spring over Rails is an idiot and vice versa. Cheers.
It's Ruby that makes Rails what it is. Matz combined the best of Smalltalk, Lisp and Perl to produce a language second to none for writing DSLs. DHH simply capitalised on Ruby's strengths.
Go initially tried to capture the C/C++ space and failed miserably. Rob Pike lamented[^1] over that in a famous blog post. It got the most love from people coming from Python and Node. Then it became the defacto language for writing networking tools, and to this day, it holds that crown.
Go is in an awkward spot—it’s not dethroning Python because it’s not as expressive, academics hate it, and it’s not as fast as Zig or Rust to appeal to systems programmers. So it only makes sense to target the web services section dominated by Django and RoR.
Every time I step out of elixir I feel like I’m coding with some cumbersome construction gloves and everything is kinda coerced to work together. But for some reason it’s not picking up a lot of steam and the job situation is rough
Typed languages are in big time, and any dynamic language is facing an uphill battle for adoption, no matter how good it is. Elixir seems to recognize this and is getting there, but it hasn't fully arrived yet.
It’s sorta inevitable. I started with Python and used to hate the constraints types put on my design. But as I started working on larger projects, I got tired of Node-Python-Ruby and wanted something faster with stricter types but without too much ceremony. Found Go to be in that Goldilocks zone. The benefit of typed languages becomes easier to appreciate once you have accumulated a certain amount of elbow grease.
Types and editor tooling IMO. Both places they're making investments, but both areas where I feel like I'm giving up a lot of power, even though it's admittedly to GET a lot of power.
what exactly is present in intellij that isn't available in vscode / neovim with lsp / newer emacs? I ask because, I use(d) intellij for java and maybe i'm not using most of its capabilities or they're hidden away in plain sight, but i haven't noticed anything special aside from the slow ui.
For me there are two axes that are lacking (based on Scala and Elixir usage):
1. The feature set is just far weaker. If an LSP implementation and the client both hit 100% coverage, then you might end up having the same refactoring, code generation, follow definition/load docs/infer typing support. But of course the Elixir LSP matrix shows that basically none of the LSPs offer a complete feature set and you basically get to pick which features are missing. What about debugger support?
2. This could be viewed in some ways as a recapitulation of point one, but I actually appreciate the Integrated in Integrated Development Environment. I very much dislike when adopting a new technology having to cobble together a disparate number of tools to create a good editor experience, especially in a time where as a novice I'm actually not at all qualified to understand what a good editor experience would be! I actually call this the Clojure Problem, which is that many Clojure devs decide they have to learn emacs or a complicated fireplace.vim setup in addition to Clojure and wind up learning neither.
Regarding speed, don't get me wrong, I empathize with complaints about it and whenever I'm doing C# work for one of our services I'm reminded of just how slow developing Scala can be in particular. But I don't think of LSP approaches as fast, either. Perhaps they are async and don't block the UI, but now I'm just sitting here typing and getting constantly out of date feedback from the editor as it and the LSP catch up to whatever text has been entered.
Not too familiar with Go but this makes sense to me. The standard libraries are really great for microservice type stuff. Things that, as a python guy, I would have reached to Flask for. Problem is, I never reached to Flask for much of anything.
Go’s stdlib is almost as good as Python’s—with the bonus of a stricter type system and faster execution speed. Package management in Go is better too, though uv is making Python’s experience smoother.
That said, Python is great, and beginners love it. For algorithms and prototyping, I still prefer it. But for writing servers, Go’s stdlib lets me spin up a production-ready, concurrent server using just the basics. What Go lacks, though, is something like Django, which it could really benefit from.
> Go’s stdlib is almost as good as Python’s—with the bonus of a stricter type system and faster execution speed
Define good, and for what applications? I'm having a very hard time imagining that go's standard library is anything like as comprehensive as python's.
Go’s HTTP library is production-ready. Python’s isn’t. Python has a ton of dead batteries in the standard library—stuff like urllib is plain dangerous to use these days. But Go doesn’t have collections.abc, itertools, heapq, deque, and many other data structure niceties. I still reach for Python for numerical and algorithmic tasks.
I’ve found the Go standard library to not only be very complete, but also to contain far fewer sharp edges and dead batteries than that of Python for every use case I’ve tried.
ASGI too. But it’s not too bad and tools like Starlette / FastAPI make it a breeze. Go servers are fast but generating docs from code is a lot more work which you get free in FastAPI.
The Kubernetes API is one of my least favourite Go packages - largely generated, boilerplate all over the show and hasn’t even adapted to use things like log/slog without some wrapper.
A much nicer library for dealing with Kubernetes is the kube crate [1] for Rust. The worst aspect of it is the dependency discipline, though that is no worse than the official Go client.
Go’s k8s package is the OG. Everything else spawned off of it, so it’s packed with legacy artifacts. But yeah, I wouldn’t use it as an example of a good Go package.
Yeah, Go’s niche is networking. But it could be so much more. The language is nice and fast, and there’s no reason it can’t be a solid choice outside the microservice and tooling universe.
Node/Express is my goto for quick and dirty picoservices that only really run on local developer machines. Asp.Net WebAPI or MVC is my ideal backend stack
The problem is, Go community has never really filled that gap. I love Go, but the whole "Go doesn’t need a Rails or Django" mindset is part of why it hasn’t taken off in this space. Building networking tools and CLIs in Go is great, but when it comes to quickly building a full-stack web app, I still reach for Rails or Django. So this whole "X is dead" doesn't apply to Rails at all.