> but still came away with the feeling there was literally no one using Servo

Code from Servo is in every single copy of Firefox, so it's pretty popular as code goes.

> And I find it wholly unappealing to abandon the existing corpus of literal decades of knowledge having been poured into those language ecosystems all in the name of whatever it is that Rust delivers on. I just have too much experience in the industry to throw away my time and play with toys.

Rust doesn't throw away that corpus. Rust draws heavily on that corpus. It leverages LLVM (used to compile C/C++), integrates with C libraries, integrates with GDB, draws a ton of design decisions from actual experience using C++, and so on.

It's a tool that runs inside Firefox, AWS, Microsoft, and a lot of other high-reliability, high-performance areas. It may be young, but it's quickly building (IMO compelling) evidence that it's very much not a "toy." ;)

> Code from Servo is in every single copy of Firefox, so it's pretty popular as code goes.

This is akin to saying the DWM is in every copy of Windows so it's the most popular graphical compositor of all time.

It really isn't. The entire purpose of servo was to be a vehicle for r&d with the eventual goal of merging code back to firefox. It succeeded. No one used it because that really wasn't the point.

> I think you're right in that that was the original sell, but it's not how they sell it today.

That's a very recent change, post spin-off from Mozilla.

I guess that will take a few years then. Having only CEF and Webkit ports out there and is really hard for us out there looking at offscreen embedding.

> I embed web tech

Wait, you're working with web tech – probably the most archetypal field where preventing security vulnerabilities is the top priority – and you don't see the benefit of using Rust instead of C?

It’s definitely a major focus, but from where I operate I have to trust the embedded library to address a lot of those concerns. There’s usually very limited exposure offscreen embedders have to see to.

If Servo is any lighter than CEF, I absolutely want it to be the solution I use. So I’m very interested in its development.

Well, isn't it? :-)

I can give you a few reason you might like rust.

    - Instant boot time.  Because rust is statically compiled, there's no runtime startup or anything involved with it.  From dead to alive is pretty much instant.
    - Low memory footprint.  Because rust does not use a GC, it doesn't need all the bits and pieces of memory storage that modern GCs require.  The memory allocated is (close to) the minimal memory needed to run the application.  Further, due to it's low level nature, it's a lot easier to avoid heap allocations all together and instead focus on stack allocations.
    - It's safe to deploy and expose to the internet.  You'd be a fool to setup a public facing C++/or C application.  That memory model is simply too expensive to safely do even if you did want all the benefits of using a system language.  Not so with rust.  Client facing rust services or even just backends that may see client data are safe to push out.
    - It's fast.  Rust has no startup or warmup time.  From boot it is running just as fast as it ever will be.  This means you don't have to have a warmup period or periods of slow runtime as you scale out rust applications.  That consistent performance is easy to plan for.  That speed and low memory usage have the added bonus of making rust really good if you are trying to optimize operation costs.  You can use smaller or less instances to get the same amount of work done.
    - The model model not only makes memory safe, it prevents different types of concurrency bugs.  While rust won't prevent ALL classes of concurrency issues, it will prevent several of them.  That makes it easier to write parallel applications.

Certainly, if none of those things are issues for you, then there's no reason to give rust a second glance. However, I personally see rust as super exciting because of all of those aspects.

> The model model not only makes memory safe, it prevents different types of concurrency bugs. While rust won't prevent ALL classes of concurrency issues, it will prevent several of them. That makes it easier to write parallel applications.

Bringing data to this discussion, many of the big tech companies have found that ~70% of CVEs are due to memory bugs (free after use, double free, etc.)[0], and these are prevented by Rust's model.

[0] https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro...

> Instant boot time. Because rust is statically compiled, there's no runtime startup or anything involved with it. From dead to alive is pretty much instant.

Dynamic linkage is not the slow part of application startup. The slow part (for applications which are slow) is almost always the gathering of non-compiled assets from disk.

IMO, the lack of dynamic linkage is Rust's #2 weak point, second only to slow build times.

Sorry, that wasn't a dynamic linking dig, but more of a JIT dig.

