Where is Ruby Headed in 2021?
bignerdranch.com
bignerdranch.com
I approach programming creatively. I think in large systems and architecture. Ruby allows me to skip worrying about the details. Code blocks abstract away thinking about loops and just focus on data. Just about every array operation I could want is there, waiting for a code block. In other languages, things don’t flow like that.
I’ve tried purely function languages and I just can’t wrap my head around them because they abstract too much.
I’ve tried python, but I end up having to deal with the mess of importing modules and having to set up loops when all I want to do is map data.
Node.js comes so close but anemic standard library and absolute mess of explicit async everywhere just gets in the way. I want to love JavaScript. :(
Then there is Rails. Nothing even comes close. The attempts to replicate it in other languages ends up missing part of what makes it so great. I’m sad about the move to mounds of JavaScript. Nothing can match the productivity of simple_form and bootstrap.
My entire career has been in Ruby on Rails. I hope improvements to Ruby can keep it relevant. If not, I suppose JavaScript will do.
Making software in Rails feels creative, and the act of writing code in itself is very satisfactory.
A good opportunity to re-read the Rails Doctrine: https://rubyonrails.org/doctrine
Now, I know that this is very subjective and I can see how others might prefer other languages or frameworks, so I'm not adding this here to start a discussion. Just to share my feelings :-)
The small/large project distinction makes sense to me. I think there’s a clear point in project size where the joy of writing code has to be deprioritized behind maintainability and simplicity, even if it becomes less fun to write code that way.
Even then - there's no real path to a mature and maintainable language/framework. In my area (Atlanta) we're seeing a glut of RoR devs available because a lot of the large employers have given up and shut down the RoRs projects in favor of anything more suitable to teams in the 15 to 500 engineer range. Usually this has been typescript/java/.net.
Even within the RoR guys I know - a LOT of them are trying to get out and work with something else (several folks I know are moving to elixir)
Dumb move, Elixir has around 1000 job openings in the U.S while Ruby has 35000. In fact I find it pretty hard to believe they can't get a Ruby job in the U.S, and they choose Elixir from all stacks as a solution to their problem. Sounds to me like they just wanna try Elixir and can't really build a good argument in their head on why they're doing it. Jobs-wise things are definitely not gonna be easier for them with Elixir.
Hopefully that is what Github and Shopify brings to the table. Instead of just using Rails they are now actively shaping its future direction.
>because a lot of the large employers have given up and shut down the RoRs projects
My impression is that the vast majority of Rails communities don't care much about its ecosystem growth. They are just happily using it.
My opinion, typed/tooled is useful when the desired solution/behavior/concept is complex.
It's still got most of what made Ruby a joy to work with and several unique advantages, too!
I completely disagree. Joy of writing code must always be a top priority, also in large codebases. There are enough examples of where Ruby (on Rails) is used in large codebases with GitHub, Shopify, etc.
I guess it's a matter of personal match, too. Some people match better with TypeScript, others better with Rails. Nothing wrong about that.
I'm aware that they use a heavily modified version of Rails, but it still is Rails in the fundament.
Without those imports, how will people reading the code find the definitions? How will they track down the source code for all the methods being called?
If the answer is "with an IDE / tools", then can't those same tools be used to solve the "mess of importing modules"? If you're using a good IDE, imports and go-to-definition are both solved problems, no matter what language you're using.
If you're not using an IDE, that's a more interesting situation, and without an IDE I much prefer having the explicit imports so that I at least know where to start digging.
[0]: A big disadvantage of the above is it's not statically resolvable, so you couldn't really build an IDE go-to-definition with it.
Solargraph is an amazing project but ctags is still just so fast and low overhead that it's what I mostly use.
ctag support is available for most editors and is built into Vim. You need to first generate a tag file (or have an editor plugin do it for you[3]) and then press Ctrl-] to go to definition.
With ruby 3.1 I think we’re getting a new default debug.rb gem.
It will be interesting to see if pry or the beat ideas from pry can be integrated with that.
THIS. 100%!
I also think Python seems to do this better with the namespace pattern of `import x.y.z`. Never seen the `import *` pattern before, didn't know Python can do that (never done Python really though either, only browsed some code here or there).
But one addition to your statement I'd like to add: not just idioms, but documentation can spread this antipattern too.
Noobs come to a language, read the documentation for some tool, library, etc., and understandably come away thinking "Oh ok, this is how it's done" when in reality, while they're not doing anything wrong per se, they're being taught a bad habit right off the bat. And that makes the inevitable hard slap across the face that reality (or a co-worker) eventually hits you with all the more shocking, possibly even leading to resentment of others when this happens.
I myself had this problem many years ago; "why the hell do you need all these subclasses and so many layers of abstraction?!" I once asked. "Because those class/method names already exist within other classes loaded at runtime, or will likely be added in future external dependencies, and we don't want to accidentally overwrite those."
Well, I thought that was a stupid idea. In my (very limited at the time) experience, when I had that problem, I just insisted on finding a damn good descriptive name that wasn't going to be used for anything else, even if it was wicked long or a pain to type. Too long? Don't be lazy. Typos more probable with length? Learn to copy/paste. That was the approach I learned at some point from some documentation somewhere on the internet, and it always worked for me, so it was the "one true path" and all others were inferior, making proponents or users/adherents of any other way "wrong" and inferior to me and my superior, non-lazy intellect. You're telling me that you do it differently? You must be stupid or lazy, and I'm neither therefore I'm better than you; thus forcing me to adopt your inferior standard?! Preposterous! Insulting! Offensive! That's how I saw it.
God, was I dumbass.
I developed this attitude by learning my skills in a near total vacuum, other than documentation written by people on the internet back in the 90's. Not official company-published technical docs, mind you, but forum and BBS posts, mailing list discussions, and way too much IRC to be considered "healthy" by any stretch of the imagination.
Those who taught me did so in a way that was efficient and they did no wrong at all of course - this failure was entirely of my own making, from my own arrogance. But it's also true that had I been taught at the same time that "there are other ways in other languages that are totally valid; this is just for simplicity's sake" and then been shown, or better yet required to use other patterns in school/projects/etc., I might have been able to see the short-sightedness of my own arrogance sooner. Instead, it resulted in an antipattern that allowed me to become overconfident, arrogant, and more difficult to work with than I should've been.
----------
In case you're wondering, I can't remember what I read or where that came from so long ago. Sorry. Might have been C, C++, Java, DOS BASIC (non-GUI/non-Windows), Visual Basic (before .NET) or maybe even PHP 3.something, no idea - that was 20+ years ago. I was inexperienced, arrogant, and a fool; none of that was the author's fault whatsoever. We're all young and stupid at some point in life. I'm no longer young, but at least now I know I'm stupid! :-)
Short of that, assuming all your dependencies are unpacked under your project's directory (likely .gitignore'd but there nonetheless, instead of in somewhere like /opt/ or /usr/local/lib or something) you could also `grep -ir 'def method_name' | less` or something to try to figure that out, though it's nowhere near as smooth as RubyMine.
Other editors have Ruby and/or Rails plugins that may help ease this pain point as well, though personally I haven't done anything with that on the editor front in a very, very long time. Generally I'm outright militant about keeping my dependencies to an absolute minimum in a project, and doing everything the most "vanilla" (standard, accepted, most widely adopted patterns, naming conventions, etc.) way possible, and therefore I usually know what gem/lib is providing what particular method, so I don't really need that kind of utility most of the time because I can google up some API docs...when there are API docs anyway.
But in cases where you're having a legacy project/monolith dropped in your lap and nobody knows anything because "the business guy" fired the one developer who actually knew how everything worked and now that guy won't answer his calls because working for free is dumb? Yeah, in those cases, RubyMine or a real good editor plugin can be a lifesaver for this.
People trying to write Java-like OO in Ruby end up confused and frustrated.
object.method(:name).source
object.method(:name).source_location
To put it bluntly, assuming there's a method on the other side of your message, is practically the antithesis of Ruby.
It's similar to the category error that leads folks to conflating type with class, and writing type checkers that look for class signatures.
Though having suffered in a Rails codebase written by Java engineers, I definitely agree that a light touch is needed with OO -- though composition has its own difficulties and together this forms one of my bigger criticisms of Rails.
RubyMine, and the "jump to definition" feature in particular, is the primary thing that enabled me to really "get" Ruby and finally understand how everything worked together.
If someone asks for directions you give them directions or a current map.
I understand using to find out why it's there, but not what it is.
Indeed, and the problem is that IDEs have encouraged developers to write convoluted code and to forget how to navigate a filesystem. Reading code and commit history is a much faster path to understanding a system than an IDE's autocomplete. I learned this from Ruby, and it serves me well in C, Kotlin, Scala, PL/SQL, Typescript, etc.
I would argue the exact opposite. Developers who force tools designed 30 years ago to dictate programming language best practices today are holding back the entire industry. There is no reason for my tooling to depend on my filesystem; imagine if my IDE integrated directly with vcs, and a language server provided both of those tools semantic information about my code, available on any device. Let's not kid ourselves either, utf-8 isn't human readable on disk, it's still a binary-like format.
Input and output parameters on a program with hundreds of thousands of lines becomes .. rough, to say the least. DryStruct has helped a lot; but several teams working on a single codebase with their own opinions of method calling patterns evolved over several generations all in a single codebase, and it’s … rough.
I think for people that come to love Ruby it feels more natural to think about a program that way as opposed to thinking about a purely lexical context of a piece of code.
That's also why I don't think it's a great idea to add types etc. to programming languages like python or ruby. They are not made for this and they should focus on what they do well. Use the right tool for the job, don't try to make every tool being able to be used for the same task.
In fact, the philosophy of convention over configuration et all makes Rails MORE scalable and easier to onboard new people than anything else out there that I’ve seen.
I recently worked on a Rails project for someone who didn't like to create scaffolds, models or controllers for small things, thinking that it would add to the bloat. But conceptually it makes everything 10x times easier and faster to find and understand
There are soooo many blogs about migrating away from Ruby, adopting Go, Scala, whatever statically typed thing.
There's a reason even Ruby is getting a proper static type system.
Its productivity is simply hard to beat.
Most of these companies are unicorns or public. https://spreecommerce.org/ruby-on-rails-most-popular-among-t...
I doubt they can be listed as a Rails success story.
Stripe doesn't use Rails either. That was a pretty bad article. And it is somehow from Spree.
Almost all the major former startups that I could find are from 2010 or earlier.
I've found that people that gravitate towards Ruby enjoy meta-programming. The running joke is that you're not a Ruby programmer until you've decided that you should write a DSL. Like everything, clever programming has its tradeoffs.
These days no one reads the source code of every method they call until something is not working the way they expected it to.
Personally, I find the JS ecosystem that absolute worst for this because of the amount of imported code to layer basic functionality on top of the standard library.
If you've worked with rails long enough - well at that point things like Devise are probably in your mental model of how they work.
Personally I still find the large unbridgeable chasm between Python 2 and 3 to be a large friction point in the ecosystem. But if I worked in Python a smuch as I worked in Ruby, I may find Ruby more troublesome.
The simple fact is all languages are getting better. The best tool is not always the one that would be best for the job, sometimes it's just the one you know best. And the tradeoffs we make for ease of programming and abstraction can then turn around and mean we are pushing megabytes of JS over the wire when we don't need to, and now we are trying to solve that with more explicit inclusion and automatic tree-shaking in build pipelines etc.
It's all good. Every tool has two edges. I'm much happier to see people continue to engage with this edges are figure out how to make them more effective than to always argue about which edge is sharper.
Memorization is not consistent between teams/team-members.
Memorization is also the fastest skillset folks lose if they step away from the language/toolset for a while (it degrades rapidly)
Worst of all - The RoR ecosystem (6 versions in) requires memorization about which set of things you need to have memorized for this specific version of the framework.
I'll take some boilerplate code EVERY FUCKING TIME. The magic becomes a curse.
I think in dynamic languages like Ruby and Python, there are two very different cases that we need to distinguish when thinking about this.
The first one is global references to modules/classes/functions. For example, in Python you may write:
import my_module
foo = my_module.Foo(some_arg)
In Ruby, you may see instead something like:
require 'my_module'
foo = MyModule::Foo.new(some_arg)
So, how is this resolved?
By convention, basically. If you see a reference like `MyModule::Foo` and want to see the definition of that, the convention is that that definition will live under my_module/foo.rb, so you can go to that file with some confidence that you'll find the the code for that class there.
So, if the convention is strong, and people follow it, this is basically a non-issue, and the go-to-definition can be done as easily as in Python, with or without an intelligent IDE.
---
The second case is when you have a dynamic reference to an object/function/whatever, like:
def do_something(arg):
arg.foobar()
There are different ways to make this go-to-definition somewhat more ergonomic than a global search for `def foobar`. But on the language level, i think both Python and Ruby are basically the same in this case: not very helpful. We then compensate by using good naming conventions, type annotations/comments, or using powerful IDEs that analyze the code to make good guesses about who is calling what.
I totally see the value and understand why someone would like it but I just never could get to that point with it.
I much prefer the explicit imports, loops, etc I suppose
For example, I really don’t like that rails implicitly imports stuff into the namespace.
I like being able to follow the imports explicitly at the top of the file. I feel like there is way less of “where does this come from or what IS this?” when working with Django.
What function did I import, exactly? Which of the 37 “update” calls did I call when I called it on this?
You might like some of the recent Rails 7 previews. I believe they’re removing Webpack out of the box and trying to simplify things on that end[0].
[0] https://weblog.rubyonrails.org/2021/9/15/Rails-7-0-alpha-1-r...
The Achilles Heel of Hotwire apps has previously been the low number of supported websocket connections and high memory usage when using ActionCable and Puma but I have high hopes that Falcon[1] will take care of that.
That along with Github's View Components[2] and Tailwind make me really please with the way Rails is heading right now.
i'm personally not a fan of tailwind (or bootstrap) for being overly/cryptically verbose, but i understand why it's popular when coupled with view components, which do seem useful.
The nodejs API is rather big really. If you're using Ruby as your standard of normal sized almost everything would look small in comparison, but "anemic" is a stretch. You'd really hate Lua.
If you're taking suggestions, you might enjoy Janet[1]. It has a pretty large user API, lots of bells and whistles included in the standard libs like you'd find in Ruby, and lots of different ways to achieve the same result like Ruby. It's been a while since I checked out the ecosystem, but I was _very_ happy with the Joy Framework[2]. It definitely doesn't come close to the scope of Rails, but I think it _does_ near Rails in it's easy of use for the developer with it's scaffolding, controller generation etc.
Just curious about why you'd suggest going from a popular stack to Janet? I'd rather suggest Common Lisp as it's a way more stable, mature and standardized technology.
But now that Rails has incorporated Stimulus as a sane approach to the client-side of things, I'm coming back and it will be difficult to take me away again.
Not sure what you mean here specifically (do you not understand Enumerable.inject in the Ruby stdlib? That's about the hardest thing to understand and once you're there, functional langs are pretty trivial) I was already coding in a functional style in Ruby (PORO, intentionally not mutating vars, etc.), so that wasn't an issue for me at least, when I hopped to Elixir.
The kicker was when I spent an entire month debugging a problem that would have been impossible to occur in Elixir/Phoenix- I was working on a million-line Rails codebase and there was a session issue where sessions would seemingly randomly get dropped... it was nondeterministic and absolutely maddening, a number of other devs had attempted to fix it and failed, and I finally did- and it ended up being a key-overwrite issue with a regular Hash being merged with a HashWithIndifferentAccess in the ENV variable passed between rack layers (and god, was that hard to find! I had to write custom debugging tools that walked through every Rack layer and deep-diffed the ENV hash, etc.). That was the last straw.
So far, Elixir/Phoenix has been fantastic for me at NOT producing "flagging tests", nondeterministic-seeming bugs, etc. Massive productivity boost.
Have you tried Phoenix? It's really close. It's better in some ways. The data layer is quite different however. As much as I like Ruby, Elixir made a lot of things I liked about Ruby better
It's such a better platform than Ruby and Rails that I won't bother writing about it here - there are already hundreds of blog posts about it. Productivity is at least on par with Ruby (I believe better) and performance on another plane of existence.
It's not just jobs, by any metric you can think of Elixir is an obscure tech, if you want I will add sources to this claim but hopefully we can agree.
- https://appunite.com/blog/top-10-elixir-companies-to-follow
If all that's true, it's a natural consequence that better tools will have fewer job postings: you need fewer people to get the job done, and the ones you've got have really good retention. However, so will tools on the other side of the bell curve: nobody in their right mind wants to go there, either on the supply or demand side. So all popularity really tells you is where the enterprise hype machine was, five, ten, fifteen years ago such that "nobody got fired for choosing X" and "learn X! It's got a lot of job postings!" still align.
But the enterprise hype machine is optimised for tools that have a very specific set of surface criteria: enormous libraries so you're not inventing anything, rock-solid vendor support so there are people being paid to evangelise it into orgs (or, like JS, are ubiquitous anyway, but I think that particular lightning only strikes once), and "easy to learn" ergonomics such that developers asymptote towards replaceable cogs in both quality and quantity.
"Well respected but obscure" describes a certain sort of success, by that reasoning. It just needs enough of a community to stay alive, and that's a bit more of a toss-up. Ruby haemorrhaged people in the Rails 4-5-6 cycle as people jumped ship to node, but Rails 7 and Ruby 3 are looking extremely tasty despite that, and I wouldn't be surprised if we saw a bit of a resurgence in popularity over the next couple of years outside big enterprises.
Most of the people I interview have got into tech after Rails 3 was released, and generally aren't aware of why the Rails/Phoenix/Django concept was such a breath of fresh air. I think what you'll see is that the reason Phoenix and Elixir have a "next big thing" isn't technical factors at all. It'll be a rediscovery by the new generation when someone unexpected goes unicorn and the story is "it was all down to Phoenix", even when the real factors were elsewhere.
> there's little jobs that's all
wasn't an issue for me. I applied for five elixir jobs in a limited sector (fintech) and got an offer.
maybe come out from under that ruby rock and smell the dev air now and then
Also, I was on Ruby since the time when it was "trying to be the next Java" (this was prior to 1.0!). All good things start out small.
Anyway, after the initial learning curve, much happier working in Elixir/Phoenix than I ever was in Ruby/Rails... especially from a code-writing AND code-maintenance standpoint. Immutable-everything is the way forward (which also massively aids concurrency). It also being 10x faster and far better/easier at working in a concurrent context are also perks.
2. The amount of users Discord has has nothing much to do with anything. Facebook has 2 billion users and its programming language is Hack. So Hack isn't obscure? How many people know and use Hack besides a few thousand Facebook employees? If Facebook gets 2 more billion users in the next decade will Hack become 2x as popular?
> The amount of users Discord has has nothing much to do with anything
The argument I was arguing against was that Elixir is niche, not argumentum ad populum. It's no longer really niche, just elite. ;)
It's funny, the fact that Ruby doesn't have a facility to import modules is one of my biggest gripes with it. Instead of importing into a specific scope, the global namespace becomes a dumping ground for anything that has ever been loaded, and you need something like Zeitwerk to do auto-loading for you. Which I guess can be seen as a convenience initially, but it makes things harder to manage as your app grows in complexity.
It would have been nice to be able to do something like: `MyActiveRecordImport = require('activerecord')` to take control of the constant name, but honestly it's not something I hugely miss.
While Elixir has more than enough uses and I love it dearly, nothing comes close to the productivity and expressiveness of Ruby (+ Rails).
I have very high hopes for JS/TS. Using a single isomorphic language for web development must have some benefits, but I'm afraid it's not there yet.
This is a question about standard-library. The standard-library of kotlin is equally amazing (but Kotlin more or less requires the IntelliJ eco-system of course).
It is 2021, web frameworks are ... one of the solved problems. Polyglot is the future, and people are already adapting
Yes, right. I like how you can read into the future. Let's see what happens 10-20 years from now, things tend to change. But even if we look at how things are now, plenty of places still commit to 1-2 languages (in fact if you're a small shop it's pretty crazy to try anything else).
That might be true, but it didn't mean they will commit to ONE language for forever. Even governmental agency's code gets rewritten in newer languages eventually:
https://aws.amazon.com/blogs/apn/automated-refactoring-of-a-...
Since I’ve run Linux servers at every job I’ve had, I’m trying to get my toe into devops at my current employer. Getting all of our application into Docker has been fun. (Why does everyone run shit as root in a container!? Dropping permissions isn’t difficult!!!)
I’ve bounced around over the years and I’m doing a lot of Python now. It’s funny You said that about “loops” because I do feel like I’m always looping something in Python ha
It's not as nice as rails, but we love kotlin so it's hard to give up.
Totally agree, 100%. Ruby isn't "perfect", but it's a pleasure to use. As in, I actually want to use it, not just am "ok" or ambivalent about it. I have my nitpicks about Ruby, about Rails and other things just like anyone, but I second your comment that nothing else has been able to match that sweet spot of great productivity that is a direct result of a fantastic developer experience created through a programming language that just "flows" linguistically so much easier than...well, everything else I've personally ever seen (with Python being an arguable tie there).
My biggest gripes about Ruby and its ecosystem have been the pain in the posterior it is to deploy apps (all those gems, which eventually wind up abandonware and now you've got dependency hell, especially with apps not maintained in 5 years or something) and its relative sluggishness when compared against some other deployable artifacts.
Personally, I think Crystal (https://crystal-lang.org/) fixes pretty much all of this, as long as you're willing to cede a few things due to the nature of the beast (compiled vs. interpreted).
And that's not considering the speed improvements Ruby's gained in the last few years (3x3); it's undoubtedly far better now than when I last released an app with Ruby or Rails (circa ~2016, maybe ~2017ish). I'm just so disappointed that everything's "JavaScript this" or "Go(lang) that". Not that I have a problem with Go (I do have many problems with JavaScript, which I strongly dislike, but that's a separate topic), it's just that this industry acts like lemmings in a lot of cases. "New shiny!" attracts the horde, and that critical mass creates a new tyranny of being the "snowflake" technology/stack/developer, which has a lot of risks for both the organization paying for what you build in tech stack $X (rare language, can I replace this hire later, can I find somebody that knows $X, lower risk if we use $Y b/c we can find plentiful/cheap talent in $Y or $Y salaries are lower than $X), and by that token therefore it's a risk to the developer's career to get hard core on anything perceived as "snowflake" or otherwise not "flavor of the $(month || year || interval)".
Which is just so sad, and I feel like it's a contributing factor in Ruby's decline (in terms of hiring demand for full time positions). It's not at all the technology's fault, and it's not a performance "issue" whatsoever anymore (really wasn't in the first place unless you were nickel and diming literally everything or did stuff just plain stupid).
Go, Rust and friends all have their own benefits and drawbacks too, and they're fine languages with their own killer features and/or quirks. They can produce pre-compiled code for a variety of platforms from a single machine, resulting in (if desired) a single file binary deployable artifact that can be installed and simply run, no dependencies to install, no OS configuration necessary. Ruby, without lots of hacks potentially questionable hacks and potential future abandonware, doesn't do that at all AFAIK, but Crystal can also produce fat binaries just like Go can (and I assume Rust can too), making it the best of both worlds in my opinion.
Crystal: compile Ruby-like code to a "fat" binary for single file, zero-config/dependency deployment that runs true multithreaded apps as native code. And most of those tradeoffs you'd have to give up because "compiled" - most of those you can work around pretty easily and I've heard you can even have it embed source code in the binary to be run in interpreted mode at runtime, so you can have your app compiled for the vast majority of use cases, then have it run its own code inside itself interpreted/JIT'd when run, giving you access to many (all?) of the features you'd otherwise think you'd have to sacrifice.
So yeah, I love Ruby, and I think Crystal is definitely the next evolutionary step for that language and ecosystem. No hate on Ruby there whatsoever, I just see it as a more mature option for a lot of use cases, but definitely not all. I don't know if you can do that metaprogramming magic Ruby is so amazing at any faster in Crystal since you'd have to run the code as interpreted at runtime, not pre-compiled (AFAIK), so it's not an outright replacement. Still, I think it's damn near one, and you can probably "color outside the lines" just a tiny bit as needed when you absolutely MUST have that feature anyway.
Okay, end stream-of-consciousness. I haven't been able to sleep for 3 days, so rambling is a sort of unavoidable side effect...sorry about that. But yeah, try Crystal if you haven't already, you'll likely be very happily shocked at how amazing it is!
I think the actual reason why it's not more popular is something I personally call "The Tyranny of the Masses". In short, what's popular/flavor-of-the-month is automatically "right", and everything else is automatically "wrong" or "high risk" in our industry. These are of course not real demonstrable facts, but people's perceptions that influence choice of technology stack.
Take JavaScript/Node.js for server-side apps for example. MASSIVE ecosystem. Near total ubiquitous skill availability in the developer market (with one major caveat I'll explain below). Not perceived as a rare or difficult skill to pick up, so salaries can be on the lower side than, say, a C developer with Linux kernel experience, for example. To employers and managers, this is a much more attractive mix than something where all of the above are in any way seen as "less true".
Compare that to Elixir. Not around nearly as long as JS, far fewer learning resources, relies on perceived turbo-nerd/esoteric "Erlang" runtime, so support availability may be harder to find and more expensive (so what's that mean for the employer's support and availability contracts, uptime agreements, and/or regulatory environment should something go sideways?). Not nearly as many available published libraries as on NPM (yes I'm sure Elixir's are far higher quality, but remember: it's perception, not fact, at play here). Skilled hires in market not nearly as common or ubiquitous as JavaScript devs are. Nobody has 20 years of Elixir experience. 20+ JavaScript experience does exist though (again, perception matters, not the fact that JS 20 years ago was laughably bad and would almost never even run today!).
Then there's the "safety" factor for production apps. JavaScript? Billions of apps all over the place. Nearly ever prod scenario imaginable has happened and 90% of them have at least been blogged about. Async/await in single threaded runtime using multiple processes for concurrency? Yep, somebody's done it. True multi-threaded single-process concurrency? Yep. Big, perceived as financially stable tech company behind it? Yep. Large market/ecosystem of firms that provide high quality support at reasonable prices to compete for business? Yep. Elixir? Arguably none of that, and definitely not to the quantity - again, not quality, quick-glance perception, optics here is all people look at - that JavaScript has behind it.
Is Elixir a better language, runtime, and ecosystem than JavaScript/Node.js? Almost certainly, and you can probably prove that pretty objectively with only some very obscure/esoteric exceptions having merit. I mean, dude, it's JavaScript, that's a low fucking bar! (Yes I'm a JS hater, go ahead, flame away! "YOUR BOOS MEAN NOTHING TO ME, I'VE SEEN WHAT MAKES YOU CHEER!" - Rick Sanchez)
But is it popular? Not compared to JS! JS is like that air-headed valley girl high school cheerleader that every guy wants to sleep with, and Elixir is that nerdy girl with a good heart, a great head on her shoulders, who can respect people and while she covers nearly every inch of her skin with clothing, leaving everything to the imagination, even a blurred photo would tell you that underneath all that, hot damn! She's the total package. But you want the cheerleader because of the popularity contest. You'll be the big man on campus if you get with her! Well, maybe not "the", more like "a", one in an ever-growing series.
Fast forward to 5-10 years post HS graduation. Cheerleader? Trailer trash with 6 kids on food stamps and zero drive in life whatsoever. Nerd girl? CEO of her own startup, and somehow even hotter now than she was back then!
Oh how foolish we are for falling into the trap of popularity. And while some may feel justified in their subservience to that popularity because reasons, some of them even good, we'll all feel curse the lack of choice, the absence of competition, the void of creativity and innovation - that we inevitably acquiesce to the clamors of the mob. Our future's bright hope will be made dim indeed when we succumb to the Tyranny of the Masses.
EDIT: The caveat on JS skills I mentioned above? Almost everybody who says they "know" JS is really at best an intermediate-level developer with it. It has a lot of special use cases, variations in how things work depending on engine, execution context (server app? browser engine?), and even today in 2021 we still see even self-described "experts" telling you to use alert() to get debug data instead of at the very least console.log/warn/error, etc. The language has made some frankly just plain weird (IMO flat out bad) design choices, like allowing more arguments to a method than its signature declares, and used to be so vastly snowflaked (nearly zero consistency between browsers) that you absolutely had to write an ENTIRE new JS app for each browser you wanted to target. Granted, that was the Netscape Navigator days, when Internet Explorer (Exploder?) was version 5, the rightly-maligned version 6 didn't exist yet, Firefox was a twinkle in somebody's eye, and Microsoft even shipped IE for the Mac (like OS X 10.1 or 10.2! Remember Aqua, the striped textures? Ahh, the good 'ol days...) It's come a long way since, but it still fundamentally suffers from having more bad documentation than good, and while most consider it a "lowest common denominator", that's unfair to people who really are true experts in the language, who will tell you that when you get real deep with Node or V8, you can see some gnarly shit. It's a god-awful security nightmare; why the hell would I let whatever website in the world run whatever code they want directly on my machine all willy-nilly, automatically accepting every API call by default, denying almost nothing, with unrestricted access to some pretty advanced/low-level APIs that can do some serious damage if abused? And people say Flash was bad (well, they did only after Steve Jobs made a big deal about it; he wasn't wrong, but virtually NO ONE hating on Flash back then had any idea how it even worked before Steve bitch slapped it into oblivion and rightly so). Its syntax is arguably archaic (we don't need semicolons to end statements/lines these days, language parsers are much more capable now; look at Python, Ruby!), it's littered with inconsistencies in the language itself, and since everybody's a hammer (JS "expert"), everything looks like a nail (a suitable use for Node/JS/DOM/Script), even when it's damn well obvious, painfully so, that it's absolutely NOT. All this, and yet everybody's somehow an "expert" with JavaScript. Really? Really?
It is incredibly malleable and yet pure. It carries a certain warmth and kindness that permeate its community.
It becomes faster every couple of years :)
I feel so grateful to work with a language that makes me feel like a wizard and look forward to writing code.
The community is so incredibly creative, smart and generous that I feel humbled every day.
Whereas the impression I get of the javascript community is that everyone is paranoid about doing the hottest new thing, like "oh you're still using x? how quaint, haven't you heard everyone is using y now?"
If your idea of static typing is Java or Go or "something", if your idea of it is that it's for "giant orgs" and not improving your own correctness and throughput of code (I write better code, faster, in TypeScript than I ever did in Ruby!), yeah, it might not make sense. But that's a pretty out-of-date take, I think, and the wins the suitably plastic individual can get, even on a solo or small-team project, are significant.
I don't want Ruby to become another TS because I'd use a typed language if I wanted one. The problems I use Ruby for don't need the speed of a statically typed language and it's nice using a dynamic one for.
I don't think I've talked to anyone who has gotten "over the hump" with TS and felt like they were missing something from JS - I may be in a bubble though. It's almost frustratingly beloved in my experience.
2. What made JS uniquely nice?
I wanted to leave these questions entirely open to answer, but I'll add my own opinion on (2) because I feel compelled: nothing, JS is quite possibly the worst language ever designed. Certainly the worst in widespread use.
I think the general point the above commenter is trying to make is that not all typed languages are equivalent: i.e. if you're avoiding TS/typed ruby/etc. because you don't want something like Haskell/Java, then that's not a well-informed decision as they're (all) radically different approaches to static typing, each with their own unique benefits and drawbacks.
TS is nothing like Java nor Haskell. Nor Rust.
(I can't personally speak to Ruby/Pony yet)
Tooling isn't great, it's missing things like a language server (compiler gives good error messages at least), but it's also quite simple (whole syntax fits into a smallish page) and the documentation is decent.
Playing around with it for doing economic simulations. Actors + good multithreaded performance = pretty much perfect for the domain. Makes sense too, the creator and half the core members came from the financial field.
Ruby is my go-to for scripting, one off programs, and anything web-related (blog, putting together a small crud site). For things where I want performance, I just use a compiled/static language.
Gradual/optional static typing are not new ideias. It’s just that they are fashionable now.
It used to be that not having to deal with types at all was the cool place to be in. Our computers were getting so much faster every year, why would performance be a concern? Programmers are more productive in dynamic languages and computer time is cheap, etc, etc.
The “correctness” pitch, the required for larger projects, compiletime vs runtime errors are all discussable, even though they are often thrown in the conversation as irrefutable advantages of static typing.
The performance angle, not so much. Static will almost always be faster then dynamic typing, even with all the crazy tricks we’ve developed over the decades.
On the static side, Java and especially C# are simply _better_ than they used to be. Type inference is great - I can just write var x = new List<Thing>() rather than having to stupidly repeat the type e.g. List<Thing> x = new List<Thing>(). Add in generics, and lambdas, and about a dozen other things that have now become widespread, and it's really a different game than 10 years ago.
Coming the other way, I never expected to see Intellisense-like autocompletion for languages like Ruby or Python. It honestly feels magical. Refactoring has gotten much better to where I can pull methods up and down inheritance chains using PyCharm or other mainstream IDEs.
I actually think it's mobile that's pushed people back toward static. Swift, ObjC, Java, and Kotlin are all static and there's less emphasis on this "one language" idea that drove a lot of people toward trying to use the same language (JS/TS) for their React front-ends and node backends.
The argument has always been whether or not the price of that correctness is too high.
But at this point if you're using a modern IDE / code editor (e.g. VSCode), it's actually easier to write statically typed code because the inference / auto-completion / etc is so much better when you do.
At least with TypeScript in VSCode.
No. I mean, that's been part of the argument, but so has whether static typing actually gave you useful correctness. Many static languages have had type systems that are more designed around convenience of compilation (and performance of compiled code) than correctness; the type systems of the optional typecheckers of modern dynamic languages are leaps and bounds better than static type systems of most popular static languages a couple decades ago, and have been for some time.
> But at this point if you're using a modern IDE / code editor (e.g. VSCode), it's actually easier to write statically typed code because the inference / auto-completion / etc is so much better when you do.
If you have good inference, statically typed and dynamically typed code is virtually indistinguishable TypeProf-IDE for Ruby, discussed in TFA, generates type signatures by inference from plain Ruby code.
Maybe Rails is special-cased enough to get away with it, but I still maintain a project in Grape and none of the autocomplete solutions I have found for Ruby help significantly at all. Meanwhile over in TypeScript, I literally can't remember the last time I used `any` or `unknown` except at a module's edge during validation of untrusted input, and autocomplete is awesome.
Ruby has a pretty nice language server, nice linter, REPL (Pry), many other tools.
The best development experience IMO is still stuff like SLIME or Smalltalk environments.
"Intellisence" just makes using statically typed languages bearable. It's not a unique feature.
Like just seriously try intellij with java and pycharm for a php code.
I'd add that Common Lisp has had optional type hints (as both documentation and performance improvement) for getting close to 40 years now.
AFAIK registers and assembly is untyped.
I've never written TypeScript but I suspect the tooling around Sorbet is pretty far behind at this point but it's still worth it. For example, there are is a whole class of unit tests that no longer need to be written. In addition to the gradual typing, having access to interfaces, typed structs and enums is all nice too.
I just really like writing silly in/out tests less.
I'm not sure that's a great use of time. If A is passing the wrong thing to B, B will throw a `NoMethodError` anyway once it tries to do anything with the arguments, which will make the spec test fail anyway.
But maybe I'm misunderstanding what you mean by "silly in/out tests"...
It can also then create security issues around untrusted input; you should be sanitizing at module boundaries any time something might be sensibly used with rando input, IMO, rather than relying on web developers who may or may not be competent enough to duplicate other consumers' effort to do it.
Having to do less work to enforce sanity at module boundaries, and having it tied in with the type system when you do have to do it, is a powerful force-multiplier. For example: I use `runtypes` to create validators in TypeScript when I must handle untrusted input and it's smart enough to take the validator I specify and create a type of the same shape for use at compile-time, so users who aren't dealing with untrusted input just have the nice computer cross the T's and dot the I's for them.
People choosing to write JavaScript in 2021 might be plenty productive. I trust their code much less, though, unless they're writing a battery of tests to establish sanity at their module boundaries and making the extra effort to ensure correctness that you get very cheaply with TypeScript.
Not needing types is another benefit of good testing.
That's my experience, at least.
* Static typing catches many kinds of bugs earlier by simply not allowing you to write incorrect code in the first place.
* No matter how good your test suite is, you're still putting the burden on the human to always remember to write tests for corner cases.
* Static typing allows you have to write many fewer tests by making invalid data unrepresentable. You don't have to write millions of unit tests of the type "what if this list is empty" if the function literally can't accept an empty list.
We just don't write these kind of tests on our Rails codebases and we are fine. The world hasn't exploded yet anyway. If some piece of code is super tricky and sensitive then sure maybe then (though I have yet to see such a test case I think), but as a rule? No.
I don't write a million tests. There are much better strategies for testing.
Simple tests that just executes the code will catch the vast majority of type mistakes.
What would you be testing for, exactly? That `SomeClass#some_method` raises a `NoMethodError` when you pass it the wrong thing?
You could test for that, but I don't think that would be a good use of code or your time. If A is passing the wrong things to B, your specs will fail anyway on that `NoMethodError` once B tries to actually do something with those improper argument(s).
I suppose it could be useful in cases where you'd stubbed out B in your specs, but ehhhh.
Having types not line up at various boundaries (DB/API/reading from a file) is already a pain, but Ruby made it worse by having that bad data pass through many layers until it actually blows up somewhere far removed from the issue. I worked on very real bugs where e.g. a corner case lead to a date being deserialized as a string and then because the last few characters were numeric interpreted as a number so when treated as a date resolved as millis since epoch (or something similarly crazy). It took ~1 of those bugs for me to be convinced that I had no interest in dealing with those kinds of problems, and adding a 'Date' type means it fails in exactly the right place immediately and is a 2 second fix.
I agree with you though - it'd be a silly test to write, so how do you get the correctness/robustness without either types or tests that look like they're effectively validating types?
You're talking like that's rare and not something people constantly do when writing tests in Ruby.
Also, what happens when you don't get a NoMethodError? Duck typing is an extremely common practice in Ruby, which means that you can easily run into situations where code "runs" but the output is nonsensical.
Did Java for 13 years. Then moved to Ruby and lost the type system I had leaned so hard on.
After an adjustment period I got into the new groove of just testing all code, and I don't miss my hard typed days at all.
I sometimes get annoyed when I get stuck screwing around with the RBI files. Then I get in the flow and remember how fast Sorbet allows me to move.
I would say that's a big overstatement.
I don't understand how anyone that has experience with dynamically typed languages and the insane runtime errors that can result from them would ever consider using a dynamically typed language. It's terrible and it actually provides little to no benefit in development speed. People always say development is faster in a dynamically typed language, this is not my experience. You need to actually run the program and step into it with a debugger in order to determine the type of anything at run time.
Given the popularity of typescript and how nearly all major internet companies have moved to typed versions of their dynamically typed languages it's clear to me the whole dynamic typing experiment has failed absolutely miserably.
You just develop on the running program... If you just write it in your editor, run, check for errors, stop, edit more, run, stop, etc... then yes, you don't gain anything.
Ah yes, don't worry about correctness at all, just wing it. I take it you haven't had to debug some of the stuff you've written?
Did you miss a decade or two of CS history? Lisp and Smalltalk have been around long enough that the value of programming with dynamic languages is known... I mean, there's shaceships and whatnot running on Lisp.
Or did CS simply start and end with Java?
Most Ruby devs work as contractors. They deliver the software and go to the next paying contract. They don't have to live with their software. :)
Python is one of the most popular programming languages.
Ruby's choice of making it optional means folks like yourself who want to move fast and break things are welcome to do so, but those of us working on more mature systems that need the reliability and lack of bugs can add this on and get the safety.
Mixing it up with JS (which is weakly typed)?
I'm slightly concerned that people will overdo it. E.g. I've more than once wanted to pass an input to something that enforced stricter typing than necessary via guards e.g. checking its input with #kind_of? when it otherwise only needed a class that implemented a sensible #read (for example). But Rubyists are pragmatic - I think after a period of overzealous annotations (the way people went totally overboard with monkey patching for a while) most people will keep the type declarations just loose enough.
Maybe with the new developments in Ruby ecosystem somebody will fix Net::Http so an absolute request timeout can be set to protect against slow client/server and maybe oversized payloads as well. Maybe 2030?
Typescript is 9 years old. React was still a project then and Angular was brand new. SPA's were still a new-ish concept then. JS was not used as widely 10 years ago as it is now, thanks to SPA's. The web was a drastically different place back then.
I am not at all saying that TypeScript should always be used, far from that. I just think it has a valid spot in the world of web development.
Granted, I've only written C in University settings where I'm writing small programs. I had no idea how to write "real" programs. But with Python and Javascript it felt like I could more easily write "real" programs.
What I found out is that I quickly burned out. Around 2011 I felt like I don't know how to start making programs. Programming basically became dreadful. I taught myself to wade through it anyway, convinced I would find the joy again when I get more proficient.
What eventually made me redisocver the joy of Programming is switching to procedural programming and static typing.
First it was with Typescript. Now with Go.
Writing programs with just structs and functions is really enjoyable.
Programming in dynamically typed languages is dreadful. There's no joy in it.
I guess that in part it's a matter of mentality or personal style (I know that I think mostly in terms of guarantees, invariants and so on, which is why types are so useful to me; I feel like other people think more in terms of operations when they program, and maybe dynamic programming suits them more). But there are some huge advantages as well. The tooling is far better (like the incremental compilation in Eclipse, also available in IntelliJ but turned off by default IIRC, which highlights compilation error while you are still writing the code); there are fewer unit tests required because there are fewer things that can go wrong, since a lot of them can be enforced by the type system; most important of all, reading someone else's code is far easier because mandatory documentation, in the form of type names, is all over the place (yep, not a fan of type inference either). And there are more and more advantages.
I just don't see myself working on even a moderately sized code base in a dynamic language. The pain is too real; I have been there.
Have you written multiple microservices in Go? The lack of an opinionated framework often means that each microservice contains code that is organized in its own unique ad-hoc way with lots of repeated boiler-plate code. The learning-curve to understand how each service's code is organized gets old fast. With Ruby and with RoR I never have to waste time with this and I can get straight to the business logic.
When writing one-off scripts, I can see the advantages of dealing with just structs and functions.
That was my first semi-serious project. It was around 2012. Yes it was dreadful. The problem is I was still programming with mentality of someone who wants to use dynamic typing.
I would read JSON from an http endpoint, and then just make assumptions as to what keys are availabe, and just read them off like this:
data['key1']['key2']
I don't do that anymore. When programin in Go, JSON is just a serialization format for a struct. You have a concrete struct type and you just use json to fill it with data. It's so easy and trivial.
> Have you written multiple microservices in Go?
God no! Why would I do that? I hate microservices. I like Go because I can make a self contained application.
> The lack of an opinionated framework often means that each microservice contains code that is organized in its own unique ad-hoc way with lots of repeated boiler-plate code.
So you're talking about working within an organization with multiple insulated teams, each writing services that are supposed to communicate with each other, but the teams themselves don't follow any standard.
Well, that's just one of the awful things about microservices. I don't think the language matters.
> With Ruby and with RoR I never have to waste time with this and I can get straight to the business logic.
Having to debug a RoR codebase was the worst experience in my programming life. It's all magic. Trying to read the code helps you with nothing. You can't read the code to understand the program. You have to read the RoR documentation to understand all the magic. Worse, you can't just read a part of it: you have to read all of it. Because nothing in the code will give you any hint as to _which_ magical aspects of RoR this codebase is using. So unless you know all the magic that RoR does, you have no idea what's going on.
> When writing one-off scripts, I can see the advantages of dealing with just structs and functions.
It's the exact opposite. When writing one off scripts, I can see why someone would not want to bother with structs. You usually are dealing with strings any way (filenames, paths, keys in a json/yaml file, etc).
This does mean that you should know and define your schema in advance, which is not always doable. An alternative is to use a sum type and pattern to safely deconstruct `interface{}` but Go has a notably poor support for sum types. Static typing is not really a culprit here, but Go would make a bad example for anonymous JSON parsing.
What's dreadful about it? I use it all the time and find it easy to use. I love static typing though and prefer my JSON to have a proper schema (to automatically generate transport layers in both Go and JS from the same source)
>The lack of an opinionated framework often means that each microservice contains code that is organized in its own unique ad-hoc way with lots of repeated boiler-plate code.
Our organization has a microservice generator tool which creates a new microservice for you so that you could start writing business logic immediately and didn't have to think about how to organize your code. It doesn't really do much - it defines a source generator for the transport layer (from protobuf descriptions so you don't have to deal with JSON), creates a bunch of folders ("put domain logic here" etc.), and adds some infrastructure code to connect to DB, RabbitMQ etc. while also adding imports to our org-wide common utils Go library. It took like a few days to create this tool, but the author already had a lot of experience writing microservices so he knew how to structure code and what dependencies to use.
>Have you wrangled with JSON using Go? Absolutely dreadful.
No it is not. You just take a json object, put it down as Go struct. Yes, it takes more time unlike in JS or Ruby but it makes this code much more readable. You can open a project and see what kind of json it expects as an input. All contracts are there. Not need for any kind of schemas or yml definitions (though you can generate one if you need to).
>Have you written multiple microservices in Go?
We currectlly have more than a hundred of those. The lack of an opinionated framework is a bad thing only from the management point of view. Once you and your team is done with this - there is really no difference from using a framework.
Again - yes, it requires more time and most likely not a great option for a small company without a developed background (ie no preferred ways for doing different kind of things) but no a problem for a relatively big company. We have a number of teams solving different problems and thus using different ways of building their services (micro or not).
>With Ruby and with RoR I never have to waste time with this and I can get straight to the business logic.
Yes, until you face a problem were your favourite gem is not enough to do the job and you have to go the hacky root.
PS: But honestly this whole topic is getting old. I've build apps in both Ruby (mostly not Rails though, we've had Roda) and Go and while RoR\Ruby\etc are great for one set of tasks I'd never use them for some other tasks. For example systems integrations which is my main job for the last ~5 years.
People often forget the web dev is not just your clients' browser to server communication.
Yes. Of course it's dreadful. It's JSON. It's way better in Go than Ruby or Javascript, though.
As the codebase grows larger, if people dont have the discipline to write proper code, the code will get more and more complicated since you will not know what exactly you will get. Mostly dynamic languages are easy to get into (which is a strength) but this becomes a weakness as the project becomes larger.
It's far easier for them to adopt a static analysis tool that mimics the type safety that Java provides than to migrate their codebase.
I was writing a web app in Rust (I want to be cool!) and only after a couple hours of implementing CRUD did I realize I'd effectively made an inconsistently implemented rails scaffolding. The default opinionated round trip for DB -> application -> UI for CRUD is still really slick.
I don't feel strongly about any of this and if another language is your favorite for small one-offs, that's great. Ruby works well for me though, and I hope it sticks around.
The bad:
- Cannot compare Rails' ActiveRecord with TypeORM. TypeORM still lacks proper documentation and sometimes we even had to write raw SQL (or use the query builder feature )for joins.
- Testing using Minitest (Ruby) is easy and the code looks very clean. It is not as easy to go through our Jest tests. Also the test suite required some customisations for small stuffs like cleaning the db after every test.
- There is no clear winner for web frameworks in Node ecosystem. The framework you choose will be less adopted and less matured than Rails.
- A lot more applicants for the backend roles. We tried to hire senior Ruby developers in June and we got only a few applicants. After switching to Node, hiring has become easy.
- Having only one language in the stack is helping us get contributions from more external developers.
- Nest.js is not very opinionated, we can easily customise it to follow the conventions and directory structure followed by Rails.
How would that be a bad default, when it's probably more than sufficient for 99% of the use cases out there? It's even the same default as nginx: https://nginx.org/en/docs/http/ngx_http_core_module.html#cli...
Nest.js is clearly targeting JSON-based CRUD apps, and the defaults are pretty good. File uploads through JSON is not as simple a problem as you try to make it. Are you using bas64 encoding and embedding it in the JSON? Are you using multipart/form-data?
NestJS on the other hand is very solid. It has good documentation and a good community. We haven't faced any issues with NestJS yet.
The IO/performance improvements and concurrency improvements are exciting. Reading this makes me want to try out ractors.
If there was a way to do a type signatures inline without making things ugly, I would use them. Optionally enforcing @param and @return comments would be good enough for me. A separate file is useless for me because I don’t use an IDE.
1: I have my reasons for using Sublime over the alternatives.
AFAICT the Ruby community is big on gentle iterations, and this is that: enough of type system to start playing with, and to get to the whatever the next step might be.
In a language where so many things are fast and loose, it seemed like an odd decision, but I agree with it.
npm install --save-dev @types/node
I've seen some folks dealing with Java, NodeJS, Python as their first (and only) tech stack and they never become a senior developer one.
So, what i love the most from Ruby and RoR is how it helps you on your career path to become a better engineer in a concise way that no other framework/languages can offer you.
Learn from what the Ruby/RoR teach you in a short timespan and you'll see the whole new world of real world programming.
From my story: I started with Ruby and RoR in 2 years then i can master all other languages, framework in NO time. All concepts are there, learnt from Ruby/RoR already. No need to re-learn new things to get the job done in your future tech stack.
I'd argue that Python (or similar) back-end and JS-flavor front-end is a better path to growing since it's just a much wider area of growth.
I disagree. A lot of this discussion is about semantics - what do we mean when we say senior developer? for FAANG they don't really care what languages you know - in fact they don't really seem to care how well you can code, it's all about your ability to solve algorithms under pressure. Is that a senior dev? Guess for them it is.
But for smaller startups - where your ability to code well and onboard fast is critical to the team, when they hire a senior they will most often prefer someone familiar with their stack. So to them, a senior (preferably) has deep knowledge in their stack already (or is good enough to get up to speed really quickly).
About your concern, other frameworks/languages offer you only part of story, Ruby and RoR offers you complete story in a concise way, it's the difference.
Most systems use similar-enough patterns you can carry them over where-ever. It doesn’t have to be rails, but it was for you.
In era 2010, .NET stack couldn't offer you that.
I wrote about 4 production application in Ruby stack in 6 months, it's super productive and the Ruby language has OOP/FP done right in comparison of other languages, too.
C# had task-based async and a very good, compared to the competition in Java, database framework to work with. Seriously, how doesn't Java have named parameters yet?
It is kind of hinted at with static typing, but the real story behind a lot of what happened since ruby 3 was released has been the tools and IDE plugins around it. Static Typing via RBS is also the existing LSP integration + VSCode plugin, the Typeprof plugin which allows scaffolding .rbs files for untyped modules, and the new debugger which will ship with 3.1, finally a core-blessed debugger, but above all, a debugger one can integrate with docker and IDE.
I'm expecting more of this in the future, such as a production-ready profiler, better tracing, overall better monitoring.
Can you expand? We have a kubernetes setup at work and I can't do binding.pry locally to get a breakpoint! (the containers aren't running on the developer's machine just clarifying). I was wondering what it would take for us to have breakpoints at work.
Golang is the trend. (I don't have any opinion in either Golang or Rust; but most jobs out there are looking for Golang microservice deployed in K8S)
I would see Go being more usable for DevOps tasks, writing pipelines, programming infrastructure and such.
If performance would be the most important thing, then I would consider Rust.
Source:
https://insights.stackoverflow.com/trends?tags=next.js%2Crus...
https://star-history.t9t.io/#rust-lang/rust&golang/go&vercel...
But day to day I use JRuby and Go quite often, and in the process of converting some Ruby code over to Go, for specific performance, dependency and memory reasons.
Our stack is front-end heavy with a very mature JS framework and the back-end is mostly an API server. Databases range from SQLite to Postgres.
Development is usually done on SQLite and staging / production on Postgres. Quite a few projects with SQLite DB in production as well.
Middlemanapp is a great static website generator written in Ruby and easy to extend that I used many times to generate simple generated websites.
Jekyll is a great static blog generator.
I think Elixir has better chances of taking over some of the Ruby pie from this perspective as the Elixir community is a lovely and helpful as the Ruby one.
Without such community it is very hard to build momentum and most programming languages remains great options but limited to a small number of projects.
I like Crystal and played with it a little bit. I tried to use it in production for a small project where I offloaded some tasks from Rails into Crystal small programs.
I'm bookmarking this. God willing, we can check back in 5 years.
Would job postings and TIOBE be enough?
I think what's being played out is the maturation of a platform. Ruby and Rails have been around for a while now and there are many large Ruby codebases out there. The Ruby standard library is fairly comprehensive. The dependency management debate has largely been settled. So, a focus on performance and taking advantage of multi-core systems is a natural area to shift focus to. Adding a progressive, opt-in, type system can help navigate large applications.
At the end of the day, all of this new stuff can be ignored if you want. Ruby will still be Ruby. But, if you do want to use one of these new features, you won't have to go through the time-suck of porting to a different language.
Now C… that’s a blight that’s never going away. ;)