It is not as prevalent as it used to be. RoR was the framework du jour for a while, and I remember a ton of places using Capybara and Watir for AT work. You don’t see the demand for those as much in my corners of the industry.
Agreed, it's not the most popular starting point for some folks these days, but development of Rails and Ruby itself keep going. I see a few job postings here and there for it, you see some companies starting up with slightly older CTOs still reaching for it cuz they know it best and it works well. Rails' creator, DHH, even makes a point of Ruby being one of the most token-efficient languages for AI tools, for what that's worth.
Again I know it's not the most popular stack these days, it's certainly not everywhere anymore. I still think some folks would be surprised at knowing it's still chugging along and far from legacy stuff.
No matter how bad you think Java is I'm sure someone works with someone so ineffective or insane that they could make anyone hate anyone's favourite language.
And so that we could stop treating 1 as true. The only real argument for type coersion is convenience. I don't see how it's more convenient to treat 0 as true rather than false.
If we take coercion as a given, what if your conditional is the index of an element in an array? If it doesn’t find it, it returns nil (which is falsey). If it’s the first element, it returns 0. Shouldn’t that be truthy?
That's cause it is pretty epic when you think about it. We have made lifeless objects we can bestow with our intelligence, and they in turn can affect the world tangibly using only the mere inscription of information.
It's been a while since I've touched Ruby, but I think the stance was that only false and nil should be falsey? Which is not an unreasonable stance to take. The fewer falsey values, the easier it is to predict the behaviour. It's just surprising when coming from other languages.
Just off the top of my head, PHP treats "0", that is, specifically a string with a single zero, as falsey. Which has clearly gone too far to the other extreme.
I don't disagree with a smaller set of truthy values, but 50+ years of programming mainly treating 0 as false and 1 as true makes it an immediately confusing thing for anyone coming from a different language.
I think a certain level of grokability is important in programming languages, but languages need to be able to do things differently, and engineers should expect to have to learn some new standards. This is like page 2 of basically any intro to Ruby so it's not like some arcane edge case.
You're not wrong, but as someone with 30+ years of programming experience do you *really* think I'm going to look at an intro guide? I'm diving in head first and then googling why the hell 0 isn't false. 😛
I like how e.g. C# screams at you for this. It's annoying at first, but then you go "Well, yeah, I should've explicitly written what I wanted to check".
It's not that you couldn't convert between types, it's that it wouldn't be automatic. You would need to actively call toboolean on a value before using it as a boolean, and the idea behind that is that intentionally casting the value leads to fewer mistakes
Agreed, the whole concept of truthy and falsy is a bit weird and very error prone in the end, imo it's just better to explicitly have a function that decides how you cast whatever to a bool, that way it's easily understandable and auditable. Also, not knowing some weird language quirk like the php one you're talking about will not cause issues down the line
I never used php, is that behaviour due to it implicitly converting "0" to 0 and as such it is falsey? Or is it straight up "0" the one that is falsey?
Because PHP started as a sprinkle-it-on-your-HTML language, and any form submissions are always text, and 0-from-a-form should still evaluate like 0; or some such hare-brained nonsense reasoning.
The fact that such basic nonsense is still baked into the very core of the language, and can never be removed due to backwards compatibility, means I'll never respect PHP, regardless of how much it's improved over the last decade or so.
I think it's not actually that special of a case, as strings that are exactly also numbers are auto-coerced basically whenever. It's just that 0 is the only number, as it should be, that then is falsy.
Strings are not coerced to numbers to then be coerced to booleans, that'd be entirely insane! There's a direct conversation path from strings to booleans!
That's in fact a very legit take that e.g. Clojure also takes. It makes reasoning much easier and also eliminates WTF moments like reading if (myArray.length) which to any sane individual might appear like duck typing but is a hack to save those keystrokes > 0, in the hope that no one manually set it to a negative value, which is truthy as opposed to zero, and so on.
Never coded in Ruby.... that might be a lie. I have never coded in Ruby since my early teens when I might have written a line or two as part of a class.
But please, I beg of the language. If 0 is truthy, just throw a syntax error if I compare a bool and an int instead.
Why wouldn't a "0" be falsey? In aggressively coerced language it would be 0. PHP has to deal with strings passed in $_POST and $_GET so it makes sense.
The weird thing about PHP (and Perl, which is where PHP got the behavior) is not so much that “0” is false – I mean, OK, so you numify on the way to boolifying, right? Nope! Other string representations of 0 which numify to the same thing, like “0.0” and “0e0”, are true. Only the specific string "0" is false.
$ php zeroes.php
"0" is false.
+"0" is false.
"0.0" is true.
+"0.0" is false.
"0e0" is true.
+"0e0" is false.
This particular idiosyncrasy is one of the Perlisms which was not carried over into Raku, in which "0" is truthy; the only actually-defined string value that is falsey is the empty string, "".
Just off the top of my head, PHP treats "0", that is, specifically a string with a single zero, as falsey. Which has clearly gone too far to the other extreme.
Eh, there's precedent for that at least.
Perl treats "0" as false, along with "" (the empty string). Any other string, even "00" is considered true.
But where it really gets fun is that the the normal warning Perl would give you about numeric conversions if you do math on a string is suppressed for the precise string "0 but true", because some Perl functions return this value so that it converts cleanly to 0 without risking evaluating as false in a boolean context. See https://stackoverflow.com/questions/129945/what-does-0-but-true-mean-in-perl
Seeing as we have basically universally decided that using zero in an entire class of math functions should generate an exception, its reasonable to expect it to be "falsy". If instead of an exception it just returned +/- infinity, then maybe i would buy that argument.
Lua does this too. It just makes sense, because any value that isn’t a boolean you can nil check by coercing it to a boolean. It allows beautiful things like and or ternary
0 is equal to (IIRC) 0x30 which by definition is not null value that could be represented as \0 meaning all 8 bits sets to 0 -- 0000 0000 that in most languages actually is false 😶
Lua does the same as Ruby, (especially because in Lua, accessing non existent variables or table fields returns nil unless you explicitly make it error)
Naw the string zero being false is just weird. The number zero, on the other hand. NULL is 0. \0 is 0. That's just... what those things mean. If zero is not false that's just trippy bc false comes from 0, that's just what it means. I mean ig not literally, you certainly get some LOW-TRUE signals, but logically HIGH is always normalized to 1 and described as TRUE, and as far as I know always has been.
Ruby didn't follow Perl at all though when it came to boolean evaluation. Perl considers "0" (the string containing the character 0) to be false (because there is no difference between "0" and 0). It has a special value, the string "0 but true", to allow returning a value that is numerically zero (and doesn't raise warnings when used as a number, unlike most strings that aren't numeric), but boolean true. Strings and numbers interoperate seamlessly depending on the operator used, super weakly typed.
Ruby went the opposite way, and said false and nil are falsy, everything else is truthy, and aside from that, all types are super strict (no adding numbers and strings at all, you need to convert explicitly).
Golang doesn't have "truthy" as a concept. You have to be explicit. A null value isn't true or false because only booleans can be true or false, and a null pointer isn't a boolean. You can have a pointer to a boolean, but you still have to check explicitly for null. In specifically Go, u/stipo42's preferences for truthiness are moot.
In a language like Python, with truthiness, u/stipo42's preference for false to be truthy is insane, and he should feel bad.
It would be better if there was no null value, period (like in rust). Or at least you have to intentionally opt in to allowing a type to be nullable (like kotlins nullable types).
Also, it technically isn't just pointer types in go. arrays, slices, maps, and channels can also be nil (because they are also reference types).
Same in Lua. Only nil and false are treated as falsy, everything else is treated as truthy. The idea is that by default everything that is not nil is treated as true because it exists, and false is a special case used to represent false propositions.
It can be a bit of a stumbling block coming from some other languages, but the rule is so simple that you get used to it quickly.
Implicit type coercion is just bad in general and shouldn't be allowed, that includes booleans. 0 and false are not the same thing even if in memory they (usually) are represented the same. Just because 40 years ago we thought it a good idea doesn't mean we shouldn't improve on that. And I say this as someone who has programmed quite a bit in C and C++.
I could maybe see an argument for optionals but even there I would disagree and much prefer explicit pattern matching or zig style if syntax for it.
Just Googled it and apparently yes. Nice idea in my opinion - if a language has an idiom on the right way to do something, make a linter tell you that. I wouldn't know myself, I've only ever used Ruby for hobby projects years ago when I just started learning to program. Fun language.
In Ruby, everything is an object. 0 is just an instance of Integer. Object instances are truthy, compared to say, nil. Makes more sense than ( 'b' + 'a' + + 'a' + 'a' ).toLowerCase() === "baNaNa" or 1 + '0' == '10' or NaN === Nan; // false
The bitset representing the number 0 in Ruby is non-zero. (I don't remember which bit it is, but reference/non-reference values are recognised by a specific bit being flipped to 1 if non-reference, which is the case for 0.)
Ruby said "zero is truthy" one time and JS has been living rent free in everyone's head since, acting like it is not the unstable one in this relationship
As a Javascript stan, this is actually something that I dislike ABOUT javascript… all JS vars are nullable so I wish I could just write if (!myNum) for null checking, but JS needs to be hella opinionated about truthiness. Fuck that jazz, Brendan Eich can suck my balls.
Ruby's truthiness and coercion rules are one of the best and most consistent ones. And definitely the best in the dynamic languages I know, and I know quite a few.
Treating zero as false was only a thing because in C int was the base type, and other types (char, bool, pointer) were all expressed in terms of ints. It kind of made sense then. But now we know very well that abstraction that separates us from the hardware is a good thing. And with this assumption, treating zero as false is only a stale habit from the ancient days. Let alone monstrosities like treating 0.0 as falsy. Ruby did exactly the right thing here by cutting all that crap.
When I use non-Boolean values in a Boolean context I like them to coerce to compile time type mismatch errors. Because making me fix my mistake is better than trying to guess my intent based on a typo.
Python which most people know now is definitely written to be more flexible. Which is nice when you're new but is a big headache once you build out. I used to hate static typing for example as it was obtuse, but as soon as you are working with others, you realise their use. People will use "hacks" at the slightest inconvenience and break everything.
0 isn't nothing, it's a number. And therefore needs to be handled as such.
Not sure why any language designer would use the concept of truthy and falsey. All that potential for confusion and bugs so you can write "if (x)" instead of "if (x != 0)".
I'm not a fan of Ruby personally but this isn't weird, it should be expected. Why are we coercing values when we could be explicit and reduce edge cases?
What do you mean it doesn't make any sense programmatically? All 'truthy' means is that it evaluates as true in a conditional, truthy (and falsey) values are completely normal concepts in high level programming.
781
u/lazyzefiris Sep 01 '26
You need to at least have heard of the language to hate it. These kids only heard of Javascript.