I agree that rust would be better with dynamic linking. It sucks that you have to build everything when you build one thing :(.

The issue I was specifically thinking of is how slow an untuned JVM can be for startup times and to get to peak performance (It HAS gotten better, but is nowhere near as fast as rust or even python). The default for these JITed languages is to pass everything through a non-optimized code path and only optimize later when the various methods are exercised enough.

Rust has an advantage here in that it doesn't do any sort of runtime analysis to improve performance. It simply is as fast as it always will be.

You can use dynamic linking with Rust. You just have to stick to the C ABI when interfacing w/ shared objects, because there is no stable Rust-specific ABI.

(!) I was under the impression that you could not develop a shared library in Rust even if you exposed a C ABI.

A Rust artifact being used as a dynamically loaded library within a Ruby process via a C ABI is one of the very first, if not maybe first ever, production uses of Rust. You've been able to do this for a long time.

That being said, it is not simple to say, take a binary Rust Cargo project and say "please dynamically link all the crates it uses" or something like that. But if you want a dynamic library to be used by something else? First-class support for that use case exists.

Realistically, three of those 5 points are non-issues for C/C++ devs. The last is only relevant for certain types of workload. So you’re left with one real killer-feature of Rust: the safety. It’s a massive feature that cascades very well into pretty much anything you do... but it’s also one feature really - the benefits of which might not be particularly relevant on large established projects who have probably addressed that problem a long time ago (in their own ad-hoc ways). So the cost-benefit analysis of moving an existing codebase from C/C++ to Rust is not exactly a slam-dunk.

For greenfield, though, my feeling is that one should justify why not using Rust, at this point (when building stuff that was previously the realm of C/C++, of course). If it’s just because of unfamiliarity and initial slow speed of development (as people learn it), it becomes an issue of institutional laziness more than a technical choice.

> the benefits of which might not be particularly relevant on large established projects who have probably addressed that problem a long time ago

It's quite the opposite: the larger a C/C++ project gets, the more problem you are starting to have with safety. Securing and modifying millions of lines of C/C++ code (especially if it's multi-threaded) is a nightmare, and actually impossible, where people are afraid to refactor old code because all the ownership uncertanities.

Rust changes a global ownership tracking problem to a local one.

But if you can’t have a Big Rewrite, you’re looking at meshing Rust and C/C++ - a suboptimal situation for any language, regardless of ease of technical integration, because of the organizational overhead (now you need to hire developers proficient in both C and Rust, rather than just one of them, and have two sets of standards, two sets of onboarding procedures, etc).

To clarify, I’m not arguing that Rust is bad or inferior (to the contrary!), just that the incentives for established projects to move on from C/C++, from a strategic perspective, might not look that massive if they’re only gaining in safety.

Big companies already use microservices to separate programs (and be sane with memory ownership), so the logical way to move to Rust is to write new microservices in Rust.

> addressed that problem a long time ago (in their own ad-hoc ways)

I think it's becoming increasingly clear that "addressing the problem" in C and C++ means fixing all the memory safety issues you know about. Sqlite is the posterchild of careful testing in a C codebase, and they had a serious CVE last year. Realistically, the vast majority of C and C++ projects have more bugs than that, even if they're staffed by experts who take security seriously.

But I agree with you about the cost-benefit analysis. It's not very often that security issues destroy an entire company, and trying to rewrite a large codebase might be existentially riskier more often than not.

I think the more interesting cost benefit isn't moving from C++ to rust. Rather it is moving from Java or Python or Ruby or Perl to Rust.

You'd pretty much never make the move from Java -> C++ because of the lack of safety. But you may want to do it because of the other non-safety features.

That is where Rust is interesting and competitive. It's the performance and memory footprint of C++ with the memory safety of Java.

Absolutely, but the parent poster referred to C/C++, which is why I mentioned it.

From other languages it’s definitely a stronger proposition in many respects.

> [...] to throw away my time and play with toys.

Rust is not a toy. It's possible that your prejudice stops you from seeing Rust's benefits. It's also possible that you're working in a niche where Rust's advantage compared to C or C++ isn't as great as for most other areas of software development. And that's okay, Rust isn't quite there yet. For some very small niches, it might never be.

> [...] existing corpus of literal decades of knowledge having been poured into those language ecosystems [...]

Frankly, even with those "decades of knowledge", C programs and libraries are still full of security vulnerabilities caused by C's limitations and memory handling. How many more decades will it take? How many more thousands of vulnerabilities?

That's the question, how many UBs and how long more?

> I haven't worked long enough with C or C++ to complain about them (only about a decade or so), but I don't have any issues with those languages

This may be part of the reason. Rust improves on those languages in many ways including better safety, package and build setups as well as doc setups. It's genuinely a breath of fresh air setting up and maintaining rust projects versus C++ or even Python.

> I find it wholly unappealing to abandon the existing corpus of literal decades of knowledge having been poured into those language ecosystems

