Hacker News Reader

Comment by david2ndaccount | Hacker News Reader

Rust’s choice of sigils is aesthetically displeasing. Double colons (::) and angle bracket generics are ugly. Unmatched apostrophes is jarring to those used to them being used for strings or character literals. It was an unforced error to imitate C++, which was forced to use those characters due to backwards compatibility with C and the C preprocessor. A new language doesn’t have to use those characters. For example, the D language uses the dot as a path separator for modules, namespaces, templates, etc. as do other languages like Python.

View on HN

> It was an unforced error to imitate C++

Rust spent enough of its weirdness budget on new semantics. I may not be a fan of C++-style syntax, but if your goal is to specifically tempt C++ developers with the promise of safer/saner language semantics, then making syntactic concessions towards familiarity with C++ is the right call. Rust isn't trying to be The One Language To Rule Them All, it's trying to target a very specific domain.

This is almost overly permissive... Yeah sure it looks the same but the semantics are so different that the statement seems... wrong

As someone with a long history of c++ experience I found rust syntax fairly familiar even if some details are meaningfully different. For example, most code you read is very very similar. I found an easier time coming to Rust from c++ in terms of syntax familiarity than swift. I found swift much faster to write code once I actually got my head around it (I also had substantial experience with Objective-C/C++ prior to picking up swift).

I think the strong counter is that you only really learn a language once, but Swift is a bridge from those coming from Objective-C not C++ and tries to hit other language goals so it’s hard to compare. Certainly this is the first real language giving c++ a run for its money in a way that nothing else has before, that’s not nothing, and it’s hard to argue whether the syntax chosen is part of that success or in spite of.

Because Rust is, in effect, a GC-less Ocaml derivative with a coat of cherry-picked C++ syntax as paint.

That's why the semantics are so different. It's more of the lineage that began with ML in 1973 than of the ALGOL 68 lineage like C is.

The Rust compiler was even originally written in Ocaml before it became self-hosting.

That's also where syntax elements like these come from:

- let for variable declaration and postfix type annotations separated with colons

- 'a (Ocaml's equivalent to <T> for generics, because, on an abstract/theoretical level, Rust's lifetimes are a special type of generic parameter, right down to "a" apparently being the habitual default type variable name, just like "T" is in C++)

- Option (option in Ocaml), Some, and None

- match

- fn (fun or function in Ocaml)

- -> and => (just -> in Ocaml) for function returns and match arms

- ()

> if your goal is to specifically tempt C++ developers with the promise of safer/saner language semantics, then making syntactic concessions towards familiarity with C++ is the right call. Rust isn't trying to be The One Language To Rule Them All, it's trying to target a very specific domain.

I wonder how well that's worked out for them. My impression is that there's been a lot more people moving to Rust from Python/Ruby/Javascript than from C++.

Recall that the initial target was browser developers. I've seen what feels like considerable adoption from among Firefox developers. Chromium developers feel very tempted, too. Feels like success!

> My impression is that there's been a lot more people moving to Rust from Python/Ruby/Javascript than from C++

Is there any reason in particular you think a lot of high-level language people are moving to Rust? That is not my impression or experience at all and I struggle to think of any reason to do so besides a large, individual change in career focus. As a higher-level language user myself, I can't think of a single reason I would ever use Rust for anything. Sure, I think it's cool, and it's always good to learn new languages, but in practise it's just not suited to my domain - and I think that goes for the vast majority of us.

I would say golang has scooped off more of the dynamic language types myself, although I also consider it a productivity downgrade and/or cargo cult to mostly be ignored without compelling reason. Which is even more the case with Rust!

Fullstack & Wasm. There comes a point in your career where you're dissatisfied with the capabilities of the warm and friendly upper layers of your stack, and you descend into the cold dark waters where things are hard but fast.

I used to write primarily in highlevel languages, but if you want to write realy interesting high performance stuff in javascript, WASM+Rust is a really neat tech to use. Similarly, with WebGL/WebGPU you need some familiarity with bare metal programming.

I still write a lot of JS, but I regularly drop down to Rust.

