https://github.com/Kotlin/kotlinx.coroutines/blob/master/cor...
But dang it's nice to do stuff in it.
The GIL would be quite easy to replace otherwise.
IIUC for CRuby it's mostly about how to keep the VM simple. Koichi Sasada is working on an ownership based model like Erlang has, which sidesteps a bunch of theses issues.
I used to love Ruby too but the dynamic typing quickly became a deal breaker. So I set out to find a language that's as pleasant to use on a daily basis, with well designed libraries and collections, but also statically typed.
Kotlin met all these requirements for me.
Knowing exactly what types a method takes and the compiler catching incorrect uses before the code ever runs saves a lot of frustration. Another thing I've enjoyed in Rust include `match` clauses forcing me to define branches for any possibility, especially for `Result` structs. In ruby this isn't possible because anything can be anything.
I have a hunch that single/static dispatch is what tends to cause more problems than merely the presence of nil. It's not nil, but how you use it.
Can you elaborate on how multi-dispatch reduces the issue of nil/null?
I also use static type (typescript) to prevent issues with nil and would like to know how I can achieve the same in a dynamic language.
It's a lot easier for me to reason about and avoid edge cases when I can (more or less) verify at compile time that invalid states are impossible.
This is about more than just catching null values, and also encompasses things like mutually exclusive fields, and access control.
If you're interested, I gave a talk once that dives into these ideas more effectively than I can express in this comment: https://github.com/ShaneWilton/programming-with-types-talk/b...
We were on a really old Mongoid (or carrierwave, or some other gem, can't remember), It was difficult to find the right methods to use and etc.
I understand it was our own fault not to write comprehensive tests or keep all gems up-to-date.
But a dynamic typing language is a lot more "punitive" when we aren't writing perfect code, using perfect design, and/or exercising perfect engineering practices.
It's easy to find what's available in Ruby: https://ruby-doc.org/core-2.5.3/Enumerable.html
Good luck with Clojure: https://clojure.github.io/clojure/clojure.core-api.html
Your example could be improved by using "products.sort_by(&:cost).last"
I try to not use map because often there are methods that already implement filtering. Gotta love Ruby readability.
const list = [ 1, 3, 4, 2, 8, 5];
const [fst, ...snd] = list;
head, *tail = *list
You don't on the RHS, or rather, it's redundant in the given example. On the LHS you need it to prevent single element capture.. and within the ruby language, it's a fairly consistent sigil.