4 ms·
I think boring languages (apparently C, C++, and Java) are rated well enough. They are fine for software that is working okay, and is too expensive to rewrite i
by ghosss 5y ago
I think boring languages (apparently C, C++, and Java) are rated well enough. They are fine for software that is working okay, and is too expensive to rewrite in a language without the footgun that is “null”. But starting a new project in them is borderline malpractice for a lead engineer at this point. Please use a language that, if nothing else, statically prevents the “billion dollar mistake”.
Rust, replacing C/C++, or Java in some cases (not Android apps), and Kotlin, replacing Java, seem like winners. They are pretty boring in the end, and prevent programmers from making the mistakes that programmers consistently make. Swift also qualifies, if you happen to be writing an iOS app.
- rightbyte 5y agoIf don't get where the hate for null comes from. It is a free runtime assertion that invalid objects are not used. The problem arises when invalid pointers are not null ...
- kentm 5y agoIt's not so much that null is used but that every reference type is nullable in practice for languages that have it. Languages "without null" specifically mark certain variables as optional (same as nullable), so you're able to know that a given value is either always non-null or nullable (requires null check). In terms of checks for null vs checks against an option type for data, there's some ergonomic improvements for languages with good option support, but it's mostly the same. The real benefit is that not everything is null, and if it is nullable then its explicitly called out.
- zapzupnz 5y agoAgree. It's not null that's the issue. Null can be fine, especially in a union type like Some|None (which in most languages is a type called Optional). It's mainly to do with languages that couldn't signify that some value could be null so you'd be forever doing defensive nullity checks. Developers get lazy or forgetful and miss out those checks when they need to be there; without language support, the compiler has no reason to assume that's a problem and lets code go ahead with unexpected behaviour. The ergonomics of a language that can tell you this value may be null, check for that" or one that provides syntactic shorthand — and that the compiler complains when you aren't treating those nullable values safely — is where the magic happens. Turning nulls into optionals is all in the name of helping the reader AND the writer. (And I know I basically repeated what kentm said :-) but it's a message worth repeating!)