> I ran Rails in production years back and swore it off then. We had constant memory leaks that seemingly came from Rails itself, and the only solution we had was "just restart the server."

This hasn't been a serious problem in a decade.

> We also had no typing then, so every bug was a runtime bug. Hopefully it's improved in the years since...

The ecosystem has been introducing gradual typing, but even at high scale, types were not remotely the most common type of problem I ever ran into, and certainly not "every" bug.

(ex-Braintree engineer, we processed billions of requests on Rails)

> types were not remotely the most common type of problem I ever ran into, and certainly not "every" bug.

If you took that away from what I wrote, I apologize. I meant that without a compiler and type-checker, you would only find bugs at runtime. In my experience, the vast majority of these would be easily discovered by a compiler. Presumably that experience is shared by Ruby devs since they're now adding type-checking.

> This hasn't been a serious problem in a decade.

That may be true. I haven't had any need to revisit Ruby or Rails since I moved to Go. But it was a serious problem with no workaround, and I've never encountered any scenario like that since switching to Go.

While I do like static typing, I find more bugs because people have no clue about security and they think they can do it better by just tying together a few libraries and storing a jwt in local storage or they forget to handle Prisma exceptions or they didn't know what session fixation is or because they forgot to consider a corner case of foreign key exceptions from the database library, etc, etc than because somebody passed a string where an integer was needed.

Giving up frameworks with 10+ years of hardening and documentation and libraries and support etc just because of coroutines or static types or nice syntax or because that's what google does then I should do it too makes absolute no sense to me.

Yes. And new projects are even better started now with Rails than in the past (aside from the JavaScript hell still plaguing rails).

Active storage and variants make life so easy.

> (aside from the JavaScript hell still plaguing rails)

It's not too bad now, set up a Node environment and there's first class support for using vanilla esbuild or if you want to go without Node entirely there's import maps and lots of goodies at the Rails level to help you manage your JS dependencies. Technically Webpack is still supported too but it's vanilla Webpack instead of Webpacker, that's all part of the new https://github.com/rails/jsbundling-rails abstraction for using a number of different JS bundling tools with their stock set ups.

Personally I went with the esbuild + tailwind combo and it's been smooth sailing. I have an example app here https://github.com/nickjj/docker-rails-example.

If you're finding bugs in production that a compiler or typechecker could have found then there's something seriously wrong with your test suite. That's how Rails works, if you don't have 90%+ statement coverage it will be hell.

IME, adding that 90% statement coverage is much of the tedium and frustration of the job in Ruby-land--in particular for things that you just get solved for free with something like TypeScript.

It might have improved somewhat, but I find myself pretty comfortable with a much more pared-down test suite that focuses on correctness tests at logical module boundaries in TypeScript, rather than verifying things the computer can just do. I do look forward to seeing Ruby's gradual typing become more entrenched in the ecosystem, though, because I like the language--I just don't like using the language professionally because of the additional manual work I find myself doing.

> IME, adding that 90% statement coverage is much of the tedium and frustration of the job in Ruby-land--in particular for things that you just get solved for free with something like TypeScript.

I would argue that if your unit test is only testing things which would have been shown by the type system of another language, you are testing at too low of a level. In addition to being tedious, such tests are often very brittle.

Those tests are brittle, and they're also the thing that protects you at module boundaries when those boundaries are being hammered on by different groups of people.

Having them not be necessary is nice.

On the other hand, if you have a compiler/typechecker that finds things that your test suite could find I will always reach for the compiler/typechecker. No sense in writting tests against something a standard tool will find aside from sanitizing data from your inputs.

My experience with ruby is often documenting the expected argument and return types with comments and then writing code and/or tests to enforce the types.

Having also used Go a fair amount, I very much prefer the real type system which both documents and enforces.

I enjoy both languages though.

I’ve worked on many large rails apps at scale and large Java apps at scale. There has been no significant difference in the big count between them despite Java having static types.

