Hacker News Reader

Comment by pie_flavor | Hacker News Reader

You draw up a list of checkboxes, you debate each individual point until you can check them off, you don't uncheck them unless you have found a showstopping semantics error or soundness hole. Once it is complete it is implemented and then everyone who had opinions about whether it should be spelt `.await` or `/await` or `.await!()` vanishes back into the woodwork from whence they came. Where's the disconnect?

Rust works like this. Sometimes an issue can be delayed for over a decade, but eventually all the boxes are checked off and it gets stabilized in latest nightly. If Go cannot solve the single problem everyone immediately has with the language, despite multiple complete perfect proposals on how to do it, simply because they cannot pick between the proposals and are waiting for people to stop bikeshedding, then their process is a farce.

View on HN

"despite multiple complete perfect proposals on how to do it"

There is no such a thing.

and this is how rust gains its reputation as an ugly to read language with inconsistent syntax: design by committee

Ugly is subjective, but which part of the syntax is inconsistent?

.await something that looks like a field access but actually does something else

Designs have trade-offs.

In this case, it was important for await and error handling with the ? operator to be readable together.

The order of operations in `await foo()?` is ambiguous, but `foo()?.await` and `foo().await?` have an obvious and clearly visible order. As a bonus, the syntax supports chaining multiple async operations without parenthesis. `fetch().await.body().await` is much nicer to write than `await (await fetch()).body()`.

Since `await` is a reserved keyword, `.await` can't be a field access. Editors with syntax highlighting can easily color it like a keyword.

The problem looking like a field has proven to be total a non-issue in practice. OTOH the syntax avoided major pitfall of visually unclear operator precedence, inconvenience of mixing of prefix and postfix operators, and ended up being clear and concise. It's been such a success, that users have since asked to have more keywords and macros usable in a postfix form.

It's also worth considering that many editors have default snippets that transform something.await into (await something) for languages with prefix await, so it kind of makes sense to cut out the middle man and just make that the syntax to me.

That transformation makes writing both variants similar, but you still need to read `await (await fetch()).body()`, which IMO is much worse.

I don't know if this qualifies as inconsistent, but:

`impl T for for<'a> fn(&'a u8) {}`

The `for` word here is used in two different meanings, both different from each other and from the third and more usual `for` loop.

Rust just has very weird syntax decisions. All understandable in isolation but when put altogether it does yield a hard to read language.

All three have the same underlying idea: do this for every thing of that. In the first case, it's implement a trait for a type. In the second case, it's "for all choices of the lifetime" and for a for loop, it's do something for each element of a collection.

I understand how that seems logical in isolation but it's just not how syntax is usually read by people. It's done so as part of a reading context instead of as separate syntatical tokens. The underlying idea is not the same for the reader because the context is vastly different.

This feels disingenuous. I have a hard time imagining a case where someone would find this confusing.

Sure, and I think that's insightful: what you may consider a mess, I may consider orthogonal!

Rust tends to prefer reusing keywords (in unambiguously different contexts) rather than introducing new ones, because adding a new keyword is a backwards compatibility break that requires a new language edition and creates migration pain for anyone who had an identifier with the same name as the new keyword.

While that's true, all three of these uses pre-date Rust 1.0, so there was total freedom in this case.

I tended to disagree on this discussion in the past, but I increasingly no longer do. For example, let's have a look at the new `implicit lifetime capturing` syntax:

  fn f(x: &()) -> impl Sized + use<'_> { x }

It's weird. It's full of sigils. It's not what the Rust team envisioned before a few key members left.

The only parts of this that I (as someone who has dabbled in rust, but barely interacted with explicit lifetimes, ever) am confused by is

"&()".

And I assume it is similar to some kind of implicit capture group in cpp ("[&]") and "`_", which is a lifetime of some kind. I don't know what the "use" keyword does, but it's not a sigil, and "->", "impl Sized", and "{"/"}" are all fairly self-explanatory.

I will say https://doc.rust-lang.org/edition-guide/rust-2024/rpit-lifet... does not answer any of my questions and only creates more.

It's a reference to a unit type. unit is pretty useless (like void in Java). It's sort of a silly thing you wouldn't do in real production code, just whoever wrote this example picked a type that is short to type, would be understood by a Rust programmer, and doesn't require any external context.

"u8" would have done the job fine and actually been readable

It would need to be &u8, as without a reference, you won't have any captured lifetimes, and therefore it wouldn't serve as an example for the capturing lifetime feature. &u8 is also a mostly pointless type in reality.

Your assumption is incorrect, it‘s just a reference to an empty tuple

Just some examples I thought of:

* Array types have completely different syntax from other generic types

* &mut T has a space between the qualifier and the type, &T doesn’t

* The syntax for anonymous functions is completely different from a function declaration

Whereas Go has taken the approach of designing everything "later".

It's good to have languages with different approaches to design and and with different design philosophies.

To be fair, Go, under the watch of Google, deemed it a finished product as far as the language goes. "Later" wasn't expected to happen. It was complete already. Only when the outside community took control of the project did it start considering new features.

