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.
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.
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.
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.
That’s a fine analysis, but most people have a more generally accepted definition of what low-level means in a context of modern systems programming languages. I suppose you have provided an alternate definition, but it’s not really in the context of what most are thinking about in this arena.
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.
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.
... but, garbage collection, no direct memory management = impossible to write any firmware etc that needed to directly set bitflags and such. how could you call Go "low-level systems programming"?
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...
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++.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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?
(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.
> 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.
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.