[ok123456]

This pretty much mirrors my experience. Rust is the inverse of Perl: It makes the easy stuff hard.

Writing basic data structures isn't a niche, esoteric edge case. There may be a crate that "solves" what you're trying to do. But does it rely on the std---(i.e., is it unusable for systems programming)? Is it implemented making gratuitous copies of data everywhere? Does it have a hideous interface which will then pollute all of your interfaces? Does it rely on 'unstable' features?

Then, there's the 'community.' It seems to consist solely of extremely online people who get a dopamine hit from both telling people they're doing things wrong and creating the most complex solutions possible. They do this under a thin veneer of forced niceness, but it's not nice at all.

[hgs3]

> It seems to consist solely of extremely online people who get a dopamine hit from both telling people they're doing things wrong and creating the most complex solutions possible.

I've observed that certain programming languages have a culture of complexity. I'm not sure why this is. I can only speculate its because these programmers are working on "boring" problems so they make busy work for themselves OR their beginners who think this is how "real programmers" work.

While I think calling them "idiots" is a bit strong, I think this quote from the late Terry A. Davis is worth remembering: “An idiot admires complexity, a genius admires simplicity [...] for an idiot anything the more complicated it is the more he will admire it, if you make something so clusterfucked he can't understand it he's gonna think you're a god cause you made it so complicated nobody can understand it.”

[kaba0]