This is the kind of criticism made by people who've spent less than a few days working with a language. Just glancing at some code from a distance. There's nothing actually wrong with it besides being foreign from what you are used to. After you gain some familiarity, it doesn't look ugly or beautiful it just looks like syntax.

Golang is also ugly, for example some fields start with a capital letter and some do not.

Also I don't understand how to implement transparent proxies in Go for reactive UI programming.

you don't Go is explicit about things.

maybe caps for export is ugly, it's not much different from how python hides with _

I find both the golang uppercase lowercase naming scheme and python underscores for private (and __ for *extra* private) to be terrible design choices.

They are hidden functionality, a set of rules which must be remembered. “Make sure to do <weird trick> because that mean <X> in <PL>”

Leave identifier names alone. Packing extra info inside is unnecessary mental burden

the other option seems worse, i dunno if i can use this identifier unless i have an IDE or i look up the definition every time

Also, I recently learned that only leading __ are considered special, whereas both sets of __ go back to being a public method due to the dunder magic methods such as __add__, __eq__, etc

Oh yeah, I didn’t even notice. Much worse than I thought!

Imagine explaining these rules to a beginner learning programming.

It should be mentioned that within the python community using __ for extra private is widely seen as a misfeature that shouldn't've been added and shouldn't be used.

> and __ for extra private

That was never its purpose and using it that way is in fact misuse.

Name mangling was added to avoid unintentional conflicts in inheritance scenarios. That’s why it’s static, simple, and well documented.

"_" does not hide anything in Python. It's just a convention that says "use at your own risk".

If you don't care about field access just always write fields with uppercase. Any APIs you're using only expose uppercased variables as well, so it'll stay consistent.

The public/private stuff is mostly useful for publishing modules with sound APIs.

Isn't "design by popular vote" an extreme version of "design by committee"? Go won't implement error handling syntax because it can't reach community consensus.

Go may take community opinion into account, but just because something is popular doesn't mean the team will accept it. the language designers have the final say, and they will reject popular but bad ideas.

This might be a valid point if Go wasn’t an atrociously ugly and verbose language with some of the worst design out there.

Programming languages are designed systems, they need to make sense holistically. They're not simply collections of tick-boxed features that are expected to be added once their tick-box requirements are satisfied.

This opinion is clearly far more arguable than you might think.

> Programming languages are designed systems, they need to make sense holistically.

Of all the languages in common use, golang is the one that makes the least sense holistically. Return values are tuples, but there's nothing that lets you operate on them. Enums aren't actually limited to the values you define, so there's no way to ensure your switch cases are exhaustive when one is added in the future. Requiring meaningful zero values means that your error cases return valid, meaningful values that can accidentally be used when they return with an error.

!RemindMe in 25 years.

Did Rust become a clusterfuck like C++?

Is Go as timeless as it was during release?

> Go cannot solve the single problem everyone immediately has with the language...

What? Survey says 13% mentioned error handling.

And some people actually do prefer it as is.

https://go.dev/blog/survey2024-h1-results

13% mentioned that error handling was the biggest challenge with using Go. This was not a multiple choice question, but you had to pick one answer. We don't know how many people would consider it challenging. (This is typically why you have a 1-10 scale per choice.)

This doesn't mean the rest of the 87% enjoy it. Honestly, I'd rather the next survey included a question "are you satisfied with the current error handling approach"

I'm as satisfied with the error handling approach as I am for the email address handling approach, the time of day handling approach, the temperature handling approach, etc.

But that doesn't imply that I am satisfied. I do believe there is a lot of room for improvement. Frankly, I think what we have is quite bad. Framing it as something about errors misses the forest for the trees, though.

How would I respond to your query without misleading the reader?

That survey specifically asked for the "biggest" challenge. One could make a compelling argument for the survey answer "learning how to write Go effectively" being an extremely bad option to put on a survey, because it at-least partially catch-alls every other answer. Its no wonder it got first place.

> complete perfect

This is entirely subjective and paints the Go community as being paradoxical, simultaneously obstinate and wanting change.

The disappointing reality is that Go's error handling is the least terrible option in satisfying the language design ethos and developers writing Go. I have a penchant for implementing V's style of error handling, though I understand why actually implementing it wouldn't be all sunshine and rainbows.

No, actually, an operator that's essentially a macro for this entirely boilerplate operation would be less terrible, exactly the same decision Rust made for the exact same reason. So would Cox's proposal, so would others. Doing nothing, as a permanent solution, because you can't figure out which of the better things you should do, is not a virtue. You may be confusing it with the virtue of holding out on simpler solutions while a better solution is implemented, or the virtue of not solving things which aren't problems, but this is a problem and they have intentionally blocked the solution indefinitely.

Rust's try! macro was† "essentially a macro for this entirely boilerplate operation" but the Try operator ? is something more interesting because in the process they reified ControlFlow.

Because implementing Try for your own custom types is unstable today if you want to participate you'd most likely provide a ControlFlow yourself. But in doing that you're making plain the distinction between success/ failure and early termination/ continuing.

† Technically still is, Rust's standard library macros are subject to the same policies as the rest of the stdlib and so try! is marked deprecated but won't be removed.