Rust builds on these ecosystems. It uses LLVM as its backend compiler, much like clang does for C++.

Additionally it has great support for CFFI so it can integrate very well into existing codebases with other languages.

> I just have too much experience in the industry to throw away my time and play with toys.

I read this as prejudice. Rust isn't a toy as can be seen by the large number of companies and projects that are putting significant efforts into it.

Conversely, perhaps having entrenched experience in the industry means you're predisposed to approaching new paradigms in the field with higher cynicism than may be warranted?

> It's ugly as sin, and I know I'm not alone in that opinion.

I think that's very much subjective. I do know many programmers who find it ugly, but many like myself who find it write clean to read.

Certainly I find it significantly easier to grok than C++ or Objective C for example. It's possible to write very elegant rust code that can verge on being Pythonic in nature. It's also possible to write very ugly code too.

> there was literally no one using Servo, the site didn't tell you how to actually use it

Servo is a research project from which portions have been taken and integrated into Firefox. That means a lot of people are using servo whether directly or indirectly.

I've noticed that Rust uses LLVM as well, but aren't there some significant compile time differences or am I recalling that from Go?

I do definitely wish there was an easier way to go about Rust's C FFI, though. LuaJIT has spoiled me. All you do is preprocess headers and then you have access to all of the exports without having to do any work whatsoever.

Go is the language with very fast compile times; Rust's aren't particularly good, and, depending on the exact details, maybe slower than C++'s. It's pretty variable. We've been working on it but it's non-trivial.

There are tons of tools in Rust to preprocess headers, and do even more fun things like https://github.com/Hywan/inline-c-rs (which is obviously not a general solution to this problem but is interesting)

Oh very cool. Maybe I should spend some more time looking into those. Thanks for pointing that out!

No problem. Some links to get you started:

* https://crates.io/crates/bindgen (generate Rust FFI from headers)

* https://crates.io/crates/cbindgen (the inverse of bindgen)

* https://cxx.rs/ (a similar tool to bindgen, newer)

That's it right there. You may have just won me over by pointing these out. It's just so hard to go back to writing bindings mostly by hand instead of the other way around. I've generated thousands of bindings for all sorts of things, so it's really critical to my work.

Thanks again, Steve. And for all your patience, too.

For what it's worth, I think it's great that you are willing to at least reconsider the pros/cons of Rust when presented to you, even if it's not enough to change your mind.

I believe your issue with the "Rust hype" is that your pain points are different from the pain points of many other Rust users, and when they tell you that Rust is great for reasons A, B, C, you say to yourself, "so what?" But maybe you'd find Rust useful for less often cited reasons X, Y, Z, and you'll like it once you use it in earnest. Maybe you won't, and Rust isn't for you. And that's okay, too.

Also, kudos to Steve. I sincerely admire your politeness and patience when confronted with less polite, less patient posts. You're probably the best ambassador the Rust community could have.

Yeah, I think you hit the nail on the head.

I think the biggest thing I'm worried about from my end is I just work with so much C and C++ I can't attempt to do programming that takes away from being productive. I don't have the hours for it. I don't recall the Rusts docs yelling out to me, "Don't forget! C FFI bindings can be generated!" But at least Steve was able to point out some libs to me that would help with my work.

I'm OK with a small productivity hit because learning something new will always entail that, but the long term benefits need to be there. I'm almost always more worried about shipping than I am about anything technical.

That being said I think I can see some benefits over the horizon. In C and C++ land, there are a lot of people who don't use std or boost for one reason or another, and I've worked in circles where I had exposure to that type of programming. Honestly, just the fact that I might be able to rely on Rust's libraries OOTB could be a productivity gain right there.

I have the "Hello, World!" rust app on my workstation, so I've given it a small try. I'd be curious to see how other powerful concepts like threading work in Rust, but that's reading I've got to do.

It's difficult trying to sort out threading concerns from Lua, another language I use frequently, since the most common distributions aren't thread-safe without some work. I'd be interested in seeing what a Rust + Lua software integration could look like, since that might be a successor to the C work I do now.

there’s a number of Lua bindings, but some of the semantics are indeed very tough. The game dev community is maintaining the most famous bindings https://github.com/amethyst/rlua/issues/174

Short, incomplete list of reasons I prefer Rust, speaking from about five years experience with C++:

* Real pattern matching and sum types. std::variant doesn't cut the mustard

* Traits and derivable impls, rather than obscure operator overloads with fussy cv-qualified signatures

