Hacker News Reader

Comment by troupo | Hacker News Reader

> [] simplifies the parser

Strong PHP vibes. They also went for weird syntaxes that don't exist or rarely exist in other languages to simplify the parser.

It's 2023. How is parsing anything is a problem?

View on HN

Go 1.18 had to run programs written for Go 1.17. What if this is your program:

    a, b = w < x, y > (z)

Is that "a, b = w[x, y](z)" (call function w of with type parameters x and y against z), or is it "a = w < x; b = w > (z)" (assign true to a if w is less than x, ...).

With type information, this is possible to disambiguate, but the goal of the parser is to not require type information. Remember, now if you want correct syntax highlighting your editor has to have the type information, but you haven't typed that in yet!

As always, I think they made the right choice here.

> With type information, this is possible to disambiguate, but the goal of the parser is to not require type information.

Why?

It looks like a pretense at purity for the sake of purity.

Separating parsing from semantic analysis simplifies the parser considerably.

If one of Go's aims was to make different trade-offs than [C++][1] did, then the choice not to use "<" as a grouping operator was a good one.

[1]: https://youtu.be/WfIr7lKT4Sk?t=204

Do you want to parsing your language to require implementing the typechecker and using shotgun heuristics, all so you can use <> instead of []? Compiler writers die for your sins in code. Let them do things that can drastically simplify things everywhere, instead of suggesting that they're intellectually jerking themselves off. Not that they're immune to that.

EDIT: Apologies, after a bit I realized the above is a bad comment.

Separation of concerns is a common pattern in programming. It allows for things to be testable and changes to be more localized. This is an example of that.

lots of things in Go are very annoying, but this isn't one of them. being able to parse the language without type information makes parsing way easier and faster, which you definitely care about in at least one case - syntax highlighting in your editor.

> It looks like a pretense at purity for the sake of purity.

if you go (ah!) far enough on the other direction, you end up with 'template typename' soup.

So you don't have to wait as long for obvious errors. Anywhere near as long, like a couple orders of magnitude in many cases - milliseconds vs minutes.

Allowing ambiguity isn't just a style decision, it pushes error detection later, where you have enough info that it's no longer ambiguous.

Reply on news.ycombinator.com