7 ms·

I've a hard time seeing how this could work out. Admittedly it's been some time since I did ruby but as I recall there was a shocking amount of mutability going

I've a hard time seeing how this could work out. Admittedly it's been some time since I did ruby but as I recall there was a shocking amount of mutability going on in the core language and throughout the ecosystem. Mutable lists, tables and strings everywhere, even the "constants" of ruby were mutable by default which bit me more than once. I'm just not convinced that good parallellism is something you can successfully bolt on to a language 25 years down the road. The languages I've seen do a really good job all embraced parallelism as an important problem from the start and had a strong policy of immutability by default and good persistent data structures. Such a clear commitment permeates the ecosystem and you get libraries with clear parallelism stories . Hopefully I'm wrong and this will all work out great for ruby.

deleted 6y ago
[deleted]
gameswithgo 6y ago
I don't understand bolting concurrency onto something that is interpreted. A compiler would get you 10-100x speedup, without your users having to do the complex thing of writing safe parallel code.
- jashmatthews 6y ago
  CRuby has had JIT for over 3 years now and I think JRuby must be over a decade?
  - gameswithgo 6y ago
    are those first class options now? or is it like python where you can kinda sorta sometimes use a jit?
    - jashmatthews 6y ago
      First class option in Ruby 2.6 onwards.
      - pjmlp 6y ago
        Yeah, but not that impressive in capabilities, hence other projects. https://developers.redhat.com/blog/2020/01/20/mir-a-lightweight-jit-compiler-project/ https://developers.redhat.com/blog/2020/01/20/mir-a-lightwei...
        jashmatthews 6y ago
        While MIR could be an interesting alternative to CraneLift it doesn't really address the challenges faced by trying to improve performance via JIT compilation within CRuby.
- chubot 6y ago
  Ruby can’t be compiled easily due to the very dynamic semantics of the language. If you wanted to compile it, it would probably start behaving a lot more like Crystal, which looks similar but behaves completely differently.
  - gameswithgo 6y ago
    you could aot compile most of most programs and jit the rest. or just jit everything
  - jashmatthews 6y ago
    If you're talking about just compilation then it's easy enough doing something like context-threading where you translate bytecode into a call instruction per operation to a function implementing the bytecode. If you're talking about producing a static binary then both Rubymotion and TruffleRuby can do this.
    - chubot 6y ago
      I should have clarified that I meant "compiled easily for 10-100x speedup" (on representative workloads) as the OP was saying. You can definitely compile anything... whether it's worthwhile is a totally different story. I learned this the hard way :) As far as I remember the Ruby 3x3 effort yielded 3x on SOME workloads, with tremendous effort, which is about what I would have expected due to Ruby's very dynamic semantics.
      - jashmatthews 6y ago
        TruffleRuby already has that kind of performance increase on microbenchmarks. The CRuby JIT for 3x3 built by one person in their spare time.
    - FooBarWidget 6y ago
      > If you're talking about just compilation then it's easy enough doing something like context-threading where you translate bytecode into a call instruction per operation to a function implementing the bytecode. Ruby has already been doing threaded dispatch on bytecodes since 1.9.
- ramchip 6y ago
  A lot of web services do a little bit of work, wait on a DB query, do a little bit of work, wait on DB, etc. It’s even more true with websockets, which spend most of their time idle waiting for messages. Good concurrency support lets you handle thousands (even millions) of these activities in a single process, which is massively more efficient than using a process each, and puts less load on other systems (DB, Splunk, Graphite, RabbitMQ…) Green threads in particular make it possible to get these benefits without writing the code in async style. You just write regular, blocking code and the runtime / frameworks take care of yielding to the scheduler (event loop) when appropriate.
mapgrep 6y ago
Yes, like the amount of thinking and novel work Rich Hickey out into the immutable but fast data structures in Clojure, the use of mvcc stm for transactions when you do need to share mutable state between threads - it was there from the start. I don’t even pretend to fully understand half of the things going on in Clojure concurrency on a deep level but I find it reassuring that parallelism was deeply considered from the start. And also grew with even deeper models like core.async. How many languages are there like this? A handful? Erlang, Scala, Haskell, Go.... Java has always been parallel but with pretty primitive concurrency tools, no?
- cutler 6y ago
  Don't forget Kotlin's coroutines.
- pjmlp 6y ago
  Java started with the same concurrency primitives as Ada and Modula-3. Java 5 got the concurrent package, with support for futures, chained computations, ability to create ou own schedulers, only matched by .NET dataflows. Java 8, integrated the concurrent package with parallel streams. Recent versions are being refactored so that eventually virtual threads are surfaced across all runtime, so instead of not knowing if green or red threads are being used like in the early Java days, the developers get to choose which ones to use. On .NET side, naturally it copied the Java primitives, then came TPL, Dataflow, async/await, PLINQ, F# agents, F# async/await (not the same as standard async/await, based on F# computations).Additionally there is the research done with Axum, Cω, Singularity, Midori, Immutable C#.
