4 ms·

Writing large web applications in Rust isn't going to happen fast. Large applications written in Rails won't run fast, might be ridden with bugs and might be ha

Writing large web applications in Rust isn't going to happen fast. Large applications written in Rails won't run fast, might be ridden with bugs and might be hard to maintain and extend. 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.

0xblinq 2y ago
You can't be seriously saying using "Go" (a low level systems language) will be as productive as using Rails (a very high level framework intended for CRUD applications). Despite how much you might hate Rails, that's like saying you'll build a blog faster with C++ than with WordPress.
- 59nadir 2y ago
  Go is not a low-level systems language. Even using the more flexible modern definition of "low-level" it's not a low-level language. That's like saying OCaml is low-level; it's not even close.
  - yxhuvud 2y ago
    Go is not a low-level systems language, but it is a low-level web site builder language.
  - pjmlp 2y ago
    Great given that OCaml seems good enough to write hypervisors and unikernels.
- jb1991 2y ago
  Go, a language with garbage collection and a compiler that does only an average job at optimizing machine code, is now considered low level?
  - deleted 2y ago
    [deleted]
  - pjmlp 2y ago
    It is as high level as C, unless you consider all non ISO extensions part of the language, in which case, any language can have similar extensions. There are more compilers by the way.
    - jb1991 2y ago
      Last I checked, C was not garbage collected.
      - pjmlp 2y ago
        So what? Here is a kernel writen in a GC enabled system programming language. https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kernel.Mod.txt https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kerne... Or do you rather have one in Go? https://www.phoronix.com/news/TamaGo-Bare-Metal-Go-ARM https://www.phoronix.com/news/TamaGo-Bare-Metal-Go-ARM
        jb1991 2y ago
        OK, so it sounds like you are confirming an answer to my question, that Go, a language with garbage collection and a compiler (at least its most popular one) that does only an average job at optimizing machine code, is now considered low level.
        pjmlp 2y ago
        yeah, it has always been as low level as something like Cedar in Xerox PARC, and just as high level. 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.
- unit149 2y ago
  In terms of Go or C, even Rust which is one of the only of the two used in kernel development. Migrating is in line with the principles of the CRUD methodology, whether it takes place by means of a compiler or a junior developer parsing assembly line-by-line.
- consteval 2y ago
  Go is absolutely not a low-level systems language. It has a GC. Even C++ isn't a low-level systems language: C++ is a high-level language. 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++.
  - neonsunset 2y ago
    C# stands out a bit as it provides first-class manual memory management APIs, zero-cost abstractions and tools to do RAII like many other systems programming languages do. It's quite unlike most other GC-based languages once you look at it closely. If anything, it allows you to go way more low-level than Go.
    - consteval 2y ago
      While true, I'd argue the way C# is used is closer to Java than C++, despite the tools it provides. Also I think Go allows manual memory management as well, although close to nobody uses it. In my head, there's a "sharp" divide between GC langs and non-GC langs. While the GC langs may provide some shallow hacks to get close to what lower-level langs can do, for those lower level langs that's all they can do. And typically it's not a 1-1.
      - neonsunset 2y ago
        The tools C# provides are far from "shallow hacks". Go does not provide "equivalent" ability to malloc and free, or write C structs with explicit layout. Does not have the same type of struct generics C# has ala Rust or C++ templates, it's not even close. Perception problems do not affect technical capability, and there exists a world of gamedev beyond enterprise engineering that treats C# appropriately.
loktarogar 2y ago
> Large applications written in Rails won't run fast, might be ridden with bugs and might be hard to maintain and extend. 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.
- t-writescode 2y ago
  I think the biggest difference for me is that when there's a rat's nest of a Rails application, refactoring it becomes the hell of type errors and writing tests that, frankly, a compiler would catch. 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.
  - cageface 2y ago
    This is my experience as well. Rails makes it incredibly easy to get a web app off the ground but as it grows and adds more features and complex business logic it becomes much more difficult to maintain than a codebase with static type checking.
  - loktarogar 2y ago
    I guess my point was that, with discipline, it's not a foregone conclusion that a Rails app is going to be a rats nest. The lows can be pretty low for sure. But it's one of the tradeoffs for the framework and one that can be mitigated with thought and effort.
n_ary 2y ago
> Large applications written in Rails won't run fast, might be ridden with bugs and might be hard to maintain and extend. 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.
PaulRobinson 2y ago
You can write large applications in Rails that run fast, have low bug counts and are not hard to maintain or extend. There are many examples in the wild. 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.
- jkman 2y ago
  As a dev that hasn't touched Ruby in his time yet, could you expand on the productivity differences you've seen between Java/C# and ruby devs? I totally buy that a language like ruby can be more productive, but a 3x difference is wild. Have you found that RoR is really just that much more productive than say, Spring or Asp.NET?
  - cloverich 2y ago
    (Ruby -> Rails) As one that switched into Rails after a decade of web dev, IME its the batteries included nature. You can't compare Rails to Go or Typescript. You compare Rails to language + all the standard libraries people use. The trick with Rails is _most_ of those choices are baked into the framework, so e.g. 25 rails dev's will know _mostly_ the same exact set of libraries walking in the door. 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.

