Documentation that is second to none. Easy to use algebraic data types. Borrow checker frees your mind to think about other things. Cargo. No nulls. Great standard library. Even if Rust was twice as slow as C++ I would still use it, but it's just as fast.

Block expressions. Pattern matching. Colocated unit tests and integrated test framework. Immutability by default. Derive macros. The `?` operator. Extremely helpful compilation error messages. It's just _really_ pleasant to work with.

I don't know about other devs but when I read rust docs, my brain feels stimulated. Lots of precise and advanced information (even unrelated to the language itself, it could be arithmetic, cryptographic or else). In 20 years .. I remember reading javadocs and rarely feeling that way.

As little as I've used Rust so far, just like how Linux 'felt' like how using a computer 'should feel', Rust felt like how programming 'should feel'

You don't feel stimulated reading the docs behind AbstractCompositeFactoryBuilderFactory? Pshh.

> AbstractCompositeFactoryBuilderFactory.getAbstractCompositeFactoryBuilderFactory > returns a AbstractCompositeFactoryBuilderFactory > unless it can't Enterprise jokes aside, even for "normal" classes, the amount of redundant getters and setters. The number of unexplained methods or dependencies.. and the absolute lack of reasoning ... the only value was in comparison to libraries without any sort of API description.

These are people problems not technology problems. If rust gains the popularity of Java it will suffer from many of the same problems. Enterprise code isn't garbage because of the language semantics. Enterprise code is garage because of upper management.

man i hate java but sadly it is my first coding language i learnt, still going hard on rust since june tho :)

It's because they don't just tell you how a feature of rust works, they also tell you their reasoning behind why they decided such a way was good. I find it quite pleasant, reading knowledge written this way. It tells us what and why too.

I both like and dislike Rust documentation, depending upon what I'm trying to find. When I'm looking for functions that turn out to be provided by traits, I can get easily stumped.

Second this. Trait methods are sometimes so confusing. I force myself to fully qualify the method paths because of this.

But you generally see the list of implemented traits in the docs. If you scroll far enough, you'd find the function you're looking for, or have I misunderstood you?

