5 ms·

Calling it "fashion" is disingenuous. I ran Rails in production years back and swore it off then. We had constant memory leaks that seemingly came from Rails i

Calling it "fashion" is disingenuous. 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." We also had no typing then, so every bug was a runtime bug. Hopefully it's improved in the years since... I've been happily running Go backends for the past 7 years now, and they're stable and fast and easy to refactor.

simplify 5y ago
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.
christophilus 5y ago
This is my experience, too. I'm currently working on a TypeScript+Node service, which is decent, but Go is my preference these days.
xionon 5y ago
> 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)
- hellcow 5y ago
  > 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.
  - tinco 5y ago
    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.
    - eropple 5y ago
      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.
      - dwaite 5y ago
        > 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.
        eropple 5y ago
        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.
    - DerArzt 5y ago
      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.
- Tainnor 5y ago
  > [...] 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).
  - Lio 5y ago
    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.
  - djur 5y ago
    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.
    - Tainnor 5y ago
      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.
midrus 5y ago
> 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.
jjice 5y ago
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?
- hellcow 5y ago
  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.
  - jjice 5y ago
    sqlc is very interesting. Gives me sqlx (from Rust, not the Go package) vibes. Definitely will play around with this.
    - zinclozenge 5y ago
      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.
hw 5y ago
> 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?

simplify 5y ago

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.

christophilus 5y ago

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

xionon 5y ago

> 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)

hellcow 5y ago
> 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.
- tinco 5y ago
  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.
  - eropple 5y ago
    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.
    - dwaite 5y ago
      > 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.
      - eropple 5y ago
        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.
  - DerArzt 5y ago
    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.
Tainnor 5y ago
> [...] 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).
- Lio 5y ago
  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.
- djur 5y ago
  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.
  - Tainnor 5y ago
    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.

midrus 5y ago

> 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.

jjice 5y ago

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?

hellcow 5y ago
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.
- jjice 5y ago
  sqlc is very interesting. Gives me sqlx (from Rust, not the Go package) vibes. Definitely will play around with this.
  - zinclozenge 5y ago
    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.

hw 5y ago

> 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?