* No iterator invalidation bugs (among the worst C++ issues to debug, IME); no inheritance or need to care about "virtual destructors"; no "object slicing"; no crazy interactions between overloads and templates which require an IDE to determine which function you are actually calling

* Way better compiler error messages than clang or gcc

Each of those "no"s is something I've spent days if not weeks of my C++ career debugging.

One of the reasons it's so enchanting is how it manages memory without the use of a garbage collector thanks to the magic of lifetimes. Couple that with performance that's on par with C/C++ and design choices that encourage testing and documentation... there are a lot of technical reasons to love Rust.

The welcoming community is another great reason, but I'll let community leaders speak to that point.

In terms of how the language looks... the important thing is that `rustfmt` standardizes this, so you only have to learn how to read one style, and not a different style for every developer you work with.

Yup - it drew me in as a Go programmer, entirely replacing my Go stack with Rust.

It offers me so many of the joys of Go with more power. Some negatives too of course, but a big boon for me in learning Rust was realizing i didn't always have to reach for the biggest tool. Sometimes a simple Clone or [A]rc was perfectly okay, especially when comparing it to Go - my benchmark.

Rust became as developer efficient for me as Go was, and then more so when i leveraged the huge surplus of code locality tools like Iterators and various functional patterns (.map, etc).

Plus, now i get to play with new toys like WASM without a GC or game engines! I miss almost nothing from Go and gained so much power when i want to reach for things. Most of which, like Iterators, are power with little to no cost.

I've been a Rust fanatic for a couple years now, and C/C++ were not even in my toolbox. I think Rust can hit a lot of sweet spots for a very very wide range of people, eg non-C/C++ domains. Which isn't an argument for its usage, but an explanation for its popularity.

I mostly use Go. But I've been keeping an eye on Rust because I like the language expressiveness, the safety provided by the stronger type system, the smoother integration with C calling conventions, the generics, the error handling. But I'm hesitant to switch to it because it feels like the learning curve is steeper in Rust than Go, and that's important for my team where we want to be able to onboard new engineers quickly. What's your experience in that regard?

The learning curve is very, very steep. Worth it, in my opinion. I think, though, you can become productive in Rust after a week or two. Go is great because you can grok it after a couple of days - you'll have most of the main concepts of the language down pretty well. I feel like I'm able to "bend the spoon" every day when I sit down to write Go, and I've only just barely been writing it for a year.

Rust? I haven't even made it to the Oracle yet and I've been writing it (granted, in my spare time) for the same amount of time.

Thanks! Why is it worth it, in your opinion?

It has made me think more clearly about ownership than other languages have. I work primarily in GC'ed languages (Go), so I never really had to worry about it. But now, I find myself writing better code everywhere because I now think about lifetimes and ownership of values. Granted, this only works because I took the time to understand Go's GC.

I definitely love the rustfmt thing. I think I recall gofmt existing as well?

I feel like C++ can get really out of hand, so not having a cppfmt is surely a thing of jealousy.

It does exist, and importantly, existed earlier, and has effectively no configuration. This means its usage is significantly more, and more internally consistent. Frankly I am a bit jealous, but I only have myself to blame here :)

There are people who like gofmt and dislike rustfmt.

Thanks for all of your contributions, Steve!

I live in JavaScript land mostly, which is the wild wild west when it comes to "the way to do things," so rustfmt is still many times better than, say, prettier and eslint. It exists AND it's part of the standard tooling!

To those taking the time to sell me on it, thank you. I really appreciate you all sharing why Rust is important. I value a lot of the mentioned benefits listed below, specifically wrt speed, but I'm not finding the trade-off there yet.

I work with codebases and projects where the expense of time is far too high to justify its usage, especially in existing designs where there is no meaningful way to extend the codebase with Rust. Believe it or not, but there really are a lot of us out there who just do not have memory (safety, ownership, or otherwise) problems with C or C++.

It sort of feels like the argument people make with static typing vs dynamic typing. It's just not a concern I have.

Perhaps with enough time and coercion I'll find a reason to use it.

FWIW I expect you're getting downvoted for tone. In particular:

> I just have too much experience in the industry to throw away my time and play with toys.

Implication: Rust is just a toy, people who use it have too much time on their hands, and they're not experienced enough to have good judgement.

IMO if you're interested in a productive conversation you'd probably have better luck if you simply omitted content like the above: it doesn't add to the conversation, and is inevitably going to raise hackles among those who disagree with you.

OK, good point. Removing it.

