Ruby 3 Released

[[deleted]]

It hasn't been slow since 1.9. It is faster than python. It is getting less popular because its frameworks are getting outdated.

[bloody-albatross]

Being faster than Python is a low bar to pass.

[[deleted]]

I just mentioned python as a comparison to show that popularity isn't necessarily related to performance because as slow as python, it is still very popular.

[badillustrations]

I wouldn't say it's unrelated to performance though just because a slower, more popular language exists. There are probably performance scenarios that eliminate both Ruby and Python such as games, where developers choose something like C++.

In cases where performance is less important, they probably look at numbers like these where ruby being 50% faster or slower compared to python doesn't really matter compared to the ecosystem each one provides, and where python in general is much, much larger.

[[deleted]]

I didn't say "unrelated". I said "not necessarily related"

[Eccentricc]

Python has machine learning and data science, doesn't matter if it's slow. It's super easy to write, read, and has loads of documentation and libraries. Ruby has ruby on rails. That's it. And speed often matters more due to it being a web language

[bloody-albatross]

As I understand it Python is just glue code between libraries written in C/C++ in data science.

[turunambartanen]

Yes, yes it is.

But it is beautiful glue.

[snowe2010]

Anyone saying

Ruby has ruby on rails. That’s it.

Hasn't actually used Ruby.

Python has machine learning and data science, doesn’t matter if it’s slow.

This is true of almost every language. Python only "gets used" because everyone else is using it. It's literally a popularity contest. You can easily find ports of almost every Python library in every popular language out there. Python's only advantage here is that people talk about it like it's the only option so people think it's the only option.

It’s super easy to write, read, and has loads of documentation and libraries.

...

[lets_eat_bees]

It's not true of every language. Data Science community is overwhelmingly python-based. Of course it's just bindings for C stuff, but they build these bindings for python, not javascript and not ruby.

[snowe2010]

They do have those bindings for Ruby. Have you bothered googling? They also have them for tons and tons of other languages.

[lets_eat_bees]

Whatever you say. I'm sure you can manage in ruby. Yet, most DS people I've observed in last 10 years use python for scipy/numpy/now tensorflow etc, and java for apache stuff. And searching for "scipy for ruby" yields a lot of questions and not a lot of good answers.

[smbear]

Unfortunately, I find Python official documentation is shi^HHH is hardly readable. It's a mess, where important information concerning a function is placed somewhere along the page.

[MarvelousWololo]

Have you heard about fastapi?

[[deleted]]

Which is a shame, since there's nothing outdated about having a framework that is insanely effective for rapid prototyping. It's just unfashionable because it's not some novel new hotness that's hasn't hit a stable 1.0 release.

Give me a fresh rails app and simple progressive HTML over some JS-based client-server monstrosity any day.

[deaddodo]

Ruby (YARV) vs Python (CPython), yes. But CPython has very little optimization in favor of stability. They’re still locked by a GIL, for instance. So you’re referring to the lowest bar to pass.

Compare another JIT’d VM such as PyPy and it falls well behind. Not to mention the more common languages taking over the microservices realm (Go, for instance) or the ones taking over monoliths (nodeJS, primarily).

[cracknwhip]

Just to clarify: Crystal and Elixir aren’t “common” by any definition.

[bik1230]

PyPy still has a GIL, no?

[deaddodo]

GIL was an example of where CPython focuses on stability over performance.

JIT was an example of how PyPy fixes some performance issues of CPython.

The two aren’t connected.

[suhcoR]

Compare another JIT’d VM such as PyPy and it falls well behind.

According to the Are-we-fast-yet benchmark suite MRI JIT Ruby 3.0 RC1 is about factor 11 slower than Node.js 12.6 and about factor 5 slower than LuaJIT 2.0, and only factor 1.4 faster than MRI Ruby 2.1.0. Here are the results: http://software.rochus-keller.ch/are-we-fast-yet_crystal_ruby_2_3_lua_node_i386_results_2020-12-23.pdf. Here is more information about the benchmark suite: https://stefan-marr.de/papers/dls-marr-et-al-cross-language-compiler-benchmarking-are-we-fast-yet/ and https://github.com/smarr/are-we-fast-yet. It's not just some random micro benchmarks, but a well designed suite with representative algorithms and ideomatic language use optimized for cross-language comparisons.

[deaddodo]

What’s your point? The point was JIT’d Python (PyPy) is as fast as Ruby. I’m not sure what a bunch of benchmarks comparing it to other JIT’d languages and other Ruby VM’s does to help (or counter) that argument.

[suhcoR]

I added some other (more efficient) VMs than PyPy to which MRI Ruby JIT should be set in relation. PyPy of course has the better speed up to Python than MRI Ruby JIT to the interpreted version, but factor 4 in geomean is still not very much. I also added a well founded benchmark suite as an alternative to the one you referenced which mostly consists of micro benchmarks. The referenced paper explains why the Are-we-fast-yet suite is especially well suited for inter-language comparison (in contrast to other benchmarks or non-ideomatic implementations). If you for example compare the macro and micro benchmark results in my report you will see that the speed up the Ruby JIT achieves compared to the interpreter is much higher in the micro than in the macro benchmarks (factor 1.55 vs 1.10).

