Honestly yes. If I need to manipulate the filesystem or manage processes with any amount of conditional logic or looping, I’d much rather do it with Rust than shell scripts.

The only thing I use shell scripts for anymore is completely trivial sequences of commands.

Something about the language promotes writing it using these kinds of idioms.

As someone who has used Rust professionally for 3 years, the idioms are good. I wouldn’t want the idioms to go away, and I don’t particularly want the style/aesthetics of the language to change unless it can be done without negatively affecting the idioms.

It’s not a situation where the aesthetics are actually bad, it’s just different than what most programmers are used to, but almost all of the differences are for pretty good reasons. With enough familiarity and practice you’ll start to recognize those differences as benefits of the language rather than detriments.

But I think a lot of people have so much inertia about tweaking their way of thinking that they don’t feel motivated to try long enough to make it over that hump, especially when their expectations get set by rabid Rust promoters like myself who insist that Rust is vastly superior to any other languages in almost all situations. The stark contrast between how good they’re told the language is and how they feel when first exposed to it might be too much whiplash for some people.

This is the most sober take in this thread. I was bothered by all these things you mentioned for the first two weeks of using the language. I begrudgingly accepted them for the following two months because I felt the benefits of the language were worth it. Now all of these things feel natural and I don’t give them a second thought.

I get it there are people who want to play around and have language/compiler babysit them, but there are also people like me who want to see exactly what something is.

This is a false dichotomy when it comes to Rust. Despite everything I said and despite Lucy’s complaint, there is nothing that actually stops someone from explicitly annotating the exact type when declaring a variable. It’s just not required by the language, and most developers eventually realize that it’s not actually useful.

You’re right that these preferences are subjective, be although much of that subjectivity has more to do with how our past experiences have shaped what we’re familiar with, rather than any intrinsic characteristics of person. By that I mean, someone who uses Rust enough will most likely come to like the way the general community styles its code, sooner or later. In the meantime you’re welcome to do things in a way that suits your needs.

The only thing that Rust’s type system is weak on is runtime reflection. There are ways to achieve it within Rust’s type system, but it’s considerably more work than what you get in Python and JavaScript. Imo the only reason to choose a language other than Rust for a greenfield project is if you have a strong need for runtime reflection all over the place and aren’t very concerned about performance, threading, or avoiding entire categories of bugs that the Rust compiler protects you from.

It’s incredibly disingenuous to call this average Rust code and further erodes your credibility. I may as well point to hundreds of lines of preprocessor macros in a C++ header and call it average C++ code.

This is not what an average Rust developer is writing 99% of the time. If someone on my team submitted a PR with an implementation of sum that uses macro_rules! I would almost certainly reject it.

Types are not implicit, they’re inferred by the compiler when there is no ambiguity about what the type needs to be. This is a huge benefit for refactoring code and reducing maintenance. I acknowledge that sometimes you might care to know the exact type of the variable, and sometimes that’s not as easy for a human to infer as it is for the compiler, but every decent IDE will provide inline type hints for you. Interpreting code by reading it in plaintext is an exercise in masochism.

Python is actually the opposite on this, and it’s one of Python’s worst characteristics. The type is unknown until runtime unless you annotate it, and then the annotation isn’t really enforced. It’s the worst of every dimension.

C++11 introduced auto, and now the community is split between “almost always auto” and “never auto”.

JavaScript needed a whole new compiled language (Typescript) to fix its type system problems, and Typescript is only an incremental improvement at best.

Rust has the best type system of any modern language by far. If you’re tripped up by not always seeing the type declarations then you’re either focusing on the wrong details in the code or you just need a little more practice. The key thing that needs to sink in for new Rust users is that the compiler is always providing safety rails. That means it’s no longer your job to verify that every aspect of the code is correct. You can relax a little and actually have something akin to duck typing without all the pitfalls that usually come with it.

It’s hilarious to me that people talk about “ugly” as if their opinions are objective.

I found Rust unpleasant to look at for the first two weeks of learning it, and now that I’ve been using it professionally for three years I loathe when I need to read code in other languages.

No other language can rival Rust in showing the exact information needed to understand the code — never too much and never too little — while being concise, correct, and handling all edge cases.