Maybe consider this as well:

>It's just not a concern I have. Perhaps with enough time and coercion I'll find a reason to use it.

Or just don't? Its like the validity of Rust is dependent on wether you use it or not. Try a different tone, and change a mindset from where yourself have to acknowledge/use/like something for it to be valid. If a fact based discussion about this is to be had you need to stop shoving your anecdotes and personal likings in the way. Its impossible for people to know whether Rust is right for you, and thats a pretty boring discussion by itself.

I've never moved past reading the rust docs, but I understand why people react on your comments.

It has C and C++'s performance without a lot of the footguns. A better type system. The trait system is a nicer way to extend types than C++'s class system (IMO). Generics from the start, instead of absent (C) or added on and still not fully utilized by practitioners (C++, some practitioners get the value, other offices bar using them). The ownership model means that using the lower level concurrency primitives is less likely to have the subtle issues of C and C++. It also means they could avoid encoding a specific concurrency model into the language (like Go or Erlang) and let those be libraries.

Cargo as a standard build system, package manager, and test runner. This makes for a much more coherent development environment than the tire fire that is C and C++'s build, test, and package management story.

Developing tests is much easier than in C and C++, which means many of the packages are actually reasonably well tested (maybe not perfect, but better than the average C or C++ package you might want to incorporate into a project).

Rust has a pretty good module system. C has nothing of the sort, and C++ has a mix of things that can be used similarly (classes, namespaces) and only recently got modules proper in C++20. This helps a lot with organizing your code into a modular structure and then sharing that code with other projects.

Rust can call and be called from C, so there is no tossing anything out. You can integrate Rust into an existing project one file at a time. Move your more critical code into it, and let other code call it. Going back to concurrency, put the part that generates and manages workers (as an example of one model) in Rust and leave the rest of the logic in C or C++. Gradually migrate the worker logic into Rust, or not. Perhaps it's a library that you don't control or don't want to change.

Some things aren't pretty or aren't clear. For instance, str and String are pretty confusing for new users. But the compiler will catch these for you. Speaking of, actually decent compiler warnings and errors. Often with potential fixes included, which usually do what you want.

In summary: Fewer footguns, better quality of life components, better language features in some areas (type system, modules, in particular), no performance hit (or no major performance hit) compared to other options for languages attempting to offer improved safety (where safety could be along many dimensions).

Is it possible to use Rust without much necessary usage of generics?

Depends what you mean I guess. You can certainly write code that doesn't create more generic structs, and needing to create more generic structs when writing simple application plumbing code is relatively rare. On the flip side you also certainly want to use stdlib (and third party) libraries and instantiate generic structs they define. For example a list of T objects is most commonly stored in a Vec<T> where T is a generic, or for a builtin example a fixed sized array is a `[T; N]` where both T and N are generic. There's also approximately no reason to avoid generics.

All in all the frequency of use of generics is pretty similar to languages like C++ or Scala.

Defining your own? Absolutely. Using them at all? Basically impossible. The standard (and core) library is entirely built around it.

Perhaps Rust can be the language where I force myself to get used to them. In C++ there are stilly plenty of alternatives to not having to use templates. The reason I ask is I've preferred not to use them because I find them slightly more demanding to read.

I think that's just a personal bias I need to get over.

Yeah you're not alone. Have you used concepts at all yet? Rust's generics are similar to, but different than, C++ templates generally; concepts is the closest thing C++ has to them. That being said, even when you understand them, you can create some monstrosities, just like C++.

To connect it back to your original questions, Rust relies heavily on generics because if you want runtime performance, but you also want safety, you pretty much need ways to evaluate safety at compile time, rather than runtime, so you don't have the overhead of runtime checks. This basically implies generics need to exist and be used heavily.

I haven't spent any time in C++20, so it's interesting to hear that. I'll try and read more about both. Thanks for your thoughts on this.

Any time. One last tiny bit of overview: templates can currently do a bunch of things that Rust generics can’t. Some of these are things that Rust will be adding in the future, some are not, and some are uncertain. So there’s a lot of parallels but some folks who are very invested in templates say they don’t want to move to Rust yet because we’re missing things they desire.

The Rust community alone is so much better than anything I've seen in my 15 year programming career.

The communities of statically typed programming languages were especially elitist and gatekeeping.

The Rust community is welcoming.

The meme of the Rust Evangalism Strikeforce exists for a reason - because a person can't say anything remotely uncomplementary about Rust without getting dogpiled and downvoted into oblivion.

