Boring Languages Are Underrated (2015) | Hacker News Reader

Boring Languages Are Underrated (2015)

danluu.com

75 pointspanic96 comments

I would like the definition of "boring".

Most of my day job is spent reading C++ (I write some, too) and it is more terrifying than boring. Understanding when certain errors can (and do) occur and when to optimize for performance over readability is really, really hard.

I believe that Rust, Go and TypeScript have gained a lot of popularity because they are boring to read. Even OCaml has gained a ton of popularity because it is boring to read.

C, C++, python and JavaScript: not boring to read, you constantly need to be on your toes.

If there's one thing I've learned on the topic in my life and career, it's that everything written should be written for the reader, not the writer. Perl, C, and C++ are very much for the writer. To some extent, Rust also.

Python and Go are good for the reader. These aren't exhaustive lists, just what I'm familiar with. Admittedly, Python is tricky because it looks simple(boring) at first glance, but lets one use a lot of magic.

My daughter is learning cursive and it just reminded me how much I blasted hate it. I can write it fine, reading it is a tossup. It's solely a shortcut for the writer, at the expense of reading. But anything of importance is read thousands or millions more times than it's written.

In programming especially, the easier to read the better, no matter how verbose and boring the language. I think we'll get there, when we all quit pretending we're too clever to write that way.

I find people make the mistake of thinking about how long it takes them to read 20 lines rather than how long it takes them to read x piece of functionality. (Of course it's much harder to compare the latter, but that's like the drunk searching for his keys under the streetlamp rather than where he dropped them). If there's a dense 200 lines of Haskell (or APL) takes you a week to understand, does that mean that Haskell is hard to read? Well, maybe, but if those 200 lines are replacing 20,000 lines of Go, then maybe not.

>If there's a dense 200 lines of Haskell (or APL) takes you a week to understand, does that mean that Haskell is hard to read.

IMO, Yes! If you put a mental onus on folks to understand x before you understand y, there's no telling how deep the rabbit hole goes. Why not use asm? Why can't you understand pointer arithmetic? The more you increase the mental requirements of the reader, the worse.

I used to be the opposite. I used to write smart C code and feel good about it. Because it was fun and challenging to write, which is what we all desire. With age(mostly) and experience, I realize how much of a mistake that was, if not for others, then older me.

To play off your example, list comprehensions are a nice one liner. In Python, you can do in one line what Go takes 10x more lines for. I still prefer Go, despite it feeling like shackles at time to write.

I prefer reading Go, but it's not because Go code is less dense, it's because Go keeps the language's grammar small. I usually don't have to follow a chain of macros or pre-processor directives, because the language discourages them. Reading boilerplate is still tedious.

There's a careful balance required to make a language simple yet expressive so that concepts are obvious. On one side is a Turing machine or Brainfuck, where the concepts in a piece of code don't pop out to the reader because the language is too simple to express them concisely. On the other is Haskell or Rust, where the language expresses so many concepts and has so many rules that the reader will necessarily be unfamiliar with some parts of what they read.

> IMO, Yes! If you put a mental onus on folks to understand x before you understand y, there's no telling how deep the rabbit hole goes. Why not use asm? Why can't you understand pointer arithmetic? The more you increase the mental requirements of the reader, the worse.

I'm not talking about any difference in "mental requirements". I'm saying suppose, for an equally skilled reader at an equivalent starting point, codebase A (200 lines) takes a week to read, and codebase B (20,000 lines) also takes a week to read. And my point is that many people would blindly say that this means A is harder to read than B, but actually, what matters is whether A is doing more or less than B (i.e. is A solving a harder problem than B or vice versa) - the number of lines is irrelevant!

kind of a "what's heavier, a pound of feathers or a pound of brick" situation you got there, I like it

I wonder if there's a measurable difference in possibility space where 200 lines of dense code is less likely to contain bugs than 20,000 lines of readable code. might be a case of "some infinities are larger than others"

And often times, once you become an expert in the language of codebase A, it will take less time to understand it, while codebase B is always stuck at 20K LOC.

Why would you prefer 10k lines of readable code over 1K lines of readable code?