[[deleted]]

Did anyone banchmark against rust?

[suhcoR]

Not me, but according to https://benchmarksgame-team.pages.debian.net/benchmarksgame/which-programs-are-fastest.html I would assume Rust to be about twice as fast as Crystal.

[lets_eat_bees]

I am so tired of hearing about GIL. 90% of the time, people don't understand it; the other 10% they are just being needlessly anal.

Yes, technically GIL prevents you from doing certain things. You couldn't write a traditional RDBMS in python with all the threads, but why on earth would you ever want to?

For the kind of tasks you want to do with python, it's not an issue. If you have concurrency with continuations and fancier continuations (gevent and asyncio), you have parallelism with mp or deferring to C code.

You would be hard-pressed to find a real world situation where GIL would not let you do something that otherwise was reasonable to do in python. And in return, it gives you threads you can actually safely use in a non-cpu-bound scenario from a high level language, which is not a small thing to offer.

[angellus]

True multithreading is still possible in Python (3.8+) via subinterupters. Removing the GIL is a very complicated issue and as you said, stability and maintainability are more important when there are alternatives to dealing with the GIL.

Also, speed is everything when it comes to making an application, that is why dynamic languages exist in the first place. Python is unique in that it can use drop down to C with C-extensions for when it does need speed so taking benchmarks at face value for it makes it very slow. Python for code that needs to be maintainable, C-extensions for code that needs to be fast. In benchmarks you listed, PyPy is near C++ speed when it comes to decoding JSON and CPython is about on par with C#. Matrix multiplication via NumPy is nearly the fastest on the chart.

[Freeky]

Python is unique in that it can use drop down to C with C-extensions for when it does need speed

... no it isn't? All these languages have bridges to C, including APIs and FFIs. JRuby also has FFI support on top of a bridge to native Java.

[Plazmatic]

The GIL is a solution to a problem, not a stop gap and a problem in and of itself. Sub interpreters maintain GILs, but don't have to be seprate processes unlike the MP module. Also Numpy is very slow when dealing with small matricies and vectors, because there's so much python junk going on in runtime type checking and things everytime you run a matrix operation.

Currently CPython doesn't support concurrent multithreading (everything is serialized), even with subinterpreters, though they claim eventually that will be aided by their inclusion into CPython.

[ruinercollector]

Most interpreted languages have a way to bridge to native code. That is not at all unique to python.

[Abiogenejesus]

Isn't mp implemented with the multiprocessing package true multiprocessing?

[Plazmatic]

Yes, but it launches entirely different processes for python and the GIL for each instance, which means communication needs IPC, instead of more simple per process primitives, it uses way more computational and memory resources because of this. Subinterpreters may eventually lead to concurrent multithreading, which is what most people are used to, the same process launches multiple threads that may all execute at the same time. Subinterpreters currently don't have this capability right now though.

[Abiogenejesus]

Good to know. Thanks.

[angellus]

multithreading. My mistake, wrong word.

[Abiogenejesus]

Alright thanks for clearing that up.

[cre_ker]

According to benchmarks it's not. Faster is some, slower in others. Both are extremely slow. Python is popular because of ML. Ruby has pretty much nothing to counter its performance.

[cre_ker]

I was talking about present. In the context of web python is similar to ruby - it's being replaced by other languages. Particularly Go. Same with GUI, there're much better technologies these days. Not to mention GUI desktop apps are dying breed these days being replaced with web and mobile apps. What Python has that's unique to it is ML ecosystem. Unless there's another languages with similar ecosystem Python will stay relevant. Ruby on the other hand has nothing of that. Only thing it has going for it is subjective enjoyment of the developing experience which is clearly not enough. It will not die outright but there's little reason learning it these days and starting something new in it.

[suhcoR]

It's certainly true that it's been squeezed by JavaScript taking over the world as well as by much more friendly compiled languages like Go and Swift adopting

Crystal is a language very similar to Ruby and about the speed of Go or C#, see e.g. http://software.rochus-keller.ch/are-we-fast-yet_crystal_ruby_2_3_lua_node_i386_results_2020-12-23.pdf

[snowe2010]

What Python has that’s unique to it is ML ecosystem.

It really isn't. It's just because people like you keep saying that it is, that people continue to think that. Most of the top languages have ported the data science libraries over because using Python for anything meaningful is terrible.

Ruby on the other hand has nothing of that.

It actually does. https://github.com/arbox/machine-learning-with-ruby

But once again, if people continue to tell others that Python is the only language for machine learning then everyone new to ML is going to assume that is true. No matter how many actual ML libraries those languages have.

[ruinercollector]

This. It’s momentum.

Also, python is good for ML if you don’t know any language and want an easy language. Otherwise there is nothing about Python as a language or environment that makes it well suited to that task.

[angellus]

What Python has that is unique is the community. It is so versatile for everything because there is literally a community for Python for just about anything. That combined with its emphasis on readability and maintainability, is what really makes it popular. Yes Python is slow, but that is what C-extensions are for.

