I don't think "fast" languages are automatically better, they have downsides for sure:

* Rust - I do not understand the borrow checker at all and I'm a senior engineer at FAANG. I can barely write a simple function in Rust. I've struggled more learning Rust than any language (and I can write C and C++ just fine!)

* Go - I like Go, but there is a ton of boilerplate involved with writing it. Ruby is far more concise and you can get straight to business logic.

* Java - Even more boilerplate

* C/C++ - I think Ruby clearly wins on productivity here

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

I prefer Go to Ruby so I don't know what you're trying to argue. I just said it requires a lot of boilerplate and that makes it harder to be productive. Technology choice is about trade-offs.

It doesn't mean a project is doomed simply because it chose Go. That said, Heroku tried to do a major Go rewrite of their entire backend and the project failed miserably.

What's the story behind Heroku's rewrite?

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

New Java is pretty damn good actually, I don't see a real need for Go over it other than compile time perhaps.

Java has a lot going for it but the JVM remains anathema to a lot of developers. Modern C++ has similar stigma on the language end – it's possible to write fantastically expressive and terse code in it nowadays, but it maintains a reputation.

2 years ago I spent 2 months learning C++ coming from almost entirely scripting languages throughout my career. (Though I have a CS degree so a decent academic background in memory management)

I came away liking C++ more than I thought I would. I didn't find it hard to learn but it was time consuming. Where learning Rust I never understood the basic concepts enough to be productive, I could be productive pretty quick with C++.

The trouble is there is a lot to learn because the language is just so old and has been through so many revisions. To some extent you can't just limit yourself to the modern stuff since in order to learn the modern stuff you need a basic understanding of what it was before to know why things are done the way they are now. You also run into code samples that use the old stuff or corner cases where they're needed.

I also think it really gets you to think about how computation and memory is happening at the metal level which is great for optimization but I think for most of the work I do it would be largely a distraction. I see this is a downside, not an upside.

That said, you're definitely right. You can have nice, expressive code in C++: I just think the learning curve is the biggest problem. I'd be happy to use C++ in my next project though.

Javac is still probably going to compile faster than go. Javac doesn't have to do ANY optimizations. I doubt you'll find a compiler faster.

You may be right. My knowledge of Java is from 1.4 in college and vastly out of date.

I should spend some time actually learning modern Java and less time avoiding it.

There's still some verbosity. I would kill for C# like properties for mutable data classes (JPA entities). I also really like Kotlin/Scala style apply functions for interfaces and Kotlin's delegates for making easy decorators, but none of these have ever convinced me to leave Java behind. The only languages that have come close are C# or D because of their lower level capabilities.

Second one in Go:

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

Each language has its own pros and cons. Go wants to be explicit and simple to be understood. Java is fully-featured.

This is just anectodal evidence anyways. And these are tools in the and, and no point for a "tool fight".

The point of that example wasn't to show if there was a standard library function for it. It was to show the verbosity of writing code that contains if conditions, loops, and generic programming. I obviously could have written:

    new BigInteger(n).isProbablyPrime(0);

My general point is that if you put Ruby up against a nonspecific compiled language it's hard to argue Ruby is better. When you analyze something like Go vs Ruby or Go vs Java then the warts of particular languages come out.

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

That's why my language of choice is TypeScript, but I think Sorbet looks promising (haven't used it though)

Same. Next whatever startup or what I will do will be done in TypeScript(/JS) for the back end and front end. The ecosystem is so massive. And most of the time people will do a library, tool, database, or whatever, and the next language they will support to interact with it is JS/TS.

make sure you give Deno a test run too. I think it could be great for some applications already.

(Specifically cases where you want the project easy to jump into with almost no toolchain setup.)

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

And in Visual Studio (full, not code) you have an amazing IDE that is an incredible help when writing the code.

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

One major selling point of Ruby is the robust ecosystem of high quality, open source libraries which are relevant to the things SaaS companies need to get done. There's a ton of code you just don't have to write if you stick to Ruby.

The fact that "Ruby developers already basically know the Crystal syntax" is a selling point for Crystal, but if people are already evaluating a switch to another programming language, that's just one of many factors that must be considered.

> with Ruby like sytnax

People use Ruby because they like the way it works, not because of the syntax.

Crystal's standard library is also a close match for Ruby's. I do Ruby every day and was able to familiarise myself with Crystal in a few hours.

It's definitely lacking in the web ecosystem department but the language is a joy to use and incredibly fast.

It can be a 99.99% close-match, but if it doesn't include key methods like a runtime method_missing, then it's hard to see how we'd reimplement Rails and our code base on top of it.