Java has a bad type system that makes it awkward to express many well-typedness guarantees (too much boilerplate to create new types (classes or interfaces), no sum types (tagged unions), no null safety, exceptions are a mess especially with lambdas, and don't get me started about all the reflection madness of popular frameworks that throws type-safety out of the window, etc.). As a result you don't get much safety in exchange for all the boilerplate. Still, I find Java massively easier to refactor. You can remove a field from a class and verify that you've changed all the places that were using it (barring reflection, of course). In Rails, that requires at least running the whole testsuite which could be very slow (because Rails tests are often very slow). And even then, you have no guarantee you didn't miss a particular case.

Languages with better type systems do exist (Rust, Swift, Kotlin, from what I hear even typescript?, and all ML type languages including Haskell, ...). They are much better at preventing bugs. My life became better when I had to stop worrying about NPEs, for example.

I’ve had the same experience with Swift, Kotlin, and typescript. No clear difference in quantity of bugs or speed of development.

> [...] types were not remotely the most common type of problem I ever ran into, and certainly not "every" bug.

That's a typical response from dynamic typing advocates, but the response is that in a language with a good type system, many more things can be type errors than would be in a dynamically typed one.

For example, from my time writing Ruby, trying to call methods on `nil` was an incredibly common error, but this is simply a type error in some more modern statically typed languages (including Kotlin and Swift).

A substantial number of bugs I see where a method is called on nil are business logic errors that result in something not being where it's expected, and those bugs would just manifest differently at runtime with static typing. Every web app I've ever seen in a statically typed language has plenty of logic relying on "unwrap nullable or raise error" mechanisms.

That may be your experience. It's not mine. Null-safety forces you to think about the exceptional case (and whether it is supposed to occur at all). If you do so poorly, yes, you'll have errors too. But it's not something that can happen to you by accident.

For example, if you have a method A that gets a foo from the method B and then does something to that foo, you might get a runtime error if B returns nil. If this happens over dozens of method calls, it can start to become very hard to see where the error was introduced.

But if you know that B is always supposed to return foo and never nil, then the compiler can show you where the error in your definition of B is ahead of time.

The value of null-safety is not in making everything nullable and then just proceed with unwrapping etc., the value is that we can make a lot of types explicitly non-nullable.

I don't think it's controversial that a good type system allows to verify more soundness guarantees at compile time. The only controversy is whether it's worth the effort.

I agree with you about the value of static typing and non-nullability, don't get me wrong. My experience is just that _web development_ and other use cases traditionally favored by dynamic interpreted languages tend to have a lot of unexpected nulls of a type that are not prevented by strict typing. There are other types of bugs that I absolutely expect to see less of with strict typing.

I agree, I think it’s a good reason to use the static typing in Ruby > 3.0.

Any static analysis tool you can use to catch bugs before runtime in production is something we want.

> I ran Rails in production years back and swore it off then. We had constant memory leaks that seemingly came from Rails itself, and the only solution we had was "just restart the server."

Nothing is perfect. In my book restarting a server because of memory leaks is an acceptable trade off versus all the crazynes of having to decide and maintain on how to tie together a database, error validation, background jobs, translations, react, redux, an API to interface with the backend, logging, etc, etc, etc. Also, Go is just part of your system, I'm pretty sure you also have a frontend stack, and complexity increases a lot as I explained here. Compare that to Laravel+Livewire or Rails+ Hotwire. Night and day. I'm pretty sure any serious business will take the restarts any day vs the increased complexity and developer time.

> I've been happily running Go backends for the past 7 years now, and they're stable and fast and easy to refactor.

Yes, and I bet something built in 7 years with Go would have taken 7 months with Rails or Laravel.

On the static typing stuff, I'm with you on that. PHP (and Laravel) are a bit closer to that, but nothing is perfect. And for Web Development using Laravel or Rails is a good trade off.

Go is good and all, but it's odd to compare it to the vast feature set that Rails provides. The point of Rails is to give you standard tools so you don't have to consider / reimplement / configure / hook up e.g. background processes for every app you build.

As someone who seems to work with Go backends quite a bit, what's your preferred way of doing this? I've been playing with net/http compatible routers and I've been liking them, but interested to hear what someone with more experience uses. Any good way of dealing with common boilerplate that frameworks like Django and Rails help remove?

On small projects, I just write out the boilerplate. It's annoying but it's straightforward to read and revisit years later.

On larger projects (100k LOC+) I use chi for my router in combination with codegen via sqlc and moq, and I wrote a small program to generate the routes for me automatically with a config file.

sqlc is very interesting. Gives me sqlx (from Rust, not the Go package) vibes. Definitely will play around with this.

There's a variety of projects out there. gorilla/mux, chi, httprouter are all pretty commonly used for just defining routes. If you want a full on framework, gin and beego are also common. For the database (I'm unfortunately mainly familiar with postgresql related projects) there's pgx, sqlx, gorm, and then code generators like sqlc such as sqlboiler and entgo.

Golang encourages libraries and frameworks with much smaller surface, so there is indeed a boilerplate issue, but that's also an issue with golang as a whole.

> I ran Rails in production years back and swore it off then. We had constant memory leaks that seemingly came from Rails itself

Curious - were these actual memory leaks or Rails memory bloat due to how ruby allocates memory and holds on to them?

This is my experience, too. I'm currently working on a TypeScript+Node service, which is decent, but Go is my preference these days.