"Default gems" means that they're packaged as a gem but always implicitly available, as if you had included them in your Gemfile.

"Bundled gems" means the same thing, but you do have to include them in your Gemfile.

https://github.com/janlelis/stdgems#about-the-gemified-stand...

Latest talk about scheduler: https://www.youtube.com/watch?v=Y29SSOS4UOc

Recent summary of scheduler, a little bit out of date (changes to interface): https://www.codeotaku.com/journal/2020-04/ruby-concurrency-f...

You may be interested in precompiled native Nokogiri: https://github.com/sparklemotion/nokogiri/issues/2075

My thoughts:

- A Ruby "Preview 1" release? Oh crap, I have to start Christmas shopping soon.

> Endless method: this one is cute, I love it!

Now they just need to make it defless too.

> - Endless method: this one is cute, I love it!

It's a weird name for it. It should probably be called something like 'equational method definitions'

I love Ruby, but I agree with you about disliking that kind of thing.

I've done Ruby since 2014 or so at a few shops. My general anecdotal experience:

- Lone Ruby coders often use a lot of that cutesy/obscure/dense stuff.

- Teams of people writing Ruby, with healthy code review practices, tend to value simple, easy-to-read Ruby.

- A lot of Popular Ruby gems (and projects at aforementioned Ruby shops) have Rubocop-based style guides. Rubocop has some very strict ideas about Ruby coding style. The defaults are mostly quite sane and it's easy to disable/customize the ones you disagree with.

Not making excuses for some of the more florid parts of Ruby's syntax and stdlib, but in practice I do find things are manageable!

But that's what I love about Ruby! There's so many great ways to express logic, making Ruby a language that really rewards exploration. Of course, when working with a team on a production application, you'd set up standards everyone can agree on and understand with rubocop or prettier-rb (which I loathe and will not touch with a 10-foot long pole for my personal projects). That's also great for onboarding newcomers - they can get their feet wet with "standard" ruby at work, and then experiment with it more deeply in their own time, finding themselves in the ways they choose to express their logic. And then, every now and then if you find something really elegant and beautiful in your own exploration, you can introduce it to your team and add it to your team's style if they all agree on it. Between a language that makes all the choices for you, and a language that gives you the freedom to choose how you do things, I'd pick the latter nine times out of ten: at least in the latter, you can restrict yourself from the more wild stuff, but in the former you're forced into a narrow band of choices. I sure didn't ask for right assign, but I'll be trying it out in my personal projects!

The thing that most annoyed me about Rails (not Ruby) was that

    users.size
    users.length
    users.count

are all valid, all useful, all have different meanings, are all present in plain Ruby but with different meanings, and contain absolutely no information about what they do.

For reference, .length loads everything and gets the length of the collection, .count runs a SQL COUNT query, and .size uses length if the query has already been run and .count if it hasn't.

I would never share a Ruby code base with anyone either. It’s like issuing kindergartners a can of silly string and asking them to be sensible with it.

I consider myself a sensible developer, but even I’ve had some childish moments with Ruby: doing something I thought was clever and productive but which really just made my code inscrutable and unmaintainable...

...by other people. The flip side is I can just about figure out what I was trying to do when I read my own code: enough so that I still always use Ruby for personal projects.

Ruby is just too much fun and critically, to date, it’s the only language where I can write a page of code at the same speed I am thinking. It also usually executes first time without any errors, which is a joyous thing.

I am not claiming to be some kind of 10x uber hacker. Ruby just happens to be an incredibly wonderful language for thinking aloud with code.

Ruby can also be an extremely decision-fatiguing language to write code in.

! means “dangerous”, not mutation. Yes, that’s how it plays out because it is one kind of danger, but it’s not inconsistent.