I don’t know, people who go too hard on simplicity often don’t even grasp the underlying problem in a given case (looking at this utterly dumb piece of text as an example: http://harmful.cat-v.org/software/) - sure, no sane people would want to deliberately introduce complexity/abstractions, but abstraction is the only weapon we have against complexity. Problems have an inherent complexity which simply cannot ever be reduced. If you do have to make it work, what else can you do?

I think go is a good example for this fallacy, it claims that it is a simple language, but ad absurdum asm should also be trivial to understand as every line is also easy to grasp, right? Low expressivity just creates chaotic complexity, won’t reduce it.

[yung_steezy]

Some people seem to really struggle to understand that abstraction is intrinsic to computer science. Trying to get as close to the metal as possible while using your daily driver is a fun hobby but there is nothing innately virtuous about it.

[ternaryoperator]

I quite agree. I take it a step further: I think devs should be taught how to handle complexity better. It's a skill that some programmers have and that others sorely lack, but AFAIK, it's not a skill taught at all in CS programs.

[scoutt]

Complex problems and complex solutions are two different things. The genius is in solving complex problems with simple solutions. While it might seem that adding a crate to solve a problem is a simple thing, from the system programmer point of view (mine), it is not.

[kaba0]

But it is simply not possible to solve many many complex problems with simple solutions, no matter how hard you try.

Also, using a (hopefully) well-tested library that someone wrote is absolutely a good (and only significant, as per Brooks) way to increase productivity - but also correctness! Do I really have to write a matrix library myself? Sure, I can probably write a function that multiplies two matrices, but will it have sane numerical stability? [1]How can I even test that out? It is a whole separate field, where I likely overestimate my knowledge about. Was it really worth that extreme amount of time to write an almost surely buggy and slower implementation than depending on someone else’s work?

The art of programming is also about knowing when to reach for other tools.

[1] Hell, multiplying multiple matrices already “needs” a dynamic programming algorithm to decide how to associate pairs of them

[scoutt]

I would definitely do like you and reach for math libraries/crates whenever I can, since I suck at complex math. But this also means three things: there is the chance we are both no geniuses, we added a complex "black box" solution (who knows how this library/crate work?) and now we have to babysit a dependency.

[javajosh]

>abstraction is the only weapon we have against complexity

I don't agree with this. We also have stinginess and stubborness as potent weapons against complexity. If we are stingy with our time and effort then we insist on getting much use out of every tool we learn. We are stubborn, and so we do not add new tools quickly, or throw old ones away quickly, and we are skeptical of easy solutions. tldr: first cut away needless complexity, then use abstraction on what remains.

[kaba0]

Do note that I was talking about essential complexity, not accidental. The latter can and should indeed be dealt with.

[ok123456]

Terry would have probably used a word stronger than 'idiots'.

[doodlesdev]

Insanely enough, he was quite lucid (at least compared to other live-streams) when he said this quote, so no n-words there. [0]

[0]: https://youtu.be/k0qmkQGqpM8

[mustache_kimono]

> Rust is the inverse of Perl: It makes the easy stuff hard.

It's a bargain. Rust is pretty great, but it doesn't make some things easy because it would make everything else hard.

This comment is amusing, mostly because Perl is so full of tradeoffs. Do you want to write something to do some string parsing quickly? Great language, maybe. Do you want to understand what you've written later? Maybe not so great.

> Writing basic data structures isn't a niche, esoteric edge case.

Not if you're using C, because the batteries are definitely not included. Want a resizable array, or hashmap? The answer is DIY. Not in the std library. Whereas all are provided by default in Rust. Picking a basic data structure off the shelf is a pretty nice feature for most applications.

That said -- should you really need a custom implementation of a linked list, and you need to write and rewrite such an implementation all the time -- I'd understand if Rust wasn't your first choice.

> Then, there's the 'community.'

And I'm not sure anyone loves this attitude either. Keep it technical.

[mwcampbell]

> And I'm not sure anyone loves this attitude either. Keep it technical.

Still, we, the Rust community, should take the high road and respond to the criticism by assuming that it's valid and asking what we can do better. I, for one, don't want developers to reject my Rust-based library because of the community's reputation, especially once my library has a C API.

[mustache_kimono]

> Still, we, the Rust community, should take the high road and respond to the criticism by assuming that it's valid and asking what we can do better.

I have to disagree. I think this meme/issue has been talked to death. And I'm sure I find retrograde, sour-pussing about Rust just as distasteful as others find dewy Rust optimism. The answer is -- they're both silly. Draw the line at speaking about the tech or the comment or person in front of you. Speaking about stereotypes in "communities" is about as vacuous as a Valley Girl's/Perl programmer's head[0].

[0]: a joke!

[spoiler]

But also, where is this malevolent, toxic Rust community that disgruntled C++ developers always engage with? I've yet to encounter a single person from this unstoppable force of sanctimonious assholes ruining everyone's fun on non-Rust projects. By their accounts Rust is a mental health catastrophe for our industry.

Anyway, shit posting aside. I do agree with them that the Rust community is a bit eager to suggest rewriting stuff in Rust.

However... I think this has always been the case for every developer who likes a language. I've seen Ruby devs talk with a passion for Ruby, and Elixir devs about Elixir, and Haskell devs about Haskell. You get the point.

Except I suspect Rust just incredibly grids the gears of some C++ devs. I see how it can be irritating, especial if they've decided C++ is the language they "settled in" with. There's the implied (and irrational) existential threat that this new technology is going to ruin their future prospects. This is probably subconscious and also completely irrational. C++ is too big and too commercialised to go away anyway.

I've seen a similar thing when TypeScript was being adopted and I was pushing for TypeScript (or Flow) adoption at work.

Some people seemed to have an allergic reaction to any mention of TypeScript.

There was people calling the TypeScript community toxic, immature, incompetent, holier-than-thou for arguing why types make code easier to maintain and write. And some of the arguments were they don't want to use the language that had such a childish community.

Edit: On second thoughts I feel a bit like an asshole too, and a bit regretful and ashamed I stooped so low to even write this comment. Others wrote more level headed replies than I did, too. Anyway, let it serve me as a reminder not to engage with trolls in the future.

[pjmlp]

As polyglot dev, with love/hate relationship with almost any language worth using, until Rust gets free of "my compiler compiles yours", there is always an attack vector from those devs.

It was like this during the Usenet flamewars on C vs C++, and while I rejoice most C compilers now being written in C++, there are a few domains where C++ failed to take over C.

Rust advocacy strike force would do better to learn from history of programming languages adoption.

[scoutt]

> until Rust gets free of "my compiler compiles yours"

I would better argue that "your Rust program runs on top of my millions of lines of C code, so please pass to my C API a pointer or a reference to a pointer so I can screw it up, and now all your safe code guarantees are out of the window".

[ksec]

I wish more of the Rust Community are like you and own up to the issue. And then I wouldn't have to keep repeating the same thing like I am a troll. The "Keep it Technical" has been the Rust community answer for years, is basically asking the rest of world to tolerate RESF ( Rust Evangelism Strike Force), while any push back against Rust ( or specifically RESF ) are "un-helpful" and they take zero tolerance. So I should tolerate your ideals while you have zero tolerance with mine? Does it sound familiar to some real world Silicon Valley politics?

The only reason why some are suggesting they haven't seen RESF recently, is because it has gotten to the point where the backlash, which used to be a minority and voiceless finally becomes the mainstream. And so they back down.

And to the original question, and in my previous comment, when was the last time you saw people telling you to use Zig in a Rust thread? ZERO. The comments are mostly, if not 99% about how they couldn't deal with Rust's complexity, they call themselves an idiot and they only wanted a Better C, which the answer to that question is always Das C, Zig or some other contenders. In which Rust Fans will always find it offensive. Even mentioning Ada / SPARK being a languages aiming for correctness is somehow "trolling". And it is not the first time I have been told to stop mentioning Ada.

And yet, how many times has Rust Supporters came into a Zig thread ( or other language ) telling the world how Zig / X is memory Unsafe and Rust does it better? To the point so detrimental that they founder of Zig is crying or begging publicly to give Zig the language some breathing space?

And finally I want to add, HN has a link for front-page [1] where you could visit every post that was listed in the front page. And comments as well as user post are not deleted unless specific circumstances which requires Dang to manually operate. i.e All the evidence are still there.

[1] https://news.ycombinator.com/front

[mustache_kimono]

> The "Keep it Technical" has been the Rust community answer for years

Because it's a better answer than smearing a group of people.

> So I should tolerate your ideals while you have zero tolerance with mine? Does it sound familiar to some real world Silicon Valley politics?

I will say that your argument does feel like modern American politics in one way I notice -- it's all about vibes. It doesn't have anything to do with anything technical. It's all about how people (sometimes transitively) made you feel. And I'm sorry someone made you feel that way, but I'm not sure the way you're acting is conducive to feeling any better.

[ok123456]

> And I'm not sure anyone loves this attitude either. Keep it technical.

If I didn't include that proviso, I'd have someone arguing with me to the death about how I'm completely wrong and an idiot who doesn't understand the Correct Way of doing things.

[rat9988]

This is the same as people behaving as jerks claiming that other people are jerks.

[ok123456]

It may be "not nice" but it's an accurate and sincere appraisal.

[saurik]

If you define "being a jerk" to include "calling out someone for being a jerk" then you will never be able to improve the situation.

[nindalf]

They’re not just calling out though. They’re condescending with their “airquotes”, they’re stereotyping with their broad strokes.

It’s not useful criticism to simply say “this community was such-and-such”. I’d expect them to do better. Speak specifically to people saying something you disagree with. Don’t let it fester within you and then take it out on a broad group.

And I know you didn’t do any of this, but you did seem to be defending some pretty low quality behaviour.

[loeg]

> [Rust] makes the easy stuff hard.

I totally disagree with that claim. The easy thing to do is not use unsafe Rust. You can use stringly-typed datastructures with lots of refcounting or copying, just like Perl, without ever venturing into unsafe Rust.

> Writing basic data structures isn't a niche, esoteric edge case. There may be a crate that "solves" what you're trying to do. But does it rely on the std---(i.e., is it unusable for systems programming)?

In what world is Perl suitable for systems where possible memory allocation is a problem?

[eldenring]

> Writing basic data structures isn't a niche, esoteric edge case

Maybe it isn't an edge case (although it should be) it also isn't `easy` in a non GC'd language, and a huge source of memory bugs.

I wouldn't say it makes the 'easy stuff hard' as much as the 'hard stuff appropriately difficult'.

[adamrezich]

why should writing a basic data structure be an edge case? …what?

[TheCoreh]

All of the "basic" data structures are already provided by either the standard library or crate ecosystem, so you'll rarely (if ever) need to write your own linked list or hash map from scratch.

I say "basic" in quotes because once you factor in the concurrency, ownership and memory safety concerns that are optional in other languages, but mandatory in Rust, there really isn't a simple implementation of these structures that is provably correct anymore.

[GrumpySloth]

Rust is supposed to be a systems programming language. If writing basic data structures was an edge case in it, the language would be broken. Luckily, in my experience it isn’t (at least not in this way).

[adamrezich]

I'm glad you posted this, I was confused as to whether "basic data structure" meant something different to Rustfolk than it did to the rest of us.

[DeathArrow]

Writing data structures is trivial in C/C++.

[pie_flavor]

As long as you don't care about UB or edge cases. Every time Rust makes something hard, it's forcing you to handle an edge case up front.

[DonaldPShimoda]

It's blowing my mind how many commenters here don't understand this.

Rust isn't hard just for fun. It's hard because the code you've been writing for so long is actually bad and you've not been thinking it through appropriately. This is why we keep finding serious bugs in code that is decades-old, despite the belief that code so old must be well-tested by now.

[indymike]

> we keep finding serious bugs in code that is decades-old

I'm sure of one thing: we will find many and different bugs in decades old rust code one day, too. The problem with software is that it has code in it ;-)

[hn92726819]

Difference of course being that zero of these bugs will be due to buffer overflows or use after free or other memory bugs in safe rust, which is a huge source of bugs in C[1].

I don't understand why this argument keeps coming up. Not all bugs are the same and when you make entire classes of bugs unrepresentable, that's a massive win, especially when they happen to be the class containing >60% of the highest severity bugs in C.

https://www.chromium.org/Home/chromium-security/memory-safet...

[kaba0]

While I do like Rust, let’s not forget that it indeed “forbids” to a degree many code/lifetime structures that are extremely common in basically every other language.

I believe the tradeoff for this in Rust’s niche is absolutely acceptable, but it is still a tradeoff and might not be the correct choice in certain cases.

[loeg]

It's in part hard because the borrow checker isn't omniscient and accepts only a subset of safe programs. There are also some concepts it's difficult to explain to the borrow checker. Both of these are things that make writing programs harder in Rust that do not add any safety value, and it's ok to acknowledge that.

[haberman]

That would be true if Rust was a perfect language, but it isn't (no language is).

Sometimes Rust makes things hard because the invariants you want to express cannot be cleanly mapped onto Rust's type system. I described one such case here: https://blog.reverberate.org/2021/12/19/arenas-and-rust.html

[Tarq0n]

Not strictly true. Rust makes things hard by making you design within the limitations of the borrow checker, and some of those are accidental, not a necessary edge case.

[bigbillheck]

Writing correct ones is not.

[dathinab]

> Writing basic data structures isn't a niche, esoteric edge case

writing data structures _properly/well_ was never easy

it just looks easy and is nearly always a sub-par solution

e.g. a list in many lisp like languages seems simple, until you look under the hood what magic tends to be used by more advanced compilers to make that list work fast

the think people most commonly got wrong which was supposedly easy when programming when I was school/stadium where data structures, even comparatively simple ones like double linked lists

it's like sorting, sure you find docents easy to implement sorting algorithms everywhere, but then when you look at the properly implemented sorting build ins of standard libraries their complexity is hundreds of times that of quick sort or similar

[xxpor]

>Writing basic data structures isn't a niche, esoteric edge case.

It very much should be though! That's exactly the type of thing that should be written once by someone who knows what they're doing, and then reused 1000000 times. People slapping together a quick data structure is a huge problem in C.

[ilrwbwrkhv]

On top of that Rust might be the ugliest modern language.

[zamalek]

That is extremely subjective. I find the syntax extremely easy to read, and there are significantly fewer edge cases than nearly all other mainstream languages:

* Why does C# require a break; under switch?

* What about the "Most Vexing Parse"?

* Why does Zig change capitalization of @import and @TypeOf?

Rust is an extremely "guessable" language. It's highly likely that experimenting with syntax will succeed in Rust, which is a syntax feature that I have seen nowhere else.

[somethingor]

@TypeOf returns a type: https://ziglang.org/documentation/master/#Names

[edflsafoiewq]

> Why does Zig change capitalization of @import and @TypeOf?

TypeOf returns a type. Corresponding to how type names are uppercase.

[stouset]

People keep saying this and I just do not get it. It's just… not that bad?

[jcranmer]

I suspect the things that people are reacting to are a mixture of the following:

* Types in Rust use prefixing to create derived types whereas C family languages generally use postfixing. A pointer is i32, not int; an array [i32; 5], not int[5], etc. This makes special characters appear more heavily at the beginning of the scan line, and probably makes them slightly more noticeable as a result.

* Lifetimes have the form 'a, and that single quote is likely to bother a lot of people (I know it bothers me).

* Unqualified name lookup in Rust is a bit weaker than other languages, which makes the scope operator (::) more common.

* Passing in explicit generic type arguments for a function requires an extra :: for seemingly no reason.

* Similarly, macros require an explicit ! in the name to invoke. Given that println! (and formatting in general) is a macro and not a function, this means you get a lot of extra uses of ! that's unexpected for C family code.

* Again, the try operator (also decently common) is another random special character.

* Attributes also use #[] syntax, or sometimes #![]. While C++11 did use [[]] to designate its attributes, it's also something that always felt a bit ugly to me personally (I find the @Decorator() pattern from Java or Python to be a visually cleaner way to do attributes).

In short, Rust generally has a higher density of special characters than other C family languages, and I think that contributes to a sense of ugliness.

[q3k]

> * Passing in explicit generic type arguments for a function requires an extra :: for seemingly no reason.

There is a very good reason for this. Behold, the Bastion of the Turbofish.

https://github.com/rust-lang/rust/blob/master/tests/ui/parse...

[loeg]

That is not a good reason as far as end users are concerned.

[pie_flavor]

It's not about actual ugliness, it's just something that is hard to articulate as something other than ugliness. https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html

[DonaldPShimoda]

It's amusing to me that many of the people who complain about the aesthetics of Rust's syntax are quick to also say bad things about, like, Haskell, or Lisps, or other languages with comparatively low syntactic overhead.

I think the thing people don't like about Rust is that it looks vaguely C-like but is clearly not C. People might like it better if it was further removed (aesthetically) from C's syntax. But then they would also complain.

I think there was no way for Rust to meet all its semantic goals and also make people happy about the syntax.

[flohofwoe]

Typescript and Zig are two other languages that look vaguely C-like (even though they are on two opposite ends of "C like"), but both are a whole lot easier on the eyes than most Rust code.

C++ on the other hand also is vaguely C like, but can look equally messy as typical Rust code.

OTH I find Makepad's Rust style very readable, but I can't quite put my finger on it what's different from other Rust code bases:

https://github.com/makepad/makepad

[throwawaymaths]

Languages on the two ends of the spectrum are "not that great", IMO. Lisp is awful because even though there are very few greeblies, it introduces a TON of cognitive overhead, because you need to be constantly thinking about what something is, because the layout is TOO uniform. Rust on the other hand has a lot of greeblies and you have to remember what it is and what they do. For example macro attributes (and all their hidden effects) as well as the turbofish. Even some things like -> for the function body are simply unnecessary.

[jasonjmcghee]

I'm going to assume, based on when he said "As a slightly more serious and useful exercise" and then proceeds to remove each piece of the code that's intentionally there for performance and safety, that the whole post is satire?

[munificent]

The second sentence of the post is the thesis: "I think that most of the time when people think they have an issue with Rust’s syntax, they actually object to Rust’s semantics."

By removing the ugly "syntax" (and thus also removing important semantics), they're showing that the reason Rust has a lot going on syntactically is because the code is actually expressing important semantics. You can't have a nicer Rust syntax without losing semantics in the process.

[foldr]

One random thing that bugs me about Rust's syntax is array initialization. In Go I can initialize an array (or strictly speaking a slice) of structs like this:

    var foo []my_struct = {{"foo", 1, "bar"}, {"foo", 1, "bar}, ...}

This is often useful in tests (where each struct value represents a test case). Rust doesn't seem to offer any similarly compact initialization syntax for arrays or Vecs. You have to write some abomination like this:

    let foo = [MyStruct{a: "foo", b: 1, c: "amp"}, MyStruct{a: "bar", b: 1, c: "fff"}, MyStruct{a: "amp", b: 1, c: "aaa"} ];

Sure, it's more explicit. But even if I add a type annotation to 'foo' specifying the array type, I still have to repeat MyStruct for every member.

[rom-antics]

If you want compact, use an array of tuples:

  const foos = [("foo", 1, "bar"), ("foo", 1, "bar"), ...];
  for (str1, num, str2) in &foos {
      // ...
  }

For a proper struct you have to name the fields, because otherwise refactoring the fields could cause struct instances to silently get out of sync with the definition.

[foldr]

>otherwise refactoring the fields could cause struct instances to silently get out of sync with the definition.

Having to name the fields is only part of the pain. You also have to redundantly repeat the struct name. I don't see any fundamental reason why something like this shouldn't be valid:

    let foo: [MyStruct; _] = [{a: "foo", b: 1, c: "amp"}, {a: "bar", b: 1, c: "fff"}, {a: "amp", b: 1, c: "aaa"} ];

I can see the logic for insisting on field names. However, the builtin 'go vet' tool has a nice behavior where it will flag the use of unkeyed literals for public structs only. This strikes me as a good compromise between concision and safety.

[alpaca128]

Dropping field names from definitions like Go would make the syntax inconsistent with destructuring and pattern matching. It's always possible to define a constructor function that takes unnamed values if you care about code verbosity in test cases. Or use `type M = MyStruct` to have an abbreviated type name within the test function.

Rust is more on the verbose/explicit side and I agree that can sometimes be annoying, but as autocompletion exists I can live with it.

[foldr]

>Dropping field names from definitions like Go would make the syntax inconsistent with destructuring and pattern matching

There's no reason you couldn't match on struct fields positionally as well. It would actually be quite convenient for cases like struct Point { x: f64, y: f64 }.

[no_wizard]

you'll have to forgive me, but isn't this why there should be a `::new()` callable attached to the struct?

I'm really new at Rust, but that was my takeaway, e.g. `String` has `String::new()`

[tialaramex]

The convention of providing a new() function isn't relevant here, that name isn't magic, the Rust compiler doesn't care whether it exists, and it won't cause Rust to do anything special with tuples (or any other data structure) that happen to have a similar shape.

String::new() just makes you an empty String, which, since an empty String doesn't own any storage and doesn't contain anything, is very cheap (and indeed constant evaluable), likewise Vec::new() makes an empty Vec.

What your parent commenter wants is for Rust to make the appropriate MyStruct, but without them needing to say MyStruct each time, which would have worked in e.g. C or Go.

[guipsp]

Do you mean the vec! macro?

[foldr]

It doesn't let you drop redundant struct tags, as far as I can tell.

[ok123456]

The core language is fine, but when you actually start building things you need to introduce lifetimes, all the traits that you polluted your interface with and then add on async, it gets out-of-hand quickly.

[dimitrios1]

The top comment gave a perfect example: #![feature(strict_provenance)]

These feature enablement blocks drive me crazy. You could go from codebase to codebase and it's almost like you are working in a different language depending on how many of these are enabled or not. I've been trying rust on and off since it's release, and I still have yet to feel like I have a grasp on some "core" subset of the language I can fall back on to solve most of my problems. I always have to scour documentation for the hot new thing to turn on or do, and this isn't to scorn innovation and change, but it does get exhausting at some point.

(Please release a spec)

[Rusky]

A spec is not a replacement for #![feature] attributes. It's rather the opposite: #![feature] indicates that you are stepping out of the stable, specified core language and into an area that is still a work in progress and thus cannot have a committed specification yet. You shouldn't need it at all unless you are actively experimenting with some unfinished proposal.

[satvikpendem]

Those feature blocks exist only for nightly/unstable Rust. You don't have those on stable Rust. The most you might have are derive blocks but those just automate what you'd write by hand anyway.

[kaba0]

I think it is just inherent complexity in the low-level space.

(Though I do agree that Rust definitely moves fast, which is sort of understandable as a relatively newish language)

[malcolmstill]

There are a number of sources of noise in rust, but the one I find most annoying (because it's also so common) is the double colon. My current theory is that it's because the colon is the same height as lowercase letters.

If you end up with a long::run::of::module::names, I find it all just blurs into one.

[stouset]

Okay but who is writing code like this instead of using `use`?

Also this is an no-win situation. C++, Ruby, Perl, and others have used `::` as module-scoping syntax for decades. If Rust does something novel, it's penalized for being unfamiliar. If Rust uses syntax for which there's ample prior art, it's apparently line noise. If rust used a `.` as a separator, it's unclear if you're descending into modules or calling a function chain.

There's literally no way to win.

[coderedart]

If an import is used rarely, then i prefer qualifying paths instead of importing them.

This is especially true when there's similarly named items from different paths. Best example is `Result`/`Error` types. eg: std::io::Result vs normal default Result vs other crate's Result type. Another example would be math types like Vec2 between game engine and egui. String in mlua vs std rust etc..

Usually you can get around this by importing it with a different name like `use mlua::String as LuaString`. but it is still something that you need to actively do.

[malcolmstill]

I did use the example of long run of module names, and I do take your point about `use` (though I have to sometimes read the very top of a file too!)...but the same applies to a lesser extent to the "last mile" module (e.g. `String::from`, `Vec::new`) which will be seen throughout any rust code.

> If rust used a `.` as a separator, it's unclear if you're descending into modules or calling a function chain

Interestingly, from the zig documentation:

    Zig source files are implicitly structs, with a name equal to the file's basename with the extension truncated. @import returns the struct type corresponding to the file.

This means that there isn't really any difference between accessing a struct field and accessing something in module...the module is also a kind of struct (and rust, as in zig, differentiating struct field access vs function invocation is possible because of the parens in the latter).

[lloydatkinson]

> There's literally no way to win.

Yes there is? Follow what C#, F#, Java, TypeScript, etc. do

[bxparks]

That is a very interesting observation. I am starting to have a similar distaste for the visual noise caused by the ':' in my fully type-annotated Python code. This is particularly noticeable after spending a few weeks writing Golang, then going back to my Python code. The Go code feels far cleaner syntactically and visually.

[Tarq0n]

I wonder if this could be ameliorated through font choice and highlighting.

[coderedart]

can you please point out a few more annoyances in rust syntax? I am a newbie playing with language design and could use some perspective :)

[malcolmstill]

To be honest that's the major one for me. Someone else has mentioned lifetime annotations, but those uncommon enough that I don't find it much of an issue.

If I was to think about it: comparing rust to zig, zig benefits a lot from error and optional types having their own syntax rather than being treated like any other type. For example a return type of:

    Result<Option<usize>, Error>>

in rust is rendered (mostly) equivalently in zig as

    !?usize

Note: there are some options in rust for cleaning up errors such as the anyhow library.

Disclaimer: I'm a zig fan and contribute monetarily so please weight anything I say on zig vs rust with that in mind. (I do write rust at work though)

[dureuill]

i'm curious, how do you specify the error type in the zig version?

[Asooka]

My biggest peeve is types on the right. I would say that C is "humanistic" in its type declarations, while Rust and the rest of Pascal's lineage are "mechanistic". Concretely, look at this:

    int foo(int a, float b);

vs

    fn foo(a: i32, b: f32) -> i32;

In Rust's case you're specifying to the machine what the thing is, i.e. "I am declaring a function called foo. The function has a first parameter called a, of type i32, ... The function returns an int". Whereas in C you have a "declaration follows usage" idiom, such that what you're saying is "typing foo(a, b) produces an int on the left side, within foo a produces an int lvalue, ...". The function arguments flow from right to left and the result emerges on the left with the given type. The order of tokens in declaring foo matches the order of tokens when calling foo. It also matches the order of importance - first is the return type, then the function name, then each parameter type followed (optionally) by the parameter name.

Or look at an array declaration:

    int arr[5];

"You get an int when you type arr[N] where N is less than 5".

This kind of argument of course goes all the way back to AT&T vs Intel assembly syntax and I am firmly on Intel's side.

[__jem]

This isn’t a Rust thing. Lot’s of new language have the type declaration after the variable because of type inference which makes such declarations optional.

[todd8]

Algol 60, Algol W, and Algol 68 were influential in the historical development of subsequent programming languages. C gets its type on the left order from the Algol family.

Pascal, Modula, and Ada are all type on the right languages and were also very influential in the historical development of programming languages. I happen to prefer types on the right for complex declarations. Note that Pascal and Modula were designed by Niklaus Wirth after he created Algol W; it seems he preferred types on the right.

[stouset]

I'll simply say that you are the first person I've seen come to the defense of C's inside-out variable syntax.

[alphanullmeric]

No arrow operator, no default args, no named parameters, no structure defaults and instead the incredibly verbose ..Default::default() + a trait impl as a substitute, no variadics, overall weak generics compared to C++ and a huge reliance on macros, etc etc. Rust programmers address this by calling everything rust does poorly an antipattern, ie. the “why would you do that” card.

[tialaramex]

The arrow operator is just a terrible idea, and it's weird that people defend it. It makes sense that C did this, it was a long time ago and compilers weren't very smart so C needs to make up for that, in C++ it's just carried over from C.

The absence of default args is a deliberate choice, notice that Rust does have default type arguments in polymorphism, the absence of defaults for function parameters -- which would be technically easy to implement -- reflects a belief which I've come to agree with that overloading is a bad idea, and defaults most often in practice mean you're overloading.

For example, C++ std::ranges::binary_search uses defaults to present what are in effect at least two distinct features, as a single function, suiting C++ sensibilities, whereas Rust reflect almost the same capabilities as three functions []::binary_search []::binary_search_by and []::binary_search_by_key

For a very simple binary search, things seem pretty similar. In Rust we have a single parameter, for our searched-for element, and in C++ we can stop after that parameter, leaving the comparison function and projection as default for similar effect.

However for binary_search_by the C++ is contorted by this API shape. Instead of a callable to decide whether our search found what it was looking for, and if not where it is relative to the searched-for element, the C++ is obliged to carry that element (because it was an earlier parameter) even if it's unused - and then a comparison function which takes the element, and only then optionally a projection which you may or may not use.

And for binary_search_by_key the C++ is even more awkward, we have a good reason to use a value here, but we're obliged to specify the comparison function even though we only want to write a callable to make suitable keys (ie a projection), because of the order of the parameters.

These would be better served, as in Rust, by three distinct functions, with only the appropriate parameters for each function - even if you choose to actually implement the simplest in terms of the others, because of the documentation and the API shape afforded if you think about it as three things not one with defaults carefully tailored to allow all three uses.

Variadics is a genuinely useful feature, but to do it properly is very difficult, C++ 98 doesn't have anything better than Rust [C compatibility, with no real type checking], C++ 11 does have the outline of what you'd actually want, and C++ 17 has much closer to what I'd want to see in Rust some day.

Much of what you're thinking of in "weak generics" is probably deliberate constraints to only allow coherent things, in C++ they don't care if you want to make a Foo<NaN> even though that's nonsense, IFNDR gives them the ultimate out, your program has no defined meaning, so too bad.

There are some obvious things Rust wants to have but doesn't yet in this space, including broader const Generics (e.g. my OnewayEqual ought to be Oneway<Ordering::Equal>) but it's not going to pursue the irrational C++ exuberance because it's so quickly unsound. C++ doesn't care about that while Rust does.

[jstimpfle]

Why do you think the arrow operator is a terrible idea? I feel that it costs very little of my time, and that it's so much easier to intuit what's going on from an expression like Foo->Bar.Baz->Quux compared to having only dots on there.

[alphanullmeric]

The arrow operator is far better than what you currently have to deal with in unsafe rust when trying to access a pointer member of a pointer to a struct. Rust’s way is more verbose and less clear.

I don’t really care for your examples of defaults being abused in C++, because all of rust’s workarounds like builder pattern and the default trait have the same potential to be misused while also impeding performance. They also suck for ergonomics, see bevy and polars. Rust already has a huge function colouring problem with async and mut and the lack of defaults only makes it worse.

Similarly for generics. Templates are simply better. Don’t use the power if you’re scared if it, that’s the great thing about freedom, you won’t be forced to. C++ can always do something the Rust way, nullifying everything you’ve said, but the other way around is not true. Rust sacrifices the complex case to make the simple case a little simpler and just leans on macros to do everything else. “Rust just allows coherent things” is a typical example of the bullshit rust programmers spew when they don’t have an actual response but want to say something anyways because it’s completely wrong. Plenty of useful template functionality is impossible to replicate in rust. For example:

https://youtu.be/gOdcNko2xc8

[pjmlp]

C compilers weren't smart.

[coliveira]

Agreed, using Rust is like switching a monster (C++) for another even worse. And notice that Rust is not even a mature language, it will get much worse. I will stay with C, thank you.

[kaba0]

Can you write a performant, generic vector data structure in C? Until then it is useless in my book.

[coliveira]

So useless that Linux, gcc, and all UNIX system commands is written in C. But you're probably doing much more important things, right?

[heldrida]

We should definitely appreciate the craftsmanship. This comment says everything, regardless of how trendy Rust might be, let’s respect the craft, your favourite language doesn’t make you more important. Legends!

[kaba0]

Rust is not my favorite language and I didn’t mean to speak anything negative about projects written in C, but I do think that those that become great did so in spite of C, not because of it.

No access to performant generic data structures is a major reason why truly performance oriented programs rather choose C++ over C.

[ok123456]

'constexpr' and 'auto' in modern C++ can eliminate a large portion of the ugliness. In some cases it can be much more ergonomic than the equivalent Rust.

[pjmlp]

Indeed, one gets to write macro like code on the same language.

[spoiler]

You can write Rust macros in Rust too, if you wish, but it's a bit more involved (https://doc.rust-lang.org/reference/procedural-macros.html). I realise this isn't the same as constexpr, but I'd argue it's nicer.

Rust also has const generics (but they are still a bit shabby in places last time I used them).

I for one never liked the constexpr semantic and syntax. Always felt like a... Little pebble in my shoe. Didn't quite annoy me enough not to use it since it was useful, but it was never a comfortable experience.

[DeathArrow]

At least C++ is enormous and you can find a sane subset that you enjoy using. And C++ can be pretty safe with smart pointers.

[vore]

This almost works until you have to integrate with other people's C++ code and find out they picked a different subset to you.

[pjmlp]

Unfortunately there is always that clever one than can't let go of writing C style code, regardless of what kind of pointers are being used.

It is one of my favourite languages, but I also acknowledge that C compatibility is a big pain point for security.

[edflsafoiewq]

IMO Zig isn't exactly a beauty either.

[Narishma]

That's entirely subjective. I personally find Zig, Nim and even Go much uglier than Rust.

[Karrot_Kream]

One technical criticism I have of the "community" is that a non-trivial portion of the community thinks that if the borrow checker forbids a program then the program is a bad program. None of the core contributors do this and many prominent library authors are upfront that this is not true, but I've read lots of comments and posts in Rust rooms about how the borrow checker should be the way to write and architect correct programs.

The Rust borrow checker imposes a style that is safe, but is not the only safe way to write that program.

[nextaccountic]

> It makes the easy stuff hard.

> Writing basic data structures isn't a niche, esoteric edge case.

Writing basic data structures isn't "easy stuff" in any low level language. It isn't in Zig by any means, nor in C nor in C++

[pjmlp]

There is already C for when one wants to do otherwise.