The Rust community has proven itself, outside of the Rust specific forums, to be exceptionally elitist.

And, as shown in a sibling thread, the founders of Rust are right there on the dogpile attacking the character and dissecting the comments of any dissenters.

I've come to the conclusion that many people just project whatever they want onto these kinds of conversations, positive and negative.

For example, in my comment, I very much said "made it seem" and suggested that maybe people were misunderstanding the poster, not attacking their character.

Many people post many negative things about Rust, including those who are its most fervent advocates. But the gray areas mean there's places where people can post things and some people say "ugh any criticism is downvoted" and others can say "wow this is an absolutely off-topic, baseless criticism" and both will walk away feeling right.

I appreciate your comments here for multiple reasons and will not forget them. Thanks for taking the time to talk, it really sets a great example, too.

This is exactly what I mean. I don't see how saying "hey this statement came across a little insulting and that's probably why people got a bit aggro" is attacking someone's character. There's nothing to do with someone's character in there, at all.

I myself post negative things about Rust, including in this thread. Heck in the last week I've told the story about a team I was on not choosing Rust and how I thought that was a good decision in like, three different threads between here and Reddit.

I doubt we will ever agree though, so I'll leave it at that.

Most of the time, it's about people wanting to make rude remarks and less about them saying "anything remotely uncomplementary about Rust".

Downvotes are "ignore the troll". Their whole purpose is to hide comments that don't substantively contribute to the discussion.

Replies are (or at least can be) "dogpile on them until they realize they're wrong".

Rust has a lot of deficiencies, like any programming language, but in general what I've seen is that "the community" believes the ownership model/lifetimes and "unsafe" keyword effectively makes it flawless. I think it's dangerous, to be honest, and the community in this regard is not very good--it's filled with people who hype the power of the language well beyond its limits.

>Am I just not "with it?"

>all in the name of whatever it is that Rust delivers on

If you haven't bothered to groc the purported benefits and you have not decided to reject them on their own merits then yeah, I'd say you're just being a grump.

Feel free to not like Rust but your complaints don't show a lot of effort in trying to understand it.

As far as what you lose when you try new languages, you really shouldn't worry so much. A vast majority of your skills as a programmer are portable.

I kind of think it's ugly too.

But I think back many years, when I was put on a project written in Perl. At first I balked at the syntax.

I can see $foo on the right of the equals sign, but on the left? And $_ and @_ and regular expressions everywhere like line noise.

But working with it for a bit... and all of that just disappeared as I became fluent. They just started becoming idioms in my head. And after a while, I found Perl the most expressive language I've ever worked with.

So, maybe you just have to get over the hump?

(But yeah, I thought python was too ordered, but I switched and it's pretty much my favorite language presently)

Perl was great. I miss Perl. v_v

Yeah, sounds like I just need to get over some syntactical hangups.

There's this odd genre of comment where people sound personally threatened by a language. Why?

Why would a person be threatened by a language? I'm asking the HN community why I should reconsider and to share their thoughts on having used Rust.

The world isn't made up of people who either love or are threatened by things. Could you not use this language?

I haven't used it myself, but my understanding as an outsider is that a lot of the excitement around Rust is that it's bringing a new model of memory safety: with the borrow-checker, you can avoid the performance penalties of garbage collection, while also avoiding the bugs and security risks seen in C.

People who care about such things are really hyped because it's a truly new idea in a mainstream(ish) language.

https://willcrichton.net/notes/rust-memory-safety/

The primary reason why I love Rust is that the compiler catches most of my bugs at compile time. For example, I recently spent three full days on writing code without running it at all — I just made sure it compiled as I went along. Afterwards when it was time to run it, there were a few mistakes not caught by the compiler, but I was able to fix all of them in 30 minutes.

That program has been running in production without any issues since then. We use PHP for most other projects at work. I can assure you that this kind of thing is not possible with PHP.

So in short, Rust forces me to think about every edge case and error path, so I can feel confident that my code really works, even in the face of obscure situations.

In fact, this is also the first line in the AWS article in question:

> One of the most exciting things about the Rust programming language is that it makes infrastructure incredibly boring. That’s not a bad thing, in this case.

The only language I've had a similar experience from is Typescript.

That it's fast or uses only a little memory is just a bonus for me.

You are not alone. I think the use of method chaining especially takes away from the aesthetic of newer programming languages.

Well, if you hadn’t noticed it’s mostly the same dozen of users upvoting and commenting every Rust-related article on HN.