Hacker News Reader

Comment by beeforpork | Hacker News Reader

Why use Rust syntax (fn, x:Type, ...)? Syntax is one thing that is not so well-designed in Rust (in my opinion). Also, with the stated goals, it seems a bit unnecessary to overhaul C++ syntax, but then I found no explanation why syntax was changed. So what's wrong with C++ syntax if your goal is a successor of C++?

This now looks to me like a Rust-- instead of a C++++, which is a picture they might not want to give rise to. Because then I'd rather use Rust instead, which then feels like the real thing(tm).

[EDIT: If you think about downvoting, maybe answer instead as I am genuinely interested in this syntax question. I am not trying to be negative, it was just an observation and a question.]

View on HN

It's not just Rust syntax. `name: Type` is the syntax used in TypeScript and Python type annotations (also Ocaml, which is probably where Rust got it from). Golang drops the colon, but still keeps the name first.

As for what's wrong with `Type name(constructor, args)`? A lot of tooling wants to be able to parse "mostly-valid C++", like IDEs and compiler diagnostics. Sure, once clang's type inference is finished, the lexer hack and most vexing parse aren't problems, but when the program isn't complete, parsing isolated fragments is impossible, and that limits the amount of useful tooling the language can have.

OK, I see. Yes, C and C++ syntax is definitely ambiguous without semantic analysis. Maybe this could also be explained somewhere.

And to add, the `name: Type` syntax is not just a modern fad, don't forget the OG language that did this: Pascal! (https://en.wikipedia.org/wiki/Pascal_(programming_language))

The syntax `name: Type` is also friendlier to type inference as you generally have a token indicating a declaration. If you have `var x: Type = …` then you can just omit the type and let inference do its job.

Even better, when you start having more complex patterns on the left-hand side of `=`, you can type annotate them as you want. Hypothetical syntax would be:

    var (x: f32, y, [z1,z2,z3]) = SomeExpression();

That's harder to do when you have a type declaration on the left imho.

It would make sense if Carbon started allowing omitting ": Type", which they currently don't: https://github.com/carbon-language/carbon-lang/blob/trunk/do...

On the other side `name:Type` doesn't allow an IDE to suggest a name based on the type, because you type the name first. Also setting values looks pretty confusing. I claim writing the type before the name is much more readable. Compare

    five: integer = 5

    integer five = 5

> I claim writing the type before the name is much more readable. Compare

I claim writing the name first is much more readable. Compare

    integer five = 5

    five: integer = 5

There is a lot of Rust in the Carbon syntax.

`fn`, `name: Type`, `i32`, `->` for return type. `impl` as a keyword. `Self` as a keyword.

Nothing unique to Rust, but it's interesting to see.

C and C++ are infamous for being harder to parse than it's reasonable. C has lots instances of context dependent syntax where code changes meaning depending on what a name is.

You can parse Go without a symbol table, but not C, because stuff like

  item *a;

changes completely in meaning depending on the existence of a previous typedef for `item`.

C++ in order to not break compatibility with C has elevated this to insane extremes - there's so much ambiguous syntax in the language.

  x = b.get<item>(r);

This expression can either be a function invocation, if `item` is a type and a template method named `get` exists, or else it's a series of comparisons.

  item f(r, f);

is also ambiguous: if r and f are types, that's a function, otherwise that's a variable declaration. There's no way to know that unless you have a symbol table, which makes separating syntactical and semantic analysis impossibile at best.

The whole C++ language is full of similar ambiguities, and attempts to fix warts that backfired spectacularly. That's also the reason why writing a C++ frontend is a decade long endeavor that takes lots of people and resources. A full time team of 3 people can probably write a C parser in a few weeks in comparison, and C is big mess too, albeit a smaller mess though.

A blog post by Roman Elizarov (Kotlin designer) on the observation of types following the variable name [1]. It mostly states that having consistent length prefixes (fn, val/var) makes the code more readable than arbitrarily long type identifiers (in the eye of the beholder). Not scientific, but interesting.

[1] https://elizarov.medium.com/types-are-moving-to-the-right-22...

Fixed prefixes also make a codebase significantly more grep-able. Want to find the definition of the function named `foobar`? Search `fn foobar` and that will always match, no regex required.

Only if you use a code formatter (which you should) because otherwise there will be some 'fn foobar'(two spaces or more) just to annoy you..

While I think rust has some serious issues with syntax (and I love rust), the things you've pointed out here are not rustisms, but programming language theory-isms.

x:Type has been used in MLs (SML, Ocaml) and recently TS. Haskells uses x::Type. This usage dates back to at least the simply typed lambda calculus in the 1930s.

fn and fun are used in SML and probably elsewhere. fun is used in OCaml, as well.

From the "Why build Carbon?" section:

> The best way to address these problems is to avoid inheriting the legacy of C or C++ directly, and instead start with solid language foundations like a modern generics system, modular code organization, and consistent, simple syntax.

That last part seems to imply that the authors don't consider C++ syntax to be a good foundation for a modern successor language, so they chose to change it. As to why change it in a Rust-like direction I'd imagine that it's both because it's what fashionable at the time and possibly to attract people who are already familiar with that style.

They could have went the C# route, but didn't

Go authors put out a good post explaining the problem with C syntax and contrasting it with Pascal/Go/Rust syntax: <https://go.dev/blog/declaration-syntax>

Indeed, syntax only a mother could love. (Swift, I am looking at you, too.)

C++++ is C# (notice how the four pluses can be arranged to form a #)

C#++ would be the next one, but I'd pull what Microsoft did to Windows 9 and skip right to C##.

Knowing my music theory though, C## is just D.

not sure on this one, on my keyboard there is a halftone to get D from C so I believe it's more C# = D ?

I can't handle [] syntax for generics. It makes code unreadable as far as I'm concerned because it makes it twice as difficult to know if I'm dealing with an array indexer or a generic.

The rest I can excuse but [], I cannot. Same reason I won't touch Nim.

I can't handle <> syntax for generics. It's impossible to auto-pair and looks ugly.

The real solution is [] for generics and something else for indexing.

When looking for eleguant solutions: look at D, it's full of pearls: they use !() for generics.

Using function call syntax for array indexing always made sense to me. Functions are mappings from inputs to outputs, and arrays are mappings from indexes to values.

I agree, but explain that to programmers who think parametric polymorphism is too complex.

Given that one of the languages that historically used the same syntax for array access and function invocation since day one is BASIC, I would dare say that it's not a complicated concept.

Reply on news.ycombinator.com