[andrewmcwatters]

Maybe I just need to spend more time with Rust and deal with it, but I'm sad the industry desires to rally around it. Despite the specific subset of protections it aims to provide, I have always had issues with how ugly the language is.

To a lesser extent, I have a problem with the protections it doesn't provide and leads developers to think they're writing safe software that in specific cases, actually just promotes silent failure through invalid data, not crashing.

I'm impressed that the language is even uglier than bad C++, which is an accomplishment in violating the beauty of reading.

Edit:

No, I think complicated C++ is also distasteful, but equally, sometimes both are just simply necessary.

Annotating specific attributes of data flow is just a requirement for types of guarantees, but I wish they weren't always done inline. It incentivizes programming language authors to squeeze more out of columns, and as a result creates quirky reading that while is more featureful or does things that aren't even possible in other languages, makes for a less than aesthetic reading experience.

I think my opinions can be handwaved away here, but I just wish we as programmers found nicer ways to give these attributes to functions, variables, and parameters.

My account is throttled by Hacker News moderators. So, I can't participate any more here for the time being. Thank you for replying to my comments.

Just expressing some petty opinions, I don't mean to start a syntax flame bait war, sorry all.

Edit (for Ygg2): What you think is superficial is an entire portion of the art of software development. And your usage of FUD is incorrect. Disliking a painting, a song, or a book isn't FUD. It's just plain as day disinterest.

[malwrar]

I’d suggest reading their (free, online) book if you haven’t already, that’s what motivated me to actually try using it. It sells its core features pretty well and eased me into it better than just trying to grok the syntax. What kept me using it is how annoyingly frequently my code would _just work_ once I got it compiling, which I could often get to pretty quickly by catching errors early with a linter. I’d highly recommend giving it an honest try, the aesthetics make sense with a minimal amount of experience.

[adastra22]

As we transition to an era of LLM-generated code, it also means that once the LLM gets it to compile, it likely works.

[andrewmcwatters]

I am definitely interested in working with it more. It's obviously a fantastic modern language. It just has warts to me. Ones that make learning it a little off-putting in specific domains.

I mostly expose myself to it, at the moment, through benchmark work which highlights how competitive of a good language it is.

[mikepurvis]

What are the specific aesthetic complaints here?

In my limited rust experience, I’ve found that it does a pretty good job of using the ugliness of something like an explicit lifetime to signal to the developer and reader that the code is doing something complicated and non-obvious. Like “here’s a part where the types logic required more help than what the compiler could figure out on its own; here be dragons.”

In that way the “ugliness” is really just a manifestation of “hard things possible” and the language not hiding the underlying realities from you.

[mrheosuper]

I have no specific compaints, but here one example i saw online, and i'm talking from a C dev perspective.

  let x: Option<Result<Vec<i32>, std::num::ParseIntError>> = Some(Ok(vec![1, 2, 3]));
  let flattened = x
 .map(|r| r.unwrap_or_default())
 .unwrap_or_else(|| Vec::<i32>::new());

I have no idea what the code is doing here, but while reading python or JS code, i can make an educated guess what it's doing.

I have no experience with Rust so it makes sense i dont understand, but i also have no experience with Python or JS.

[tialaramex]

It is of course impossible to know the context in which you saw this, but I will say this is a particular idiomatic way to write Rust which won't mesh with your C knowledge.

Also this code isn't a thing you'd actually do, it's maybe an illustration or part of an example I suppose

You see that vec![1, 2, 3] ? That's what we're getting at the end, a growable array with three integers in it. All the other stuff is machinery to handle errors which in fact have not happened.

    let flattened = vec![1, 2, 3];

Is the same effect, although probably for style you'd write:

    let flattened: Vec<i32> = vec![1, 2, 3];

[mikepurvis]

It's a bit unusual for a type to be wrapped in both an option and a result, since they have a lot of overlap. They're both union types, but semantically, Result takes the place of throwing an exception (Ok is your return value or here's the error) while Option takes the place of a pointer (Some is an instance of the underlying type, vs None which the null case).

Normally these union types would be handled with a match, or an if let, eg:

    if let Some(x) = fn_returning_an_option() {
        do_thing_with_x(x);
    } else {
        // handle that it was none
    }

The unwrap functions are basically just shortcuts for this, with the most extreme being unwrap() itself, which simply returns the Ok/Some value if present, and otherwise triggers a panic state resulting in the program exiting.

But all of this is rust forcing the developer to either address the null case, or explicitly put in an "unwrap" to acknowledge that they're not addressing it. This is in contrast to C or C++ where you just myPtr->lol wherever you want, and if myPtr is null then it's a segfault.

So that's the worst of it. The rest is the function chain, which is a bit obscured by lack of indentation, and that the functions are being passed lambdas.

[andrewmcwatters]

Some of my complaints are petty, and I think can be dismissed as just personal preference. I don't have a great deal of complaint with languages with different syntax, just ones that are so intentionally cryptic so as to invent needless specific sigils that you need to memorize.

I agree that most of the awkwardness of reading comes from explicit declarations, but really, even if it's more verbose, I would prefer that that explicit nature is defined elsewhere rather than reading like a compact run-on sentence. (I'm hypocritically writing here, since I do this too often myself.)

[mynameisash]

> just ones that are so intentionally cryptic so as to invent needless specific sigils that you need to memorize.

Can you back up this claim that the language is intentionally cryptic?