- julik 6y ago
  In Go pretty much everything is very much mutable. The part that distinguishes Go is exactly the M:N scheduler used for both evented IO and parallelisation of compute. For _concurrency_ (what the Ruby fiber schedulers are for) what is proposed is probably quite a good idea. We can do as much hatin' as we want on JavaScript but its concurrency story has been much more successful than Ruby's due to evented IO as well - even though everything is mutable. As far as Ractor is concerned - well, WebWorkers are kind of similar - they get a separate thread, but you can only send them "messages" which must be immutable. How the MRI team is going to tackle mutations in those messages is an interesting excercise, because Ruby is ultimately a _live runtime_ - i.e. most of the things can change at any time. Not because it is made for sloppy programming but because it is made for incremental changes to the VM like Smalltalk.
jshen 6y ago
Did you even read about the implementation details here? It appears you didn’t.
- colonwqbang 6y ago
  Please tell me how I'm wrong instead of insinuating that I didn't read the article. > It will likely take some efforts and at least a year of work from the community to push libraries towards less shared state. About one year to rewrite the ecosystem to fit this new threading model. Does that strike you as particularly realistic? Like I said, I very much wish they would succeed.
  - studius 6y ago
    They downplayed the actual amount of time that went into these changes and the upcoming changes. Here's the history: Matz[1] released the first version of Ruby in Dec 1995. DHH was a major player in getting Ruby into the global spotlight with Rails[2] in 2004. Rails got very popular as a framework for developing new applications, with Basecamp being novel, showing that it could work well and introducing people to REST, in a flexible interpretation, as well as ActiveRecord, whose ease of use and migrations became a model for modern web development. Rails v3 divided the community, specifically around how and what Rails would support for the server and request-handling. This hinted at problems to come, but Rails was still strong, and many took it with a grain of salt and upgraded. However, Twitter, which had been built on Rails became popular, and the "fail whale" emerged as they were unable to handle all of the requests. This was not a problem with scaling Rails, but with them knowing how they could scale Rails without much greater expense, but since they had to rewrite things and there was pressure to get scaling done right, they switched to Scala and Java, since Scala was functional and fast, and there was a lot of support for the JVM. Functional programming had already been making a comeback in popularity in the 2000s, because it often required a lower memory footprint and was fast. But, at that point in time, many teams and developers were looking into it. Though it wasn't the first time he'd done optimization, in 2012, Matz released mruby[1][3], an embedded Ruby. Around the same time, with functional programming having been cool, Elixir was born and some of the Rails community left for writing Ruby/Rails-ish code in Erlang. Some had been trying to slim down Rails in core, so that there would be less code needed to serve requests. Tenderlove, who came from the system programming side of things, joined the Rails core team with a focus on optimization, did work on Rack, and eventually he started working to help speed up Ruby. For years, Matz and others had focused on speeding up and slimming down Ruby. Ruby had run on Lighttpd and Ruby on Rails could run on it also. All of these things have been driving Ruby to get better, and now it is. So, no, I don't think it's realistic that they put a year into it. At least 9+ calendar years led to this point, and it's been 26+ calendar years since initial release. And this isn't the end of it. It's not trying to compete with or tank your favorite framework or language of choice, it's just been improving and its team, even as good as it already was, has been improving. P.S.- Ruby is not Rails. But not talking about how the history of Rails in the scope of things would be remiss. I can't think of anything in the history of Ruby that has been bad, but certainly Rails has had its "fun". But right now, it's coming together. I also didn't mention Sinatra's influence on slimming things down, or Puppet, Chef, etc.'s contribution to the Ruby community, or Crystal which has been a valiant effort for a compiled Ruby-like ecosystem. There is so much that happened leading to today that shaped where things are and where they are going. I'm totally psyched about this. [1]- https://en.wikipedia.org/wiki/Yukihiro_Matsumoto https://en.wikipedia.org/wiki/Yukihiro_Matsumoto [2]- https://en.wikipedia.org/wiki/Ruby_on_Rails https://en.wikipedia.org/wiki/Ruby_on_Rails [3]- https://github.com/mruby/mruby https://github.com/mruby/mruby
zelphirkalt 6y ago
As long as the language supports the primitives needed for implementing good parallelism, I do not see why it could not be done in form of a library. Of course the ecosystem would have to evolve to make use of such. However, it seems more and more language get on the bus for having concurrency libraries, that derive from CSP directly or indirectly as in "we want concurrency like they have in language x". In some languages functionality is integrated and in some languages people developed it as a library. Which one is the right thing to do probably depends on what you can work with in the language. Just to name some examples that come to mind: Erlang (messag passing to actors), Go (hyped go routines), Rust (multiple frameworks, Bastion comes to mind), Guile (guile-fibers, a library, because the language offers the primitives), Pony (actors, similar to Erlang), Elixir (on top of Erlang) I do not know sufficient Ruby, to tell whether or not it offers the primitives required to implement this stuff as a library. If it does, then there is a higher chance of anyone eventually getting it right. If it does not, it will depend on the language designers to get it right.