I think people focus on the superficial similarity of Crystal, without thinking what semantics need to be the same for it to use usefully similar. And those semantics aren't there, so it doesn't matter if it sorts of looks the same and includes most methods.

I feel like if it was tractable to run Rails on Crystal then someone would have done that.

I'm waiting until I hear some success people are having with it. I suspect the ecosystem is young and library support is minimal too.

Last I heard (which was years ago) it was pretty much a solo project.

That said, the demo is really something and I like what they're doing. I hope one day it becomes my language of choice.

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

Biggest downside is you're likely committing yourself to the Microsoft stack and a single vendor for most of your technology.

I don't think it's necessarily the wrong decision but you have to decide if it's right for your project.

Dotnet core runs fine in Docker/on Linux?

Most C# apps I've worked on in the last 5 years are deployed to Kubernetes.

fair enough, perhaps I should give it another look

100% inaccurate/outdated (by 5 years) info. I've run .NET Core applications on Linux/Docker/K8s + Postgres. The only Microsoft 'stack' there is .NET itself.

.NET Core is still absolutely designed to nudge you into the MS stack.

- EFCore is MSSQL first, even if other options are provided

- Many libraries ship with two implementations: an over-engineered Windowsy version that barely works (with a big scary warning that it should never be used in production), and a thin wrapper around some Azure service

- Important tooling like the debugger (which wouldn't be so necessary if .NET had halfway decent support for printf debugging, but here we are...) is locked to be compatible with VS and (MS' build of) VSCode, despite both of them using supposedly open (and Microsoft-pushed!) standards like DAP

- The community is really culty, the response to "X is broken when using the non-MS-Stack alternative" always seems to be "well use the standard MS solution then"

- It's practically open source in name only, because the build engineering is so convoluted that it's nearly impossible to find the canonical source code of core features like the standard libraries

- EF Core is not MSSQL first. EF Core is an abstraction layer and is in no way tied to Sql Server. In fact, Microsoft's own getting started tutorial uses Sqlite (1). I've personally used the Postgres drivers in production and they are as good/production-ready as Microsoft's SQL library for EF Core.

- "Many libraries ship with two implementations..." I've yet to come across these "many" libraries in the 5 years since I've been building services with .NET Core.

"The community is really culty" - I'm not sure where this is coming from. It's hard to refute such vague criticisms.

- "It's practically open source in name only" - Here is the base class library source: https://github.com/dotnet/runtime/tree/main/src/libraries or https://github.com/dotnet/corefx/releases (depending on what version you're looking for)

1. https://docs.microsoft.com/en-us/ef/core/get-started/overvie...

If you want to build .NET Core yourself, Microsoft provides you with the steps necessary to do so here: https://github.com/dotnet/source-build

Maybe our definitions of open source are different, or maybe you're just shitting on Microsoft for your own reasons. Regardless of whatever your experiences have been with .NET in the past, they don't mirror the majority of the folks that use it everyday.

.Net Core is universal platform. Our API servers run .Net Core exe’s on Ubuntu behind NGINX. Full AWS stack, some Google Cloud and Mongo Cloud services internally. I don’t think we even have an Azure account.

Still a lot of Windows baggage with C#. It's changing, but I think most c# devs are still learning fundamental unix and docker stuff. So you'll get an overhead with C# too, just not in technical performance.

Source? As a .NET developer I can tell you that there are plenty of us with Linux/Docker experience. There is zero Windows baggage with C# in .NET (Core). Your information is out of date.

Projects making use of Sitecore, Dynamics, SharePoint, SQL Server CLR,... GUI frameworks out of Redmond

Graphical tooling to deal with process dumps, etw data, and profiler information only available on VS.

> Projects making use of Sitecore, Dynamics, SharePoint, SQL Server CLR,

What projects? None of those are forced on you or have any references to them built into .NET Core. I've been building .NET apps since 1.0 reached beta (in 2001?) I can count on one hand how many times in total that I've worked with those systems. This argument is a hell of a reach.

