Shopify invests in research for Ruby at scale (shopify.engineering)

Metaprogramming, yes but also pure objects. Ruby has that Smalltalk heritage in a way no other language has. Also the fact that it focuses on developer happiness makes it a way more pleasant language to use compared to say Golang or Rust.

I have been working with Ruby for over a decade and IMO most metaprogramming is the worst part of Ruby code. It makes code very difficult to reason about outside of runtime and makes unclear traces when something does go wrong. Now I know it can be done right, but I think the Ruby community ran too much with DRY (Don't Repeat Yourself) and "clean" minimal syntax at the cost of maintainability and readability.

It also makes it hard for tools to reason about what is being run as well when you have stuff running in `instance_eval` contexts and `method_missing` being abused. So now here we are trying to unravel that by trying to make the interpreter smarter with caching to improve performance but if I had to turn back time, I would reverse every instance where one tried to be clever with metaprogramming in the name of syntax.

> They have completely different semantics, performance characteristics

Many times it is the different semantics that allow for better performance.

If you can add new methods or change their implementation at runtime, performance optimizations get a lot trickier, for example.

The immutability that's foundational to Elixir and Erlang enable the incredible scaling capabilities of the Erlang VM.

Don't. It's not that amazing.

It's on me really, I made the huge mistake of taking the interview when my child was sick and my super loud father in law and wife were in the house with my toddler child. It was after the interview was postponed twice and I didn't want to postpone it again. In addition to all the noise they made the cat hated it that I closed the door during the interview and kept meowing to be let in...if I had let her in she would have kept bumping into me but in retrospect that would have been better. The icing on the cake was I took a room in the house that had a lousy connection so I was disconnected twice during the Leetcode thing (I don't remember if it was Leetcode but it was one of those online coding platforms). It was such a disaster it was the first time ever I asked to stop the interview in the middle - I just gave up and was a complete sweaty mess lol.

So lesson learned - important interview needs to be in an empty house. I don't have a great solution for the cat problem.

Anyway I usually don't take interview failure that hard but this one was painful because my performance was so embarrassing and I cared about the job. Probably my poor performance was in direct proportion to how excited I was about the opportunity - too bad.

> iirc it was them that was holding up node at that version

really? I thought it was Joyent? Would love a source on this.

Theory #4: The performance is actually fine, but the developers were given a project to improve performance in order to keep them around for hot fixes in a codebase they know well and to mentor junior employees.

And in the process add a couple of CVEs...

Agreed, as someone who has largely done web services in Python, along with some data engineering

I work professionally in Golang now and I appreciate so many things about it, but when I go back to get something done for a personal project in Python, it is scary how much faster I can move.

Pydantic, FastAPI, SQLAlchemy, Alembic, requests, attrs, click... it's going to be a long time before other languages can hope to provide libraries with developer experiences that even come close.

cough common lisp cough

What about C#? That being said, I might just be accustomed to all the boilerplate.

Prove Productivity scientifically.

    records = User.limit(10)
    records.select { |user| user.is_admin? }.map{|user| "#{user.id} : #{user.name}"}

    records := Stream.Limit(User, 10)
    records.Select(func(user User) bool {return user.IsAdmin()}).Map{func(user User) string { return fmt.Sprintf("%d %s", user.id, user.name) }

why not just use Crystal https://crystal-lang.org, it is faster than go, with Ruby like sytnax.

Gitlab split and rewrote some services in $faster_language. Based on the hires, Github seems to be doing that as well.

Gitlab's history with $faster_language has at least some background documentation, e.g. https://about.gitlab.com/blog/2016/04/12/a-brief-history-of-....

They seemed to have liked it, as at least a couple of other services are written in $faster_language - gitlab-shell and gitaly (probably, several others).

There may be more static languages nowadays, but they're very young - I think in real world, there wasn't, pragmatically, a lot of choice, although today's young languages are... still young :)

This is definitely true, and I wouldn't fault anyone for using Ruby or Python to write the initial version of their startup. However, there's a difference between initial productivity and ongoing productivity (maintenance). Statically typed languages like Go and C++ are much easier to rework and refactor, because the compiler is checking types (not to mention typos).

C# and F# have a good blend of performance and code style.

You could make most scripting languages much faster by adding immutable structs and keeping everything else more or less the same. There was a game middleware company selling more or less this for Lua.

IMO Go has far more boiler plate than Java. Go is going to have countless amounts more boiler plate for simple logic. Just like your comment below try writing one of these in go:

    var lst = users.stream()
        .filter(User::isAdmin)
        .map(u -> u.id() + “ : “ + u.name())
        .limit(10)
        .toList();


    static boolean isPrime(int n) {
        return switch (n) {
            case 0, 1 -> false,
            default -> !IntStream.range(2, n).anyMatch(i -> n % i == 0)
        }
    }

    func IsPrime(n int64) bool {
        return big.NewInt(n).ProbablyPrime(0)
    }

    new BigInteger(n).isProbablyPrime(0);

Precisely. Twitter is a great example of this. I'm sure they have moved beyond Ruby in many areas but it was originally core and got them off the ground quickly, I presume.

Splitting services and porting them to a faster language doesn't prevent prototyping in the main, slower, language (in this case, Ruby).

It also doesn't need to be microservices madness - see GitLab (and also GitHub, but I think they don't open source their internal services), which rewrote some parts in Go.

Dynamic and somewhat loose language doesn't preclude not having at very least JIT support out of the box, even BASIC was better in that regard.

And if we take into account Ruby's predecessors, Smalltalk, SELF, Dylan.

Lua definitely caught a stray here. The reference VM is pretty fast, the JIT is just way faster. No idea how Lua ended up wrapped in the conversation with Python...

Lua has no OO, and changes its stdlib all the time.

> effectively zero compile-time, one can achieve significantly tighter iteration cycles across a team

I don’t know what machines do people develop on, but on a fairly old laptop I get practically instantaneous iteration with incremental compiles with Rust, which is one of the slowest compiling languages. I honestly can’t imagine where is this supposed slow compiles in case of something like Java - like sure one can create some monstrosity of a build definition, but if some competent person wrote it it is just as fast as an interpreted language. Hell, it can do hot swapping just fine.

More importantly, you had to hack shit together as fast as possible to get a dice roll at the $50B business or bust game.

One plausible reason in my mind is that startups tend to hire devs on the younger side, and it seems (from my perspective in the USA) that most new-ish grads come out of school having done most of their programming in Python. Plus some Javascript if they've dabbled in web dev building hobby projects.

This is something I've thought a lot about over the years too.

Runtime performance is great and very much welcome if you can get it for free but for a ton of web apps it's not a major selling point on its own.

If I can write 30-100% less code and be able to Google almost every single problem I encounter and find tons of high quality blog posts, documentation and videos along with having decently maintained third party libraries for common features then this is going to win every time in my book against something that doesn't have this. It doesn't matter if your web app uses 100mb of memory instead of 1gb or can serve 300 requests per second instead of 30. Most apps never come remotely near the point where this level of performance matters and Rails makes it easy enough to cache things where you can get your p95+ responses responding in 50-100ms or less without much effort.

Basically Rails sets you up where a solo dev or small team can run an entire SAAS app on a single $20-40 / month server and have tens of thousands of paying customers without really having to think much about performance. Combine this with Hotwire and you can build really nice feeling sites very quickly if you're the type of person who doesn't want to build APIs + JS front-ends.

On the other side of the spectrum with Shopify, GitHub and Basecamp you have engineers running Rails at massive scale making the framework better for everyone (themselves included). It's a self-fulfilling prophecy and win / win scenario because the more people that use it contribute back to the project (patches, community related things, etc.).

At this point the only things that matter are fast how you can build your app and how happy are you building / maintaining it. As Ruby, Rails and compute resources get faster then frameworks who focus mainly on performance become less appealing over time for a huge class of web apps because once you reach "good enough" performance it's all about the community and mass adoption. It's like a company who pops up and tries to copy another company but adds 1 small feature to differentiate themselves. As soon as the company you copied decides to add that feature you're going to be climbing way up hill to barely survive.

Latency matters, but nobody’s platform is unusably slow. Expressiveness matters for morale and hiring, and most of all while iterating early on. Efficiency only starts to matter when product/market fit brings enough load to push your backend budget.

Trivial.