deleted 6y ago

[deleted]

gameswithgo 6y ago

I don't understand bolting concurrency onto something that is interpreted. A compiler would get you 10-100x speedup, without your users having to do the complex thing of writing safe parallel code.

jashmatthews 6y ago
CRuby has had JIT for over 3 years now and I think JRuby must be over a decade?
- gameswithgo 6y ago
  are those first class options now? or is it like python where you can kinda sorta sometimes use a jit?
  - jashmatthews 6y ago
    First class option in Ruby 2.6 onwards.
    - pjmlp 6y ago
      Yeah, but not that impressive in capabilities, hence other projects. https://developers.redhat.com/blog/2020/01/20/mir-a-lightweight-jit-compiler-project/ https://developers.redhat.com/blog/2020/01/20/mir-a-lightwei...
      - jashmatthews 6y ago
        While MIR could be an interesting alternative to CraneLift it doesn't really address the challenges faced by trying to improve performance via JIT compilation within CRuby.
chubot 6y ago
Ruby can’t be compiled easily due to the very dynamic semantics of the language. If you wanted to compile it, it would probably start behaving a lot more like Crystal, which looks similar but behaves completely differently.
- gameswithgo 6y ago
  you could aot compile most of most programs and jit the rest. or just jit everything
- jashmatthews 6y ago
  If you're talking about just compilation then it's easy enough doing something like context-threading where you translate bytecode into a call instruction per operation to a function implementing the bytecode. If you're talking about producing a static binary then both Rubymotion and TruffleRuby can do this.
  - chubot 6y ago
    I should have clarified that I meant "compiled easily for 10-100x speedup" (on representative workloads) as the OP was saying. You can definitely compile anything... whether it's worthwhile is a totally different story. I learned this the hard way :) As far as I remember the Ruby 3x3 effort yielded 3x on SOME workloads, with tremendous effort, which is about what I would have expected due to Ruby's very dynamic semantics.
    - jashmatthews 6y ago
      TruffleRuby already has that kind of performance increase on microbenchmarks. The CRuby JIT for 3x3 built by one person in their spare time.
  - FooBarWidget 6y ago
    > If you're talking about just compilation then it's easy enough doing something like context-threading where you translate bytecode into a call instruction per operation to a function implementing the bytecode. Ruby has already been doing threaded dispatch on bytecodes since 1.9.
ramchip 6y ago
A lot of web services do a little bit of work, wait on a DB query, do a little bit of work, wait on DB, etc. It’s even more true with websockets, which spend most of their time idle waiting for messages. Good concurrency support lets you handle thousands (even millions) of these activities in a single process, which is massively more efficient than using a process each, and puts less load on other systems (DB, Splunk, Graphite, RabbitMQ…) Green threads in particular make it possible to get these benefits without writing the code in async style. You just write regular, blocking code and the runtime / frameworks take care of yielding to the scheduler (event loop) when appropriate.

mapgrep 6y ago

Yes, like the amount of thinking and novel work Rich Hickey out into the immutable but fast data structures in Clojure, the use of mvcc stm for transactions when you do need to share mutable state between threads - it was there from the start. I don’t even pretend to fully understand half of the things going on in Clojure concurrency on a deep level but I find it reassuring that parallelism was deeply considered from the start. And also grew with even deeper models like core.async. How many languages are there like this? A handful? Erlang, Scala, Haskell, Go.... Java has always been parallel but with pretty primitive concurrency tools, no?

cutler 6y ago
Don't forget Kotlin's coroutines.
pjmlp 6y ago
Java started with the same concurrency primitives as Ada and Modula-3. Java 5 got the concurrent package, with support for futures, chained computations, ability to create ou own schedulers, only matched by .NET dataflows. Java 8, integrated the concurrent package with parallel streams. Recent versions are being refactored so that eventually virtual threads are surfaced across all runtime, so instead of not knowing if green or red threads are being used like in the early Java days, the developers get to choose which ones to use. On .NET side, naturally it copied the Java primitives, then came TPL, Dataflow, async/await, PLINQ, F# agents, F# async/await (not the same as standard async/await, based on F# computations).Additionally there is the research done with Axum, Cω, Singularity, Midori, Immutable C#.
julik 6y ago
In Go pretty much everything is very much mutable. The part that distinguishes Go is exactly the M:N scheduler used for both evented IO and parallelisation of compute. For _concurrency_ (what the Ruby fiber schedulers are for) what is proposed is probably quite a good idea. We can do as much hatin' as we want on JavaScript but its concurrency story has been much more successful than Ruby's due to evented IO as well - even though everything is mutable. As far as Ractor is concerned - well, WebWorkers are kind of similar - they get a separate thread, but you can only send them "messages" which must be immutable. How the MRI team is going to tackle mutations in those messages is an interesting excercise, because Ruby is ultimately a _live runtime_ - i.e. most of the things can change at any time. Not because it is made for sloppy programming but because it is made for incremental changes to the VM like Smalltalk.