You can be more concise in other languages, but it will come the loss of handling every little possible bug. You can be prettier in other languages, but it will come at the price of adding a lot of useless boilerplate.

Of course there are cases where Rust can be verbose or confusing, but that’s when you’re doing very esoteric things that would be just as confusing in other languages.

Like any opinion on aesthetics, how someone feels about the prettiness of a language will have far more to do with familiarity than with any objective metrics.

Being unable to give an actual example proves you’re just a foaming-mouth hater with nothing to contribute.

Or would the band name be “Actual Dragons”?

Looks like this whole post is an ad for someone’s project. The links hardly have to do with the post.

I don’t agree with the previous poster. There’s nothing wrong with diving in and figuring things out as you go, especially if that’s a way that you commonly like to learn. Everyone has different learning styles, and Rust can fit all those styles.

The main thing to understand is you shouldn’t let compilation errors discourage you. You will get a lot of compilation errors. And I mean A LOT. That’s okay, it’s normal, and it doesn’t mean you’re dumb or that Rust is an excessively difficult language. It generally just means that there’s some new piece of the language for you to learn before you can take your next step.

When you run into compilation errors, just read the error message carefully and see if you can understand what the problem is. Often the error itself will tell you how to fix it, but you should take the opportunity to understand why the fix is necessary. In every case there’s a reason that the language is putting limitations on what you’re doing. It’s to protect you from bad habits that other languages used to let you get away with. So understand what’s bad about what you were doing and you’ll rapidly grow as a developer.

If you can’t figure out what’s wrong from the compilation error alone, that’s when it makes sense to turn to the book. The error messages will generally include a reference code which you can use to get more details on the nature of the error. Googling that will lead you to online discussions and maybe entries in the Rust book. Otherwise there isn’t a real need to read through the book from front to back unless that’s a way you like to learn.

I’m not trying to shill for Google but I really think it would be a mistake to break up Google without breaking up Microsoft simultaneously if not first. If they actually manage to crack open Google’s search and browser monopoly, who do they really think is going to start filling in that void? Local mom and pop search engines…? No it’s primarily going to be Microsoft with Bing and Edge, and I’m absolutely certain that whatever people don’t like about Google having its monopolies is going to be orders of magnitude worse if Microsoft gains ground there.

It makes total sense that new C++ will contain a higher percentage of bugs than old C++, but after being an almost full time Rust dev for the last two years, you will not convince me that new Rust code has more bugs than old C++ code.

So far I have yet to come across a bug in any of my Rust code that made it into production. All issue reports from users are still related to the C++ code base that we haven’t managed to fully divorce from.

The only advantage to C++ interop is that managers want to see new code get deployed immediately and continuously. They don’t want to wait until the corporation’s billions (literally) of lines of code are all rewritten in a new language before they start to see the benefits of that transition.

She would have lost Michigan and Wisconsin by even larger margins if she went with Shapiro instead of Walz.

I’m not convinced he really believes that OpenAI is going to roll out AGI in the next ten years, but I’m completely sure he’s determined that it’s a good marketing strategy to make people believe that he believes it.

OP really needs to heed this advice. Modifying things in the cache will cause breakages that will confuse the hell out of you.

Best practice when using .unwrap() in production code is to put a line of documentation immediately above the use of .unwrap() that describes the safety invariants which allow the unwrap to be safe.

Since code churn could eventually cause those safety invariants to be violated, I think it’s not a bad thing for a blunt audit of .unwrap() to bring your attention to those cases and prompt to reevaluate if the invariants are still satisfied.

But only if pattern matching were included, otherwise they would be as unpleasant as C++'s std::variant.

This makes a lot of sense, but the functions were Rust bindings for plain C functions, they weren’t function pointers. Granted I could have put pointers to the function bindings into fields in a struct and stored that struct in the mutex, but the ability to anyhow call the bindings would still exist.

It’s a massive win, and I would question the credibility of any systems programmer that doesn’t recognize that as soon as they understand the wrapper arrangement. I would have to assume that such people are going around making egregious errors in how they’re using mutexes in their C-like code, and are the reason Rust is such an important language to roll out everywhere.

The only time I’ve ever needed a Mutex<()> so far with Rust is when I had to interop with a C library which itself was not thread safe (unprotected use of global variables), so I needed to lock the placeholder mutex each time I called one of the C functions.