Ruby 2.3.0 Released

I like that they did it this way, give a chance to see if it actually brings performance improvements in real world scenarios before imposing it on all code.

As Chris Seaton points out as well, we're not really open source yet. Working on getting there, but it's going to take time. The important thing now is that we can start talking with the community and making it more likely that when we do get open source, it can happen in a way consumable by the Ruby community.

params.dig(:user, :address, :city)

Also I think this would make possible hot code upgrades which are cool but probably more work than their worth. Unless you can build smart hooks into background job and web server libraries that only change the byte code in between jobs and requests. Oh the possibilities!

They are not goals of this project:

- packing scripts to one package

- migrate obfuscate binary to other node to hide source code

---

But.. what I don't get is: why wouldn't this works as a cheap way to obfuscate some ruby code?

After all, isn't it true that when a script is compiled to byte-code then it is interpreted by the runtime as-is (and without being re-translated to the original script in memory or on disk) ?

If so - I understand that rebuilding the original ruby script would not be a big deal for a developer - but wouldn't this still pose a small barrier to the casual prying user?

I quite like Go, Python, TypeScript, etc but Ruby is in a league of its own when it comes to short and sweet. It's a pleasure to write.

Obviously there are languages that are better in each of these areas, but few that combine so many as well as Ruby. In other words, if you know that you'll be working in a problem domain (e.g. high concurrency) where specific advantages of some other language (e.g. Go/Erlang) are likely to be needed, use that language. If you're just building something, then Ruby's a fine place to start.

it's just a nicer language to use than most, or maybe all others.

It's used by some interesting applications, such as Github, Shopify, Heroku, Square, Zendesk and AirBnB.

The second part, aside from Ruby's general applicability and ease of exploration, is that I think Ruby scales, in terms of application design, from that garbage-y first-cut code to really elegant, really clean code that's fun to work in and easy to maintain. That first solution, borne mostly out of dumping my REPL history, may not be great, but that's okay: with the help of the excellent ecosystem around the language I can reify my expectations in tests and swap out the original exploratory system for good, easy-to-work-with code that's clear in its behaviors. Of course you can do that with other languages, too--but I've never found one that makes it as easy to stretch in both directions, from noodling around to code I'd trust with my business (and I'm doing exactly that), other than Ruby.

But as for the languages you namedropped:

- Perl 6 is great, but it's a decade late and it isn't sufficiently compatible with Perl 5, so it's starting miles and miles behind where Ruby is right now. It's not dead out of the gate, but it keeps lurching toward the green and making everybody nervous. Practically nobody knows Perl 6 now, I don't know why somebody would pick it over Ruby if they're lining both languages up side by side.

- Clojure is super interesting and Rich Hickey is a supergenius and we're all lucky he didn't go into supervillaining because I think he'd be really good at it. And Leiningen is an amazing build system. But Clojure suffers from what I view are the usual problems a Lisp has around readability and the hands-on-keyboard experience (and I like Lisp, I've got DrRacket installed on my laptop for a reason, but I've been writing Lisps for a decade or more now and grinding out Clojure code is slow). Love the people, love the community...would rather write Ruby.

- Rust doesn't do nearly the same thing as Ruby. They're useful for different things. I feel like Rust inherited the good parts of the Ruby ethos from the participation of folks like Steve Klabnik. Big fan of the language and the community, but it's not incompatible with Ruby where it matters anyway so who cares?

- F# is a great language and, like Rust, also has little overlap with what I use Ruby for. If I cared about Ruby for the web, maybe there would be more overlap, but F#-for-web is swimming upstream anyway. (Doable, but harder than C#.)

- Go, while it as a language deserves some small credit for introducing co-routines to people who come from Python (he said, only somewhat snarking while he makes Lua gang signs), is close to an unmitigated disaster of an ecosystem that tries to be prescriptive when it should be hands-off and hands-off when it should be prescriptive. It is also a tremendously limited language in terms of syntactic flexibility and ability to do stuff like "second-order" metaprogramming; this is a design decision that can be debated, or could be debated if I hadn't been convinced long ago by better languages that crippling a programmer to make writing an execution environment easier to always be the wrong thing. Do not want.

    # frozen_string_literal: true
    str = 'foo'
    str << 'bar'

    # main.rb:3:in `<main>': can't modify frozen String (RuntimeError)

    str = 'foo'.freeze
    str << 'bar'

    # main.rb:2:in `<main>': can't modify frozen String (RuntimeError)

You can also trigger this behavior globally with the --enable=frozen-string-literal option.

[1]: https://github.com/ruby/ruby/blob/v2_3_0/NEWS#L17-L26

[2]: http://ruby-doc.org/core-2.2.3/Object.html#method-i-freeze

  nil&.+(3)&.+(5)&.-(7)