This just plasters over the underlying problem, which in case of Rust is IMO that features that should go into the language as syntax sugar instead are implemented as generic types in the standard library (exact same problem of why modern C++ source code looks so messy). This is of course my subjective opinion, but I find Zig's syntax sugar for optional values and error handling a lot nicer than Rust's implementation of the same concepts. The difference is (mostly): language feature versus stdlib feature.

Rust developers are doing an awesome job of identifying those things and changing the language to meet it. Today's Rust is much cleaner than it was 5 years ago (or 8 if you count nightly).

But yes, there is still a lot of it.

Anyway, most of the noise comes from the fact that Rust is a low level language that cares about things like memory management. It's amazing how one is constantly reminded of this by the compiler, what is annoying, but the reason it doesn't happen on the alternatives is because they never let you forget about that fact.

I’m not familiar with zig. Can you give some examples to illustrate your point?

An optional is just a '?' before the type:

For instance a function which returns an optional pointer to a 'Bla':

    fn make_bla() ?*Bla {
        // this would either return a valid *Bla, or null
    }

A null pointer can't be used accidentally, it must be unwrapped first, and in Zig this is implemented as language syntax, for instance you can unwrap with an if:

    if (make_bla()) |bla| {
        // bla is now the unwrapped valid pointer
    } else {
        // make_bla() returned null
    }

...or with an orelse:

    const bla = make_bla() orelse { return error.InvalidBla };

...or if you know for sure that bla should be valid, and otherwise want a panic:

    const bla = make_bla().?;

...error handling with error unions has similar syntax sugar.

It's probably not perfect, but I feel that for real-world code, working with optionals and errors in Zig leads to more readable code on average than Rust, while providing the same set of features.

I don't see how that is all that different from Rust.

The main difference I see is that in Rust it will also work with your own custom types, not just optional.

  fn make_bla() -> Option<Bla> {
    // this either returns a valid Bla, or None
  }

  if let Some(bla) = make_bla() {
    // bla is now the unwrapped valid type
  } else {
    // make_bla() returned None
  }

..or with the '?' operator (early return)

  let bla = make_bla().ok_or(InvalidBla)?;

..or with let_else (nightly only but should be stable Soon(tm))

  let Some(bla) = make_bla() else { return Err(InvalidBla) }

..or panic on None

  let bla = make_bla().unwrap();

How does Zig represent Option<Option<i32>>? Would it be something like this?

    ??i32

I had to try it out first, but yep, that's how it works:

    const assert = @import("std").debug.assert;

    fn get12() i32 {
        const opt_opt_val: ??i32 = 12;
        const val = opt_opt_val.?.?;
        comptime assert(val == 12);
        return val;
    }

[https://www.godbolt.org/z/oncd5shvP]

The problem with this premise is that by raising the bar for any IDE that wants to support that language, you risk the creation of an IDE monoculture.

Is that as true any more with the language server model?

I'm not familiar enough with it to know how much is truely in the protocol vs what the editor still has to do themselves.

LSPs are great, I think they've proven fairly easy to integrate into many text editors. But consider something like the Scratch programming language. How many editors support Scratch? Once you stray from code-as-text, adding support to old editors often becomes infeasible and the effort needed to create new editors is a significant barrier to entry.

JetBrains is doing quite well with InteliJ monoculture.

Like Common Lisp, Smalltalk, SELF, Delphi, C++ Builder, Java, C#, Visual Basic,....

The problem is that most on FOSS community tend to design languages for VI/Emacs workflows.