I love all that stuff in Ruby to-date (used in it's appropriate place, following convention, etc) but the rightward assignment feels useless to me.

I have no idea why the few languages that allow it do so. I've never wanted it and I can't imagine it makes parsing simpler in a language where you are sometimes compiling code at runtime and where parsing is already pretty wild.

I've said this before and been wrong so let's hope this turns out to have excellent use cases.

Totally agree.Different approaches to the same thing won't add points to the language.

P.S. the 'endless method definition' is meaningless, too.

> def square(x) = x * x

The original reason of this proposal was:

> Ruby syntax is full of “end”s. I’m paranoid that the ends end Ruby. I hope Ruby is endless. --mame (Yusuke Endoh)

It sounds like "let's add a new syntax for lisp because it has too many brackets"

Ruby has been referred to as Smalltalk meets Perl, and the problem of dealing with other people's code is one of the main things that kept me in the past from using Perl on text processing projects. The problem of collaborating in Perl was lessened a lot by adhering to Damian Conway's Perl Best Practices. Is there anything similar for Ruby?

In a sense Ruby is sort of a cleaned up Perl but maybe not cleaned up enough.

I fell totally in love with it almost 20 years ago but these days I think we have better languages to choose from even if their ecosystems aren't always as rich.

>.NET went with non-standard SQL-like names (select/where) […]

Which names do you believe are standard?

Happy someone else echoes my sentiment too, especially when Ruby seems to be beloved by everyone around. So many ways of doing the same thing; unnecessary cognitive burden for both reading and writing.

That README isn’t up to date. The benchmark has seen significant performance improvements since then.

https://benchmark-driver.github.io/benchmarks/optcarrot/comm...

I have been out of the ecosystem for a while, but use Ruby frequently. So the 3x3 is coming along? More up to date places I could see benchmarks or similar?

Note: I have been using Roda with Ruby 2 and it is pretty fast. Can't wait to see what it would be with 3x3.

This might be a bit of a novice question, but will this affect the initializations of ActiveRecord objects in Rails anything?

For example, processing a large CSV file and inserting new rows in a database from it has always been extremely slow using Ruby/Rails unless you basically just write raw SQL that copies from the CSV and don't do any initializations of Rails models, #create, etc. I wonder if this will improve these things at all, but my guess is that it has to do with memory usage and not the speed of Ruby?

Ruby already had a sort of limited form of rightward assignment, in exception rescue:

    begin
      #... do something
    rescue StandardError => ex
      #... handle exception
    end

The ex here can be any assignment expression, it's not just a lexical variable. So you could already do this:

    class Guru
      def meditate=(exception)
        puts "caught #{exception.inspect}"
      end
    end

    # later ...
    rescue OutOfCheeseError => Guru.new.meditate

i.e. creating a nice opportunity for passing error handlers around as an argument; or, this worrying idea:

    rescue TransactionError => Thread.current[:exception]

and now I'm afraid you can do this:

    Cat = Struct.new(:name) do
      class << self
        def all() = @all ||= Set.new
        def adopt=(...)
          all << new(...)
        end
      end
    end

    "Astrid" => Cat.adopt

    def my_method
        .. code ..
    rescue FileNotFoundError => FileNotFoundHandler
    rescue StandardError => StandardErrorHandler
    end

What's strange is that it seems to have been an offshoot of the pipeline operator (|>) work from last year[1], which was originally proposed as having an assignment syntax like

  foo |> bar(20) |> (x)

where x is assigned to. People didn't like that syntax, and there were issues with = being higher precedence than |> [2]. This new right-assignment operator was created in response to that [3].

The weird thing is that the pipeline operator got killed, so the original reason for r-assign no longer exists. It looks to me like there's just some people on the Ruby team who took a shine to it.

[1]: https://bugs.ruby-lang.org/issues/15799 [2]: https://bugs.ruby-lang.org/issues/15799#note-22 [3]: https://bugs.ruby-lang.org/issues/15921

The examples given were all things that would be nice to do in the REPL. What I don’t understand is why not just define it in the repl, then, like ‘_’.

JS has already adopted the endless style and it’s obvious when to use it and where a single line adds needless complexity. It’s really an overrated barrier to entry with a high return value in code simplicity (particularly aesthetically, which goes a long way with Ruby).

I have no comment on the rightward bit though. That is more... radical. Until I see how it is adopted generally.

Completely unnecessary syntax.

It does nothing but add complexity.

I was just looking for this a few days ago. Thanks!

> Just curious on how popular it is in the hacker news community ?

Seems to be well represented by successful companies here.

https://www.ycombinator.com/topcompanies/

You know I've long stopped caring about how popular a language is in the community.

As I get older the question I ask myself is do I honestly enjoy using it? If the answer is yes, then I put it in my programming toolbox and ignore the hype.

I only ever tried out a rails tutorial once, and coming from a C/C++ background, but having used with many languages, too many things felt like magic back then, but no further experience with the language itself, so can’t really judge it.

However, now I’m on the operational side of things, and there are 2 types of applications I avoid to deploy/maintain, mainly because of their runtime: Java and Ruby apps. It’s very likely the Ruby runtime has improved, but we actually set up a haproxy with multiple instances of the same ruby app, which we just restarted every 2 hours, just to keep it running properly. Upgrading ruby back-then was a mess, and could break a lot of things. I can’t comment on the language itself, but the runtime left a very bad impression. I since then (4/5 years ago or so) have successfully avoided ruby, so it’s possible things have improved, but first impressions last...

  puts "bar"

I suspect it will be quite a while before we see Ractor being used in Rails. Ractor is very strict about data isolation to prevent race conditions and existing code will need significant refactoring.

I don't understand what you mean by "real multithreading". What I understand from Ractor is that it makes it safer to write concurrent code (e.g there are constructs that keep you from mutating shared data). But there is still a global VM lock, or is that gone in Ractor?

puma, the default webserver when using rails, is most-likely what would be using ractors