> GUI frameworks out of Redmond The upcoming Microsoft MAUI is cross-platform (no, Microsoft isn't building support for Linux, but there are open source efforts working on it.)

You can use https://avaloniaui.net or https://platform.uno

> Graphical tooling to deal with process dumps, etw data, and profiler information only available on VS.

https://www.hanselman.com/blog/dotnettrace-for-net-core-trac...

There's also https://github.com/SachiraChin/dotnet-monitor-ui

You can use JetBrains rider to profile in Linux/MacOS as well: https://www.jetbrains.com/help/rider/Profiling_Applications....

If you don't want to use .NET, you obviously don't have to.

I work for a C# shop. However maybe the signal is ex-Microsoft rather than C# itself, when I think about it more. We have lots of ex-MSFT.

Switched from a career of a windows/.net/c# to a max/ruby/js shop. Docker skills transferred. Had to learn Unix commands but it didn’t feel much different from cmd/powershell

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.

Prove Productivity scientifically.

We gonna double-blind developers or something? I know Go and Ruby very well. I know what it takes to write in one vs the other.

Ruby is faster to write and more concise by a long shot—certainly if we're talking back-end web services. I prefer Go to Ruby generally but it's weird that Go developers tend not to even see how much yak shaving is involved with it. Or really any downside with it.

Try writing this in Go:

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

Thanks to generics, assuming there is some stream/sequence like type

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

Yes a bit more verbose, that is the price to pay for static typing without full type inference as in the ML language family.

It blows my mind why Go didn’t have generics at launch. I suppose they just didn’t want people to be able to have abstractions like this at all?

> In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier.

https://go.googlesource.com/proposal/+/master/design/go2draf...

oh wow thanks for this. I haven't been actively using Go since around the time this was written so I've missed it

Stream.limit and Stream.select(…).limit are not the same thing :)

records.collect({case u if u.isAdmin => s”${u.id} ${u.name}”}).take(10) guess the language

Well you can argue semantics, it doesn't change the fact that it is possible to implement the same concepts in Go with generics.

That line of code could be Scala, or something else.

In any case, the point is that there are compiled languages that offer similar productivity like Ruby, with AOT/JIT compilers out of the box, and great IDE experiences.

It is Scala. I meant to demo type inference and pattern matching. I know pattern matching(something I cant live without) does not exist in Go and Ts, not sure how well type inference works in Go

I may be wrong, but aren't you doing two loops by doing it that way? One for the select, and another for the map? Or does ruby compile out the select loop with smarts.

In Go, the intuitive way would be one loop with an if inside it. So it would be easy to spot this performance issue if you did it the ruby way with two loops.

https://go.dev/play/p/ixDKuosxPNp

I bet I wrote my for loop as quickly as you wrote your map. The character count isn't that much higher.

The amount of times in my career where the performance would be even measurable between these 2 styles is vanishingly few. If I cared I could just use #filter_map or a classic for-each loop. If we're assuming the project is written in Ruby in the first place, clearly we're not valuing performance that highly.

The more important thing is the ruby version is chainable and more readable—and that matters far more often.

You had me until

> more readable

Without having more context, User in your code is possibly an ActiveRecord class, so to read the #select, you have to consider that it could be radically different and heavier than Enumerable#select (eg. it may execute a DB query as a side effect). So I like your example still, because it’s representative, and certainly expressive, but not readable per se. IMO this sin here is simply that ActiveRecord shouldn’t have overloaded select.

That’s more of an argument against ORMs which I realize my example used. I was mostly trying to convey using map/filter against POROs though.

Using an ORM was a poor choice on my part. I agree the magic there does harm readability since it makes it a lot harder to understand what it really is doing.

Ruby has had lazy iteration[1] for quite a while but as n here is only 10 there's really not much to loose in not using it.

In fact given that only a subset of users will be admin users for the second loop n is going to < 10 anyway.

I believe it was Rob Pike that actually said something along the lines of not bothering to optimise until you know that n is large[2].

1. https://ruby-doc.org/core-2.5.0/Enumerator/Lazy.html

2. https://users.ece.utexas.edu/~adnan/pike.html

Not sure about Ruby, but Java’s streams would do one loop only here, as they are lazy. Also, both solutions are O(n), so unless this is the hot loop of your program, or it iterates over some insane amount of entities, it is a completely meaningless microoptimization.

Why?

Because it underpins the argument above.

If Ruby is "so productive", that's a quantifiable measurement, no?

Shopify was founded in 2006 and I'm sure (having never worked there) there are things in their codebase that are that old.

What were the options in 2006 for languages with both a fast runtime and reasonable DX? I honestly can't think of any. Ruby at the time was pretty far ahead on DX for mainstream and up and coming languages. It was known to be slow but DX for Java was really not great and mired in "enterprise" features and mindset.

Edit: python was of course around and I don't remember the Django timeline well enough to say if it was viable in 2006 or not. PHP was of course around but again there was a mindset issue at the time.

cough common lisp cough

Sure. Not exactly mainstream so one would need to consider the hiring pipeline, but if it serves as a competitive advantage then sure.