0xblinq 2y ago

You can't be seriously saying using "Go" (a low level systems language) will be as productive as using Rails (a very high level framework intended for CRUD applications). Despite how much you might hate Rails, that's like saying you'll build a blog faster with C++ than with WordPress.

59nadir 2y ago
Go is not a low-level systems language. Even using the more flexible modern definition of "low-level" it's not a low-level language. That's like saying OCaml is low-level; it's not even close.
- yxhuvud 2y ago
  Go is not a low-level systems language, but it is a low-level web site builder language.
- pjmlp 2y ago
  Great given that OCaml seems good enough to write hypervisors and unikernels.
jb1991 2y ago
Go, a language with garbage collection and a compiler that does only an average job at optimizing machine code, is now considered low level?
- deleted 2y ago
  [deleted]
- pjmlp 2y ago
  It is as high level as C, unless you consider all non ISO extensions part of the language, in which case, any language can have similar extensions. There are more compilers by the way.
  - jb1991 2y ago
    Last I checked, C was not garbage collected.
    - pjmlp 2y ago
      So what? Here is a kernel writen in a GC enabled system programming language. https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kernel.Mod.txt https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kerne... Or do you rather have one in Go? https://www.phoronix.com/news/TamaGo-Bare-Metal-Go-ARM https://www.phoronix.com/news/TamaGo-Bare-Metal-Go-ARM
      - jb1991 2y ago
        OK, so it sounds like you are confirming an answer to my question, that Go, a language with garbage collection and a compiler (at least its most popular one) that does only an average job at optimizing machine code, is now considered low level.
        pjmlp 2y ago
        yeah, it has always been as low level as something like Cedar in Xerox PARC, and just as high level. 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.
unit149 2y ago
In terms of Go or C, even Rust which is one of the only of the two used in kernel development. Migrating is in line with the principles of the CRUD methodology, whether it takes place by means of a compiler or a junior developer parsing assembly line-by-line.
consteval 2y ago
Go is absolutely not a low-level systems language. It has a GC. Even C++ isn't a low-level systems language: C++ is a high-level language. 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++.
- neonsunset 2y ago
  C# stands out a bit as it provides first-class manual memory management APIs, zero-cost abstractions and tools to do RAII like many other systems programming languages do. It's quite unlike most other GC-based languages once you look at it closely. If anything, it allows you to go way more low-level than Go.
  - consteval 2y ago
    While true, I'd argue the way C# is used is closer to Java than C++, despite the tools it provides. Also I think Go allows manual memory management as well, although close to nobody uses it. In my head, there's a "sharp" divide between GC langs and non-GC langs. While the GC langs may provide some shallow hacks to get close to what lower-level langs can do, for those lower level langs that's all they can do. And typically it's not a 1-1.
    - neonsunset 2y ago
      The tools C# provides are far from "shallow hacks". Go does not provide "equivalent" ability to malloc and free, or write C structs with explicit layout. Does not have the same type of struct generics C# has ala Rust or C++ templates, it's not even close. Perception problems do not affect technical capability, and there exists a world of gamedev beyond enterprise engineering that treats C# appropriately.

loktarogar 2y ago

> Large applications written in Rails won't run fast, might be ridden with bugs and might be hard to maintain and extend. 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.

t-writescode 2y ago
I think the biggest difference for me is that when there's a rat's nest of a Rails application, refactoring it becomes the hell of type errors and writing tests that, frankly, a compiler would catch. 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.
- cageface 2y ago
  This is my experience as well. Rails makes it incredibly easy to get a web app off the ground but as it grows and adds more features and complex business logic it becomes much more difficult to maintain than a codebase with static type checking.
- loktarogar 2y ago
  I guess my point was that, with discipline, it's not a foregone conclusion that a Rails app is going to be a rats nest. The lows can be pretty low for sure. But it's one of the tradeoffs for the framework and one that can be mitigated with thought and effort.

n_ary 2y ago

> Large applications written in Rails won't run fast, might be ridden with bugs and might be hard to maintain and extend. 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.

PaulRobinson 2y ago

You can write large applications in Rails that run fast, have low bug counts and are not hard to maintain or extend. There are many examples in the wild. 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.

jkman 2y ago
As a dev that hasn't touched Ruby in his time yet, could you expand on the productivity differences you've seen between Java/C# and ruby devs? I totally buy that a language like ruby can be more productive, but a 3x difference is wild. Have you found that RoR is really just that much more productive than say, Spring or Asp.NET?
- cloverich 2y ago
  (Ruby -> Rails) As one that switched into Rails after a decade of web dev, IME its the batteries included nature. You can't compare Rails to Go or Typescript. You compare Rails to language + all the standard libraries people use. The trick with Rails is _most_ of those choices are baked into the framework, so e.g. 25 rails dev's will know _mostly_ the same exact set of libraries walking in the door. 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.