It is 4.0.0 largely because matz created ruby 30 years ago.
matz is no longer the youngest - although he does look young,
he is already 60 years old. He also said he has a retirement
plan, e. g. avoiding a situation such as when Guido quit (or
semi-quit) from Python (due to fatigue/frustration; Guido is not 100% retired but he is also not necessarily the solo-design-dev either, so it is a bit of a semi-retirement). So we won't know how long matz will be the lead designer of ruby - and who will succeed. Which may be reason to worry depending on who it would be. Imagine DHH takes over - man, there would be an insta-exodus of people ...
So while this release does not have a lot of content as such,
one thing that is quite big, even though right now it is not,
is Ruby::Box. There are many who don't understand it. The thing
is ... I understand the use cases for it. I was not involved in
any way with regards to its design, mind you - that was mostly a
japanese-group in design. But there are objective use cases for
it.
Many years ago I recall on IRC (we oldschool people used IRC back
in the pre-discord stone age) some C# hacker said he won't use ruby
because there are no strong namespaces, that is, someone else can
just overwrite things and then nothing works. Although I think he
was a drama guy, and any "danger" to be minimal, objectively he has
had a point, simply because ruby had no strong concept of isolation
here. Lateron there came refinements. Now refinements are strange,
because while I think the use case makes sense, the syntax is strange.
Syntax is one huge reason why I do not use refinements; but also because
I try to avoid putting my own modifications all over the place, largely
because I'd have to distribute that too, and also because modifying core
classes, while that has a use, should not be done excessively, IMO.
Ruby::Box kind of builds on that and makes the refinement use case more
generic (eventually; I am aware that right now this is not the case but
you need a transition stage. Syntax-wise Ruby::Box is also weird, so
hopefully the syntax gets easier too, but I instantly understood the use
cases. Many people don't, in particular about 95% who demanded a name
change away from Namespace to something else, really don't understand the
underlying use case.)
Now - making isolated per-project changes is not the only use case. For
instance, ractors could be simplified if you know that there are separate
ruby processes; ruby threads probably too. These I consider secondary
benefits though (and yes, that may be far in the future, who knows; when
python removed its GIL though, it put ruby under pressure, aka shape-up-or-go-extinct mode).
One thing I would complain a lot is that on rubygems.org, before RubyCentral went shopify-controlled-only, that people would occupy namespaces. Such as Configuration. I wanted to have a project called Configuration so I can do Configuration.new or Configuration.parse_this_file(). This is possible of course, but when it comes to distributing code, who owns that toplevel namespace? Normally the one who occupied the name first on rubygems.org, sort of. Via Ruby::Box, it should be possible to have ownerships. This could be strong or weak; weak as a hint, aka "psych is owned by ruby core ownershiper but it can be modified", or strong aka making it immutable. Both have use cases. Could also be both. Having this more organized would be really convenient for developers. I would not have to worry whether anyone else uses that "namespace". And of course we need a way to query this state from within ruby code too aka, say immutable:
"If psych is owned by ruby-core, continue to use it."
psych (for yaml) is not a good example here but you can think of any other namespace where you may only want to consider some gems/projects but not others. (Again, the use case may differ between strong and weak ownership, but the thing is that this is an improvement over the prior status quo.)
I'm tasked to amend a project written in ruby. With a python background (and some nice pydantic, type annotated, etc "strong" code bases behind my back), every day I spend with ruby is a minefield, a nightmare.
I hoped that ruby4 maybe implements stuff that python has, like type annotations or making the damn parens mandatory, but no. Not surprised that python has ten times more developers according to stackoverflow's survey... I can't possibly imagine a collaborative project where other people also have to work on the same code base, and not having any clue what a symbol under the cursor might be.
No type hints. No mandatory requires. No parens, so never know if something is a method or, callable, or variable. Basically IRB is a must for development, because in the editor, I'm blind.
And the ecosystem is just sad. Swagger-rails libraries out there are rookie jokes compared to what python has. At least there is decent GRPC / protobuf integration, so all new services I am writing can be in python. Or any sane language.
This is always my biggest complaint about Ruby. Last time I made a fuss about this on HN someone pointed out rbs-inline which might make it into the core rbhs gem itself soon! This would be huge for the Ruby community imo
From where I stand, Ruby has much more interesting work going on JIT land than Python.
Much of the Python stuff, is actually about rewriting Python tools into Rust due to its interpreter slowness and no one caring about PyPy, now apparently there is even a PEP to rewrite CPython!
14 comments
[ 1.9 ms ] story [ 36.6 ms ] threadmatz is no longer the youngest - although he does look young, he is already 60 years old. He also said he has a retirement plan, e. g. avoiding a situation such as when Guido quit (or semi-quit) from Python (due to fatigue/frustration; Guido is not 100% retired but he is also not necessarily the solo-design-dev either, so it is a bit of a semi-retirement). So we won't know how long matz will be the lead designer of ruby - and who will succeed. Which may be reason to worry depending on who it would be. Imagine DHH takes over - man, there would be an insta-exodus of people ...
So while this release does not have a lot of content as such, one thing that is quite big, even though right now it is not, is Ruby::Box. There are many who don't understand it. The thing is ... I understand the use cases for it. I was not involved in any way with regards to its design, mind you - that was mostly a japanese-group in design. But there are objective use cases for it.
Many years ago I recall on IRC (we oldschool people used IRC back in the pre-discord stone age) some C# hacker said he won't use ruby because there are no strong namespaces, that is, someone else can just overwrite things and then nothing works. Although I think he was a drama guy, and any "danger" to be minimal, objectively he has had a point, simply because ruby had no strong concept of isolation here. Lateron there came refinements. Now refinements are strange, because while I think the use case makes sense, the syntax is strange. Syntax is one huge reason why I do not use refinements; but also because I try to avoid putting my own modifications all over the place, largely because I'd have to distribute that too, and also because modifying core classes, while that has a use, should not be done excessively, IMO.
Ruby::Box kind of builds on that and makes the refinement use case more generic (eventually; I am aware that right now this is not the case but you need a transition stage. Syntax-wise Ruby::Box is also weird, so hopefully the syntax gets easier too, but I instantly understood the use cases. Many people don't, in particular about 95% who demanded a name change away from Namespace to something else, really don't understand the underlying use case.)
Now - making isolated per-project changes is not the only use case. For instance, ractors could be simplified if you know that there are separate ruby processes; ruby threads probably too. These I consider secondary benefits though (and yes, that may be far in the future, who knows; when python removed its GIL though, it put ruby under pressure, aka shape-up-or-go-extinct mode).
One thing I would complain a lot is that on rubygems.org, before RubyCentral went shopify-controlled-only, that people would occupy namespaces. Such as Configuration. I wanted to have a project called Configuration so I can do Configuration.new or Configuration.parse_this_file(). This is possible of course, but when it comes to distributing code, who owns that toplevel namespace? Normally the one who occupied the name first on rubygems.org, sort of. Via Ruby::Box, it should be possible to have ownerships. This could be strong or weak; weak as a hint, aka "psych is owned by ruby core ownershiper but it can be modified", or strong aka making it immutable. Both have use cases. Could also be both. Having this more organized would be really convenient for developers. I would not have to worry whether anyone else uses that "namespace". And of course we need a way to query this state from within ruby code too aka, say immutable:
"If psych is owned by ruby-core, continue to use it."
psych (for yaml) is not a good example here but you can think of any other namespace where you may only want to consider some gems/projects but not others. (Again, the use case may differ between strong and weak ownership, but the thing is that this is an improvement over the prior status quo.)
There are several...
I think I read somewhere that Matz is actually in favour of that but Samuel is holding off for now.
I hoped that ruby4 maybe implements stuff that python has, like type annotations or making the damn parens mandatory, but no. Not surprised that python has ten times more developers according to stackoverflow's survey... I can't possibly imagine a collaborative project where other people also have to work on the same code base, and not having any clue what a symbol under the cursor might be.
No type hints. No mandatory requires. No parens, so never know if something is a method or, callable, or variable. Basically IRB is a must for development, because in the editor, I'm blind.
And the ecosystem is just sad. Swagger-rails libraries out there are rookie jokes compared to what python has. At least there is decent GRPC / protobuf integration, so all new services I am writing can be in python. Or any sane language.
Wish we'd see more action on RBS, perhaps getting Sorbet to core or something. At least having some sort of consensus in the community.
Or even some considerable project in the JIT, dunno!
Python is definitely ahead in types, work on removing the GIL... list is huge.
This is always my biggest complaint about Ruby. Last time I made a fuss about this on HN someone pointed out rbs-inline which might make it into the core rbhs gem itself soon! This would be huge for the Ruby community imo
https://github.com/soutaro/rbs-inline
Much of the Python stuff, is actually about rewriting Python tools into Rust due to its interpreter slowness and no one caring about PyPy, now apparently there is even a PEP to rewrite CPython!
https://discuss.python.org/t/pre-pep-rust-for-cpython/104906