You definitely don't need to consider a hiring pipeline with Common Lisp. 1-2 people are enough to write and maintain it.

But if you prefer 500 devs instead you should consider ruby, python or PHP. Middle managers are getting high on these numbers.

Honestly, that’s just bullshit. Every language is more productive with fewer developers since communication does have an inherent cost. But there is no Silver bullets as per the famous article, no language provides not even 2fold increase in productivity over another managed one, let alone an order.

while I agree a 500 fold increase is a bit of exaggeration, There is some merit to the argument.

more expressive languages including common lisp certainly give more power for an experienced engineer to outperform someone fresh out of univeristy. enough to say that I'd rather have 2-3 senior engineers experienced with common lisp or clojure or haskell over 10-15 juniors working on go or python.

and what if you gave them the same expressive language? I'd argue that its even more dangerous. Common lisp is a powerful language but its easy to code yorself into a corner if you don't have the experience to properly use it. it;d be easy to build overcomplicated systems that are brittle. go is in fact better for them because it limits the damage they can cause.

it was used to write viaweb back in the 90's. The original saas that made Ycombinator possible.

Ok but that still doesn't make it mainstream or have a candidate pool. If those things don't matter then anything goes.

An underrated feature of obscure languages is that they alienate people who think “$tool developer” is a an identity.

Where would the community, mindshare, and hiring pool be? Or would you have to innovate on how you come up with that (on top of your core product) to accomplish anything there?

community is small but extremely dedicated.

I agree that the hiring pool is small but if you want go level performance, metaprogramming and developer productivity, common lisp was your best option.

Shopify went with ruby. not a terrible language but it did come at teh cost of performance.

A better question to ask is, why are these "slow" languages winning? If performance is as important as we think it is, why don't we see startups using Rust or whatever just running circles around startups using Ruby?

The answer to this will lead to what actually matters in a language, in terms of building a product. Raw performance isn't it.

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.

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.

Ruby/Rails optimizes for developer productivity. Once you prove yourself as a company and your product reaches a scale where you cant just throw $$$ at the problem, you’d be in a good spot to then hire folks to start rewriting parts in $languageofchoice.

40 years ago those newly hires would have only learned BASIC.

Except at least BASIC had compilers available, and Darthmound BASIC was originally designed with what we call JIT nowadays, even if that wasn't a thing on 8 bit home computers.

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.

I think Lua is catching a stray here. For most uses, Lua, even the PUC-Rio/vanilla implementation, is pretty fast. LuaJIT is quite fast. And because Lua is an embedded language authors can defer to C or whatever the host language is for bottlenecks requiring more speed. IDK if people are seeking dynamic types specifically, but it sure is nice to have stuff like memory management + easy string manipulation built-in sometimes.

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.

I have no idea what you're alluding to. Not only are many people on LuaJIT's api version anyway, I don't remember ever running into any meaningful stdlib change that wasn't easily fixed. And Lua not having OO isn't really a problem to most people either.

Yeah it’s an interesting point. Wrt Python, I’ve tried writing ML in many different languages for this exact reason, but at the end of the day community is everything.

Pythons community in the ML space is pretty incredible. Trying to recreate all the libraries in another language is no small task, then you also have the issue that Data Scientists don’t want to write in complex languages.

In events like this, improving the language can start to look like the best option.

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.

Because management want's to "get things done" and quickly "evaluate ideas", a dynamic and somewhat loose language is actually an advantage in prototyping. Also it is very easy to find new developers than for example if you'd use rust, because you can just hire any frontend dev.

tooling can be built with money and money is usually not the issue for these companies.

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.

SELF was really fast, at least as claimed [0] - about half the speed of optimized C and quicker to compile. It was where the HotSpot tech for the JVM came from, and V8 uses a similar object model and thus techniques. Just wish they could have made it usable!

[0] https://bibliography.selflanguage.org/practical.html

afaict Self and Dylan were research projects / product development projects.

Smalltalk had multiple commercial implementations and was used to build mission critical software in banks and utility companies and manufacturing companies and…

https://www.davethomas.net/papers/ubiquitous1995.pdf

Apple sold Dylan to Harlequin, which sold it as a DylanWorks for some time.

Smalltalk still has commercial implementations, like Cincom.

https://www.cincomsmalltalk.com/main/

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.

Isn’t twitter running on Scala with Graal nowadays?

Yours is a fair question. Theories: * Cheaper to invest in your tools than overhauling your people/codebases/etc * Sense of wanting to give back to your core tooling * The decision maker(s) for the investment just really love Ruby?

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.