For the same reason I'd rather read Romeo and Juliet than 'girl pretends to die. guy kills himself. girl kills herself'. Yeah they're both the same, but one gives you thought process, at minimum.

I find it's far more common that the extra lines are meaningless ceremony. No-one thinks about writing, say, boilerplate getters and setters, whereas a more concise version of the code will express the actual intention with a minimum of chaff.

Python is hard to read at scale in my view. There are no mechanisms for managing state effectively. Long procedures that mutate globals can be very difficult to follow.

Instagram uses Python.

And? I think you can find an example of every major language at scale.

Python is hard to read if you use vim and don't use something like lsp.

IDE's make languages like Python really easy to read. Plus these days you also have type hints in Python as well.

"IDE features are language smells"

-- Reg Braithwaite

Yeah, Ideally we should all be using Common Lisp. But let's not go down that debate again.

My interpretation of that quote is that if a language is so complex and unergonomic that it needs complex tooling for developers to be productive, then maybe the language is poorly designed.

Advanced tooling should be a nice-to-have, not a requirement.

How much to optimize for the reader versus writer depends on context. In my daily work on a mature system I completely agree I should optimize for readers: the things I'm writing will likely last a long time, during which many people will work on them.

On the other hand, there are other contexts such as research or prototyping where it's much more important to get things out quickly; turn your ideas into code so you can see how they work.

It's a common excuse in any place...we just need an MVP.

I guess my wish is that the language du jour was one that made things harder for the writer and easy to read.

The only reason people seek shortcuts is because they exist.

> It's a common excuse in any place...we just need an MVP.

Software projects are more than just code. Getting MVP out in 2 Months instead of 3 or 4 that it would take to do it properly, could doom the project.

And I am not just talking about startups. I am talking about project at big slow moving enterprises.

Getting somethin that the client can see, is one of the most important milestones.

Sometimes that means that you will need to do a lot of cleanup, after first mvp, and sometimes yes it stays in sad state.

But the alternative often is not better project, but project that got canceled/failed before first release.

There are times that you want to go fast, and times that you want to take your time and do it properly.

> I guess my wish is that the language du jour was one that made things harder for the writer and easy to read.

This has been the trend for a few years with static typing being added to every language.

True, but everything is hard to read until you learn to read it; cursive included.

I studied and wrote cursive for a decade. I don't believe there's a person who can read cursive as well as printed language. I think it's also why there's no cursive font in widespread use.

Cursive makes sense of you're a writer and still for some reason write your drafts by hand. The final result will get printed anyway.

Otherwise, it's rather useless as anything but an art form; modern pens don't benefit from it at all and if you're not writing a lot by hand for whatever reason, why bother?

Partially because you've been exposed to printed language more.

> C, C++, python and JavaScript

Coincidentally, also the languages actually used to make real-world software. (As opposed to self-congratulatory blog posts.)

If Rust or Ocaml ever get to the point when they're the tool for actually keeping the software ecosystems alive, they'll be terrifying too.

(It's not a problem with the languages; software is terrifying, that's a core property of software engineering and no amount of language abstraction will ever make the terror go away.)

P.S. I've been mentoring software developers for decades, and in my opinion the psychological ability to deal with the terror is the #1 predictor for success in the software industry.

Could you elaborate a bit on the terror part please? That's the first time I've heard someone mention that, and it seems interesting.

Hard to explain, but programming elicits a visceral reaction in most people. Something about the infinite and fractal nature of information complexity growth, I think. :)

(Probably also what makes it fun and addictive when you ride that tiger.)

I think everyone has their own definition of boring. For example I wouldn't call C++ boring, but would call C boring. Java would also be a boring language.

For me a boring language is a language that has a single paradigm, and there's one way to implement most stuff. With C and Java, there is little room for making "fun" code, you just write lines and make it work. Java forces you into the OOP paradigm and every problem is just a few design patterns away. With C++ you can have a lot of fun with OOP, templates, compile-time magic, old C APIs, new C++ APIs, even if you solve the same problem, two codebases in C++ will look completely different.

It's partially covered in the first link on the page: https://mcfunley.com/choose-boring-technology.