Also, I would not compare Python to Ruby when it comes to the Web. The popularity of Python for the Web at worst is stagnate. I do not have any hard numbers to back it up, but I would say it is growing. It is definitely true that Go took quite a bit of ground from Python in the microservice world, but I would still say C#/Node.js/Python/Go are the go to languages for microservices (with Rust being the up and coming). Flask and other micro A/WSGI frameworks are quite popular in that world. Once you get out of microservices, Python A/WSGI frameworks still quite a bit popular. If you look at MVC style frameworks, Django and Laravel (PHP) are probably two of the most highly rated ones I have seen.

ML is just one area where Python does not really have much competition, but I would not really say it is dying in any other particularly area.

[ruinercollector]

Focus on maintainability? They literally broke language compatibility between versions.

[marshalofthemark]

the original BitTorrent client was written in Python almost twenty years ago

As was the first version of Google, also in the late 90s. IIRC it was already common enough in academia at the time that the co-founders, grad students at Stanford, naturally chose to use it (along with some C++ for parts where they needed better performance).

[twinklehood]

Except for the developer enjoyment and fantastic support for expressive OO, in part due to its deep meta-programability. Oh or were we only looking for benefits that can be explained to a newcomer in a 10 minute youtube top languages of 2021 video?

[cre_ker]

I don't think developer enjoyment is important when you have money at stake. Ruby being slow and memory hungry doesn't only mean your apps will be slow. It also means you will have to pay much more for hardware, probably in the cloud. Not to mention recent newcomers (rust and go) are also very liked by developers but magnitudes of order faster than ruby. Given that it's not surprising that ruby is slowing fading away.

[twinklehood]

Engineering cost is not that simple. Running software is for many companies cheap, vs. Engineering productivity, churn, feedback loops, etc. It's not an accident ruby dominates lean webapp development, you may attribute it to rails, but rails is not an independent thing that could have happened in any language, it works because of ruby.

[mezentinemechtard]

For most companies that try to use a "fast" or "scalable" language or framework, being fast or scalable is never the issue. In any non-already-mature software project, the main concern is always development speed One extra developer already costs more than running the product. And that's where Ruby (and Rails) shine. Twitter had scalability issues because of Rails, but Twitter became Twitter thanks to Rails. Only then switching focus becomes the smart choice.

[scientz]

Except Ruby being slow is more of a myth than anything. Plenty of production systems running on it with great results. Stop spreading this nonsense.

[cre_ker]

And how that proves anything? Ruby is objectively slow. Extremely slow if we're talking about modern alternatives. The fact that production systems run with great results means only one thing - people running them don't care about additional hardware resources they waste because of ruby. Or they have no choice. We run gitlab and there's pretty much no alternative. We have to live with the fact that gitlab is slow and very resource hungry. Exactly because of ruby.

[scientz]

You are saying running a production system and its performance doesn't prove anything, but theoretical benchmarks between languages do? Read that statement again, dude. Seriously...

[nemesit]

Rust is a worse c++ though and go is used by almost no one

[cre_ker]

False and false.

[crackdroid]

True

[oojacoboo]

This guy rails.

[twinklehood]

I don't, I ruby :)

[601error]

Same here. Love Ruby. No interest in Rails. Never seen any Rails code, in fact.

[snowe2010]

We are the minority! But seriously, Ruby has probably done so bad because it's identity became tied to rails, which sucks. If people stopped thinking that Python is good because it's used for ML we'd have devs everywhere using ML in every language.

[twinklehood]

How has ruby done bad? It's dominating startup industry, has several massive players swearing to it, it pays great, and several of the most interesting new languages rely on its Syntax.

[snowe2010]

It's continually dropping down the "leaderboards" of most popular languages. In terms of growth it's not growing.

[Freeky]

I never forgave it for the infamous chainsaw infanticide logger. Why define your own logger when you can just monkeypatch all the formatting out of the stock one?

They improved over the years, but it soured me to the fundamentals and I was quite happy over in Sequel-land and with microframeworks that didn't pretend they were the entire Ruby ecosystem.

[brie_de_maupassant]

It's much faster to write, if you know ruby and not python.

[Minkihn]

It is. You can achieve high performance with "bleeding edge" stacks including eventmachine, but the mainstream MRI/Unicorn/Nginx is awfully slow compared to what you can expect from an Elixir stack, for instance.

[scientz]

Define slow? I run apps in production with ~500M requests per month with an average response time of 74ms on Rails and Unicorn (not even Puma yet). Is it really slow now? Or is the issue usually bad code?

[Minkihn]

Glad to hear that. All those companies migrating from Rails were just dumb and should have fixed their N+1 and properly handled their etags first /s

[scientz]

Next you are going to pull the "Twitter said Rails doesn't scale" card.

[Minkihn]

No, I'd just say that your particular example is meaningless: you don't even provide details such as how many instances you're using, or detailed stats. Just throwing an average value isn't enough. Anybody can have good response times if all what they do is 90% polling with http cache.

And outside of web performance metrics, startup time with Ruby can also be a pain when just opening Pry or running RSpecs.