Because you already have a $50B business that runs on the slow thing. So from a risk and cost/benefit analysis making the slow thing fast sounds a lot better than "rewrite everything".

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

Ruby is a helluva lot of fun and a lot of engineers at Shopify like it. Life isn't just about taking the shortest route sometimes.

One of my favorite quotes

> I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don't feel as if the key to successful computing is only in your hands. What's in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more. Alan J. Perlis

Time-to-market with a viable product is extremely important. In the case of Rails in particular, the developer experience is such that even a very green programmer (for example, an entrepreneur who has taken a class or two) can bootstrap a working proof of concept quickly. That alone can be worth whatever drawbacks the language "speed" is, and is partly why Rails (and python stacks) were and continue to be popular.

Also, language speed alone isn't a deciding factor if your bottlenecks are elsewhere: network latency, i/o etc.

Having a "fast" language, for many projects, is something you worry about only after achieve some kind of success, and that success is made more achievable by having good developer tools.

The thing is, interpreted languages have a natural advantage vs. more performant, compiled ones when it comes to iteration speed (and also often ease of early deployment). I think the reason we see this is that while it would be great to pick a more performant language at the beginning, it may mean that your iteration speed is too slow and you simply don't survive as a company (run out of funding, can't pivot fast enough, etc.) In my mind, it's actually a very reasonable choice to start with what you think will be the most optimized for early developer productivity. Once you get to be a company worth tens of billions, you can just pay people to solve this problem for you.

What does fast "natural implementations" mean? Runtime? Compile-time? Because if one sacrifices the latter for the former, I think that skirts over the main benefit.

With dynamic, interpreted languages that have effectively zero compile-time, one can achieve significantly tighter iteration cycles across a team, ending up limited more by test suite runtime than by slow edit/recompile cycles. This leads to higher productivity across an engineering organization with a quickly evolving codebase. Not important for all use cases, but pretty critical for many.

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

This is why we have C bindings. Let performance things be performant and readable things be readable.

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

You don't need to stay in C. You can pop through to Rust or Golang or what have you.

Why do you put a high level managed language into the same category as one with a runtime and a GC? Like, why would you want 2 runtimes at the same time? Makes 0 sense.

Which of those do you think is a high level managed language with a runtime aside from Ruby?

Both of those are comparable to C and compiled. Rust is a bit lower level, Golang a bit closer to C++.

C and Rust is obviously a low level language, as well as C++.

Go is the odd one in the list, you might as well say that one should write an external function in Java and call that from Ruby (which would be fair if Ruby would already run on the JVM, e.g. in case of TruffleRuby).

Go has nothing at all to do with C++, C++ is a low level language, and an expressive one at that. Go is neither of those, it is managed and not good at expressiveness (by design).

FYI Ruby does already run on the JVM since 2001 via JRuby.

There's no need to wait for TruffleRuby (unless you want to).

https://www.jruby.org/

Yeah, I’m aware, it was more just a tongue-in-cheek comment.

Golang is a perfectly fine choice here for performance sensitive code in place of C when paired with a less performant language like Python.

Then add JS, C#, Java, Haskell etc to the list as well, they all perform roughly in the same ballpark.

Which begs the point why use Ruby at all, plenty of AOT/JIT languages with great IDE tooling to chose from.

You think Shopify should've written their backend in Rust? I really wonder if people saying this have ever used Rust.

Ruby is great for developers of all skill to learn and be productive.

Rust is fast as the devil but you have to be a damn good coder to learn it. Even then I doubt you can be as productive managing memory all the damn time. It's a low-level language great at low-level things.

Ruby is a great option for Shopify. Rust is a great option for Firefox's Servo (though that project failed so maybe not).

Where does "Plenty of AOT/JIT languages" imply Rust?

reading my comment from yesterday I don't know what I was thinking, apologies

cost of improving the language vs cost of hiring new people in different language, keep things stagnating for 10 years while rewrite is in progress, having to deal with talent exodus etc.

Also, if they want a faster Ruby why not invest in Crystal? https://crystal-lang.org/

walmart and a few others did this with node back in the 0.10 days, except iirc it was them that was holding up node at that version. iirc when iojs forked off, they had a much faster release schedule, and then at some point rejoined the main node project which then proceeded at a much faster rate.

Was it also nike and paypal? I remember it being walmart and some others that were big champions of node in the beginning.

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

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

yeah sorry about that, thats just off the top of my head. it was a wild time for me, so the events happening at the time coincided with me reading about the whole debacle live as iojs was happening.

I mean for Lua we at least have LuaJIT which is pretty fast.

But Ruby?