JS does it { a, b } and I find it very convenient, because if you code well, you usually have related things with the same name and repeating the name twice is just boilerplate.
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:
I really like the ruby syntax. JavaScript now has the problem that it can't make code blocks expressions because it's ambiguous with object literal shorthand.
It's not just because of the set syntax; it's also because Python dicts don't treat their keys as symbols, but rather evaluate them as expressions, whereas JS evaluates keys as symbols by default and requires `{[key]: val}` to evaluate them. So in Python you'd have to do something funky where `{a: a}` is `{value_of_a: value_of_a}`, but, say, `{a:}` is `{"a": value_of_a}`.
So its a shortcut that if you pass a variable as a key with no value it automatically creates a key with the same name as the variable and assigns the value?
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
It's mostly useful when a function generates values then return them as a dict or when things are parts in different chained calculations before being included in the dict to save lookups.
Does anyone know if there's a tool out there similar to https://railsbump.org/ that would allow me to quickly check how many of the gems I depend on are compatible with ruby 3? I know ruby 3.0.x has been the recommended ruby version since rails 6.1, but I'm not sure if that means that a gem that is 6.1-compatible is necessarily also ruby 3 compatible (since rails 6.1 still supports ruby versions as old as 2.5.0)
Rust has spoiled me. I truly wish this was just built into bundler. I should be able to just update the version, run bundle install, and know what is supported.
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.
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.
Im also not in love with the shorthand hash syntax, but besides `_1` I cant remember at the moment what new syntax 3.1 have that 2.0 dont. Pattern matching maybe?
But now that I think about it, yeah, even looking only at pattern matching there is a lot of new syntax going on.
I love how the idea of highlighting a specific part of the expression that can't be resolved jumped from one language to another within the last year or so and now the most common languages all support it.
(I remember node and python getting it but now can't find that in the release notes - I didn't imagine it, right?)
> IRB now supports autocomplete, and even shows the documentation when you tab through the options.
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.
What is a compelling use case for omitting values in hashes or method calls? I would think that it just increases cognitive load for the code maintainer, and makes the parser more complex.
Rust has had this bit of syntax sugar for a while now, it is used for structs. I think it's nice syntax, because it's located in a place where there's no doubt about the meaning. Both Rust structs and Ruby hashes are defined in-language as key-value sets, so whenever there's just one element instead of a pair, it's clear what the meaning is.
It removes the boilerplate of repeating the variable name when it's the same as the hash key. It's an extremely popular syntax in the JavaScript world bleeding over into Ruby. Personally, I enjoy it because it feels more fluid.
I dont think a programming language can be _magic_ when talking about syntax. Syntax is something that one knows or dont know but no magic is there.
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.
Other than existing code bases, what's the advantage of using Ruby for new projects these days when better tools exist? For example, Elixir - ergonomics of Ruby but cleaner functional approach, distributed and much faster for typical web apps.
Elixir certainly has its use case, but so does Ruby. Things like the huge amount of available gems and a big community, especially combined with a proven framework like Rails really makes it easy to build applications.
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.
I've had professional gigs spanning Ruby, Elixir, JS, C#, F#, and Python. I've found that Ruby is the most enjoyable to work with and has the easiest learning curve. It's a language that doesn't feel pretentious or dysfunctional, and most importantly of all, I can get shit done with it.
Better is server bills that are 1/5 the cost, response times that are 3x faster and reduced complexity (no need for cache or background job servers). Don't get me wrong, I still really like and cut my teeth on Ruby, but there are better options for new projects now.
That's better performance, not better. Server bills is a pretty ridiculous metric to judge by; most of our server bills are due to the development kubernetes cluster (!), e.g our developers cost more in servers than our whole production setup. So what - should we go back to a monolith running locally then?
Why use Elixir and not Go or Rust then if it's only performance you care about, Go has great concurrency and better general performance.
...and let's not forget that performance could be improved in newer versions so it's a bit tricky to say that A is faster than B, period.
Particularly, in this new 3.1 version there is a new JIT (YJIT from Shopify guys) that shows up to 22% on railsbench, 39% on liquid-render.
And there are alternative implementations like JRuby or GraalVM with diff. in performance.
That's why I said "other alternatives like Elixir". Go is one. Elixir syntax is comfortable (and productive) for Ruby devs and Phoenix for Rails folks. Use what you like.
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: