Rewrite It in Rails
dirkjonker.bearblog.dev
dirkjonker.bearblog.dev
I have tried Meteor (back in the day), Remix, Nextjs, Node w/ Express, etc. Always talking about how much better they are. But in my mind web dev is a solved problem. The js stuff is mainly just developers wanking off, driven by a bunch of dollars from big companies.
Systems stuff, deployment infra, etc. is great for stuff like Rust & Go, but shoehorning into web dev makes no sense. I would love to just move on from this debate but it seems thats going to never be possible.
The best thing I think Rails still has is ActiveAdmin. Everything else, I really can take or leave.
ActiveAdmin gets you off the ground very quickly, but is also extremely inflexible (and, IIRC, poorly maintained). The last time I worked on an ActiveAdmin backend we had to use all sorts of weird hacks to build the interface the way our backoffice team needed it to be.
Spring and Spring Boot are incredibly productive and give you a ton of stuff out of the box, whereas some people actually enjoy writing a lot of plumbing code as a distraction/challenge from boring business code. Those people will migrate to "lean" frameworks because it will give them the opportunity to write more low-level plumbing code.
I highly doubt that.
The real reason is likely more about the GraalVM, which spring hasn't supported until very recently. (And still only with caveats)
The people jumping to Quarkus or Micronaut are more eager to chase the new shiny and are willing to spend the time debugging not-yet-mature stacks.
Edit: To be clear, the reply mentions fanboyism but we are talking about the maturity of a stack. Spring has been around for 20 years and is not going anywhere. Quarkus just reached 5.
Especially considering that Springs support isn't full yet, and quarkus has been around for 5yrs now.
They're both production ready stacks though, really strange to have spring fanboyism in 2024
I have also some nice things to say, and I'm not going to make a detailed analysis here but IMHO, it's really not worth the tradeoff.
Personally the experience with JSF and Web Forms, is what makes me appreciate any framework that exposes the underlying browser stack, instead of pretending it is something it is not.
Now, do I actually do this? Absolutely not. Rewriting everything is way too much fun, and I live for the thrill of trying new things, even if it makes zero business sense.
You can't always rely on the docs too, however excellent they may be - some game developers read code from game engines to optimize, some web developers read code from their web frameworks. But, some change their whole stack when they get frustrated, and I argue that it makes little to no business sense to do so. Just understand what you are working with and deeply.
Django by contrast, I agree, it's perfectly clear. (Though some of the meta magic does get spooky, but that's the nature of meta magic, and I generally find the tradeoffs are worth it)
You basically have either a property or a function with the name get_property for a certain number of things (queryset, serialiser, pagination class, etc.) in any case. I tend to recommend in our projects style guides that once you want to override the behaviour of a mixin, you don’t inherit from the mixin anymore.
The two biggest issues I came across with teams in DRF were people coupling the serialised directly to a single database model (i.e. using ModelSerializer everywhere, even when that didn’t make sense), and trying to put too much stuff into a single class based view or viewset.
I've historically preferred RoR but with the tremendous growth of Python in the last 10+ years, Django has become a more practical choice. ML and data science devs are already familiar with Python and, with the Django docs being as excellent as they are, these folks can be productive in a very short amount of time -- should they need to be. I've seen this firsthand on multiple projects.
Also, along with the author's case for the path of least resistance, the Django framework results in fewer "decisions" (arguments) about application structure than using a less opinionated library or micro-framework.
The Django/FLOSS community is also much more active than I was expecting it to be (Rails bias, probably) and has been very pleasant to interact with.
I only wish Django had Rails-like generators and in-built data seeding (e.g. rake db:seed).
Overall, I’ve been very impressed with the product and maintainers. There are so few OSS projects that rise or the level of quality that Django has managed to achieve. Now if only they could sort out type hints ;).
The thing I wish Django had better OOTB support for is background tasks, I've not used it but I understand this is very well done in Rails and Laravel.
You're spot on about background jobs. Rails added support 2-3 major versions ago and there's no shortage of back-ends. With Django, it seems to be Celery-or-bust and there's no Django API that I'm aware of. I actually recently rolled my own solution using SQS and a dedicated compose service which runs a management script (in the Django context). It works but ... it's klunky, the API is ad hoc and there's no monitoring/retries/etc.
It’s actually quite straightforward using CSVs and models to load each row in.
Can see it getting complex once I need to seed a large dataset or with loads of relationships. Look forward to seeing an official 3rd party app that takes away the complexity from my code base for seeding.
Yes, to your point, it would be great to see the jazzband project adopt/anoint it or another solution.
If you are using Rails for anything where you are not absolutely sure of how many users or RPS you will have, you are just saving money in launch time but spending more on servers.
So I think we're good with performance.
Also remember that Shopify didn't start out making billions. They started as a small side project on a far, far slower version of Ruby and Rails.
Same with GitHub, same with many others that are either still on Rails or started there.
You can optimise things later once you actually have customers, know the shape of your problem and where the actual pain points are/what needs to be scaled.
To me, I care a ton about performance (it's an area I work in), but there's not a lot of sense in sacrificing development agility for request speed on things that may not matter or be things people will pay for. Especially when you're small.
>On Rails, the most heavy page has a P95 duration of 338 ms. There is of course room for improvement but it's plenty snappy.
I guess everyone will have different opinion on P95 at 338ms. The great thing is that we are getting cheaper CPU Core price and YJIT. As long as this trend continues, the definition of Fast Enough will cover more grounds for more people.
That seems like an amazingly good trade off, even if it were true which I am not sure about.
But... That's kind of the whole point
yjit and fibers have made things even better, and plenty more is coming I'm sure
First, these kinds of tests don't do anything useful and just show that some frameworks have more overhead than others. Once you have an app that was developed over years rather than hours and actually does a lot of stuff on every request, it's a whole different game.
Second, the kinds of applications I write rarely get more than 10-20 requests per second. If Rails would peak at 2500 rps as that YouTube video tests it at, that would be plenty. If I were writing some kind of IoT platform rather than a business app, I'd probably not start with Rails for that reason.
Third, for an actual web application, you want to consider what the user experiences, not just how fast the server responds. You can make an application feel much faster than the server response times by preloading on hover, (http) caching, async loading of things that are not visible yet, etc.
One specific example is images and srcset. If you are doing a react front end anywhere in your app (not even an SPA) interfacing with the asset pipeline doesn’t have a canonical solution.
This just makes it feel behind the times, since what I always liked about rails was the “one right way” that was always reasonably sane.
So it feels like nowadays you need to trade user functional front end app things, like load time and LCP for dev experience in rails. Sad.
The Rails demo wasn't that appealing to me, other than showing the difference on how lucky one might get regarding adoption and spotlight being in the right place.
Nowadays I still don't see a value, and rather go for Spring or ASP.NET.
By the way, the founders of that Tcl based startup, went on to create OutSystems, which is one of the few successful RAD tools for Web development at enterprise scale, and Portuguese success stories in IT world.
Unfortunately every team I’ve worked in hasn’t seen the light and prefers FastAPI/SQLAlchemy/Pydantic (before FastAPI it was Flask).
My theory is that the initial learning curves are different: with FastAPI it’s quick and easy. You barely have to read anything. Django has a steeper learning curve. There’s a lot of reading involved. Type hints aren’t a big thing in Django, but they are in FastAPI, and the average full stack dev seems to like them.
Later on it’s totally different of course. With FastAPI you’re building it all from scratch, and it’ll be much worse than the Django solution.
SQLAlchemy was historically a much better ORM than Django's. It's layered architecture combined with Alembic does make a difference.
I still agree that using the integrated thing anyway is probably the right way to do it if you are working in a team. I also think Django should just adopt these components and we would not have the discussion in the first place.
Now of course it is not Django's responsibility to unite the Python ecosystem in the first place and they can value other factors and arguments as they see fit.
Although this very thread shows that there might have been something to it.
> a sizeable share of the community deems inferior
Well, yeah, SQLAlchemy is standalone, you can use it in a lot more situations than Django's ORM in practice, because you're not tied to using it in a Django site. But that doesn't mean it's "better"
I see what you’re saying, but a lot of Python users, especially those who have been using it pre-3, would say that this is unfortunate.
> I also think Django should just adopt these components and we would not have the discussion in the first place.
Oof, such a monoculture sounds terrible to me!
The main thing I miss about Django is always the DB migrations in any case. I found that pattern to be very flexible and very powerful.
I agree that web dev is basically a solved problem, I don’t know why stuff like next.js exists
This forum leans backend heavy and there's definitely a bias against using javascript on the backend. But many top websites use it for their infrastructure. It's not all hype driven development.
Plus with Django and Py03, one can write the service layer in Rust(if you’re into that).
It also enables building an interface to Python’s data tools.
What use cases with Django would you say it makes sense to reach for?
Hahaha this made me chuckle out loud.
Rails has a high learning curve. Perhaps people working with it for years don't notice it. Node + Express seems faster to learn and ship, but my experience with Rails is limited.
Somewhat unfair comparison but I expect authors to at least learn from the mistakes of the past.
I've written my fair share of far too long ruby methods, 200 lines and more, but those are truly my fault. With a more granular unit test regime those can be prevented.
So does the autoloader used in Rails, it's called convention over configuration. There are only very few places it will look for the code (and in production everything gets preloaded too)
So unless you want your class User actually in iMeanThisUser.ext or ../../../a/random/path/that/makes/no/sense/user.ext you shouldn't need explicit configuration
>> Interestingly, all of the things that used to annoy me about Ruby and Rails now annoy me much, much, much less. I have accepted that there is no perfect language or framework. You just have to know its strengths and weaknesses and deal with them.
But it is much more efficient working with the framework, knowing its limitations. Just spending time really understanding tools one work with.
> Meanwhile, I started building "version 2" of the application. I chose Rust as the language for the backend and SvelteKit for the frontend.
Since it started out as Rails in v1, the post is to beware abandoning a framework that's working for you.
just a nit.
I think they used a narrow definition of coherent, for blue collars, which in web often imply mundane CRUD and agency apps.
I wouldn't expand the discussion to a brother definition about a general incoherency in the language. And certainty wouldn't bring comparisons to C++ when replying to their message.
I'd also say the macro systems. Macro by example is a totally new (and let's be honest, awful) language, and the proc macros are another thing again.
Thankfully I find I very very rarely need to actually write macros, and you can avoid async most of the time unless you're doing web dev.
Still a fantastic language - easily the best at the moment IMO, but I see his point.
Despite recent trends to use Rust for everything, it’s not supposed to be used for CRUD apps. I think this blog post is really just a case study in “use the right tool for the job, not necessarily the language you enjoy in your spare time or the latest trend in programming”
Crud are still software I think
> sparing few allocations
Minimizing memory allocations is typically what you want when you reach for Rust or C++.
They wish :) Why should anyone - apart from aesthetic preferences - fight the borrow checker and deal with long compile times when they can just use a language with GC? It just doesn't make sense to me from a technical standpoint. You reach for Rust or C++ when you can't use C#, Go or Java.
> If you write async code, rules are not the same than non async code.
The thing is: Rust is (also) catering to people who want to write async code on embedded devices.
Choosing something like Java, C# or Go might not sound sexy or cool, but with get the job done as fast as Rails while running almost as fast as Rust. That choice will also generally mean less bugs and a having a project that is easy to maintain and extend.
There are more compilers by the way.
Here is a kernel writen in a GC enabled system programming language.
https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kerne...
Or do you rather have one in Go?
Or just as low level and high level as Interlisp-D at Xerox Parc.
As plenty of other languages.
If you want actual low level code, that is Assembly, and even that depends if the underlying CPU is a pure hardware implementation, or makes use of microcode and is for all practical purposes a mini-interpreter/JIT in hardware.
It’s a bit like a podcast I listened to recently where someone suggested any language with a proper algebraic sum type can be considered a dynamic typed language in some ways. I mean, if you get philosophical about definitions and lean heavily mainly on historical context, it’s possible to say just about anything.
"C Is Not a Low-level Language Your computer is not a fast PDP-11"
https://queue.acm.org/detail.cfm?id=3212479
Naturally those people will also vouch that an article on the ACM, written by a one of the GCC Objective-C and GNUStep early contributors, and nowadays key researcher on CHERI project isn't something to take into consideration.
Relative to Ruby, an interpreted dynamic language, sure, I will grant you that Go is lower-level, in the sense that you can compile a binary executable from it.
Go also happens to have web server primitives in their standard library and you COULD build a web app with only net/http...
Seriously, how could someone describe a GC memory safe language as "low level"? Unless you mean the type system, which I admit is a bit more primitive than something like C++ or C#. But Go is definitely closer to Java/C# than C++.
If anything, it allows you to go way more low-level than Go.
Perception problems do not affect technical capability, and there exists a world of gamedev beyond enterprise engineering that treats C# appropriately.
With care, none of that is necessarily true. I think that's an overgeneralisation.
I've worked with many large, bug free, stable and easy to modify rails apps. I've also worked with messy rats nests rails apps, and go apps, etc.
It can be true that some languages/frameworks make it easier to get into that state, but all have a chance to make that a possibility, or other trade offs that make it difficult to build with for other reasons. With discipline you can make anything work.
And with sufficiently large applications, those issues really start to spread through the whole program - or can.
addendum: I'd love to know why I'm getting downvoted here. I definitely speak from experience, here.
I have never used BaseCamp, but I believe their products are well written and decent, hence with adequate care, good architecture and maintenance, it should be possible.
Rails is quicker to build in than Java, C# or Go for most functionality needed in most web applications for similar skilled developers. In my experience, up to 3x quicker.
I’ve worked on large monoliths and SOAs, and worked alongside Java teams. I even introduced Go to a Rails shop because I believed what you did.
Turns out the real problems were MVC isn’t right for everything, and we weren’t name-spacing with enough rigour. Fix those in small and targeted areas, and Rails is just fine.
Personally I absolutely hate it, and regret taking a job in it. Its the first language ecosystem that made me realize yes, apparently I really do care a lot about the language(s) I work in (had prior exp in php, python, java, Go, and Typescript, and enjoyed most of them). But I wouldn't knock anyone for using it, especially if they can hire experienced teammates in it or generally find the approach (typeless, convention over configuration) appealing. It's definitely a great choice for a web product if the team(s) will stick with it over time. I'd happily manage a team using it at this point, I just don't want to write it anymore.
I'd recommend anyone who'd be interested in "Rails, but in TS" to give it a go.
It feels much more similar to rails (or Laravel) than the most popular TS stacks, and also has "batteries included" instead of leaving you to decide on every part of your stack (or trust a template from a third party).
Recently, I've been fascinated by the "batteries included" back end frameworks of Rails, Laravel, and Django, but I've written TypeScript for pretty much my entire career, and it's just easier to keep it that way than to switch now.
What are your thoughts so far in your testing? Could you compare it to any of those other frameworks I mentioned?
Rails is definitely more mature. It has a larger ecosystem and much more documentation. If you don't see any benefit from having types and sharing the programming language between the backend and frontend, then you are probably better off with rails.
That being said AdonisJS has been working out surprisingly well thus far. I've found the documentation to cover pretty much anything we'd usually want an app to do, which is refreshing in the world of TS.
You are also not locked in any way. While you can use the in-house ORM, validation library etc., it's easy to use something else if you prefer that.
There are a few more rough edges than what you'd be used to from Rails, but nothing big so far and the source code is easy enough to get around, which I wouldn't say is always the case with rails. There's also a discord channel that seems fairly active and helpful.
For a recent personal project I went with NestJS but soon after discovered Adonis. I've actually been considering switching.
To me it seemed more interested in being a smart dependency injection engine, and enforcing an - IMO not very JavaScripty - module pattern rather than being a useful tool.
You can do everything you want, but you will have to make all the decisions yourself, and you will have to make everything play by nestjs's rules. And from my experience the seemingly comprehensive docs often don't get you very far.
Follow the guide for Prisma and you won't be able to extend the Prisma client unless you refactor the service you've just made.
Follow the guide for file upload and you will have a file in your controller, but very little information about how to store that file.
That being said, I can see that lots of people really like nestjs, so maybe I'm just not getting it.
Node.JS developers are starting to realize it's not just about having the ecosystem and the tooling, it's also about the framework being a holistic solution to building out your application. That's what NextJS and SvelteKit help with, and that's what Rails revolutionized back in 2006.
I like typescript. In what way isn't it a "properly designed language", compared to C#?
Can you give any examples of ways in which those constraints have resulted in a worse language?
That's oddly rude. I thought it might be useful to someone (not necessarily you) to bring up the fact that TypeScript is subject to a very different pressure than most other mainstream languages. That has obviously resulted in a very different type system, e.g., one with much better support for structural typing than most mainstream languages.
> It just restates the claim that typescript is worse in some unspecified way.
I did not "restate that claim". In fact, I was careful not to claim that TypeScript is "worse" than any other language, because that's a meaningless word without more context.
> Can you give any examples of ways in which those constraints have resulted in a worse language?
Again, saying that it's "worse" or "better" without context is meaningless.
I do think it’s a huge improvement on JS though.
For example, C# doesn’t support parameterised enums like typescript and rust do. Once you start using parameterised enums, you seriously can’t go back. It’s a killer feature.
But even then, typescript goes further. All of these languages let me make a Color enum with red, green and blue variants. But as far as I know, only typescript will let me write a function which takes a strict subset of those variants. In typescript I can have a function that only accepts red or blue - and passing green (or something that might be green) would be a compilation error.
Typescript also lets you make another type with a superset of another type’s variants. Eg type Foo = Color | “yellow”.
In rust if I want to change a function’s signature to make one of the parameters optional, that’s a breaking api change since all existing callers need to wrap the parameter in Some(val). But in typescript, I just change the parameter’s type from T to T | null and everything works.
Again, in what way is it hamstring? I’ll grant that JavaScript doesn’t have quite the performance of C# (though modern runtimes are pretty impressive!). But typescript itself seems great.
type Animal =
| { species: "dog", name: string, catsChased: number }
| { species: "cat", name: string }
const animal: Animal = ...
// Available in all cases
console.log(animal.name)
if (animal.species === "dog") {
// Can access dog attrs here
console.log(animal.catsChased)
}
// ERROR: catsChased only exists for dog and not for cat
animal.catsChasedTo be fair, you rarely miss them with pattern matching and records. In a similar vein to a sibling comment:
var animal = ...
Console.WriteLine(animal switch {
Animal.Dog(_, var cats) => $"Chased {cats} cats",
Animal.Cat or Animal.Bat => "No cats chased",
_ => "Unknown animal"
});
abstract record Animal(string Name) {
public record Dog(string Name, int CatsChased): Animal(Name);
public record Cat(string Name): Animal(Name);
public record Bat(string Name): Animal(Name);
}
For the FE I would prefer Typescript over Javascript.
Are you seriously comparing "being able to execute code on the backend" with Rails? Or Django? Or Laravel?
There's no way in this world Next/Remix/etc are helping in any way to write code on the backend. Where's the support for database access? migrations? ORM? queues? scheduled jobs? validations? translations? authentication? authorization?
The only thing Next.js is helping with is pushing people towards Vercel's platform, that's it.
I'm not a fan of Go, but that's not the thing to blame here. Using Go for a "CRUD" application is a terrible decision from the get go.
I’ve found that perf issues were much more often caused by the DB queries than by Django itself.
Here's a list of easy/low hanging fruit optimizations that are often just forgotten: Creating indexes in the db, delegating more logic to the db than doing it in code (e.g. using pipelines in mongodb, partial indexes in postgres, etc.), turning on brotli/zstd compression for all or most requests, caching objects or requests in memory (e.g. with redis), setting appropriate cache control headers, frontend stuff such as not rendering thousands of objects as DOM nodes and instead using canvas (recently saw this in a map application).
https://www.postgresql.org/docs/current/sql-createindex.html...
It's like using Rails to write a database or a DNS server. You're just trying to use the wrong tool for the job.
Among other reasons to consider it: if you want to run on a FaaS platorm or container setup, Rust has much faster cold start time and makes for smaller container sizes.
Among reasons to not consider it: if you want to iterate rapidly by editing text and near-instantly hot-reloading your code, Rust web frameworks aren't really there yet. They will be one day, but they're not yet.
Faster start time maybe, but I’m not sure about smaller containers. Rust is terrible with binary sizes in my admittedly limited experience.
- sqlx binary: 200+ crates, 5.4Mb (after strip), 27 kb per crate on average.
- zero2prod last example: 400+ crates, 14Mb (after strip), 35 kb per crate on average.
Binary is statically linked, so Docker container is very small too.
You can download a pre-compiled sqlite tools package includes four binary CLI tools in only 6.5 MB vs that one sqlx binary which is 5.4 MB. Of course they're not the same, but the general trend I've seen is that Rust is as large or often larger than bloated C++ projects.
For example I worked with Rust on a Yocto project where you can't use Rust's stripping config because it breaks (broke?) the hashing Yocto does. A very small IoT API project ended up being 50+ MBs. It was larger than the rest of the entire Linux system. I've written IoT projects of similar complexity in Go and Nim which come in under 3-4MB with full debugging no stripping needed.
> because it breaks (broke?) the hashing Yocto does.
It's problem with Yocto. In my case (few years ago, before the war), I just build RPM packages by my own build system and then install them on top of pure Yocto system. I optimize my binaries for embedded by size.
In theory, debug symbols can be separated to a separate debuginfo rpm, and installed only when needed or mounted remotely from a host system. In practice, I just install the binary enhanced for debugging (with debugging and tracing features enabled) directly to Yocto device, then add test case to reproduce the problem on host, because I hate debuggers.
Why you think that Rust is a wrong choice for a simple or a complex CRUD application? Can you explain, please?
I looked into Ruby's static typing attempts but the picture painted was grim.
The attempts you've seen is probably Sorbet (sorbet-runtime) and RBS. In my opinion, RBS would be an option for me if they didn't force me to work in a separate file just for type declarations.
There is one gem that is interesting, it reminds me a lot of jsdoc. It's called rbs-inline https://rubygems.org/gems/rbs-inline
I think the problem with static typing is that it changes the whole ecosystem too much to be considered just optional, even if it's backwards compatible (like in Python).
Just as an example I'm using lambdas in fasthtml in Python that don't allow type specifications for adding routes and fasthtml keeps on spitting out warnings that I didn't specify the type and doesn't handle variables in lambda functions correctly.
That's a very interesting yet valid downside I didn't think of
I definitely think Rails can be worth trying, but if you're the type to be evaluating types from the outset, I'd wager that's the exact kind of person that won't like what they get into.
I think decent type checking can fix many of the usual bugs people encounter, but the syntax for types at least needs to be decent.
Our user-friendly and featureful website was a big part of our appeal. A lot of the non-Rails functionality was the unseen "secret sauce".
I think this approach worked well. Most of what you need for a web app is commodity functionality. Correctness is not even particularly important in many cases. The Rails ecosystem has a lot of useful tools that make it easy. For example, there are multiple options for automatically adding a comprehensive admin panel. This let our non-technical admins manually accomplish CRUD tasks in the web app's domain. This allowed us to avoid overengineering. We could implement something that covered 80% of cases, and manually handle any edge cases or things that happened infrequently. An example is locking user accounts when a person left a customer's company; they could just email us and an admin would manually go in and check the "locked" box for the user. This allowed us to move very fast on new web app features, and focus on other aspects of the system.
There were downsides, of course. One of the big pain points was upgrading Rails itself, and dealing with dependency hell at times with various libraries. You also have to know many things about how Rails works, which involves a lot of quasi-mysterious and implicitly-performed things. For example, I recall frequently coming across function calls, and then I would look for the function definition, only to find that it was a function that doesn't exist in the code and was generated at runtime by Rails.
In this thread and others, HN does a lot of talking about the fixed properties of these languages and frameworks.
Something I don’t see much is: choose the tool that you and your team are most familiar with.
It’s relatively easy to learn a new language, but it takes a long time to learn an ecosystem. Learning that ecosystem takes time away from focusing on your customer.
I recently started a new web app and tried to use Django because of the batteries-included framework “should” have been the right tool for the job.
But I haven’t used Django in 15 years and it was slow going. After a few weeks of slow going, I rewrote the whole thing in Typescript in a week. Not because of any general argument that TS is better, but because it’s the ecosystem I know well. Not by choice, but as a function of the jobs I’ve had.
I’d like to suggest that it’s okay to choose the tool you’re most familiar with, because you’ll move faster, write better code, and frankly web apps can be written in any of these languages.
> After probably a good year of writing Rust and Svelte, it dawned on me that our users didn't benefit from any of this.
> With days and often weeks on end being spent on adding absolutely no direct value
> these last weeks I've felt very productive again, building new features, improving existing ones, updating the UI, fixing stupid bugs. I also really enjoy working more closely with my colleagues who use the application all day, every day and figuring out how I can make the product better for them.
Rails is GREAT at solving PRODUCT problems very quickly and very effectively. In the right place there is nothing better at building _products_ or making engineers incredibly productive.
It's not the only tool in the toolbox, but it's always been one of the best to solve early applications and proofs of concept
It doesn’t seem like the author learnt that much. They know Rails and Rails is good for making webapps? Makes sense.
[1] For the author. The rest of the team didn’t know Rails. And there was no one on the team that knew that rewriting parts in “blazing fast”-lang would work.
I did learn that things wouldn't necessarily be any better if I were to use language/framework X instead of Y.
Edit: I guess I also learned that Rails does so much for you, so you can focus on building a good product. Just gotta make sure you use it as it wants to be used as much as possible.
Rails is very good until you need to go off rails. Even in that case rewrites must be partial and not to aim to fully replace the original. Most of the time rewrites are a waste of time. This article could be true if you s/Rust/Ruby and tell the story in the opposite direction.
The worst is TypeScript and Node.js.
A lot of startups are making their code bases in TypeScript. And it is an unbearable mess.
I recently consulted with a company where I rewrote their app in Rails. And now it's much simpler, much better, much more extensible, and far more enjoyable for the developers to work on it.
Developers have to invent too much themselves vs Rails? Something deeper?
The type checker is quite forgiving, but that does not sound like something it would just be fine with?
The TS type system is not sound which has obvious tradeoffs. I prefer it over Rust for most things because Rust feels like a Comic-book-guy type person looking over my shoulder going "Akshually, you didn't tell me what the lifetime of this string is", even if it is trivially obvious. I acknowledge that there are situations where that is very valuable but in my opinion it's not generally superior.
"Have many issues at runtime? Test more. Does it turn into unmaintainable spaghetti code after a while? Only if you let it. It's typically caused by developers, not programming languages or frameworks."
Ruby/Rails has this?
I did try Erlang around 2017-2018 and quite liked it. The Joe Armstrong book is one of my favorite programming books. Perhaps I'll have a look at Elixir if I ever need to build something new from scratch.
Also,
1. Spring outdates Rails (2002 v 2007)
2. Go is a language, Rails is a platform, Ruby is the language. Ruby and Go solve for different problems, Go doesn't have a singular web application framework to compare well to Rails
3. Node is a runtime, not a language or a platform. There's no direct comparison there.
Rails developers smugly assert that Ruby on Rails is more productive than anything else out there.
I call BS on the "Ruby On Rails is the very best by far" conceit.
Ruby On Rails has a monopoly only on the perception that its developer experience and productivity is off the charts.
Ruby On Rails is just another language and framework. There's literally nothing that makes it different or particularly special compared to anything else.
Developers everywhere with Python or nodejs or TypeScript or C# or Golang have a developer experience that is just as great, without the high handed conceit that what they are doing is amazingly better than anything else.
Ruby, and Rails, was an awful idea then and it's an awful idea now. Even in-browser stuff is moving to typescript to get away from having to write unit tests for basic type errors.
But sure, let's dig up this failure and try it again
You pay 100x for each line of code and get nothing in return over ASP.NET Core or Vert.X. Pick any fast compiled language you like, don’t contribute to global warming.
JVM ecosystem has other great frameworks like Active-J and Ktor. My main point is, unless that's what you're most productive in, RoR is a really poor choice for both small and large codebases and there are plenty of options that completely eliminate the classes of issues you would otherwise have to spend the time on.
Sure, I like using C# (and recently F#) a lot but it wouldn't kill me if I had to use Kotlin/Java/Go/Swift instead. All these have understandable tradeoffs and merits to them. On the other hand, my experience of interacting with advocates of Python, Ruby and Erlang is incredibly poor - it's impossible to have a technical conversation and it seems that their communities live in a bubble of belief that using interpreted junk comes with magical productivity advantages inaccessible to expressive modern compiled languages with rich type systems and excelled back-end frameworks/libraries.
If you care about power consumption of computing you need to be looking at current AI and crypto currencies consumption like Bitcoin…
Luckily, our Rails app is very snappy and runs on hardware equivalent to an average 4 year old laptop. No issues with performance that I can't fix. No exorbitant power usage.
Also, as a niche business app, it will never have to scale as much as GitHub does.
Why is it okay to waste energy for entertainment but not waste energy for development experience and efficiency?
- I have two servers with the exact same hardware - one runs a Ruby on Rails web app - the other runs a Vert.X web app - both apps have similar features to the end users - if I run both of them for a month, the server running the Ruby on Rails app will consume hundred times more energy in kWh compared to the server with the Vert.X app - another way to look at it, to serve the same number of visitors, I would need hundred servers running a Ruby on Rails apps and one server running a Vert.X app
Is that correct?
It hasn't been my experience when I measured the long-term consumptions with energy meters in real-life scenarios. How did you arrive at your number?
By comparison, going from resistive heating to a heat pump is a 2.5x-4x jump in efficiency. 100x gains would be nothing short of spectacular.
I noticed the best energy savings when switching to Arm CPUs, but that's a separate topic.