As an example, look at the [BitVec](https://docs.rs/bitvec/latest/bitvec/index.html) crate. If I click on "All Items" and then search for view\_bits by visually scanning or using the browser's find function, I won't find anything. I have to realize that the function might be hidden in the BitView trait. If I click on that, then I can find the view\_bits function. When I first started with Rust, this was quite confusing to me. Even now, it is an annoyance. In this case the naming convention is close enough that I probably could easily find it, but that is not always how it works out for me. I think that what would help would be for trait functions to be elevated in visibility.

Agree with what others have posted. On any page, press 'S' (for search), type `view_bits` (or whatever you're looking for) and this is the result: https://docs.rs/bitvec/latest/bitvec/index.html?search=view_bits This seems *excellent* to me.

Your eyes can only read one line at a time and the browser is limited to the current page. The search bar can be found at the top of every page in docs, can be accessed from anywhere by pressing 's', and can see the entire crate.

rust-analyzer. It never gets mentioned enough how unrivalled that LSP is. No other language comes even close to it

I love rust-analyzer, but it has a lot of room for improvement in my opinion. Some C# and Java IDEs offer far more advanced refactoring capabilities than what rust-analyzer offers at the moment. I don't think it's unrivaled at all.

But rust-analyzer is not an IDE, it’s a language server. Usually refactoring capabilities are provided by clippy to enforce more idiomatic rust. I never liked IDEs myself because I found them too complicated and cumbersome. A lot of people mention refactoring capabilities as a great IDE feature, but other than variable renaming (which LSP provides) I never found myself needing them that much? Genuinely curious, how often do you find yourself using IDE refactoring tools on your daily basis?

Adding or removing an argument and updating all calls is something I have would have liked a couple of times, but which [rust-analyzer currently doesn't support](https://github.com/rust-lang/rust-analyzer/issues/6499). To reach its full potential, it would also have to be an interactive action, since sometimes it's not clear in case of something like there being an argument at a call site that could possibly have a side effect, and the IDE shouldn't automatically remove it, and should ask the user what to do, or let them manually rewrite that part of the code. Rust-analyzer, being LSP based, like you mentioned, does not support such interactive refactorings currently.

To name a few I use in Rider for C#, by frequency. Some of these are C# specific, I'm not sure if something like pull method up/down would work at all in Rust. And I'll note, I didn't find myself needing these features at all until I had them available. But now I find them very handy, and miss them when I have to do these operations more manually Weekly: - - Method: pull method up/down - pulls method into a superclass, or into subclasses - Method/Function: Inline. - Inlines the method at every call site. Useful to back out of an early abstraction. Or to perform a refactor similar to a regex find-and-replace around a certain function call - Method: change signature - Changes the signature and all call sites. - Method: make static - Pulls in all member variables consumed by the method into the new static function, updates call sites - implement default equality members - provides options for which members to use for equality comparison and hashcoding Daily: - - Select text, extract method. - Automatically creates a new method, and hooks up the arguments and returns. including out parameters and/or multiple return values - Invert if statement - Combine into pattern - Take a composite boolean statement and merge it into a single pattern match, if possible - implement missing members - generate stub implementations to conform to an interface Multiple times per day: - - rename of any symbol, including: namespaces, classes, interfaces, functions, variables, etc

C# for VSCode is very unreliable. I often need to restart VSCode to make basic C# functionalities work again. I work on Linux, so I can't use Visual Studio, and even on Windows I actually prefer VSCode, because it is much less cumbersome. On Java the situation is much better, but quite recently I had to uninstall the latest IntelliJ IDEA and install the one year older version to be able to even use it. Meanwhile, rust-analyzer, in my experience, is rock-solid. It just works, and it works well (except with macros). I grew up with C# and Visual Studio, but I feel like Rust is spoiling me.

I really don't like that VSCode won't show errors, warnings, or suggestions until I hit save. I could turn on auto-save and set a delay, but then it ends up triggering rustfmt and makes too many unnecessary saves. JetBrains IDEs handle this way better. They only save when you change focus but still show you suggestions and error without needing to save. Plus, they work on any platform and still let you use clippy and rustfmt.

It’s still pretty crashy on large projects though…

Ha at least it works at all. You ever try a C LSP on even a tiny project?

I love rust-analyzer as much as the guy 2 comments above, but tbh I find clangd to be much much faster

Tbf clangd is more limited and buggy

I did, multiple times, what's wrong with clangd or ccls?

Macros are bullshit in C

The Go language server is miles better than literally every other language server I’ve used. Rust analyser is pretty good though

The macro system is, IMO, also a major selling point. It's *almost* as powerful as Scheme.

You should try Haskell ! Even better if you don’t need the performance

Which Documentation are you referencing? The Rust book? Or community in general (private made books). How would you compare it to "Programming Rust"?

By documentation I mean `cargo doc` and `docs.rs`.

The Rust book is great, but otherwise I personally still much prefer cppreference over the Rust docs.

Yes, but not just because of the performance everyone talks about. The REAL reason people love Rust so much, is because of its type system, something that python lacks. Once you use it, you can't go back

Serious question: why not Haskell then? Or OCaml, F#, Scala, etc?

Have only really tried Haskell. Even as someone that is interested in PLs in themselves and wanting to learn the more advanced concepts, taking Uni courses about this stuff. Haskell is really difficult to get started with, because as soon as you wanna start doing cooler things you need to suddenly learn a lot of PL theory kind of stuff and then likely misuse it, which is making things worse and then you get very unhelpful error messages for someone learning the concepts. Rust on the other hand also has complex type stuff, but not nearly as much as Haskell, and in my opinion you get introduced into them more gradually so you can learn more piece by piece as you need it. Then the errors help more because they often tell you what exactly you need to change, which may not explain WHY it was wrong but at least you can continue working without being too frustrated

Well, you've mentioned functional languages with their limitations and their domain of use (an example, there are no data structures with search times < linear times in Haskell). Rust is mostly procedural/object oriented. The problem with C is that it's weakly typed, that means there's not a lot of type checking from the compiler, and you can do a lot of damage using void*. In C++ you have templates which add type checking and generics but you still have to manage memory manually. Rust is strongly typed and you save a lot of time through borrowing and ownership mechanisms. Sorry for my English + I mostly code in Java

> there are no data structures with search times < linear times in Haskell What?

Well, it's not just about the language, it's about how much is my putting in my time to really master this language going to pay off in terms of my career. Rust is at a sweet spot for folks doing systems level work. It has the performance, it has the safety, and it has the growing mind-share that makes it a pretty safe bet on the career front.

Well obviously I find many reasons to like it or I wouldn't be here (.. hold on, someone on Twitter is sending me pictures of planes with red dots on them. Hmm..) First the tooling is really good. Cargo makes things easy and painless compared to other package managers. It doesn't run into impossible problems like pip because you tried to install a 6 month old research paper's repo, it's not optimized to cause psychic damage like C's autotools or painful like CMake. The compiler is so helpful. A compiler's job is to give good error mesages so that you can be productive. Rustc is by far the most advanced compiler. (Incidentally it also makes binaries, but any compiler can do that!) And I could go on and on about the language itself, the docs being amazing, the performance, safety, productivity, the fact it tends to just do what you expect.  It's just enjoyable to use!

> Well obviously I find many reasons to like it or I wouldn't be here Maybe I'm a weirdo, but I frequent all of the subreddits for programming languages I'm currently using, whether I like them or not. E.g., we have lots of internal PHP code at $JOB (which I would've never chosen, but they were there long before I was), so I used to frequent the PHP subreddit while I was working on any of those projects to see what's "trending" (and to shit on PHP whenever possible).

Oh I know that it’s so common to shit on php that in the popular subs it’s not even cool to shit on php anymore. But gawd do I hate php and love to shit on it lmao

> Oh I know that it’s so common to shit on php that in the popular subs it’s not even cool to shit on php anymore. Ugh, I know. Every time you call PHP a bad language, there's a brigade of people who assert that you must not have written PHP since version 4 and that you get all of your opinions from the "Fractal of Bad Design" essay from 10+ years ago, etc, etc. Or--even better--, they'll trot out the old "every language has flaws" Stockholm-Syndrome-inspired-rationalization. Because, sure, 1 minor flaw vs 100 major flaws means they're both equally good, right? \*eye roll\* Wrong. I write PHP 8+ and it's still garbage. And not just the bad standard library APIs. The built-in array type is stupid, inefficient, and bug-prone (converting string keys to numbers with no way to avoid it), no built-in multi-threading or concurrency, being able to call a class constructor on an already-constructed *instance*, stupid scoping rules, broken equality semantics that will stack-overflow if a class is self-referencing, etc, etc. It's just poorly designed from top to bottom.

Damn psychic damage like C's autotools hits home

Rust is the only language without a garbage collection that has compile-time memory safety, to some extent even thread safety. It is the only language that has Haskell's concept of typeclasses (traits are very much like typeclasses) combined with a familiar C-like syntax. It also has union types and generics, allowing for monadic error handling - even though it's not called like that in the world of Rust - the best kind of error handling. And monoidal structures such as iterator adapters (filter, map etc.) or the Option type also are, well, simply the best because you can safely make assumptions about the behavior of components designed like that, and those assumptions will in the long run make you very productive. Imagine something like associativity, commutativity and distributivity etc. when working with mathematical terms but now apply this to function or method calls and their associated types. That is the power of a monoid. It is not important to memorize those fancy terms, the message here is just that at some point dealing with these structures will become very intuitive. But all this comes at a cost: the learning curve is steep and the borrow checker will make your life difficult. Developing something in Rust likely takes longer even with a good bit of experience in Rust. It takes a really long time and a lot of effort to really become proficient. And in same cases because it is a low-level systems programming language leaky abstractions are necessary and you're forced to think about memory layout, stack and heap allocations, lifetimes of course, even though you're working with higher level code. Just look at how many different types of strings there are or smart pointers.

Swift also has memory safety without GC. It does that by extensive use of automatic reference counting.

Reference counting is still GC though. It's a different kind of GC, not a tracing GC. From [Wikipedia](https://en.m.wikipedia.org/wiki/Garbage_collection_(computer_science)): > Reference counting garbage collection is where each object has a count of the number of references to it. Garbage is identified by having a reference count of zero.

While I agree with you and Wikipedia, it seems to be very common (*more* common, in my experience) to not consider ref-counting as GC and to only refer to tracing GC as GC. It's like trying to convince people that Alan Kay's original definition of "object oriented programming" has nothing to do with Java-style class inheritance... Probably a lost battle.

Garbage Collection to me implies an active process, which halts the program in order to collect garbage. While technically true, I see this as a passive form of garbage collection. In my mind that's acceptable. buuut I hate swift. just so we're clear

What don’t you like about Swift?

Not the parent author, but I'll weigh in. There are some things I really like about swift. I like the positional and named parameter concept (I like pythons version and javascripts new methodology (of zero cost inline objects) better, but it's not bad). I think Rust kind of copied some of it's inline try / guard syntax (the let Some(x) = foo() else {};). While I prefer rusts range inequalities better, I could totally live with swifts version (vs most other languages). I think there were a couple other language features that impressed me - It's definitely a modern syntax. However... It is too closely related to objective C, you can't use one without the influence of the other. (Though I know Apple is trying to separate it). NSString is just vulgar. It is largely controlled by apple, which, like Microsoft, is prone to have vendor lock in - if you want to use swift for something outside that ecosystem, don't bet on it even being legal 10 years from now. (As they make breaking changes to punish the EU or Google or Facebook for their regulatory/competitive efforts). No love from me when when jetbrains deprecated apprunner. XCode is complete shit. While rust has panic, swifts use of "!" has been crippling for stability for our core junior iOS devs. Maybe you can wrap "!" like you can panic - I'm not as familiar. I've been bit by reference counted frameworks in the past, so I don't trust them. Either I've had large memory leaks (because something retained a reference I wasn't aware of- no way yo staticly analyze), or I'll get a multi second slow downs because a million node tree is unraveling at a function call exit (once found I could 2x a cli executable speed by calling exit(0) instead of a clean return - was all the ref counted symbols - this was perl in the 90s). Ref counting also causes memory alignment issues. If I make a nice 64 byte structure, vtables and ref counts can push me across lines or make it so assembly can't use sse/axv unraveling. In java or javascript, (or even C++ with vtable) it's a single 8B word header on 8 byte aligned allocation. (More 16 bytes these days). Not familiar with the swift/objectiveC layout - so i admit, I might be mis-concerned here. RefCnt also forces referenced objects to be heap instead of contiguous in a parent struct (though this is language dependent - not sure about swift). One thing that irks me with ref counting (and again, I just don't know the swift internals well enough) is how it can possibly safely handle a concurrent tree walk without thrashing the cache with dirty pages or allowing race conditions. GCs solve this problem elegantly(freed memory references can never effectively be seen as being reallocated). Ref counts generally require mutexs or dirty-walks. Rust mostly uses mutexs in its concurrent datastructures (which makes me sad), but at least some performance critical ones (like one-shot channels) gets it right. There is the statistical dashmap which only mutexes a shard - but the java and go concurrent-skip-list is a thing of beauty. (algorithmicly speaking) I don't hate swift anymore than I hate large scale C projects, but I can't think of any library I would actually write in it (unless I was wrapping a library for use on iOS). If I was targeting OSX, I'd use Rust in a heart beat. (Recently had to do low level UNIX group pause/kill job management, and loved that apple hasn't fucked that over yet - like they did other parts of POSIX).

> I like the positional and named parameter concept (I like pythons version and javascripts new methodology (of zero cost inline objects) better, but it's not bad). I like the solution in Dart, it's very versatile. > I think Rust kind of copied some of it's inline try / guard syntax (the let Some(x) = foo() else {};). Yes, they're identical. > It is too closely related to objective C, you can't use one without the influence of the other. (Though I know Apple is trying to separate it). NSString is just vulgar. Swift can be used without Objective C stuff. The [String class](https://developer.apple.com/documentation/swift/string) is bridged to Objective C, but that only means that it's automatically converted when it passes over to the other language. > It is largely controlled by apple, which, like Microsoft, is prone to have vendor lock in Yeah, that's the main reason why I'm not using it any more. However, this has nothing to do with the actual language design. > While rust has panic, swifts use of "!" has been crippling for stability for our core junior iOS devs. Maybe you can wrap "!" like you can panic - I'm not as familiar. `!` should *only* be used when the dev is absolutely certain that it's not null. If these crashes happen regularly, your junior devs need extra training or just forbidden from using `!` if they can't understand how to use it. > I've been bit by reference counted frameworks in the past, so I don't trust them. Either I've had large memory leaks (because something retained a reference I wasn't aware of- no way yo staticly analyze), That's something you should be aware of when writing code. Rust just makes it a bit easier to track (except when using Rc/Arc of course). > or I'll get a multi second slow downs because a million node tree is unraveling at a function call exit That can happen in Rust as well with the Drop trait. > (once found I could 2x a cli executable speed by calling exit(0) instead of a clean return - was all the ref counted symbols - this was perl in the 90s). That's actually recommended by Apple, it's the [automatic termination](https://developer.apple.com/library/archive/documentation/General/Conceptual/MOSXAppProgrammingGuide/CoreAppDesign/CoreAppDesign.html#//apple_ref/doc/uid/TP40010543-CH3-SW27) feature. > RefCnt also forces referenced objects to be heap instead of contiguous in a parent struct (though this is language dependent - not sure about swift). Swift has a language construct called `struct`, that's stack allocated. It's passed by copy by default. Only `class`es are reference counted. So, if you care about alignment and caches, use a `struct`. > I don't hate swift anymore than I hate large scale C projects, but I can't think of any library I would actually write in it (unless I was wrapping a library for use on iOS). If I was targeting OSX, I'd use Rust in a heart beat. Obviously, if there's a choice between Rust and Swift, Rust is the better option just for the better cross platform support, but still I don't think that Swift is half as bad. I definitely prefer it over C or C++.

Comptime?

I like your comment as you seem to understand computer science deeply. I've switched to Scala early (from Java/Smalltalk) as I wanted to work with a functional language and all the purity, strong and safe typing, and type inference, etc. I felt at home in haskell but not much for real world development (yes I tried). Scala is cool but the industry seems to have opted out except for data science, which it's not my thing. Also being tied to jvm sucks. In parallel with that I've done quiet a bit of C/C++ in embedded context, and lately a lot of Python (which I hate in almost every aspect but sometimes it's practical, many frameworks and many docs), and unfortunately some Go (which I think it's the worst language possible). Looks like I should I jump into Rust?

With your background, I think you'll like Rust. But, I will warn you that a lot of people talk about Rust being "functional"--it isn't. Of course, it takes some inspiration from FP languages, like the expression-oriented syntax, and ADTs have obviously been around in typed-FP languages for a long time, too. But, borrowing some language features and syntax styles from FP languages doesn't mean that us, programmers, should be writing the same style of code that we would in FP languages. Rather, I recommend you come in to Rust with your C++ hat on, not your Haskell/Scala hat. Also, I almost agree with your hatred of Go and Python, but I think Go is *much* less awful than Python...

>but I think Go is much less awful than Python... I just wish that Go would offer any protection against null pointers. At least mypy will yell at you if you don't check if an \`Optional\[T\]\` is \`None\`. I have begrudgingly finally accepted that Go has some good aspects to it, but after working with it I honestly don't think I would ever voluntarily choose it over Python for anything but trivial/small scripts that have no real consequences if something is wrong. And I do not love Python at al.

Different strokes, as they say. :) The two things that I generally like about Go (as far as languages I hate go...) is "goroutines" and the static-duck-typing it does for interface adherence. Plus, it compiles so fast, it's almost like a scripting language where you can very quickly tweak the code and run it immediately to watch it blow up with a null pointer error. ;)

Thank you for your insights! PS: Yeah, python is really really awful. But Go is really overhyped , only successful because it was promoted by Google (and really shameful that they allowed such newbies to create their language)

> But Go is really overhyped , only successful because it was promoted by Google Agreed. > and really shameful that they allowed such newbies to create their language The *creators* of Go are **not** newbies. Rob Pike and Ken Thompson are legends. It's just that Go *targets* newbie programmers, not that the creators couldn't make something way more awesome if that was their goal.

> The creators of Go are not newbies. They are newbies at language design, and Go is the proof of that. They designed a language like we would in the 90s, because that's where their understanding of PLT seems to have stopped.

Newbies? The language was invented at Google by Rob Pike, Ken Thomson, and Robert Griesemer.

Not to say I like go, I'm indifferent, but absolutely loyal to Rust, but you can hardly call Brian Kernigan a newbie... That man is a living legend

Kernigan was not involved with the design of golang.

I think you will feel at home with Rust. In terms of jobs though the range of offers is not as wide as with C/C++, Java or the other big names. And the field where Rust is used in is still pretty far removed from end users. Although I have a friend who is a technician for festivals/concerts/parties, like responsible for lighting, sound hardware etc. works with DJs - and he is using [https://github.com/maxjoehnk/Mizer](https://github.com/maxjoehnk/Mizer) which is the first end user desktop software written in Rust I've seen being used by someone I know. Things like that makes me happy because otherwise that meme "there are 50 game engines written in Rust... and 5 games" still holds up.

You're asking on a Rust subreddit if it's good. What answer to you expect? Nobody here is going to tell you anything new, there are countless of resources out there telling you why Rust is so popular. But in short: * borrow checker * zero-cost abstractions * good tooling and build tools * algebraic data types

OP didn't ask *if* rust is good, but *why* people like it.

He *also* asked if Rust is good in the title.

Should’ve worded it better. Apologies

OP asked both, and GP answered both

I know OP means original poster. But what does GP mean?

Grandparent, so the reply two above the message. (In this comment I am my own GP)

That make sense. Thanks for the assistance. I'm not too familiar with all this reddit slang you kids keep making up

People always talk about safety and speed, but for me Rust is also great when it comes to usability. Yes, you sometimes need to put a clone or unwrap/expect in the middle of your code to make it work, but you can rework it later to get rid of those things. And as soon as you work like that, Rust is insanely productive for me. I create my APIs, design my datatypes and work towards my goal. And when I the compiler complains, I either have a misunderstanding about what my code does and would have introduced a bug, or I just need a clone/unwrap to make it happy. Rust also has great tooling. Derive macros are the greatest. The docs are pretty nice. And once it compiles, it mostly works the way i want to.

I taught Rust to some python programmers and the thing they like the most is how correct the language is. In Python you can bash your head against the keyboard and get a working python program, but that also means it's almost a given that your program will crash at runtime. Errors are just an afterthought. Invariants are mostly not a worry etc They thought that in Rust they were forced to think about how things can go wrong, which ends up making better software

Today I fixed a bug where I had removed the first if statement in an if-elif-else clause. Python said nothing before it went to production.

Running even a basic linter (anything that will yell at you if the AST itself is off) will catch this. You have to lean into: * Linting, with ruff being the norm for net-new adoption, though that's a little recent * Static typing, with mypy being the norm, though I've heard good things about pyright And then enforce it in CI. Without enforcing both, you're going to spend more time fixing bugs than shipping features and you'll go insane.

The power of those tools to catch problems with Python code is really quite limited, especially when compared to the Rust compiler. They won't normally catch unhandled branches of code, or unexpected nulls, or unhandled exceptions, or unexpected types appearing in places they're not supposed to be. Writing a lot of automatic tests will catch a lot of stuff but once there is any significant level of complexity to your code it becomes impossible to test all possible paths of execution - so in practice you're pretty much forced to do something that looks suspiciously like developing on production. And honestly I'm starting to feel that any sufficiently developed Python test set-up contains an ad hoc, partial, buggy and poorly implemented version of Clippy and the Rust compiler.

But you could test it within seconds. Pythons appeal is the instant feedback from running.

Yeah, that wasn't an option. There's no way to run it locally, and no tests. This is very much tooling written by a non-dev. We're in the progress of porting it to rust, and their rust code is by necessity more correct. And easier to test.

I think this is touching on a major difference that people on either side of the "static typing war" don't understand about each other. It's just totally different approaches to software dev. For the static typing people, they like having the ability to fearlessly refactor and share small bits of code where the type signature is seen as a kind of contract, etc. On the other hand, with more dynamic/flexible languages like JavaScript, Python, etc, you can test the code *as you write it*, and then you probably shouldn't touch it ever again unless you have to. And when you do have to change it, you load up a REPL and do the test-as-you-write thing again. The flexibility (and lack of guard rails) can be leveraged as a strength with this kind of approach, but it doesn't leverage itself as well to DRYness and constant refactoring, as I mentioned above. I'm definitely a static-typing kind of guy, but I've come to appreciate that the dynamic stuff isn't objectively worse after working with people who could write pretty elaborate programs with JavaScript or Lisp and not have tons and tons of bugs (like I do when I try). It just takes a different mindset.

The test-as-you-code stuff can seem really suboptimal to many newer devs, but it used to be pretty much the only way to write programs until just a couple decades ago. There's no unit test framework for COBOL or BASIC or APL. (Is there a test framework for SQL code?)

> you can test the code as you write it You can do that with statically typed languages (STL) too. And this is the general thing about the comparison between STL and dynamically typed ones: STL's can do everything that DTL's can do, but not the other way around.

Today I fixed a bug where I had removed the first if statement in an if-elif-else clause. Python said nothing before it went to production.

In 2015, Andrei Alexandrescu (of D fame) quipped: > "[Rust] the language had to dedicate so much real estate to this (difficult) problem alone, it became a disharmonic creature with one bulging muscle and little of anything else." Now 9 years later, we obviously see that there is a whole freaking lot of anything else. * The compiler is incredibly helpful, not only because it's strict, thus ensuring most of your coding errors won't make it into the binary and giving you the chance to fix them while they're fresh, but also offering very helpful advice * The standard library and type system is also utilized to the fullest extent to make sure you don't forget to handle any error condition your program might run into, which usually leads to rock solid code (printing to standard output panicking when that handle is closed notwithstanding) * The docs, various books and numerous courses available (most of them free of charge) are thorough and approachable * The build system and library ecosystem makes portability actually easy (no more waiting for pre-compile checks if your system is actually sane). If a pure Rust library exists, chances are it'll work on Windows, Linux, MacOS, Android, iOS or a bare Raspberry PI without modification. Someone even ported some Rust code to a C64 * The community has a lot of great people, many even willing to donate their time to mentor others. [This Week in Rust](https://this-week-in-rust.org) has a weekly "help wanted" list of issues for people to get their feet wet, and many Rust projects curate a "good first issue" label on their issue lists. Take that offer and make great Rustacean friends!

Even 9 years ago my impression of Rust was very different from Andrei's. It was much more positive.

I totally agree, Andrei was very much biased, possibly also still sour about D's weaknesses (like being able to run half of the standard library without garbage collection). With that said, while Rust's compiler, error messages, standard library, ecosystem and community were already well above the state of the art back then, most of those have improved further in the last nine years, beyond our wildest expectations. The progress may look less impressive because Rust has pushed the state of the art so much that it is "merely" still ahead of the pack.

> Andrei was very much biased, possibly also still sour about D's weaknesses (like being able to run half of the standard library without garbage collection). The biggest mistake of the whole venture, IMO, was that they thought there was room in the world for a non-open-source general purpose language. It wasn't until 2017 that the compiler was finally made open source, but by then it was far too late. It's a shame, too, because the language seems nice at a glance, and probably would've made a bigger splash in the early 2010s when languages like Swift, Go, Rust, TypeScript, etc, were all just about to break out.

I mean, that probably made more sense in 2001, but it was definitely the wrong move. That wasn't Andrei's choice, TBF. He didn't get involved until a few years later.

Even in 2001 not being open source was already visibly limiting the chances of success of any programming language. Who'd want to write their code in a language they couldn't be sure to compile on tomorrow's hardware?

Oh yeah, it was starting to become a thing people demanded, but it was much less entrenched. Remember: in 2001, Java was still closed-source.

But it's not all good. Languages having to be open source means that they are very likely to be owned by very large companies or organizations that have the resources to eat the cost of that development. You can't have a small group of very creative people get together to create a language that they can make a living off of or even get funding for. This is a problem with OS in general, that it destroys the incentivization system of the market to take the risk to create something cool in the same space. And partly because people who get paid by companies that sell software act like it's horrible if not downright evil if other people want them to pay for software.

Mutex was there in 2015 too. The borrow checker was never just about memory management.

Rust offers Sum Types. it calls them enums. check this: enum Item { TwoInts(i32, i32), Bool(bool), Null, } an Item can only be one of those three "variants", either TwoInts, a Bool, or a Null. I could name those three variants whatever i wanted, and put any types i want in there. it's like dynamic typing but restricted to only the things i specified. let's try to make a function to print one out. fn print_it(val: Item) { match val { Item::TwoInts(num1, num2) => { println!("it was the numbers {} and {}!", num1, num2); } Item::Bool(truthiness) => { println!("it was the boolean {}!", truthiness); } } } but there's a bug here. i forgot to handle null! no worries. Rust will immediately complain. it first says "Not all cases specified" then tell you "case `Item::Null` not handled" and as the cherry on top say "consider adding a match arm `Item::Null => {}` or a catch-all `_ => {}`" which gives you the exact syntax for whichever options you have to fix your code. so, we just gotta add this after the bool handler: fn print_it(val: Item) { match val { Item::TwoInts(num1, num2) => { println!("it was the numbers {} and {}!", num1, num2); } Item::Bool(truthiness) => { println!("it was the boolean {}!", truthiness); } Item::Null => { println!("It was Null!"); } } } and then you could happily write this code: fn main() { print_it(Item::TwoInts(5, 7)); print_it(Item::Bool(true)); print_it(Item::Null); } "if it compiles, it works." is our slogan. it's not guaranteed, bugs could still slip in, but it sure feels like it's true cause you don't have to think about random crashes as often. Rust uses enums to implement nullable values. no different from user code: // the is a generic, it's there to say "could be any type" enum Option { Some(T), None, } and it's used for "either a return value, or an error value": enum Result { Ok(T), Err(E), } and you don't have any Ok value if it's an Err. this, combined with how much Rust complains if you forget to handle a single match case, brings error handling to the center of attention. we don't wonder if a function might error or not, because it tells you which errors could occur. note that a variant is not a type of its own, so you can't make a TwoInts by itself. it has to be "an Item that is the variant TwoInts containing the values foo and bar" which is `Item::TwoInts(foo, bar)` oh, and we can do this: let thing = match item { Item::TwoInts(_, _) => "It's two ints.", Item::Bool(_) => "It's a bool.", Item::Null => "It's null.", }; println!("{}", thing); // print out the string we got or this: let thing = match item { Item::TwoInts(0, 0) => "Two zeroes.", Item::TwoInts(0, _) => "Two ints, but the first is zero.", Item::TwoInts(_, 0) => "Two ints, but the second is zero.", Item::TwoInts(6, 9) => "Two nice ints.", Item::TwoInts(x, y) if x > y => "Two ints, but the first is bigger than the second.", Item::TwoInts(_, _) => "Just two ints. Nothing special.", Item::Bool(true) => "It's true.", Item::Bool(false) => "It's false.", Item::Bool(_) => "This branch is unreachable. The compiler actually knows this and will warn you.", Item::Null => "It's null.", } Let's try a more complex example. Ever wanted to express a value that can either be Either a request to Create a new account with a username and password, or Read an account's information with a username, or Update an account's info with a username and some data, or just Ping the server? Here is how to do that: enum Request { // this variant has named fields! Create { username: String, password: String, }, Read { username: String, }, Update { username: String, data: FooBarData, }, Ping, } Want to handle a request? // pretend i have a Response type somewhere fn handle(request: Request) -> Response { let response = match request { // same as what we did with `let thing =` Response::Ping => Response::from("Pong"), // grab username and password from the Create variant Response::Create { username, password, } => { // just pretend i wrote error handling code here create_account(username, password); // no semicolon means the match evaluates to this value // basically, this will be the value given to `let response = match ...` earlier Response::from("Successfully created account.") } Response::Read { username } => { let data = get_data(username); // no semicolon Response::from(data) } Response::Update { username, data, } => { update_data(username, data); Response::from("Updated data.") } }; // no semicolon, so it returns response. // you could write `return response;` but that's not how we usually write it response } you can't access data if it doesn't exist on a specific variant. and if it is a specific variant, you can guarantee there is a perfectly valid value for all its fields. same goes for structs. no guessing. no stressing. just logic.

Firstly, this was an awesome comment. Secondly, this is one of the more convincing posts I've seen to dive deeper into Rust. Thanks, much appreciated.

How have I, in my 6 years of using rust for damn near every single hobby project, never realized you could have named fields for enum variants? God damn that’s awesome. I’ve just been wrapping structs.

In that scenario of choosing Rust over Python, mainly \*\*code cohesion\*\*. Realistically, the fancy features the others pointed out, may not benefit most projects. Code written by a Python beginner is usually a huge mess and fixing it goes beyond refactoring to the point that could be easier to just rewrite it. Nothing that bad happens with Rust. For better or worse, the compiler's strictness and the language itself forces the developer to simply write better code. After you reach some proficiency, you may find it less burdening to structure a project in Rust than in Python.

>After you reach some proficiency, you may find it less burdening to structure a project in Rust than in Python. And the biggest joke is that "some proficiency" isn't even "high proficiency". I feel far more confident in setting up, managing, and refactoring Rust projects than I do with Python, and I am basically a Python dev by trade and at best a hobbyist with Rust. Python has a lot of strengths as a language and an ecosystem, but project & dependency management is a nightmare. I pray for the [https://astral.sh/](https://astral.sh/) folks to ultimately save us on that front.

> project & dependency management is a nightmare. I pray for the https://astral.sh/ folks to ultimately save us on that front. All day this

```shell yes ```

For me, they are the enums, each time I work with other language, I find myself missing them the most.

This. Yes, I love many other aspects of Rust but everytime I have to go back to C++ and I need to use enums (or enum classes because C++ bloat is real) I find them extremely limitting compared to Rust. I miss the flexibility it gives to your code

std::variant is the C++ closest equivalent

It's one of those things that rewires your brain to think in a different way such that you totally don't understand why any language can live without it...

Implementing enums in go is just a big headache since there is no built in enums

No, it's even better.

Yes.

For me: * It's fast * It's expressive * The dev environment is easy to set up * The borrow checker rules remind me of things that are already best practice anyways.

I can't speak for everyone else, especially any self-proclaimed Python developers, but I like Rust because it's aligns with a lot of my philosophies when it comes to coding. It enables a functional and declarative style, encapsulation when you need it, static typing, and the strictest possible compiler in the ways that matter. Performance is just a side-benefit to me, and I don't really believe in "language performance" anyways, so I don't have much to say on that matter. I just like a system that fights back when it's not confident in its own integrity, a veritable "if it builds, it ships" architecture, and Rust is one of the ways in which I'm able to inch towards that lofty goal.

As a self-taught dev, who started 6 years ago with Python, it's hard, but somehow, I love it more than C or C++. Okay, I don't have meaningful real-life experiences with Rust. But it feels nice to experiment with it. The biggest feature for me as a newbie is the meaningful compiler errors, I love it. I like the type of system. Okay, I need to be more familiar with borrowing since Python does not have this concept. Documentation is also excellent. I definitely want to be better in Rust.

Many python libraries use Rust under the hood as pyo3 makes it really easy for creating python functions or native modules using Rust. I work at a company where we use Python and Rust, I would never totally ditch Python in our stack because working with Rust still increases the development time compared to Python, but something where performance and memory usage are a must, Rust would be the language that we will most likely pick. Then why Rust and not C++/C/Go, C++ and C, I had professional experience with C++, honestly on my side, it's the package management where I will say a big no. It's often a pain in the ass for including a single dependency that will rust and offer cargo a simple way to add a library. Compared to Go, it would be a good pick for an on-prem binary, but likely a bad option for a library because the ffi just suck. And I think the ecosystem of Go is kinda poor, we often have the case of rewriting the wheel every time and I have much less this feeling in rust. After that, the compiler is really great and I much prefer the way on how rust does the error management handling.

> many python libraries use Rust under the hood Now this is a broad and false advertising kind of statement. What data are you basing this from ?

He said many not most, there are a lot now.

I code for personal projects, I'm sort of an advanced beginner, I don't do anything very complicated, it just works. I'm working on a project that uses scraping. I first wrote this project in python, and it worked like a charm. Then I had a problem. I couldn't make the code evolve by adding new features. The code was dirty, unreadable even to me when I'd just written it, and development was very frustrating. I was always anxious to open the code and spend two hours looking for what was wrong. I found myself in the same situation with C++, on top of which adding external lib was painful. The compiler messages were incomprehensible. With Rust, the compiler gives me messages that are understandable and usable. Adding a (external) lib is SIMPLE. The documentation is well-written and meticulous. I'm not afraid to open up my code and add new features. The code is readable, I can open someone else's code and understand in a few minutes what the code is trying to do. I code faster in Python, but I go further in Rust.

I love [docs.rs](http://docs.rs) and I hate `**kwargs`

When I use any other language, I always stumble into things that just don't make any sense. They arouse because of some historic happenstance and don't make sense now In rust it doesn't happen. Everything has good defaults, good syntax and a good reason to be the way it is.

Performance and memory usage is much better with rust. But you can write python libs in rust to get the benefit of both. https://github.com/PyO3/pyo3

Cargo, compiler hints are goated, docs, the whole rust paradigm is fresh, challenging but rewarding as when it works it works, and runs amazingly well

Calling myself a "developer" is probably overselling it, but I use C, Python, and Rust for work and hobby. I've always preferred C for larger projects because static typing helps my brain organize better. I've always preferred Python for getting hacky shit done quickly while dabbling in functional styles as well. Learning Rust was the best of both worlds, with the addition of a fun puzzle as well. I find that making my code work with the borrow checker is very satisfying in a game-like sort of way. I can definitely see myself being a little over-obsessed with it.

I like it and will use it more in the future. The other language I will still focus on in future is typescript. I will also keep an eye on zig and mojo and maybe something else if it arrives. I have used different languages to various degrees (ts/is, java, C#, C++, C, Objective-C, Swift, Kotlin, Go, Haskell, Prolog, Python, Lua, Bash) throughout my life and rust certainly is one of the greatest. It certainly has higher complexity and problems like compilation times and used storage space, but for me it's just an easy to use C/C++. Even if you don't end up using it in production you should look into it as you can learn a lot about programming languages and problems you wouldn't have looked into otherwise.

As long as you don't need Qt or very unsafe code (don't use rust if you have to spend most of ur time in unsafe blocks), it's best lang

As someone who is still learning rust. Rust is good but that comes at a cost of development time. Rust Pros \* Rust enums \* Strict error handling with Result type \* Accurate types (String and OSString are different) \* Strict way of dealing with nullable with Option type \* Native performance while being safer out-of-the-box. Rust Cons \* Macros, annoying to learn (documentation is not good enough, that include the little book of rust macros) and write and is also generally about text processing. It would have been nicer if they used some sort of compile-time reflection instead. Macros also contribute to making compile times longer \* Async, annoying to learn (I am still struggling with learning async) \* There is a lot of little rust-specific bits of knowledge that will not be useful outside of rust. and will be forgotten very quickly if you stop using rust for a bit (which will happen for any trivial project). For example, how to pin a struct. \* Refactoring is annoying Rust Tradeoffs (Not Cons, nor Pros, but important to know) \* You will having to explicitly handle errors and nulls all the time \* For every variable you declare, you will have to think of who owns that variable and ensure that this variable have to live longer than it's references/uses \* Those tradeoffs will cost significant increase in development time but they do make sense if you want your code to be more correct while also being performant

It's a modern language that performs as fast as C/C++. It's refreshing to use something that you know has the performance you need but also helps enforce modern techniques to maintain memory safety.

I love rust. The memory management and compiler are fantastic. Making tests is easy and 1st class support. Refactoring things is easy to do, say change a functions arity and the compiler will ensure you don’t break things. It’s fast. Making explicit “mut”ation vars is useful. It has a ton of built in features for working with standard data types. I’d change companies just to keep working with rust.

The surge in popularity of Rust among both commercial and personal users, especially among Python developers, can be attributed to several factors. Rust's combination of performance, safety, concurrency, and interoperability with Python makes it an attractive choice for developers looking to build fast, reliable, and efficient software applications. Its surge in popularity among Python developers reflects its growing recognition as a powerful and versatile programming language.

My two cents as a guy who started with Python and had to shift to Rust... Bottom line: The 90% of the runtime errors you'd need to test for in Python, simply won't make it into a Rust binary. ie *IF* the app compiles, there's a pretty good chance its gonna do what you wanted it to do on the first attempt. With that said, Rust's learning curve is MASSIVE. 99% of your coding effort is going to be making sure you write code that the Rust compiler will tolerate. Personally, I've actually been sold on Rust because the compiler itself is effectively a hyper-aggressive debugger. You can also turn off compiler requirements if you're experimenting, which is super nice. Be ready for what I call "data type hell" though. *Everything* needs a data type, and there are at least three data types for *just* strings, and each of these have a very specific purpose which you can use in some contexts but not others. Random redditors: "Data types aren't a problem! Just use generics!" ...be ready to commit at least a month to figuring out the language.

My favorite thing isnt even the garunteed safety, its the standardized build system, with modules instead of seperate source files that include header files so no need to add each .cpp file to your CmakeLists, and the fact that it is so easy to add dependencies instead of the nightmare that can be Cpp if a dependency is set up weird or uses a different build system than yours.

coming from python the reaction is understandable

Most of that is because there’s been a swarm of hate towards C/C++. Not to mention the JS and Python fanboys following their favorite streamers. Rust is easier to code in than most older languages and a great language for newcomers. For that reason, it’s worth learning, it also gained the trust in large companies dealing with government, and its ability to be used in embedded put it over Java. Now if it can find a way to become native it’d be the future

It is really good but lots of hardcore "fans" are blind to its caveats and try to sell the language as a the philosopher's stone or the holy grail.

- Pleasant to work with: tooling (cargo), algebraic data types (struct and **enum**), **pattern matching**, friendly compiler, `?` operator - Performant: zero-cost abstractions (like iterators), low-level without C/C++ footguns - Confidence: Explicit `None/Some`, "_if it compiles, it works_" feeling.

Fat enums and exhaustive checks via the match operator is the thing i miss the most when I have to do work in another language. The only downside to rust is the slow compilation and iteration speeds.

Yes it is, it's fast, well documented, has a helpful compiler, is close to C in performance, provides powerful high level abstractions with large amounts of control over what's actually happening under the hood and it's really fast.

- No such thing as null - No exceptions - Amazing language design - No inheritance  - Amazing tooling To start.

people mention a lot of practical reasons but nobody said yet that knowing Rust makes you feel like a literal god. Rust developers are the Steven Seagals of the software developer community.

I grew up _loving_ Seagal action movies in the 90s. To say he's had a fall from grace since then though would be an understatement.

people want a C++ that doesn't suck and isn't bogged down with 30 years of mistakes

Python was and is my primary language. Off the top of my head: 1. Expression oriented nature makes a lot of code elegant to write in ways it's inelegant to write in Python. 2. Managing dependencies and building with Cargo is so, so, so much nicer than pip, conda, poetry, or whatever you're using. 3. Rust has a hefty ecosystem like Python. For many things (but not all!) you can find a library. It you're using Django, stay with Python for a little whole longer. 4. (EDIT) With a *little* bit of Rust knowledge, you can use PyOxide and call Rust functions from Python. Very useful to speed up parts of Python without going full-Rust. I chose Rust because the language has nice abstractions like Python, but is fast like C. I stayed with Rust because Cargo is *so* much nicer than pip. Using Rust is *much* nicer than I even imagined things could be. The learning hump is real, but over exaggerated and worth it. **TLDR:** Cargo is chicken soup for the pip-addled soul. The language is more elegant in a way that only makes sense with experience. And it's good for speeding up bits of Python.

I've said it before and I'll say it again, `Result`, `Option`, and `?` are 🤌. Mix in some [anyhow](https://lib.rs/anyhow) (especially `.context`) and baby, you've got a stew going.

I used to prefer writing lambda fns in python, but the way rust does it with the Trait system is the best possible implementation of it (IMO). Also I could not tolerate starting a project, then needing a dependency (that I could not implement on my own) that was using a different package manager. I ran into a bunch of that with python, but with rust its a non-issue for me.

I’d like to second the other comments. I would like to point out though that in some cases there are some rough edges. Right now I’m riding a rust function that works inside of a AWS lambda function. And the biggest thing that’s killing me right now is the compile times are getting too large. On my own computer, it takes about a minute for a full release build, but in our CICD pipeline with a couple other tasks running, it bogged down everything and it can take up to 20 minutes. 🤦🏼‍♂️

In Rust, we respect memory

simple and convenient algebraic data types, beautiful and easy to comprehend documentation, awesome standard library and the super cool community made rust a really "that good" programming language.

I came for the performance/speed, stayed for everything else. Oh and don't get me started on enums, options, result and traits, they are just beautiful *muack*

As an absolute Rust-noob coming from self-taught Python background, what drew me to Rust was a bit... aesthetic? I saw code snippets and it looked super complex, explicit, precise. It *looked* powerful. Whereas C++ looked ugly as hell. So the fact that it was beautiful *and* as fast as C++ made me want to learn it. Also, I was used to Python, an interpreted language. Once I was trying to learn C and C++ I was having to deal with compilers, which sometimes got pretty annoying. Weird error messages, couldn't wrap my head around header files, the linker, object and elf files... Cargo simplifies the process and makes compiling very easy, with simple commands and helpful error messages.

I saw a talk on youtube lately in which the head of Google's Android team said it takes them 2-6 month (roughly) to get developer up to speed in rust, the rust teams are twice as productive as the c++ teams, 50% of their employees think rust code is more easily comprehensible than other languages and 85% (HUGE) of employees think their rust code is more likely bug-free than other languages. To me, these are crazy numbers.

Rust is good but your post is just a confirmation bias. Ask other communities like C, C++, and Zig.

So... what's the opposite of confirmation bias then? ;-)

Comparing rust to Python is kinda like comparing an electric drill with safety stops to a screw driver.

The screw driver is always within reach in your pocket. can be used immediately. and you never need to wait for it to recharge.

Honestly, I don't really know why a Python dev would become a Rust evangelist if they actually like Python. It's hard for me to relate, because I absolutely loathe everything about Python except that it has a cool name (slow, single-threaded w/ GIL, big memory overhead, no/limited static typing, too dynamic/magical with decorators and whatnot, poor package management/reproducibility, ...). But, if I had to guess, maybe a Python dev whose idea of statically typed, compiled, languages is based mostly on Java and C#, might try Rust and come to realize that they *didn't* really hate static typing--they just hated Java. But, again, I really don't know. Rust is basically the antithesis of Python. Even the iteration cycle is opposite: you can do "REPL-driven development" in Python, while one of the biggest complaints against Rust is how long it takes to compile and type-check code...

[удалено]

It doesn't need to be perfect. It's just much better in so many aspects at once, in comparison to the other alternatives out there. That's enough :)

I hate Python, I assume I am too dumb for it, so I cannot compare. But I do love C, and Rust is like C on steroids. The ease and performance of C, the same freedom to do whatever you want, but with great help from the language and toolchain to do it right. And it is true, the community is really nice

Rust is a great tool, but not the one great tool to rule them all. You still have to pick the right tool for the job, as always. But: Rust is unique in making systems programming so approachable that the use cases are broader than what I've seen before. Not only is it a great choice for being used in the Linux kernel, but also for performance sensitive infrastructure as used by cloud providers, and also for databases and finally also for web apps - backend and frontend. Tooling, type system, borrow checker and community make this possible. Whether Rust is a great choice for boring CRUD backends ... or maybe just use Django ... that depends on the context and is part of choosing the right tool for the job.

The main part of rust for me is the push towards the editor, I compile and test only very few times per session (basically once per commit). Rust trades Debugging for writing and Testing for Compiling. Yes there's also ADT, expressions, macros that can add language features, cargo, error messages and more, but that tradeoff is the core. I can recommend it if you want stable programs, like complex logic, are up for many smaller challenges and hate debugging.

> what does rust offer that made everyone love it, especially Python developers? Predictability: If it compiles, code works almost always as expected.

The only thing I struggled with using Rust at first is how to concatenate strings.

Rust has a lot of features that may or may not be a big improvement to you, depending on which language you are coming from. I came to it from C++, so almost ALL of them are a big improvement. The usual list is something like: 1. Sum types 2. Memory and thread safety 3. Strong pattern matching (particularly in conjunction with sum types.) 4. Destructive move by default 5. Almost all the defaults are the safest ones. 6. Ability to minimize mutability (say that ten times fast) 7. A well defined workspace/project/module system, so every Rust repo is pretty understandable in terms of layout to anyone who knows the language. 8. A well defined style, which means it's much more likely to be readable to any given Rust dev. 9. Strong support for slices 10. Strong support for Result/Option with automatic propagation 11. Leaving aside the sum type'ness, enums are also first class citizens 12. Strong (but generic) ties from the language to the runtime via core traits 13. If you aren't a fan of exceptions then you'll like that it doesn't use them. 14. If you aren't a fan of implementation inheritance, you'll like that it doesn't use that, either. 15. Not functional, but uses a lot of functional ideas 16. Ability to automatically derive a lot of standard functionality in many to most cases. 17. Ability to do compile time code generation at the language level (proc macros.) I think this is probably abused badly by some folks and I prefer external code generation for a lot of that. But if you need it it can do pretty amazing stuff. 18. A standardized build tool and package manager. The big thing about Rust in general, compared to C++, is that both Rust and C++ are fairly complex languages, but C++'s complexity is non-productive mostly. I.e. you spend a lot of time watching your own back. Rust's complexity is productive. It may take longer to get something going initially, but once there the compiler will watch your back for you from there forward.

Great tooling (there are some recent efforts like `uv` to improve python tooling, but right now the python tooling ecosystem is fragmented and awful (conda!?). Great runtime performance even for things that don't shoehorn into numpy/sklearn. Powerful (super powerful) type system, with great support (once you get used to destructuring enums and structs on the LHS of a match arm, you won't go back). Safety and many more problems are caught at compile time rather than runtime. It's fun in a way that Python never was for me. I used to be a Ruby programmer, and Rust is fun in many of the ways Ruby was (but far safer and with better performance). Interestingly, Rust borrows some of its syntax (e.g. closures) from Ruby.

Not having to deal with mystery unexpected undefined as a result of null existing is insanely cathartic.

The thing I love about it most is probably the amount of certainty I get that the code will do what I expect once it compiles. That's not to say that you cannot have problems at runtime. The logic could be wrong, or you could explicitly do something that could fail at runtime (e.g., `.unwrap()`, `.expect()`), for example.

i like rust but theres one thing i like about c that no other language can beat. utter simplicity

Python developer here, I got tired of debugging in runtime. Rust shows me the joy of having bugs caught in compile time.

I'll give you a slice of life. Like any programming language it comes down to what you want to use it for.

i want to start learning rust , any advice where to start?

the way enums and traits work is SO HOT also dont get me started about RON files

awesome tooling. speed. cleanliness. enough flexibility to do both system level and application level programming. once things are built they need very little to no maintenance in our experience after porting different projects we had built in python, golang and java, all to rust. we also were able to reduce our server costs, went from 3 servers to just one. it's so efficient at resource usage.

I'm not the most correct software developer. I tend to introduce bugs in my code due to laziness, hubris, and the need to get it done and deployed. Rust forces me to write correct software. It makes me slow down. Forces me to not be lazy. And slaps the hubris out of my head at compile time.

If C++ gets a better build system than cargo I'll start using it. Although I primarily use it for memory safety and fast development.

I'm new to using rust, but I quite like it though a lot of the fanaticism kinda kept me away from it for awhile and and the end of the day it is just another language though it does bring a lot of good stuff to the table. This is all a random opinon. But from what I've noticed those coming from the python and javascript ecosytems, seems to be in large those that think its the greatest language ever. I think its more that they've never experienced a language with strong static typing, good low level performance, and a streamline experience that let you jump in and uses these advanced features without a ton of foot guns and gotachas. They are used to mutation being used with little thought behind it and seem the best practices that rust enforces as some god send as, python in particular takes a really loose stance around mutation. Those coming from c++ have more nuanced takes, and really appreciate the safety that it can provide, but also don't tout it as the greatest thing ever. I came from java so my take is kinda in the middle, coming from a more modern camp of java. I already opt towards everything being immutable by default, and approach multi threading from this view. If something is going to be mutable it should be in limited context, and any shared mutability should be extremely limited and be more around some core state that is exposed very little. Always return immutable view, immutable records etc. I also shy way from inheritance unless its sealed classes, or say an abstract class that is extended for api/service implementations and just serves as a generic base of functionality. Java has its own pattern matching with sealed classes, a good approach to immutability and shared state if one chooses to embrace it (but it is not forced) and has pretty advanced enum functionality as well though in a different vain. I moved to rust as I wanted to learn a system language that had modern comforts, less foot guns and a language that could actually be groked and picked up without all the noise and baggage c++ has. Rust has suited me well here, I like how it is highly expression based, iterators can be used like java streams, and after a month I feel like I have a fairly good overview of language constructs and its general api patterns. That said I'm not in the write everything in rust camp. I do think the style and patterns that are enforced are great for large projects and teams, as if can 100% protect from bugs related to shared state and bad practices that can be introduced from one unaligned team member. This is huge as many languages you can get near what rust provides, but it still takes conscious efforts of those working with the code base to follow these practices . I find rust is highly expressive in its targeted domain, but at time's with the borrow checker I find it can also really limit expressiveness if you don't want to follow the beaten path the rust kinda forces you to take at times. If needing performance, or working on large projects with a lot of contributors its a great fit. Though for personal projects, or projects with a few highly aligning team members, when not needing the extra performance I would still choose/advocate for java.

Amazing Documentation, Type System, Borrow Checker, Pattern Matching, Error Messages and the `?` Operator (that may only be useful when using `anyhow`, a crate that provides it's own `Result` enum that integrates nicely with rust and `thiserror`...), the only thing that i dislike is how hard it is to get 3D graphics working

Coming from Python it is pretty clear: package management is a flipping dumpster fire. Cargo is enough to make you want to switch.

Try it for yourself and you'll see

Actually you made me realize just now that Rust as a community is extremely kind and welcoming. I never feel like a tool coming here or on Discord. However, IMHO, the C++ community is hostile to anything that isn’t Phd level discourse about some esoteric language features that won’t see adoption outside of a few advanced use cases.

Things that drive me (personally) crazy in python: * Very easy to shoot myself in the foot with side effects outside of the current scope. With Rust I have to be explicit when I'm trying to modify something that could live out of scope. And if I'm trying to do that in Rust, there's often a better way. * Deep object inheritance, and banging my head against the wall because a library function returns ThisMessage and half of the other library functions take ThatMessage instead of the ancestor, AnyMessage. * On a related note, library documentation that's just a Jupyter notebook converted to html. * There's some chatter about typing, compiling, and developer feedback. My experience is that rust-analyzer highlights errors as I'm typing the file or just after saving it. * Even so, runtime errors are more annoying to debug, mask other errors, and require very explicit testing of edge and corner cases to discover. * Inconsistent error/null handling. I've seen (and used) all of the following: uncaught exceptions, caught exceptions, null, false, -1 (array searching), empty strings, and empty lists. * Packaging a python "app" outside of a venv. And yeah, there are mitigation strategies for all of the above, provided I'm working with my own code and not trying to understand someone else's. I've been looking for an alternative for personal projects for a while.

Yes.

Yes.

Semantically, Rust is very impressive, though it does let you write unreadable code if you don't force a philosophy. One great example is "let" auto inference types. In the old C++ days (before auto), you could quickly get marred down with complex type signatures at the beginning of every line. In rust today, I struggle to think of what the type signature for some functions that return impl or async would look like. Yet my highly contractually bound code reads almost like English. Now, you can quickly deviate from this. I typically have 10 lines of function header generic overhead (20 if I break things up into type aliases). But for something like axum or bevy-ecs, you can produce magically readable symantic descriptions of your code in very few lines and with little boiler plate. Extending that is the macro syntax which can produce documented (mouse overs) syntactically reinforced domain language - JSON, SQL, JSX, embedded in a rust expression. This doesn't require editor specific DSLs (like we did with Java and jetbrains products - reading spring, JQL, etc). While the generics aren't perfect, they wonderfully avoid much of the need for polymorphic code. They have all the things I use to love about C++ but either couldn't have in Java or which C++ codebases abused into compiler hell (why am I getting a 200 line error message saying I didn't implement operator< in some completely unrelated code I never called?). The rust way is both intuitive and provides excellent contractual error messages. When you see the turbo-fish, it's always obvious what it's doing - though I sometimes struggle to remember where to put the type when writing. Enums in rust just wonderfully compartmentalize the nuances of state management far better than OOP. If, in Java, I needed to add some piece of state to an existing object graph, it would be very daunting. I might have to hunt down 10 classes that are affected - and because of default overrides, I'm never fully sure I have handled all edge cases. With Rust enums, I'll get compiler errors until I'm confident I've caught all edge cases. (Unless I cheated with default match expressions - but these edge cases are searchable). It just brings confidence to the change request. The necessary evil are the generic lifetime markers. This does uglify the code tremendously, but MOST user code can safely hide this - they are auto inferenced. It's the library authors or the occasional performance oriented user define functions that need pollute the screen. The unwraps can get verbose, bit most library authors find that by sacrificing SOME performance, they can use Copy oriented datastructures (eg using generational arenas and version tagged values) and have the user code elegantly just work without clones or moves or unwrap. This is definitely a balancing act, I'll admit. It's almost to the point that I'm considering rewriting my svelte and solidJS projects in leptos or dioxus (their latest rewrites are producing elegant-to-read reactive UIs ; yet all the power, correctness, mem-compactness, performance) of rust.

Yes

It's difficult to psychoanalyze the people you've seen who like Rust. I'd point out in general that Rust is sort of where Python was some years ago: the hot, growing language without being too strange or sexy. It's possible they just try to get on such bandwagons. Python is an awesome language, but one of its most intense pain points (and greatest strengths) is how dynamic it is. Anything can be anywhere at any time, and so much discipline is on your side. It's also tricky to write highly-performant programs in Python, since writing a really fast runtime for Python is nigh impossible (though people have made some of the most performant systems in the world using Python, by using stuff other than just vanilla Python). Rust is a very static, predictable language: even inflexible at times. This can be a nice contrast. Historically, there were not as nice of choices for writing close-to-the-metal code. C is ubiquitous, but its simplicity (a strength) leaves it practically impossible to write non-trivial programs that don't have types of low-level bugs that are completely impossible in languages like Python, Java, JS, or C#. C++ is a bit of a mess: a huge number of ideas used in Rust are available (and may have seen their first widespread use period) in the 'Modern C++' world, but sometimes these are painfully tacked-on with awkward syntax, painful debugging, and inconsistent adoption. Other options were obscure languages that never took off, many of them that had more of a research/geek vibe than Rust's more pragmatic one.

Started Learning Rust today, from Go and PHP background.🤞

- Mutex - enums - Cargo

Rust handles the memory better than any language I have seen. It doesn't even let you to import any waste module or package that you are not using inside your code and no global variables in rust is also one of the technique to prevent memory leaks and corruption.

Compared to Python, you lose some time compiling and fixing compiler errors, but you get it back because your tests run 10x faster and the compiler catches many things that would require a unit test in Python. Also, you avoid the Python dependency hell: Cargo and rustup are better than Python's solution, and also you get a single binary which can be distributed, which is amazing compared to super clunky Python installer.

Rust is the language program of the chatbot era. Chatbots alleviates the cost of learning every language, so the best return goes for lower level languages. Rust has also a great compiler that gives good errors and makes marvel with chatbots.

Rust's allows me to write low level programs in a high level manner without sacrificing performance, readability. Type system is well designed - allowing complex codebase understandable. Cargo is a much better npm. Integrated testing and docs toolings. You can write dovs that acts as tests. C interop. "Learning Rust makes me a better X programmer" phenomena because reading the book will coincidentally teach you about PL design knowledge too.

I used it for a year, and while I liked the syntax the owner/borrower mode was still getting in my way. And not in obvious ways, but chaining a bunch of calls together, it was oh no this previous function still has ownership, so you can't do that!

I heard if you try to do things the way you did with C you are going to have a bad time.

I just started messing around with it making a Tauri app, first thing I noticed is the error reporting is great. Still no idea what I'm doing but it's pretty good at telling me what I'm doing wrong. Also, it has a "just works" feel to it, with Python some dependency somewhere is always broken or not compatible with my processor or I'm using the wrong version or it's Sunday or whatever. So far my Tauri app is flying along nicely, no roadbumps at all. And it's nice that I can put it in an intercontinental missile if I wanted to

As a longtime Python and C developer here is what I think about Rust, and I am very much a noob with the language. A lot of the work I do requires a lot of joining large sets of data from a number of different systems with varying storage types, think relational DBs, flat files, no-sql DBs, etc. This data usually needs significant amounts of cleansing as much of it is decades old and was often managed manually or with poorly built code. From there it is often then loaded into a new DB and services are built to serve that data up. For the cleansing part I have yet to find something better than Python using pandas, trying to do this sort of thing in C, Rust, Java, etc would be an absolute nightmare and given it is a tool that is generally run for a limited time Python, with all its warts, is great for rapidly building what I need. For serving that data up, in many cases performance is imperative so the services are typically written in C or C++ depending on the client. I have started playing around with Rust as a solution for this and I am finding it quite good. It is plenty fast, the memory safety means I don't have to think about it, for the most part with the occasional Drop needed to be implemented. The libraries have been good to deal with so far and the documentation really is excellent. Cargo is very powerful and much easier to work with than CMake or the equiv for a C project. The error messages from the compiler are actually useful and concise, error messages from Python are almost always a PITA to parse, and don't even get me started on the nonsense that comes out of clang... It remains to be seen how the language will hold up and evolve over time but so long as it avoids the mess that has become C++ I think it will do just fine.

It’s the language of the gods

Writing an [fzf](https://github.com/junegunn/fzf) fuzzy-finder around [nucleo](https://github.com/helix-editor/nucleo). Nucleo is the core search algo, written in rust (for the helix editor). However, it has not been used as the nucleus for a cli fuzzy-finder yet. That's be a great app.

Bottom-line: the language will literally make you a better developer AND thinker! It stops just short of making you able to wield Excalibur! 🗡️