What's new in Ruby 3.1?
nithinbekal.com
nithinbekal.com
{ a:, b: } #=> { a: 1, b: 2 }
Because of the set syntax in Python, the JS syntax can't work, but the ruby one would be nice.
Since Python keys can be anything, but usually are strings (and hence are quoted), I would probably invert the ":" though:
{ :a, :b }That is kind of neat, but I tend to think of a bunch of {'a':a} as a bit of a code smell. Like maybe I should have used the hash/object/dict to begin with
Many dependencies have minimum, but not maximum versions specified. Most bugs have to be found at runtime (or via testing, which causes a runtime).
Again, Rust has spoiled me because if cargo build compiles, then it’s almost certainly ok.
Interesting. Has anyone ever purposed this?
In practice you may not fully depend on it because people often write too permissive ranges (i.e. >= 2.7) and there has been some breaking changes between minor versions of Ruby 2.x so even if people write "~> 2.7" it may still be broken.
A lot of the syntax feels like hacks because Ruby syntax is rather permissive and finding pattens that don’t collide increasingly difficult.
Definitely has me a little grumbly, but I’ll get used to it eventually. Already loving _1.
But now that I think about it, yeah, even looking only at pattern matching there is a lot of new syntax going on.
- Keyword arguments - where there is no way around, you have to change them, upgrade gems...
- Everything else is optional. Code that is written in 2.5 mostly runs on 3.0
Also, I recently updated a Rails app from 2.7 to 3.0 and no code change is required.
I am asking as I am trying to use new syntax in my daily code so maybe I am missing something.
What is the new syntax that you discovered in 3.0 that made your head spin?
How does the keyword arguments change break old gems? I understood the new syntax to be optional in the case of not needing to repeat keys and values.
* single line method definitions (def ... = ...)
* case...in
* pin operator
* rightward assignment (42 => int)
* use of the above to destruct arrays and hashes ( x => { b: foo } ; foo #=> 2 )
I should play a bit with them and see if they provide any help to write more readable code.
def red; “red”; end
def red = “red”
def color name = “red”
name
end(I remember node and python getting it but now can't find that in the release notes - I didn't imagine it, right?)
CMUCL/SBCL must have supported this for decades.
Or maybe I'm just so numb to it and I don't recall properly.
Comprehensive Ruby 3.1 changelog: https://rubyreferences.github.io/rubychanges/3.1.html
Oh this is pretty useful. How many times have I not wanted to learn about how to use a function. Showing the documentation when tabbing through the options can save me a lot of time browsing through the ruby docs. Looking forward to using this while working.
Good to see Ruby is still moving forward :)
I don't see any benefits at all from this.
It is like saying limit in math is magic.
I could agree that we can evaluate if it is magic a library or a standard library.
More to the point: In the Ruby apps that I saw so far and articles I read I get a different feeling: more and more the community is promoting clarity, explicitness, simplicity.
I somehow feel that from Ruby 2 forward metaprogramming is seen as last resort. Almost no guideline promotes magic in Ruby code by default. More syntax is actually removing the need to do “magic tricks” with the language. It makes explicit in some cases some things that people were doing with DSLs.
I feel that magic was more present in Ruby 1.9 for example than now even if syntax was more limited. I was solving a lot of things with metaprogramming, monkey patching, calling private attributes and more. Now I will not approve my own code from back then if I will see it in an MR.
def call(batch_id:, language: )
end
batch_id = find_batch_id_from_conditions(conditions)
language = load_language_settings(user.id)
call(batch_id: batch_id, language: language)
Better is a very personal thing :) I like the ecosystem of ruby, always did and never had a reason to change.
May I? Thanks!
At TuneCore we've already replaced a lot of our micro-services with Elixir/Phoenix/Broadway or Go and we've saved quite a bit of cash of server costs.
Right tool for the right job and all that jazz.
Elixir is well suited for a lot of things Ruby is but also has some shortcomings. For instance, the albeit growing community and available libraries is just not on the same level as Ruby. Furthermore the amount of available engineers knowing elixir can be a problem when hiring (ofcourse these can be trained internally) but in general hiring will be a tad bit harder.
Whilst I agree with you on the technical side (language is cleaner and obviously more performant) I do not agree on the statement dat Elixir is a better tool, as with a lot of things in software it depends.