My thoughts:<p>- RBS: meh... might get more useful in the future (in 2-5 years maybe).<p>- Ractor: Wohooo! I'm writing a DAG library where I was thinking of implementing something like this, good to know I can use it and get real parallelism on top.<p>- Scheduler: :shrug: don't know about this one, might be relevant with future concurrent ruby code, any ideas?<p>- Rightward assignment: it's a bit awkward but I see the use case, just wish we had the pipe operator too like in Elixir.<p>- Endless method: this one is cute, I love it!<p>- Find pattern: oh boy, code reviews are going to be interesting now!<p>- Hash#except: yes, definitely a welcome one.<p>- Memory view: if this helps with numpy style gems it will be great!<p>- `send(:"do_#{ meth }", ...)`: don't do meth kids! (it's a joke!)... seems like a reasonable feature.<p>- `order of backtrace had been reversed`: good! it was confusing...<p>- Promote default gems to bundled gems (rexml): I like this one, if only nokogiri was a stdlib gem or part of core, imagine how much time would be saved instead of having to compile it every time in a `bundle install`.<p>- `Promote stdlib to default gems`: what does this mean? Do I now have to add `gem "securerandom"` to Gemfiles instead of having it by default and just needing to require it?<p>- Mjit improvements: can't wait to try it!<p>Overall, I'm delighted!
>Rightward assignment statement is added.
>fib(10) => x<p>This is exactly the kind of stuff I hated when I had to work with ruby in my last gig and why I will never accept a job using it again - soo many pointless and inconsistent ways to do the same thing ... they have method aliases for collection operations like map/filter in standard library ! .NET went with non-standard SQL-like names (select/where) and I'm not a fan but at least they made their choice and stuck with it. And it's inconsistent all over the place - like '!' postfix means "operation mutates the object" in std lib BUT in rails it means the operation will raise an exception and not return an error code.<p>Now they add a pointless operator that means completely different thing in other languages to throw off even more people.<p>It's just a hell of a language to maintain someone else's code in.
If you interested in seeing how the 3x3 initiative* has come along, here are the benchmarks so far: <a href="https://github.com/mame/optcarrot#readme" rel="nofollow">https://github.com/mame/optcarrot#readme</a><p>Personally, I am very excited for this release.<p>* Matz's goal to get Ruby 3 to be 3x faster than Ruby 2.<p>--<p>@sosodev Thanks for the updated info!
This is all great stuff. I’m rather meh on RBS, mainly because separating types from code is less than ideal but I like the potential here.<p>But the right hand assignment operator. What on earth. Nobody asked for that and nobody wants it. Why.
I have mixed feelings.<p>I'm not a fan of rightward assignment because I don't see much value and now the => operator has even more meanings.<p>I'm not a fan of endless methods because how lazy do you have to be to not want to type 'end'? My editor does it for me automatically. Now there is even more parsing.
You can test your heroku app on the new ruby 3 preview already! (<a href="https://devcenter.heroku.com/changelog-items/1889" rel="nofollow">https://devcenter.heroku.com/changelog-items/1889</a>)
Reactor model. Nice. Very nice. So real ruby multithreading at last.<p>Okay time to upgrade to latest rails and wait for the multithreaded rails release. :P
Question: will the nonblocking scheduler start to make Ruby concurrency competitive with e.g. Node.js and Go? Currently Ruby mostly uses heavyweight threading mechanisms that cause trouble for I/O-bound microservices.
It feels like RBS is for library writers, so that they can ship type information to help the <i>consumers</i> of their library. It’s not really aimed at the consumers themselves — the long tail of casual Ruby hackers like me.<p>If RBS was for end users, adding types inline with the source code would make more sense compared to the RBS approach: keeping the source file and typedef file in sync.<p>That might actually be a pretty smart move. At first it seemed inconvenient to have to maintain a separate file for the type information, but maybe this focus on type-checking being made easy for the 90% of us who hack scripts is a much smarter one.
I wish I had kept maintaining my port of Ruby to the IBM BLue Gene/L, "Blue Ruby". It scaled to millions of cores with MPI. Had distributed versions of familiar Ruby data types. There was no fork() - restriction of the BGL kernel not supporting it - only green threads - making parallel operations truly parallel with independent Ruby VMs and passing code to data instead of data to code.
Does message passing mean it copies objects you send between threads / fibers, rather than sharing memory?<p>JavaScript has a similar pattern with Workers, and it makes concurrency for hot code impractical. Serializing/deserializing objects is a lot slower than just not doing that. In JavaScript’s case, you can also use SharedArrayBuffer, but Safari hasn’t re-enabled it.
It looks like the link they provide for comparing the source of 3.0 and 2.7 is busted on Github, but you can get a sense for the scope of this on GitClear's Open Repos <a href="https://www.gitclear.com/open_repos/ruby/ruby/releases" rel="nofollow">https://www.gitclear.com/open_repos/ruby/ruby/releases</a>. Looks like about 4x more repo evolution has gone into this version than previous.<p>See also: list of the biggest tickets tackled in 3.0: <a href="https://www.gitclear.com/open_repos/ruby/ruby/release/pending_release" rel="nofollow">https://www.gitclear.com/open_repos/ruby/ruby/release/pendin...</a>
the link to the NEWS file is broken, it should be this<p><a href="https://github.com/ruby/ruby/blob/v3_0_0_preview1/NEWS.md" rel="nofollow">https://github.com/ruby/ruby/blob/v3_0_0_preview1/NEWS.md</a>
There were times where I would not be able to sleep when such a release was done :). It isn't as much lately, but still, fantastic work by fantastic team. Congratulations!<p>There are some seriously good stuff there.
Happy to see developments on the pattern matching feature[0].<p>[0] <a href="https://bugs.ruby-lang.org/issues/16828" rel="nofollow">https://bugs.ruby-lang.org/issues/16828</a>
Didn’t see it linked in the preview announcement, here’s the RBS syntax guide: <a href="https://github.com/ruby/rbs/blob/master/docs/syntax.md" rel="nofollow">https://github.com/ruby/rbs/blob/master/docs/syntax.md</a><p>Glanced at it from my phone but it looks good! I’m looking forward to seeing it in RubyMine. Still sad that we can’t write these in .rb files but I wonder if the plan is to go the other way, eventually permit typed code in .rbs?<p>Does anyone know what the story will be with third-party definitions? Are we headed towards a DefinitelyTyped style repository for Ruby?
Am I alone in saying; for some damn reason, I don't like Ruby.. I appreciate what it can do, and indeed what it does.. I just feel like I slipped in between that moment to appreciate it more. I will go and spend some time to learn it more but out of a novelty aspect.. And that makes me feel bad.
Not a Rubyist. Would Ractor allow one process to use up all CPUs while avoiding copying objects? Can I build shareable objects with immutable lists and maps right now?
So now there are basically no dynamically typed languages left. There's Scheme, JavaScript, what else? All languages nowadays are converging to TypeScript/Rust. It's kind of sad.
I left Ruby because the performance and security weren't improving and the community was slowly dying. I delved into Go before that got flooded with newbs, then looked at Crystal and Pony, before settling on Rust and Haskell for most things.
Much as I would love to believe Ruby 3.0 delivers some kind of speed bump my simple test of doing what Ruby supposedly does best - parsing a log file with a regex - shows Ruby 16% slower than the Python equivalent.<p><pre><code> Ruby
puts IO.foreach('logs1.txt').grep /\b\w{15}\b/
Python
from re import compile
with open('logs1.txt', 'r') as fh:
regex = compile(r'\b\w{15}\b')
for line in fh:
if regex.search(line): print(line, end='')
</code></pre>
On my MacBook Pro (2013) running Catalina Ruby averaged 1.49 secs and Python 1.27 secs. The file `logs1.txt` is a 20Mb Apache log file. Pre-compilation with:<p><pre><code> reg = Regex.compile /\b\w{15}\b/
puts IO.foreach('logs1.txt').grep reg
</code></pre>
... slowed Ruby down to 1.57 secs.<p>Using --jit didn't change Ruby's overall time but considering it adds 700ms to Ruby's startup time execution time was faster.