A specific quality described there would be languages that have fewer unknown unknowns, a lack of surprises. C, C++, Java (the three he picks) have relatively few surprises. Either by virtue of design (here I'd say both C and Java) or total industry experience with the language (C++, C, Java). Ubiquity might be another consideration. A lot of other languages could probably be added to the list on that criteria.

Another would be how common it is, especially for a particular domain. In my field (embedded, safety critical, real-time) it would seem like Rust would be a great choice, but it's not common and there are both technical and logistical hurdles preventing its use (for fielding, at least, for proofs of concept it's viable and that could lead to its use in fielded systems later). I'm constrained to C, C++, and maybe Ada. Fortran has been phased out, but would've been one of the boring languages for this domain up to about 20 years ago (for a new project).

Not really what you meant, but I personally have never found C++ programming to be without surprises of some sort: easy to make mistakes which are hard to find, having to agree on which C++ features/paradigms to adopt in your codebase, willy-nilly exceptions, constant appearance of new language features, etc.

I think C++ is full of surprises, especially inersection of where macros and class templates collide.

I don't think I ever saw more surprising behaviour from a language than c++, although most of the horrible surprises were cfront related and I hope they are gone now.

Agreed. Some new languages actually have the inherent capacity to be much more boring than incumbents, once the requisite work has been done to flesh out their ecosystems and make them familiar to people.

I agree with this - I don't think there's any way to define "boring" that doesn't fall apart after examination. Is it age? Lisp (whichever flavour you like) has been around forever and I'd wager very few consider it boring, likewise for Haskell and the MLs. Ecosystem? ditto. Predictability? The MLs are probably better here than C++, as you mention. Real world usage? Gee, we're talking about this on a website written in a Lisp!

It seems to me that "boring" is an reverse-pejorative for "C/C++/Java" - which I think is ridiculous, because even in 2015 Ruby and Python should've assumed "boring" status by all means, and the author even sort of acknowledges this! I understand the word as used in "Use Boring Tech" has a certain instinctive resonance to most people, but in all usages I think we should replace it with familiar. What's familiar varies from person to person, team to team, and also doesn't serve as a pejorative to anything else. Pick what you're used to if the goal isn't to experiment.

In my experience "boring" means "popular"—usually in the "you wouldn't get fired for choosing IBM" sense[1]. But somehow "use popular technologies even if they're bad" is not a convincing thesis!

[1]: Follow-up thought experiment: how many people should have been fired for choosing IBM?

I agree that Golang is more in the boring side. OCaml, Rust, and ts though?

From my experience with TS, it usually goes from JS with types (what I usually write) to something that looks like a class-based language like Java or C# (for example Angular). Most of the decisions in TS make sense if you consider that the goal is to be able to statically type the existing JS ecosystem. It's boring compared to some of the alternatives like Resript or Elm in that it's just another layer on JS rather than a new way of doing things.

For Rust, it's another kind of boring. The language may be new, but lots of libraries are there. If you want to do something, you can usually pull a few libaries, read the (usually great) documentation, write some glue code and your problem is solved. In that way the experience is usually close to Go.

OCaml is another kind of boring. It's less "crazy" than something like Haskell or Scala. It's really stable, code from 20+ years ago can compile just fine. You can write most of your code as plain functions and data structures but you still have the object and module systems if you need them. Even when they bring big changes to the language such as removing the GIL and adding multicore, they work hard to make sure that existing code won't break and single core performance won't suffer too much.