jshen 6y ago

Did you even read about the implementation details here? It appears you didn’t.

colonwqbang 6y ago
Please tell me how I'm wrong instead of insinuating that I didn't read the article. > It will likely take some efforts and at least a year of work from the community to push libraries towards less shared state. About one year to rewrite the ecosystem to fit this new threading model. Does that strike you as particularly realistic? Like I said, I very much wish they would succeed.
- studius 6y ago
  They downplayed the actual amount of time that went into these changes and the upcoming changes. Here's the history: Matz[1] released the first version of Ruby in Dec 1995. DHH was a major player in getting Ruby into the global spotlight with Rails[2] in 2004. Rails got very popular as a framework for developing new applications, with Basecamp being novel, showing that it could work well and introducing people to REST, in a flexible interpretation, as well as ActiveRecord, whose ease of use and migrations became a model for modern web development. Rails v3 divided the community, specifically around how and what Rails would support for the server and request-handling. This hinted at problems to come, but Rails was still strong, and many took it with a grain of salt and upgraded. However, Twitter, which had been built on Rails became popular, and the "fail whale" emerged as they were unable to handle all of the requests. This was not a problem with scaling Rails, but with them knowing how they could scale Rails without much greater expense, but since they had to rewrite things and there was pressure to get scaling done right, they switched to Scala and Java, since Scala was functional and fast, and there was a lot of support for the JVM. Functional programming had already been making a comeback in popularity in the 2000s, because it often required a lower memory footprint and was fast. But, at that point in time, many teams and developers were looking into it. Though it wasn't the first time he'd done optimization, in 2012, Matz released mruby[1][3], an embedded Ruby. Around the same time, with functional programming having been cool, Elixir was born and some of the Rails community left for writing Ruby/Rails-ish code in Erlang. Some had been trying to slim down Rails in core, so that there would be less code needed to serve requests. Tenderlove, who came from the system programming side of things, joined the Rails core team with a focus on optimization, did work on Rack, and eventually he started working to help speed up Ruby. For years, Matz and others had focused on speeding up and slimming down Ruby. Ruby had run on Lighttpd and Ruby on Rails could run on it also. All of these things have been driving Ruby to get better, and now it is. So, no, I don't think it's realistic that they put a year into it. At least 9+ calendar years led to this point, and it's been 26+ calendar years since initial release. And this isn't the end of it. It's not trying to compete with or tank your favorite framework or language of choice, it's just been improving and its team, even as good as it already was, has been improving. P.S.- Ruby is not Rails. But not talking about how the history of Rails in the scope of things would be remiss. I can't think of anything in the history of Ruby that has been bad, but certainly Rails has had its "fun". But right now, it's coming together. I also didn't mention Sinatra's influence on slimming things down, or Puppet, Chef, etc.'s contribution to the Ruby community, or Crystal which has been a valiant effort for a compiled Ruby-like ecosystem. There is so much that happened leading to today that shaped where things are and where they are going. I'm totally psyched about this. [1]- https://en.wikipedia.org/wiki/Yukihiro_Matsumoto https://en.wikipedia.org/wiki/Yukihiro_Matsumoto [2]- https://en.wikipedia.org/wiki/Ruby_on_Rails https://en.wikipedia.org/wiki/Ruby_on_Rails [3]- https://github.com/mruby/mruby https://github.com/mruby/mruby

zelphirkalt 6y ago

As long as the language supports the primitives needed for implementing good parallelism, I do not see why it could not be done in form of a library. Of course the ecosystem would have to evolve to make use of such. However, it seems more and more language get on the bus for having concurrency libraries, that derive from CSP directly or indirectly as in "we want concurrency like they have in language x". In some languages functionality is integrated and in some languages people developed it as a library. Which one is the right thing to do probably depends on what you can work with in the language. Just to name some examples that come to mind: Erlang (messag passing to actors), Go (hyped go routines), Rust (multiple frameworks, Bastion comes to mind), Guile (guile-fibers, a library, because the language offers the primitives), Pony (actors, similar to Erlang), Elixir (on top of Erlang) I do not know sufficient Ruby, to tell whether or not it offers the primitives required to implement this stuff as a library. If it does, then there is a higher chance of anyone eventually getting it right. If it does not, it will depend on the language designers to get it right.