Ignoring that: other languages have sigils (Perl's @, $, %, etc.; PHP has always used $; Java uses @ annotations, and so on) or their own quirky syntax (C#'s custom attributes before a class, Python's @ decorators, etc.). What is it about Rust that is particularly confusing?

[mikepurvis]

As in the prior comment, I'm a relative novice myself and certainly never achieved that moment with Rust where the code kind of melts away and you just see raw intent ("blonde, blunette, redhead"), but I do wonder if languages like Python have set our expectations a bit unrealistically in regards to that. Like instead of prioritizing information density, explicitness, and clarity, we got excited about the quick rush that came with `import antigravity`.

Java and C++ aren't just verbose, there's a lot of redundancy there, at least classically. Stuff that is needlessly repeated between headers and implementation, cases where you're having to hold the compiler's hand and continually repeat information that it should be able to infer itself from the code. And then the moment you find auto or template inference and feel like you can finally trust the compiler to do the right thing, it barfs up half a page of inscrutable errors and you're back to babying it.

Rust—in my limited exposure—is hitting kind of a sweet spot where it's the expressiveness and build/package ecosystem of Python, the performance and precision of C++, and the density of Perl. Or at least that's what's being aimed for; but obviously these goals open it up to charges that it's actually just as unreadable as Perl or as verbose as C++.

[umanwizard]

I see this complaint all the time about Rust, and it always confuses me because it doesn't match my experience at all. Do you have an example of Rust syntax that is more complicated than complicated C++?

[adastra22]

I don’t consider Rust beautiful, but after a decade of working with Rust I am no longer bothered by its aesthetic warts.

[Ygg2]

> My account is throttled by Hacker News moderators.

Seems most accounts are throttled 2posts per hour. Mine included.

> Edit (for Ygg2): What you think is superficial is an entire portion of the art of software development. And your usage of FUD is incorrect.

There is no art in programming language design. Art can be defined as something meant to exist solely for its own sake. That's not what PL is. It's just the thing that makes up a program.

There is a lot of creativity and application involved in programming language design. You can design works of art with a language. But on its own I would have trouble seeing it as art.

But what you mean by art is probably aesthetic i.e. how beautiful is something to look at. When it down comes to userbase it's just a popularity contest. Braces, Parens, keyword or indent? It makes very little difference.

Yet people are vocal about their pet syntax being "The one true" syntax to rule them all. It's like quarreling over whether to stir cement clockwise or counterclockwise.

I'm of the Douglas Crockford school of language design. Languages are meant to facilitate transfer of programming ideas while minimizing errors. If your syntax isn't minimizing errors I frankly don't give a damn. Give me a cement that lasts a thousand years, not one with that I need to worry which way I mix.

As for FUD, I stand by that statement. Saying Rust is uglier than C++ a language known for its near-universally disliked syntax definitely strikes me sowing fear aimed at newcommers.

[pizlonator]

It’s wild that this is downvoted.

Converting all C++ code to Rust while actually getting a safety improvement is not possible because Rust does not safely support all of the things folks do in C++ (complex cyclic object graphs with inscrutable logic deciding lifetimes, intentional races, etc).

It’s easy to think that all of those “bad” things that C++ programmers do should somehow not have been done. It’s more likely that it’s either not possible to do it any other way or that you get a worse outcome if you do it another way. The cyclic nature of compiler IRs comes to mind. As do the wacky relationships between objects in games. Complex uses of syscall ABI are another. Oh and dynamic linking. Likely there are many other examples.

The idea that an LLM would convert C to Rust without introducing a slew of problems along the way is especially juvenile. Most likely the LLM with either use the unsafe subset of Rust, or produce Rust code that doesn’t actually match the functionality of the C code (but declare premature victory thinking that it did).

[AlotOfReading]

    Rust does not safely support all of the things folks do in C++ (complex cyclic object graphs with inscrutable logic deciding lifetimes, intentional races, etc).

The whole problem is that C++ doesn't support them safely either. The committee has no interest in fixing C++, so what's the alternative that doesn't involve a new language? DARPA already considered and rejected things like sandboxed runtimes and rewrites from scratch because they don't fully solve the issues.

[adastra22]

Do you have specific examples? All the areas you list are done in Rust too, where the borrow checker helps make sure they are bug free. Do you have an example of something that just can’t be represented in Rust’s type system?

[Havoc]

This is DARPA we're talking about. They've got a pretty good track record on pulling off stuff people we're convinced can't be done

[synack]

Have you tried Ada?

[ggm]

Wait, wasn't there a DARPA round funding automatic translation of C to Ada once, long ago?

[andrewmcwatters]

No, though I am familiar with its history a bit.

[scoopdewoop]

I once had a boss that used to really hate python. He would roll his eyes whenever it was brought up. He was CTO of the company and he would sneer at it. One day, in a one-to-one meeting, I asked him, "what is so bad about python?"

I expected him to explain some core deficiencies: problems regarding the module system or multi-threading limitations, or some pathological case where latency spikes... and he said "I don't like the whitespace."

I never took him seriously again and left that company shortly after.

[hn_acc1]

I mean, I don't work with python all the time, but at work, it's the #2 language.. And the whitespace stuff is the most annoying part of it by far.

[geertj]

It’s sad you are getting downvoted for simply expressing what seems to be a genuine opinion.

[Ygg2]

Because it's an extremely subjective, extremely superficial statement that does more FUD than it explains.

[andrewmcwatters]

I am getting tired of participating in this community for many reasons, but this specific reason is one of the most tiring ones.

But there's seemingly nowhere else to go, but maybe small Discord servers where you can meet people and share honest opinions that are real and agree to disagree without penalty.

Everyone should feel free to express harmless opinions.

Edit: Whoever downvoted me for this comment is proving my point.

Edit (for adastra22): I'm not sure that me providing a list of specific modifications to Rust syntax is meaningful to anyone anyway. I'm just a nobody. And it should be OK for people to express personal opinions that hint towards something being wrong without also being required to solve the problem. That's just life.

[adastra22]

I didn’t downvote you, but I can see why your original unedited comment was downvoted. It provided no actionable objections, e.g. no examples.