I am always happy to unwrap my Christmas present from the Ruby team! Some questions about this release:
- Are there any benchmarks for the new JIT?
- Why was `(Date.today..(Date.today + 1)) === DateTime.now #=> true` false in Ruby 2.5? It seems correct that right now is between today and tomorrow. Is it because one is a Date and the other a DateTime?
About your question, the reason is that `===` is aliased to `Range#include?` which checks if the argument is a discrete element contained in the range.
That range of `Date`s does not include any `DateTime`s, so the inclusion check returns false.
`Range#cover?` on the other hand, just uses >= and <= to check .
Ruby used to be my most beloved language. I've since developed a strong appreciation for good type system. However, working with collections of any kind in Ruby is just such a joy. The methods around it are so well thought throug and make writing code a joy that in most other languages just would be tedious. On top of that the Ruby team is constantly working on making that aspect even better. I truly don't understand why it seems to me that no other language I use makes even an effort to provide something similar. Getting a map, a reduce and a filter function seems to be as far as most standard libraries are willing to go.
Crystal is nice, but my love affair with Swift is going strong. Not exactly Ruby syntax but pretty similar in terms of simplicity. I am a Rubyist who feels right at home with Swift. But for the new year, I definitely want to give Crystal a fair shot!
Kotlin is my new love. Best collections library of any language I've used, great type system, coroutines are amazing, and all of it integrates perfectly with 25 years of rock-solid Java libraries.
While the collections library may be better than others, it has a great many warts, many of which aren't discoverable until you've used it a long time. Some of these warts are a result of JVM interop requirements. It's not just the collections library, while the language is great and better than others, there are mounds of bugs and poor design decisions.
JRuby threads are fully parallel and in production use today. CRuby's GIL is an implementation choice rather a property of dynamic/interpreted languages.
Is it really a "choice" if the alternative is really hard to achieve in practice? It's like calling python's GIL a choice... with numerous projects trying to get rid of it in various ways and never really succeeding to do it while keeping the single threaded performance and the extensions API.
> It is a choice to keep backwards compatibility with the C extensions API.
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.
My thoughts exactly. I feel it isn’t the library, but the grammar, which is why the same feel cannot be replicated by other languages. Ruby is just easy on collections.
Not having `nil` is soooo nice. I can't count the number of `Runtime Error`s because some method isn't defined on `NilClass` that have blown things up in weird edge cases.
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 can't type up a full answer right now, but for me, a strong type system is about being able to model my domain and bake all of my assumptions about that domain into the types I define.
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.
For a non-strong-typed language, it's difficult to dive into the code after you haven't work on that codebase for a while.
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.
Languages without full blown union types feel so impoverished. With good language typing support (including flow typing), optionals feel quite redundant.
While I understand the sentiment that all the functions aren't necessarily grouped as in OO languages, I think the Clojure functions are harder to group because they're more general. That's not necessarily the strongest argument, but it is so much more obvious in OO because you always have the object to group by compared to functional languages.
Can you recommend a post/article explaining some of what makes Ruby's collections especially pleasant? Studying Ruby's stdlib design has been on my 'someday' list, but there's so much else there...
It's mostly how complete the API is and how consistent. For example:
* Hash#merge takes a block for conflict resolution. I use this all the time for aggregating counts.
* #sample
* #unique
* Everything has a change in place option by appending "!"
one beautiful design decision ruby made really on was that every method would have the option to take a block of code when it was invoked. the code block gets passed to the method as a closure. this makes writing collection apis very pleasant, since so many of them involve passing in a single closure to operate on each element.
Definitely. I dabbled in Ruby but kept coming back to Groovy because it had all the nice syntax of Ruby but all the advantages of the JVM, solid Java ecosystem / libraries and optional strong / static typing to apply when valuable (eg: defining interfaces or data types).
Damn, I should have remembered that. Especially considering I had a project where I had to trawl through the ruby parser including multiple assignment rules.
To be fair, I find the destructuring syntax strange in Ruby. For example, why do I need the splat on the list? It doesn't make sense to me. I'm sure there is a good reason buried in the implementation, but if I were to design the syntax, I don't think I would do it that way.
> For example, why do I need the splat on the 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.
This will be fun. I’m glad we now have some performance improvements to some common methods. For those considering playing with Ruby, you should! One thing I’m surprised not many has mentioned what makes ruby unique and awesome, BLOCKS!
Still, having worked with ruby a fair bit the past year, it does deliver much of what Smalltalk does (not surprising, as ruby borrows heavily from smalltalk).
Scala and Kotlin let you achieve something similar, without requiring a dedicated `yield` keyword, as well as not introducing yet another type of function into the language... Personally, I always found the number of different types of function in Ruby to be bewildering.
Scala even allows multiple blocks to be passed in, used to good effect in the Cats effect `bracket` function, amongst others.
I'm not so sure about the block thing. I mean I like having first class function-like objects, but you've got blocks and procs and both of these are different from bound and unbound methods. I would prefer that there was a single function type, personally. I wonder if I'm missing something, though. Is there an advantage to distinction between blocks and procs that ruby makes?
But I do agree that I don't quite understand the need for the distinction between procs and methods, or the need for unbound methods; I would think that methods could just be either bound to one object or another, as unbound methods are useless for the fact that they won't work at all unless they are bound.
I love ruby, but I kind of consider blocks an antifeature compared to, say, JavaScript arrow functions (where you can actually call return and not inanvertsntly break out of the entire enclosing function).
A lot of this kind of stuff is more about language and standard lib culture than strict language features. Ex - Rust actually has exceptions, technically, in the form of Panics, and you can infact catch them. But the culture of Rust is strongly against using panics in that way. Basically never catch panics and only allow them to happen when you're okay with the whole program blowing up. Use Option and Result and check them if you care about your program not blowing up.
Similarly, Ruby has nice blocks, and many other languages have similar closure support. But Ruby's support is so built-in from day 1 and heavily used in the standard library and the general culture of Ruby gems. Many of the methods in Enumerable take blocks, making it easy to chain a bunch of functional stuff together, even without any support gems and from the earliest days of Ruby.
Just parameters that are functions, except that you can only have one per function.
I still fail to see the advantage of blocks over being able to pass functions as arguments like in other languages.
One nice feature of blocks is that `return` will return from the enclosing function, rather than the block, so you can write:
def find(x, l)
l.each do |y|
return y if y == x
end
end
Where in Lisp you'd use (return-from find x) and in other languages you might pass in a continuation or use a special return value protocol. It's a nice solution for higher order functions that are supposed to feel more language-level.
Also, you can pass functions as arguments like in other languages; lambdas behave like you would expect them to.
Negative indices aren't magic. They follow the obvious wraparound (modular) pattern: Negative `i` indexes the element in array `a` located at `i % len(a)`. If they worked any other way it'd be madness.
It depends on how you define the modulo operator [0]--there are definitions where (-1)%5 == 4 and definitions where (-1)%5 == -1. Presumably the GP is referring to the former case.
Phrasing issue, I think. I understood "Negative `i` indexes the element" as `i` itself being positive. Like you'd say "negative 1 indexes" (i is 1), not "negative -1 indexes" (i is -1)
I'm not sure about this being good for coding in non-latin. It might actually encourage behavior to mistreat ruby constants as regular variables. IIRC constants are not really constant, but only visual help for reading code and ruby just issues a warning on reassignment and these warnings are not shown by default.
I can totally imagine new devs just trying out non-ascii variables, see it not crashing and then actually writing all their code using constants.
> I can totally imagine new devs just trying out non-ascii variables, see it not crashing and then actually writing all their code using constants.
Ruby already supported non-ascii identifiers for variables; 2.6 added support for non-ascii first characters of constants, which must still be capital letters, as had always distinguished constants from variables. It doesn't make anything non-ascii a constant, it just makes constants consistent with other identifiers in terms of non-ascii support, while preserving the “initial capital means constant" rule.
And, as sibling comments note, reassigning a constant produces a warning, so devs making a mistake and using constants for variables (regardless of ascii-ness) will quickly be informed of their error.
I wasn't aware of non-ascii variables. I was thinking about UTF support for Japanese characters, when I read the change. There is no concept of lowercase/uppercase. 日本語 is this a constant or variable?
Since constants are the exception, and used to require an ASCII capital but now can start with ant capital, an identifiers starting with a Unicode character in a script that doesn't have upper/lower case distinction is a variable, not a constant.
I don't quite understand how this change makes the (somewhat remote) misunderstanding you describe any more likely than it previously was for people using ASCII only.
I also just tried and was duly warned upon reassignment, a setting I don't remember changing.
Is it a good time to learn Ruby? I mostly do React and Node + Java work professionally, but I've been looking into Ruby as a fun side project language. I would appreciate any anecdotes!
Depends what you want to do, 90% of what I code in is python or Ruby, and I'll switch to C when I want performance. I've done a lot of rails (Ruby), Django (python), and flask (python) work in web development. Much prefer rails, eaiser, and better thought out. I have several websites with hundreds of thousands of visits a year, it is fine (all the frameworks are). I have had to do some inline C to speed up my Ruby in a couple of instances - but that's very specific (and something you can easily do).
In terms of data science, python is my go-to and much more tooled for that kind of work. For any kind of desktop app I'll use C++, and for browser extensions / add-ons it's JavaScript.
You should give crystal a go for the parts you need to be performant! You can even prototype those parts in ruby and easily convert to crystal when it becomes necessary. We’ve found a really nice balance, with business logic and interfaces in Ruby/Rails and crystal for AI/data processing.
Oooh, that sounds interesting. Where would be a good place to start with Crystal assuming I specifically want to use it for AI/data processing with Rails business logic / interfaces?
Had a problem that I'd typically use Ruby for but needed to shed the GIL. JRuby worked beautifully. The only gotcha was I needed to use the JDBC driver for Sequel instead of the usual drivers. Obvious in hindsight but not so much with zero JVM development experience. I'd use it again.
> TruffleRuby is progressing fast but is currently probably not ready for you to try running your full Ruby application on. However it is ready for experimentation and curious end-users to try on their gems and smaller applications.
> TruffleRuby runs Rails, and passes the majority of the Rails test suite. But it is missing support for Nokogiri and ActiveRecord database drivers which makes it not practical to run real Rails applications at the moment.
Emphasis mine, but that puts it firmly in the "fun toy" category rather than a viable technology for anything mission critical.
I am a big fan of Ruby. The syntax and stdlib let you write code that is very close to a natural English sentence. For example, Ruby has both `if` and `unless`, so you can express a condition as `unless condition` instead of `if !condition`. And the frankly great Enumerable module provides a great collections API, miles ahead of Java in particular. If you're sick of writing for-loops I recommend giving Ruby a try!
Ruby is awesome for prototyping. It's just incredibly fast to work with, because the language makes an effort to provide as much help as possible and adding as little obstacles as necessary. E.g. you can even add/change functions to/of Object, even during runtime, if you think it helps. Rails adds `blank?` like that, which is a helper for `nil? || empty?`.
As a Ruby dev on the hiring market until recently Ruby seems to be in kind of the same spot as Perl some time ago: many new/existing Ruby/Rails projects are around, so it's kind of mainstream but not as much as PHP/Node/Java/whatever is which means less job offers, yet not quite niche neither, and there seems to be kind of a slight lack of Ruby devs around, and it can act as a differentiator, even for non-Ruby jobs. There's quite an interesting market dynamic at play here.
Is it a good time to learn Ruby? I mostly do React and Node + Java work professionally
It can be fun and it's as close as Smalltalk will probably get to mainstream acceptance, but if you are hoping for a lucrative commercial skill then probably you have missed the boat. Ruby is mainly used for two what most would now consider legacy things, Rails based websites and Chef based infrastructure. There is still some money to be made in maintenance of course and will be for a few years but the sun is definitely setting on Ruby. But 10 years ago it was super-hot.
For me it is too much fun. I love that I can use most of the standard library without thinking / looking at the documentation, and not needing to wait for compilation.
But at the same time I hate that I love a language that performs so bad compared to being closer to the metal.
APL itself looks really really bad language with bad documentation, no real libraries, non-existent type system, bad function names, and I don't see any GPU programming support in it. In the family Matlab is still the best (It can do Monte Carlo simulation on the GPU, and has a great library for different distributions), but it's still much slower language than Julia generally.
Right now I'm working on financial time series modelling.
I can't use numerical arrays because the model is not parallelizable. Also R / Mathematica are not good for these kind of stuff.
I'm thinking of trying out Julia, as it's dynamic but still has a lot of interesting libraries, but for now I just decided with working with small data, so actually I don't have performance problems.
It is as good time as to, say, learn Farsi. It's beautiful, it's fun, learning it is a great experience, and, plus, quite a few people already enjoy speaking it. Or, you could learn something else without feeling much of a loss.
The access to AST will allow for neat hacks like PonyORM on Python, which could be a way for me to improve Rebel::SQL. Tentative hacks by decompiling bytecodes or using Parser, while fun, proved practically unsatisfactory.
What is the complexity of set operations on arrays? This seems a bit too much sugar to me, to the point where people will end up writing inefficient code because they will thing these methods are more performant than they really are. Usually, I like to see explicit conversions to sets to make the performance characteristics explicit.
In most real world applications, the cost of doing an in-memory data manipulation like this is negligible compared to I/O, waiting for the database etc. It's already the wrong language for someone who wants to squeeze out every CPU cycle, and imo it's a Good Thing for a language upgrade to embrace its strengths ie syntax sugar in the case of Ruby, as long as the perf hit isn't out of control.
I'd agree developers should pick the right data structure for the job and some APIs can obscure the cost to the point of misleading developers into woefully wrong decisions. I just don't think it's the case with array ops like union as it's easy enough to handle them efficiently. I too would be interested to see any benchmarks though.
I might be more receptive to this if this was added to all collections, then, rather than just arrays. (Maybe it was? I don’t write Ruby, so I don’t know for sure. Maybe Ruby doesn’t have a generic “collection” protocol?)
Interesting point. Ruby has an Enumerable module, but these methods were added only to Array. Since the main native collections (Set/Hash/Array) all support them now, they could probably be added to Enumerable in the future, with class-specific optimizations if necessary.
> This seems a bit too much sugar to me, to the point where people will end up writing inefficient code because they will thing these methods are more performant than they really are.
Real-world performance and asymptotic complexity aren't the same thing.
> Usually, I like to see explicit conversions to sets to make the performance characteristics explicit.
The performance problem with this approach (for certain problems) when you have input arrays and want an output array is that Array->Set and Set->Array conversions are not free, and even if this is better in asymptotic complexity, you aren't always operating at the extends where asymptotic complexity dominates, so you can end up with code that is both excessively verbose and unnecessarily nonperformant just to make asymptotic complexity more apparent.
Typically, they will be linear on the combined size of the arrays. - for example is implemented by putting all elements of the right side in a hash map and then iterating through the first one and deleting all that can be found in the hash.
I haven't used Ruby before but I'd have to guess that their Array implementation utilities table doubling, if this is the case operations like concat, union, and difference should be linear.
ruby violates all of them.
so do many other languages.
BTW identifiers are not just url's, mail addresses or variable names, but also usernames and paths (filenames, directory names). eg with RTL spoofing you can hide ../
nobody cares so far, esp. not Linux filesystems. Garbage in garbage out is a security risk. The old Apple HPFS at least normalized unicode, the new one is again insecure.
How do you check your code? Presumably, you’re not able to exercise the full range of inputs, so at some point you will have to look at the code and figure out what it is doing…
Which means you'd notice the value of a constant being exfiltrated, since a maliciously named constant doesn't magically expose secrets outside of the application.
I suggest you take a look at some of the submissions in e.g. the Underhanded C Contest. Where it can be excruciatingly hard to figure out where the backdoor is even though you know that the code has one.
Do you apply formal verification to your codebases to make sure there are to cleverly-crafted backdoors that still pass all the unit tests? Would be interesting to hear about.
In Ruby it can easily be used to submit malicious source code to a repository (for example the reviewers thinking that a variable is set to some value, when in fact a new variable is created).
An attacker would still have to _do_ something with their new maliciously named constant, which would be as noticeable as any other malicious contribution. This is grasping at straws.
This is probably pretty overblown, but if a function takes a flag, it would be possible to pass in a different value to the function than appears to be passed in at first glance.
He linked a resource that explains visual spoofing, an "attack technique" in which an attacker registers a domain that renders exaclty the same as yours, but actually isn't (because it uses unicode points which render the same --or very similar-- to latin alphabet letters).
I woulnd't go as far as saying "it's a security risk", but on some situations it may lead to weird bugs in which you think you're referring to one constant/variable and you're actually referring to another (visually equivalent/the same) const/var.
It enhances risks if you are doing things that are already risky, like using Ruby's dynamic facilities to either expose the user to things based on names in source (“eval” of user-submitted content, or things dynamically constructed from it, for example.)
But I can't see much else that is a realistic security risk (readability and code clarity risks are another story.)
- Are there any benchmarks for the new JIT?
- Why was `(Date.today..(Date.today + 1)) === DateTime.now #=> true` false in Ruby 2.5? It seems correct that right now is between today and tomorrow. Is it because one is a Date and the other a DateTime?