I'm migrating everything that's feasible (eg. not stuff where I need Django's ecosystem) from Python to Rust for its combination of a powerful type system that can encode my invariants better than MyPy annotations, sum types, no exceptions, no null, an ecosystem that values "fearless upgrades", PyO3 so my Rust code can be reused in projects that still need Python without me having to get memory-unsafe code right, and not being something as alien as Haskell.

Golang specifically has three things that turned me off as a replacement for Python in the early days before I got hooked on what Rust offers:

1. A disgust-inducing level of boilerplate use for things like error-handling and poor support for metaprogramming. 2. A design that not only lacks things like PyO3, but is implicitly hostile to FFI. 3. Git repository URLs as dependency references and "you figure it out" for ensuring they don't go away.

I think there's a distinction between people making side projects/posting online and professional usage of rust.

There's a lot more Python/JS/etc developers than C++ developers, and Rust meaningfully offers something those languages don't, so I suspect you see a rush of folks from that world going to learn Rust and posting about it online.

However, I generally don't see or hear about Rust being used professionally except in a context where C or C++ would have been seriously considered as well.

Rust is used in production by many high profile companies. You almost certainly are running Rust code, or interfacing with something that does, in your daily life.

Yes, I agree - I didn't mean that the "C++ is a contender" use cases are few, in fact the opposite. Just that I don't see a ton of of professional "We wrote our Postgres CRUD app in Rust for reasons". I'm sure a few have, but that's a harder choice to defend that using Rust instead of C++.

D fell into the same trap. D 1.0 started as a relatively simple language mixing OOP and basic template semantics and attracted many people from Java/C# backgrounds. But with D 2.0 they started to appeal more to C++ programmers. Advanced template metaprogramming, even language features were added to make it easier to interop with C++, in hopes that C++ programmers will transition parts of their apps to D.

In the meantime, chasing C++ programmers introduced problems. Template heavy code means that IDEs can't follow it well and there's problems with compilation time. C++ programmers never were keen on GC so D tried to introduce GC-free semantics for the language which aren't complete.

I don't think C++ programmers in general are worth chasing. If they stuck with C++ for such a long time, it means they are used to it and accept C++ with all its flaws. It's also my impression that Rust is attracting more JS programmers than C++.

> If they stuck with C++ for such a long time, it means they are used to it and accept C++ with all its flaws.

This is also partly because there was never a language that fit the niche where GC isn't a good fit that brought enough to the table in the eyes of that space. Even today some improvements like being able to avoid UB or seemingly high level features like pattern matching are looked upon with suspicion.

> It's also my impression that Rust is attracting more JS programmers than C++.

I think this is a testament to how successful the efforts to bring high level constructs to the systems space have been, as well as the ongoing efforts to make the system level features be ergonomic and usable by as many people as possible.

If you have a theoretically perfect language that only three high priests in an ivory tower can use, then you don't have what Rust is trying to be.

> I don't think C++ programmers in general are worth chasing. If they stuck with C++ for such a long time, it means they are used to it and accept C++ with all its flaws

People don’t use C++ because it’s convenient and easy, they use it because it’s one of the best widely used options/ecosystems if performance really matters.

Any other language targeting this space has to chase C++ users because C++ is so prevalent. It would be like coming up with a new general purpose dynamic language and not appealing to Python users, or a new stats modeling language and not appealing to R users.

<> are the worst characters for generics, except for all the others that have been tried. () leads to the type syntax being difficult to distinguish from value syntax, which is great in dependently-typed languages but bad elsewhere. [] is already used for slices, albeit in a different way; and C should be objection enough if you want to make types look like values. {} is a nonstarter because it leads to ambiguity between return type and function body, and in an everything-is-an-expression language, once again we are back at types-look-like-values. There are no more matched pairs left on an ANSI keyboard.

Personally, while I hear you that :: is ugly, I do really like being able to distinguish module paths from value paths at a glance. And when looking for an alternative, we once again run into other characters already having far more familiar conflicting uses, or just being too weird. (E.g., # or @ could have been used, but that's probably worse than ::.)

To be fair, arrays and slices are probably uncommon enough in current code that they shouldn't get exclusive use of the [] brackets. They could just be a generic type like any other.

Scala uses [ ] for generics, works well. I think you're right that array access is a rare case, definitely doesn't deserve its own reserved characters. And [ ] tends to mean "crash if out of bounds", crazy to have gotten its own reserved characters :-)

And that's why we have Unicode!

    Vec⟪u8⟫
    Vec｢u8｣
    Vec⟦u8⟧
    Vec༼u8༽

I'm sure this could open up a whole new frontier of exciting, untypeable language designs. If it works for APL, it should work for any language!

Or that's why we have digraphs. `Vec[\u8\]` or `Vec[.u8.]` may have worked (these examples are from Fortress [1] and Nim [2]).

[1] https://homes.luddy.indiana.edu/samth/fortress-spec.pdf#page...

[2] https://nim-lang.org/docs/manual.html#lexical-analysis-other...

Nah, <> are much worse, because they are syntactically binary operators.

[] are already taken by the slicing syntax, but if that wasn't the case you could have something like vec@2 and vec@{end - start} for that, which would open them up for generics. I'm pretty sure the main reason to choose <> was familiarity above all else.

<> are obviously already used for less than/greater than, so they're disqualified too by this logic.

If you broaden your viewpoint, [] is the same thing for arrays and generics. A generic function is a family of functions parameterized by types; an array is a family of values parameterized by 0..n; [] selects one member of the family. In fact in math subscripting is already a common notation for the parameter of a generic.

Same for paths using dot, it's just member access on a module object. In languages like JS or Python it's literally just normal runtime member access. In Zig it's also just normal member access on a comptime object.

The exclamation mark choice seems poor as well. It’s something one would associate with something extraordinary, like an exception.

Seeing it in code all over (as a beginner…I’m sure after a while you get used to it), it screams danger to me every time I encounter it in code.

It means "DANGER: This may hide an early return or other things which violate the expectations for how control flow works."

Angle brackets aren't that uncommon, are they? Swift is a modern, elegant language that uses angle brackets for generics. Fortunately it uses the period instead of the double colon (thank goodness for that!) but I don't see anything ugly about brackets.

It's directly responsible for Rust needing the "turbofish" syntax to pin down generic return types as in

let foo.iter().map(|x| x*2).collect::<Vec<_>>()

If they'd used something like [T] for generics, then there'd be no collision with the < and > operators needing disambiguation in some contexts.

They even have a Book of Mozilla-esque entry in their test suite named "Bastion of the Turbofish" to pin down an example of the problem case, complete with

https://github.com/rust-lang/rust/blob/43192ca3d72ed0ca42ba9...

I don't think that's true - .collect[Vec[u8]]() - here you might be accessing property collect and taking the value at index denoted by the item of Vec at position denoted by the variable u8. And at the end calling the resulting thing? (That's not actually valid in rust afaik, you'd have to wrap it in parentheses like this `(...collect[])()`)

That is actually valid Rust, and it works exactly as you said:

https://play.rust-lang.org/?version=stable&mode=debug&editio...

The argument that generics should have used [] generally goes hand in hand with the argument that [] for panicking indexing is a wart on Rust's "pit of success" design philosophy and that panicking indexing should have been more verbose to type than the .get() for Result-returning indexing... but probably less verbose to type than the `unsafe`, potentially UB-inducing `.get_unchecked()`.

> Unmatched apostrophes is jarring

Welcome to Lisp! 'x means (quote x)

'(+ 1 2) evaluates to (+ 1 2)

I like angled brackets for generics but hate double colons. I assume it's because I'm coming to Rust from C# though? I wonder how C++ devs learning Rust feel.

I don't know if it's just me, but find angle brackets really hard to read. Many times I just miss the ending one, because they have the same height as normal characters, so they don't stand out.

That's a font issue. In proper type setting, angle brackets are different from normal less/greater than characters. An IDE with good in-built parsing could use variant forms for <> characters as used in generics, as opposed to relational operators.

Yes, but syntax decisions of programming languages shouldn't rely on such things. I would've preferred square brackets for generics (and something else for indexing).

«..» Always seemed like a good solution to me, from a readability perspective. But I think many will object on account of being too hard to type (which is not unreasonable; on my Linux machine it's "Compose <<" and fairly easy; I'm not sure how hard/easy it is on Windows or macOS, but even if it's easy I think most people don't know it's easy and will still make the language harder to learn).

It would have worked in C++ to use the . for them, too.

I had the same initial opinion about the '.' Vs. ':' for module separation. Why add weight to make this distinction?

However, after over a year of coding Rust every day, I now really appreciate the distinction. It's an effective way to give a meaningful context point at a very low cost.

I was wrong again! Which has been a consistent pattern with my initial Rust appreciations.

Reply on news.ycombinator.com