My point with all of that is that boring means different things to different people. People identities are stongly tied to the language they use (I talk a bit more about that here https://news.ycombinator.com/item?id=28256211). People talking about "boring" languages is probably a reaction to people talking about "exciting" languages and trying their identities to them. Someone says he learned Haskell, I feel inferior because he knows Haskell and JS and I only know JS, but I can counter that by saying that I "focus on the product" and "solve real problems" with "boring languages".

I like the irony that on the same website, there is an article about "Keeping your identity small" (http://www.paulgraham.com/identity.html) and how people that don't use Lisp can't even understand why Lisp is better (http://www.paulgraham.com/avg.html).

Anecdotely, I read by first top-to-bottom OCaml source last month and it made me question what I had been writing (PureScript and a bit of Haskell) because it was so simple and easy to read by not getting into the type classes weeds. It has just the right amount of features, like ADTs and pattern matching, without too much for the average reader. It's not as terse, but that can be an advantage.

I think that when he means "boring", it's something that is relatively mature and the pitfalls are well-known. Despite C/C++ being (in my own opinion) dangerous to use and relatively hard-to-maintain, you already know where are the failure points etc. While Rust and Go (for example) are now a bit more mature, there are still some unknowns and (solvable) limitations (for example compilers in non-ARM embedded systems).

> A question I have is, why is online discussion about this topic so one-sided while the discussions I've had in real life are so oppositely one-sided. Of course, neither people who are loud on the internet nor people I personally know are representative samples of programmers, but I still find it interesting.

Programming languages are a kind of pyramid scheme. If you get more people into the community, you have more chances of using it at your day job, more libraries will be developed, more people will work on the language itself, more people will promote it and do cool stuff with it. Popularity brings even more popularity. And popularity is usually the most important feature of a programming language.

Edit: as mentionned by ashtonkem, the proper term would be "network effect" and not "pyramid scheme".

The proper term for this is “network effect”. Pyramid schemes only make sense if you’re remunerated in some way based on the number of people you directly and indirectly bring to the language.

> Pyramid schemes only make sense if you’re remunerated in some way based on the number of people you directly and indirectly bring to the language.

But you are remunarated in a way. If your pet language become really popular, you don't have to choose between using it for less pay or not using it for more pay. That's either more pay or more happiness compared to the previous choice. There will also be more libraries, better tooling, better everything in general that will make you gain a lot of time.

Also, people that follow you will also be "trapped" in the language as they will have invested in it. If they want to make their investment better, one of the thing you can do it again, bring other people to the language.

Another thing is that if you're someone very important in a small language, and that language gets big, you become someone very important, period. Again, an incentive to bring people into it.

You benefit from the popularity of the language, not specifically from the people you bring in. In a real pyramid scheme all the people you bring in (and the people they bring in) pay you directly. Nobody else in the scheme helps you, and they may in fact be competing with you for new recruits. You’re also obligated to pass some (or most) of the benefits you receive on to the person who recruited you.

With the above hypothetical, you benefit from more programmers in your language regardless of how they got there, even if someone else “recruits” them, or they were there before you got there.

I took a deeper look at the definition of network effect and you're right.

I used to think this until I really took the time to dig into Rust. Rust has completely snapped me out of this depressing, "pragmatist" learned helplessness that people seem so keen to try to cram down everyone's throats these days.

Could you elaborate a bit? I'm curious precisely what you mean, though I can make some guesses.

Elaborate on what? Rust or the pragmatism stuff?

The "pragmatism" mainly, although I'd also be interested in how Rust specifically doesn't cause learned helplessness.

It's become very trendy these days to be hyper-pragmatic and dismiss attempts to push forward new big ideas or programming languages as frivolous.

"Shut up and give me another 500 lines of PHP, we have (made up) deadlines to meet!"

Oh oh, yes! 100%

I thought that too until I tried to recreate a web API I run at work in rust. Turns out that the language is far less important than having really great libraries. I’ll re-evaluate rust when things like resilience4j and micrometer exist for it.

"Turns out that the language is far less important than having really great libraries. I’ll re-evaluate rust when things like resilience4j and micrometer exist for it."

I agree. Ecosystem shapes how good a given language is right now but the language itself is what provides the long-term ceiling. One very real example is JavaScript. You can write all the JavaScript libraries you want and people certainly have ... but ultimately the language is what it is and many of its users still clamor for something better even after immense investment in the ecosystem.

The footnote about Sapir-Whorf slightly misses the point, I think: I found learning Haskell useful because it made it impossible to write programs the way I was used to on Python. So, I _had_ to learn to think in the paradigm it uses. I’ve mostly written Java and JS/TS for pay, but I now have experience with a whole new way of designing programs that is relatively useful.

The more programming languages I use the less I care about this or that particular language and the more I think it comes down to the atomic level of good or bad features that are often available across different languages.

For example, I was writing some vimscript earlier today. Vimscript supports var-args in functions: bad idea. Dynamic type systems: generally a bad idea. Mixing declarative and imperative code: bad. Fancy comments/docstring systems (javadoc, python test): bad. Complicated type system features (e.g. dependent types): not necessarily bad but often unnecessary. Type casting: sometimes necessary but bad. Optional function arguments/arguments with default values: convenient but bad…

Basically any semantic element that increases the cognitive demand placed on the reader should be avoided. Circling back to varargs, they might be convenient when I’m writing a function initially, but they give readers no information, and it’s not uncommon at all that I have to go back and examine the precise details of how exactly I was using this or that vararg again.

Essentially, the more I program the more I think it’s best to use the simplest features possible and avoid anything fancy unless absolutely necessary, even when the fancy stuff is terser. This is part of what makes c, go, standard ml, scheme (even though I just knocked dynamic types) some of the best languages imo. Sure they are missing a lot of great writer-oriented features that programmers tend to drool over, but their absence is actually what makes these languages better.

Just to add some nuance: simplicity might be a boon for someone/company/industry working with multiple languages, but if you live in the, say, Java world, complexity may pay off for the native residents.

For instance, natural languages develop all sorts of intricacies that are inconvenient for the learners, but expressive for the native residents.

If the frequency of language usage is high, features of previously medium-level complexity become simpler and more “chunked”, due to how many times you have seen them (e.g. decorators in Python). So to Python residents, decorators are simple.

Where does Joel Spolsky pick on boring languages? I went looking for this and could only find him defending the use of Java/.NET https://www.joelonsoftware.com/2006/09/01/language-wars/. Of course that's an old article. (Incidentally the first result of my search was this very article.)

> Where does Joel Spolsky pick on boring languages?

I wonder if TFA is thinking about some of the harsh words Spolsky had for Java (e.g., [0]). That's not a criticism of boring languages in general, but is pretty negative on one boring language.

[0] https://www.joelonsoftware.com/2005/12/29/the-perils-of-java...

Yeah maybe. Although that's more focused on _students_ of Java and ends up being a roundabout/backhanded _compliment_ to Java: "the language is so ergonomic I can't tell if basic students of it are smart"?

He missed the mark too, throwing shade on RoR; today almost everyone on this site depends on a mission critical RoR app (GitHub) that has scaled just fine (I'm aware parts of GitHub are no longer ruby)

It wasn't terribly inaccurate.

"for Serious Business Stuff you really must recognize that there just isn’t a lot of experience in the world building big mission critical web systems in Ruby on Rails" - in 2006 was true

"I’m really not sure that you won’t hit scaling problems" - Twitter's issues scaling Rails are well known

"that’s not a safe choice for at least another year or six" - For many that was true. For example, prior to Bundler (released in 2010), managing dependencies was hairy.

"you’ll be buying 5 times as many boxes as the .NET guy down the hall" - Easy to throw resources at a problem now, but pre-cloud, that required some serious capex, so it wasn't a problem you take lightly. DHH himself has acknowledged Rails needs more resources, as they aren't optimizing for that problem: "Don’t get me wrong, though. I love speed. I especially love free and cheap speed. It’s just that I’m not willing to trade things that are of real, enduring value to get more of a nice-to-have once we’ve long since reached Good Enough. Things like programmer happiness, the eloquence of Ruby, and the productivity of Rails." (https://m.signalvnoise.com/ruby-has-been-fast-enough-for-13-...)

(FWIW, I'm 100% Team Rails these days, but I do think Spolsky's assessment at the time was valid)

Shopify as well that said when you are big enough to care you likely are big enough to have the resources to fix it.

Much like Facebook did with PHP at scale (Hack).

I liked Hack, never used it but it drove a huge amount of change in the PHP ecosystem, 7 was a huge step forward and so was 8 in part because of Facebook.

In general, that team that writes OCaml compilers at Facebook (Hack, Pyre, Flow probably a bunch of stuff I missed) are doing the Lord's work.

No but it wasn't valid. It was a prediction. That was wrong. It had real counterexamples.

You can't cite Twitter as a counter-counter example, because it's definitely not a "boring" problem domain (or, wasn't, in 2006).

If you're going to give a wrong prediction like that a pass, then what the heck is the point of the scientific method?

There were no large apps in Rails at the time Spolsky wrote this. Features that future big apps would use hadn't been written yet. Scientific method requires a theory and the ability to prove/disprove using measurable data.

Yeah the theory is that if it's not boring you shouldn't use it. It was disproven. There's probably a better heuristic model out there that takes into account developer ergonomics, time to mvp, etc.

And no, theories do not need measurable data. Qualitative results can be used to support theories (much of my hard science grad school work was basically a binary "can this happen"? That is not really a measurement in a meaningful sense unless you consider all observations measurements -- I do not).

Well, technically, the Git part of GitHub is written in C.

Yep, but not many are setting up standalone git servers and most people are wholly dependent on the web UI for some nontrivial organizational or personal git management. Either that, or they're using gitlab. Which is also RoR (iirc)

There’s nothing to set up if you don’t need a GUI and are already running httpd/sshd.

Yep. And people generally don't do it. Because they want things the gui. Is this even a serious argument?

in 2006 .NET was only 4 years old, quite young as far as languages/frameworks go

He mentions other things are more effective for leveling up (other things besides learning new languages). What are some of those things beyond "domain knowledge"?

Some things I can think of: databases, architecture, unix tools.

What else do people recommend doing to become a better programmer? I'll admit I've fallen for the "learn esoteric languages" trap for a large part of my journey as a programmer.

.NET is definitely not boring. I've seen some absurd things you can do in C# that still confuse me.

Boring languages have lots of loops and things that are required to have names.

Boring languages don't have to eschew interesting concepts. The problem languages have is balancing abstraction without gaining state and losing performance. Ideally programming would consist of multiple small languages focused on specific abstractions (types, concurrency, functions, etc)

Apparently the only published way to contact Dan Luu is via a twitter account. So, additional notable C++ uses:

  - Gdb
  - SpaceX real-time flight control
  - All fintech (besides FPGAs)
  - Fuschia OS

Gdb and Gcc are interesting as wholly successful drama-free transitions from C.

"All" fintech? Not remotely true. Lots of fintech is written in C#, Java, Haskell, Ocaml, and more.

With "more" notably including Q and other array languages — pretty much as far from "boring" as you can get

It is possible to find isolated instances of fintech in other languages.

Dan's email address is his name @ gmail.com [1].

[1] https://mobile.twitter.com/danluu/status/934880279772258304

> All fintech

Outside of HFT and matching engines at big exchanges exactly what do you think is in C++? Because I don't think what you said is remotely true. C++, if used at all, would be reserved for the smallest, fastest spinning cog, everything else (95%+) in a more human-scalable tech stack.

Not even sure that that super tight inner loop stuff would be in C++ - I think C still rules what hasn't been moved to FPGA's/ASICs.

You may think so, but it turns out not to be the case.

> All fintech

Not all. Source: personal experience.

>When I talk to new programmers, they're often pretty influenced by this

They call it evangelist.

To be pedantic, Calibre is written mostly in Python, not in Java.

BTW: Why is Python not a boring language? Serious question.

Related: What makes C++ a boring language?

It is boring now. At some point c++ and Java were exciting and revolutionary. The basic premise holds, choose technology that has widespread adoption and, to be really effective, that you’re already familiar with.

Java, like Go, was specifically designed from inception not to be even a little bit exciting or revolutionary. That was their whole value proposition. If they ever excited somebody, that would be purely accidental, possibly indicating a miscalibration.

You’re talking about the design of the language. I’m talking about the adoption of the language. C++ was also intended to be very boring, very easy to teach.

False. C++ was designed as a tool for engineering large systems. Even in its earliest versions, it supported a revolutionary feature, the destructor, for resource management, since adopted as fundamental to Rust. It originated useful suppport for compile-time generic programming (at a time when Ada failed to deliver); also lately gaining support in Rust. Except for a quiet period from 1998 to 2011, it has consistently extended the library of techniques now usable for mainstream production systems.

> It is boring now.

Nah

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.

If 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 ...

It'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.

Agree. 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!)

Reply on news.ycombinator.com