It's just simply not the cause that error handling is an "entirely boilerplate operation", nor that any kind of macro in Go "would be less terrible" than the status quo, nor is it true that decisions that Rust made are even applicable to Go. Believe it or not, the current approach to error handling actually does work and actually is better than most/all proposals thru the lens of Go's original design intent.

This code:

    foo, err := someExpr
    if err != nil {
        return nil, err
    }

Is entirely boilerplate, and a language feature could generate it (and in Rust, does). This is not the same statement as 'all error handling is boilerplate', which is obviously false, which is why I didn't say that. Condensing that particular snippet down to `?` would be less terrible than the status quo, where the status quo is every function being filled with twenty copies of it drastically reducing readability. The situation is exactly the same as with old Rust, where:

    let foo = match expr {
        Ok(val) => val,
        Err(e) => return e,
    };

Was entirely boilerplate. Rust noticed that this was a problem and solved it. Go's status quo is not better than pre-`?` Rust's status quo; it does nothing pre-`?` Rust didn't. Go just doesn't solve it.

It is not actually the original design intent of Go to make every function 50% boilerplate garbage by LoC. Go is extremely full of 'helpful' happy-path short functions that leave you reimplementing lots of stuff more verbosely the moment you step off the happy path, inclusive of happy paths that do partially the wrong thing. `?` is exactly in line with `iota`, `foo_windows.go`, `flag.Var`, `http.HandleFunc`, etc. I don't know why people respond to literally every Go mistake with 'it's actually not a mistake, you just don't understand the genius', especially since half the mistakes are reverted later and acknowledged as mistakes.

    This code:
    
        foo, err := someExpr
        if err != nil {
            return nil, err
        }

    Is entirely boilerplate

But you'd never write that, you'd write

    if err != nil {
        return nil, fmt.Errorf("some expr: %w", err)
    }

which is _not_ boilerplate, in any sense that would benefit from being mitigated with new syntax or short-cuts.

> Condensing that particular snippet down to `?` would be less terrible than the status quo

This simply isn't any kind of objective or agreed-upon truth. Many people, including myself, believe that the status quo is better than what you're suggesting here.

People who are annoyed with Go at some fundamental level, and who largely don't use the language themselves, delight in characterizing `if` blocks related to errors as "boilerplate" that serves no purpose, and needs to be addressed at a language level.

> `?` is exactly in line with `iota`, `foo_windows.go`, `flag.Var`, `http.HandleFunc`, etc.

I've thought on this at length and I have no clue as to what you think the common property between these things might be. A proposed language sigil that impacts control-flow, an existing keyword that's generally not recommended for use, a build-time filename convention, and two unrelated stdlib type definitions?

You say 'you would never', 'generally not recommended', etc., about things that dominate all code in the wild. Perhaps you do not understand the Go vision. Yes, in both Go and Rust, people should add context to errors; and in both Go and Rust, they don't. Cox's proposal provides something slightly smarter than raw `?`, while Rust was designed smarter from the start and it just takes a library to do that (`snafu` or `anyhow`).

> I've thought on this at length and I have no clue as to what you think the common property between these things might be.

They are examples of the common property I specifically stated in the preceding sentence:

> Go is extremely full of 'helpful' happy-path short functions that leave you reimplementing lots of stuff more verbosely the moment you step off the happy path, inclusive of happy paths that do partially the wrong thing.

(In point of fact you shouldn't use fmt.Errorf if you're serious about errors either; it cannot be usefully inspected at runtime. You want an explicitly declared error type for that.)

> Rust was designed smarter from the start

I guess this makes it pretty clear that there's no useful conversation to be had with you on this topic.

> (In point of fact you shouldn't use fmt.Errorf if you're serious about errors either; it cannot be usefully inspected at runtime. You want an explicitly declared error type for that.)

You don't need a discrete error type to allow callers to inspect returned errors at runtime -- `fmt.Errorf("annotation: %w", err)` allows callers to check for sentinel errors via `errors.Is` -- which is the overwhelmingly most common case.

Exactly; `return fmt.Errorf("annotation: %w", err)` is just a log-friendlier version of `return err`. The original wrapped error is meant for runtime inspection.

The fmt.Errorf expr is wrapping the error, with relevant context at the wrap-site. It's not just "log-friendlier" it's actually important metadata.

I think we are saying the same thing: it is important metadata which is meant for human consumption (as opposed to the wrapped sentinel error) -- hence "log-friendly".

> `return fmt.Errorf("annotation: %w", err)` is just a log-friendlier version of `return err`

This claim isn't true. The annotation-wrapping isn't just about making the returned error 'log-friendlier', it's annotating the error with context-specific information that's useful beyond "log" contexts. More concretely, that kind of annotation is critical if you expect to be able to introspect runtime errors in any way at all -- it's not a "log-friendlier" version of `return err`, it's an important and necessary change vs. `return err` which is in no way perfunctory or whatever.

If Haskell was mainstream and everyone piled in and complained that objects were immutable and it adds so much noise having to deal with that using lenses or state monads or whatever, do we go with democracy or do we say wait.... maybe Haskell was meant to be like this, there are reasons something is a seperate language.

Reply on news.ycombinator.com