[HN Gopher] Rust is just a tool
___________________________________________________________________
Rust is just a tool
Author : JuniperMesos
Score : 141 points
Date : 2026-02-28 05:47 UTC (17 hours ago)
(HTM) web link (lewiscampbell.tech)
(TXT) w3m dump (lewiscampbell.tech)
| shrubble wrote:
| I'm glad that Rust users are willing to accept that other
| approaches to safety like Ada are also interesting or effective.
|
| In the past I had the impression that some thought that Rust was
| the first programming language to ever have the concept.
| pjmlp wrote:
| Now we just need the Zig ones acknowledging Object Pascal,
| Modula-2, Ada,.... as well :)
| pjmlp wrote:
| All technology is just a tool, unfortunately it turns into
| religion like behaviours, because it defines with whom we work,
| what projects we can work on, what CVs get through HR and which
| ones don't,....
| ozim wrote:
| The horror of picking tech working in it 10 or 15 years and
| then it suddenly becoming obsolete or irrelevant. Is something
| a lot of people can relate to.
| josephg wrote:
| We're a new industry. So long as we keep iterating on our
| tools, this will continue to happen. Obsolescence is - in
| this case - an indicator of progress.
| k33n wrote:
| It's useful to align groups on underlying philosophies about
| problem solving and what tooling we will use.
|
| The alternative is way slower and less effective. "Just use
| whatever language and frameworks you want and solve the problem
| in a vacuum" would be a nightmare for any team trying to ship.
| lioeters wrote:
| > religion like behaviours
|
| That phrasing makes me imagine a cultural anthropologist
| studying the behavior of programmers in the wild, their tool
| use, rituals, magical worldviews like object-orientation.
| There's that classic paper about how a language is a "tool for
| thinking", that it both expands and limits how and what a
| person can think. It makes sense that it shares characteristics
| with religion, a conceptual system of interfacing with the
| world.
| pjmlp wrote:
| Well, since you asked for it, :)
|
| https://youtu.be/ocwnns57cYQ?si=GLb9kNEcAQkaM0up
| josephg wrote:
| > Programming Rust does not mean I have to: buy into their
| marketing hype
|
| > give the same smug lectures about "safety"
|
| I'm often confused reading articles like this, which take for
| granted the existence of some "rust evangelism strike force"
| which goes after people on the internet for not liking rust
| enough.
|
| The way people talk, it sounds like there's some insanely
| effective marketing campaign going on to promote rust everywhere.
| But I haven't seen it. Certainly not any more than any other
| technology people get excited about for awhile, like Go. Or
| docker when that launched.
|
| Where are these comments? Can anyone give some actual links to
| these sort of comments people say online, which don't get
| immediately downvoted? The way people talk, these comments must
| be made in such large volumes that it seems very odd I don't
| notice them?
| maxbond wrote:
| It's way rarer on Hacker News than people alleging an
| omnipresent Rust Evangelism Task Force is constantly imposing
| itself on people. I have seen "overly enthusiastic" comments
| about Rust, but I can count them on one hand. I'm not going to
| link them because I don't want to dogpile ob people. Note that
| I read many/most of the Rust threads that make it to the front
| page.
|
| But I have seen thousands of comments complaining about these
| supposed evangelists (no exaggeration). Less often and less
| reliably in the past few years, the meme is petering out. But
| there's absolutely no comparison of the relative frequency.
| People complain bitterly about Rust on this forum consistently,
| actual Rust zealots appear very rarely.
|
| It is simultaneously true that Rust is "just a tool" and that
| this is a significant fact, and that the people complaining
| about Rust are the bigger problem in the day to day discourse
| in Rust related threads on this platform and in the present
| day.
| dcminter wrote:
| Yeah, I keep hearing about this toxic community from people
| who won't blink twice to use decade-out-of-date critiques of
| Java :)
| procaryote wrote:
| check further down this discussion for immediately downvoted
| comments
|
| https://news.ycombinator.com/item?id=47191837
| https://news.ycombinator.com/item?id=47191619
|
| Post anything negative about rust, or anything about a severe
| bug in some non-rust code, for examples of your own
|
| I have nothing against rust, although the learning curve is too
| steep and development in rust is too slow to be a practical
| general purpose language for a regular company.
|
| The culture around dependencies also means you pay for your
| memory safety by increased supply chain risk.
|
| Golang or Java gets you memory safety, faster compilation, easy
| hiring and have better standard libraries
| josephg wrote:
| I completely agree with your criticisms. I've been saying
| many of the same things about rust for years on HN. But I'm
| rarely downvoted for saying so.
|
| FWIW, I also really like rust. I personally much prefer it
| over Go and Java. But those are still very legitimate
| criticisms.
| resonious wrote:
| I think it's an old stereotype. When Rust started gaining
| popularity, I did see comments like that. Even felt compelled
| to post them sometimes. But now that we have real production
| Rust experience, we're a bit more nuanced in our views.
| IshKebab wrote:
| I think it's just what happens when something _genuinely_ great
| comes along. Some people try it and enthuse about it. Sometimes
| other people who haven 't tried it assume that it's just like
| all the other average things and therefore the only explanation
| is irrational fanboyism.
|
| We saw the same thing with the iPhone. It was a step change
| from previous phones. Loads of people were like "it's just
| Apple fanbois, I'll stick to my N95" without even trying it.
| pjmlp wrote:
| Remember Axum or the reflection drama?
| mtndew4brkfst wrote:
| You're probably thinking of Actix and the unsafe/TechEmpower
| thing? I've never seen Axum involved in any notable drama.
| pjmlp wrote:
| Yeah that one.
| josephg wrote:
| Yeah; but that was 6 years ago - from way back in 2020.
| Was it really that traumatic for people?
| pjmlp wrote:
| That was part of Rust Evangelism Striking Force meme
| genesis.
|
| And then we have the whole reflection drama with the
| author going back contributing to C and C++ ISO work.
| darkwater wrote:
| In this very comments section:
| https://news.ycombinator.com/item?id=47193361
|
| "all others languages are flawed, Rust is the only that stands
| the scrutiny" sounds pretty evangelist to me.
| josephg wrote:
| Sure; there's one or two unbalanced, positive comments about
| rust in this thread. Does that seem out of balance to you,
| out of 113 comments?
|
| If there was a post about Go, Kotlin or C#, I bet there'd be
| a few glowing positive comments about the languages. I'd be
| surprised if there weren't.
|
| Is that a problem? I don't want to move the goal posts, but
| this really doesn't seem like the problem its made out to be.
| I count far more comments complaining about rust evangelists
| than I see actual rust evangelism. Even in a thread about
| rust being a good tool.
|
| What gives?
| lioeters wrote:
| I think it's that the few enthusiastic fans make such
| hyperbolic statements, they create drama and stand out
| among the majority of reasonable users of the language.
| They attract attention of the people who are curious about
| the language, and give the impression that the community is
| hyping it up too much.
|
| The other day I saw a developer who works on the Rust
| language saying, please tone it down because it's making us
| look like fanatics. It's healthy to acknowledge that the
| language is not perfect, it has room to improve, even some
| fundamental flaws. Oh, I recognize your user name, recently
| read a great article you wrote - here it is. This was
| really informative and interesting.
|
| Rewriting Rust - https://josephg.com/blog/rewriting-rust/
| hu3 wrote:
| It's not marketing. It's just unproductive and incessant.
|
| For example in this PHP post 3 days ago, ofc someone commented
| about how they ditched PHP and Go for Rust.
|
| https://news.ycombinator.com/item?id=47149752
| adampunk wrote:
| IMO it's mostly people who, after being told that only bad
| programmers need memory management, don't immediately kiss the
| feet of the speaker.
| lispisok wrote:
| Rust is cool but there is way too much dogma around its memory
| safety and static typing in general being a panacea. Most errors
| are not type errors. Two days after Cloudfare's little Rust
| hiccup that took the internet down for a day I saw people posting
| about Rust "if it compiles it runs".
| antonvs wrote:
| > Most errors are not type errors.
|
| If you follow good strong typing principles, you can ensure
| that most errors are type errors. Yaron Minsky's phrase, "Make
| illegal states unrepresentable", captures this. But it doesn't
| happen by accident just because you're using a strongly typed
| language.
|
| Also, if Cloudflare had run the standard Clippy linter on their
| Rust code, and taken the results seriously, it would have
| prevented the issue you referenced. Static checks don't help if
| you ignore them.
| JuniperMesos wrote:
| I actually don't think this is true. I do think that most
| programming errors are type errors, in the broader sense of one
| part of a system making one set of assumptions about the
| properties of some data, that aren't shared by another part of
| the system; and that would've been caught automatically by
| sufficiently sophisticated static correctness checking. I do
| not think that Rust has a maximally sophisticated type system
| (nor is it trying to), and while this is reasonable for Rust as
| a project to decide, I do expect that there will be languages
| in the future that do more complex things with type systems
| that might supplant Rust in some domains.
|
| The Cloudflare incident was caused by a confluence of factors,
| of which code written in Rust was only one. I actually think
| that Rust code worked reasonably well given the other parts of
| the system that failed - a developer used unwrap() to
| immediately crash instead of handling an error condition they
| thought would never happen; when that error condition did
| happen the Rust program crashed immediately exactly as
| expected; and if Cloudflare decided that they wanted to ban not
| handling an error like this in their codebase, it's a pretty
| easy thing to lint for with automatic tooling.
| pjmlp wrote:
| If it helps finally acknowledging basic stuff like bounds
| checking matters, great, this from a guy that rather use system
| languages with automatic resource management.
|
| "A consequence of this principle is that every occurrence of
| every subscript of every subscripted variable was on every
| occasion checked at run time against both the upper and the
| lower declared bounds of the array. Many years later we asked
| our customers whether they wished us to provide an option to
| switch off these checks in the interests of efficiency on
| production runs. Unanimously, they urged us not to they already
| knew how frequently subscript errors occur on production runs
| where failure to detect them could be disastrous. I note with
| fear and horror that even in 1980 language designers and users
| have not learned this lesson. In any respectable branch of
| engineering, failure to observe such elementary precautions
| would have long been against the law."
|
| -- C.A.R Hoare's "The 1980 ACM Turing Award Lecture"
|
| From 1980!
|
| C++26 will finally have hardening on the standard library,
| something that I could already enjoy in 1990's with Turbo
| Vision, OWL, MFC, VCL, but was too much to ask for on the
| standard library apparently, even if compilers kept having each
| own their approach.
|
| It took governments and companies to start mapping CVEs to
| money spent fixing them, to finally acknowledge something had
| to change.
|
| Meanwhile on C land, business as usual regarding Hoare's quote.
| msla wrote:
| It's interesting how it's Obviously Impossible to write OSes
| in garbage-collected languages, and this is proven by the
| fact successful OSes were written in garbage-collected
| languages back in the Stone Age, or 1980s, whichever. My
| current laptop has enough RAM to swallow the entire state of
| a Symbolics workstation (RAM and disk) without noticing, but
| it's obviously too wimpy to run an OS written in anything
| other than C.
|
| (Nitpickers' Corner: "Successful" and "the most commercially
| successful" are, in fact, two different words. Gots all them
| different letters an' everything. Therefore, Genera not being
| as profitable as such Sophisticated Top-Of-The-Line Pieces of
| Professional-Grade Enterprise-Ready software as MS-DOS
| doesn't mean Genera wasn't successful.)
| pjmlp wrote:
| My android with garbage collected userspace challenging
| Termux folks, works just fine....
| josephg wrote:
| Yeah its funny what we can get away with using different
| design tradeoffs on modern computers.
|
| I've been reading through the SeL4 source code lately. SeL4
| isn't a multithreaded kernel. It supports SMP - so, it can
| use all the cores on your computer. But the kernel itself
| uses a big mutex. Complex syscalls can't run concurrently.
|
| And you know what? I think its fine. A tiny microkernel
| like SeL4 offloads almost everything to separate processes
| anyway. The only things in the core kernel are the
| bootloader, scheduler and thread cap tables. Device drivers
| are multithreaded because they all run in separate
| processes.
|
| Having the kernel itself effectively single threaded
| reduces a whole class of bugs and complexity, at a
| (hopefully) negligible performance cost. Its smart.
| pjmlp wrote:
| I noticed now that I didn't fully got your point, I do
| agree and the point with Android userspace also stands.
|
| Better half victory than trying to change the whole world
| in one day.
| IshKebab wrote:
| > Most errors are not type errors.
|
| With a sufficiently strong type system _all_ errors are type
| errors! Rust doesn 't have that of course, but it does have
| quite a strong type system so this is a very bold assertion
| with no evidence.
|
| Rust _does_ have an "if it compiles it works" feel. Nobody
| means that literally (this should be really obvious). They just
| mean that once you get it to compile the chance that it works
| first time is quite high (like 20% maybe?) compared to most
| other languages where it's more like 1%.
| dcminter wrote:
| I don't think your comment deserves the downvotes (upvoted to
| compensate) but I do think that it's questionable if _" Most
| errors are not type errors"_ is true.
|
| Rust's _culture_ of pushing things into type checking does
| eliminate a huge swathe of bugs and I wouldn 't be surprised if
| it was the majority.
|
| The hurdle of negotiating translation between filesystem
| strings and unicode strings strikes me as a good example of a
| place where most languages don't protect you from bugs and a
| strongly typed one does. The downside, of course, is that you
| have to handle these cases (even if it's to explicitly say "I
| don't care").
|
| I still create dumbass bugs in Rust, but they are usually
| simple logical errors that are pretty obvious when debugging.
| josephg wrote:
| Rust doesn't eliminate all bugs. But anecdotally, by the time
| the type checker and borrow checker have humbled me, my
| programs really do often work the first time I run them. Its
| quite remarkable.
|
| This isn't a special thing about rust. All languages are on a
| spectrum of "detect all bugs statically" to "detect all bugs
| dynamically". Rust programs run correctly "first time" more
| than javascript, more than typescript. But still less than
| haskell.
|
| You can still write bugs in rust, obviously. I've written
| plenty. As you say, so has cloudflare. But strong typing does
| find a lot of bugs in practice.
| wolvesechoes wrote:
| This industry pretends to be driven by technical
| considerations, yet, with some exceptions, is mostly driven by
| fads, folk knowledge and aesthetic choices.
|
| Folk knowledge may, and often is, grounded in reality and real
| experience, but let us not forget that most heated debates in
| programming of today are rooted mostly in tribal logic and fad
| chasing.
|
| Static vs dynamic typing is a chief example. Empirical evidence
| that static typing makes some real difference in terms of bugs
| or safety is inconclusive at best. Yet it doesn't prevent some
| people from literally shaming those that prefer dynamic
| languages. Same with OOP - for years it was everywhere, now you
| may have an impression that it is a sin to ever use it. But
| now, as much as back then, there is no evidence to support
| claim that using or not using OOP is "one true way".
|
| Now, memory safety is a real concern, and we can confidently
| say that we have found ways (exemplified in Rust) to prevent
| whole class of issues, but suddenly we are in the situation
| that every single bit of code out there is supposed to put
| memory safety as a chief concern, no matter if we are talking
| about some high perf web server, missile control logic, simple
| script solving Lotka-Volterra equations or simple calculator
| app.
| rvz wrote:
| It's just a tool. But to some people, Rust is more like a
| religion than a tool and they let it define them to the point
| even the language maintainers disavow them.
|
| At any point, if you provide any conterpoints or fair criticism
| towards the language objectively, just expect lots of fans to
| remind you that it is the best programming language ever created
| and yours is "unsafe" by default.
| dijit wrote:
| I like Rust, though I'm not zealous about it.
|
| Sometimes when you have a really good tool, you want to share
| it.
|
| This was the case with Linux for many people over many years.
|
| FWIW I agree that the community has some frustrating elements,
| and that its a lot of dogma in comments, though I actually
| think that's a fringe element.
| ozim wrote:
| Sounds like the point of the article is that you can just use
| the language and keep counterpoints to yourself.
| swiftcoder wrote:
| > At any point, if you provide any conterpoints or fair
| criticism towards the language objectively, just expect lots of
| fans to remind you that it is the best programming language
| ever created and yours is "unsafe" by default.
|
| This is mostly just a disagreement about what the word "unsafe"
| means in this context?
|
| "safe" and "unsafe" in the sense Rust uses them aren't a moral
| judgment about a language, it's a specific (and limited in
| scope) feature of the language, where memory safety is enforced
| by the compiler.
| furryrain wrote:
| > like every popular crate buy into their marketing hype > follow
| community "best practices"
|
| Yea, I get smug judgement from Rust zealots for not picking the
| in vogue crates.
|
| I get a lot of help too though.
|
| People are passionate about it. That has good and bad outcomes.
| phplovesong wrote:
| Rust has nothing new (even the lifetime stuff is copied) really.
| It just marketed itself really well. It got a huge number of
| migrants from JS/TS ecosystem, and python, and some from the
| C(+*) ecosystems.
|
| Its a good language dont get me wrong, but also a huge pita to
| work with.
| zozbot234 wrote:
| > Rust has nothing new (even the lifetime stuff is copied)
| really.
|
| Rust has nothing new by _academic_ standards, and this is an
| explicit goal of the project. (And that 's why it has yet to
| support e.g. Haskell-like higher-kinded types; or dependent
| types for compile-time programming: the interaction with its
| low-level featureset is very much an open question.) It's
| incredibly novel as a production language, of course.
| pjerem wrote:
| It has nothing new but they did a good job at cherry picking
| what what nice in other languages.
|
| Which makes it an interesting language to learn actually. I
| even feel like Rust can even be a superb first language to
| learn for a new programmer : that's a journey for sure but it
| would expose you to most of the modern programming concepts.
| AlotOfReading wrote:
| Saying it has nothing new seems like an uncharitable take. Yes,
| it has influences (that rust docs dedicate a page to [0]), but
| PL theory has such a rich body of literature that you can make
| a similar claim about virtually any language. It's the whole
| package that matters, and I don't think there's anything "rust
| but earlier" to point to there. Certainly isn't Ada.
|
| [0] https://doc.rust-lang.org/reference/influences.html
| dcminter wrote:
| > _[Rust is] a good language [...] but also a huge pita to work
| with_
|
| This is practically the elevator pitch of the language :) and I
| speak as one who likes it a lot!
| zamalek wrote:
| Rust happens to be an extremely good tool. There are definitely
| situations where it absolutely sucks. e.g. Zed is a heroic
| effort, but look at the code and you'll see that we still haven't
| figured out how to do Rust UIs.
|
| We may disagree on the premise that humans are generally
| incapable of correct and safe manual memory management, but
| that's a degree of distrust I hold for _myself._ You may have
| never written a memory bug in your life, but I have, and that
| renders me completely incompetent.
|
| If a project in an unsafe language has ever had a memory bug (I'm
| looking at you, Bun), the maintainers objectively have a track
| record of not being capable of manual memory management. You
| wouldn't put a person who has a track record of crashing busses
| at the wheel of a school bus.
|
| And Rust isn't the only memory-safe language. You can turn to
| Java, Go, C#, Type/JavaScript, and whole bunch of others. Rust
| just so happens to have ocaml tendencies and other things that
| make it a joy to read and write, so that's definitely preference
| on my part. One of these days I'll learn ocaml and possibly drop
| Rust :)
| echelon wrote:
| > Zed is a heroic effort, but look at the code and you'll see
| that we still haven't figured out how to do Rust UIs.
|
| Only a handful of apps and frameworks have figured this out.
| Most of the world moved onto HTML+Javascript plus Electron. Or
| mobile UI.
|
| Who is using native UI in 2026? GTK and QT don't feel great.
|
| I'm glad Zed is trying. We need more efforts.
| giancarlostoro wrote:
| I've been experimenting (thanks to Claude Code because it
| removes the headache drastically for me of Rust nuances, I'm
| not a Rust expert by any means) with Qt and Rust.
|
| I discovered cxx-qt which is maintained by some Qt
| maintainers, which are all employed at KDAB. I had no idea
| KDAB or this project existed. It's been very smooth so far.
|
| I can honestly say the barrier to building a GUI is very low
| with Claude, must to the dismay of others, but it beats me
| building an Electron app.
|
| https://github.com/KDAB/cxx-qt
| steve1977 wrote:
| > Who is using native UI in 2026?
|
| Swift. Which is similar to Rust in some ways actually.
| pjmlp wrote:
| > Who is using native UI in 2026? GTK and QT don't feel
| great.
|
| Game developers, Windows applications in .NET (possibly with
| some C++/COM modules)
|
| The problem with native UIs is mostly a Year of Linux Desktop
| problem.
| g947o wrote:
| Let's set gaming development aside for a moment.
|
| I believe when people talk about Rust UI, most people
| assume it's cross-platform. Developing an app just focused
| on Mac or Windows is a completely different problem. In
| fact, one could easily argue that you should never use Rust
| for those single platform apps.
| procaryote wrote:
| > You may have never written a memory bug in your life, but I
| have, and that renders me completely incompetent.
|
| This feels overly binary. Memory management bugs is just one
| class of bugs, and there have been many other bugs leading to
| security issues or defects.
|
| If you apply the standard "has ever written a bug" -
| "completely incompetent" you will have to stop using software,
| and if you think about it most other technology too
|
| Memory safety is a very useful trait for a language though, and
| as you say provided by a whole bunch of different languages
| nowadays
| IshKebab wrote:
| > Memory management bugs is just one class of bugs
|
| It's a particularly bad one though because it always leads to
| UB, which means you can't say anything about what happens
| next.
|
| That's why memory bug severity is often "MAY lead to RCE but
| who knows". At least with non-UB bugs you can reason about
| them.
|
| In any case, Rust massively helps with logic bugs too. It's
| not just about memory safety.
| zozbot234 wrote:
| > It's a particularly bad one though because it always
| leads to UB, which means you can't say anything about what
| happens next.
|
| This is also why memory safety is table-stakes when it
| comes to formal verification of the underlying program
| logic. You can't solve logic bugs (even where that's known
| to be feasible, such as for tightly self-contained,
| library-like features) without solving memory safety first.
| nananana9 wrote:
| > it always leads to UB, which means you can't say anything
| about what happens next.
|
| If you read a language standard and try very hard to forget
| that the actual computer exists, sure.
|
| If you remember computers are real, you can pretty easily
| tell what will happen when you write to address 0x00000000
| on a CPU with virtual memory.
| FartyMcFarter wrote:
| Not all memory bugs result in writing to a null pointer.
|
| For example, you can do a double free, or write to a
| pointer that was freed.
| Tuna-Fish wrote:
| Do note that with modern compilers it's surprisingly hard
| to accidentally do something that is always guaranteed to
| write to 0. Because it is UB, and an optimizing compiler
| is allowed assume that it doesn't happen. This can lead
| to seemingly crazy things like a variable that is set to
| zero, and when you deref through it it gives you
| something completely different instead. Because if a
| variable is first set to zero in all code paths, and then
| complex logic usually sets it to something else, after
| which it is dereferenced, the compiler is allowed to
| notice that the path where it is accessed without being
| first set to something else never happens, and then it is
| allowed to notice that the first write to the variable is
| dead because it's never read before being set to
| something else, and thus can be eliminated.
| xigoi wrote:
| Are there any languages other than C and C++ that have
| this "nasal demons" interpretation of undefined behavior?
| FartyMcFarter wrote:
| I think so, at least when it comes to assuming that
| multi-threading data races don't happen.
| josephg wrote:
| I assume this is a product of sufficiently advanced
| compilers. Other LLVM languages almost certainly suffer
| from this too, including Zig, Swift and unsafe rust.
| bregma wrote:
| Are you asking if there are programming languages in
| which how undefined behaviour behaves is strictly
| defined?
| IshKebab wrote:
| Rust and Zig do, and I think also Go.
| IshKebab wrote:
| Ah you're in the "but it doesn't _really_ mean anything
| can happen " denial stage.
|
| Welcome to acceptance:
| https://mohitmv.github.io/blog/Shocking-Undefined-
| Behaviour-...
| endorphine wrote:
| I guess parent argues that: - humans have a
| track-record of writing memory bugs - memory-safe
| languages prevent such by construction
|
| Therefore, what's the justification of not using a memory-
| safe language (as opposed to an unsafe one)?
| jmull wrote:
| Interop.
| josephg wrote:
| > what's the justification of not using a memory-safe
| language
|
| Use Go, Java or Fil-C, and memory safety is achieved at the
| expense of runtime performance. Tracing garbage collectors
| make your programs run slower and use more RAM.
|
| With Rust you pay with complexity. Rust has new, weird
| syntax (lifetimes, HRTB, etc) and invisible borrow checker
| state that you've gotta understand and keep track of while
| programming. Rust is a painful language to learn, because
| lots of seemingly valid programs won't pass the borrow
| checker. And it takes awhile to internalise those rules.
|
| I personally think the headache of rust is worth it. But I
| can totally understand why people come to the opposite
| conclusion.
| wolvesechoes wrote:
| > because lots of seemingly valid programs won't pass the
| borrow checker
|
| Some straight-up valid programs as well
| torginus wrote:
| Even the statement that (100% safe) Rust does not have memory
| bugs/mutable aliasing is not always true.
|
| It's well known that Rust has difficulty representing graph-
| like memory structures, and people have taken to using arrays
| of `Node`-s to represent graphs, where each graph edge
| represents a pointer to another node.
|
| This both efficient, and fast, but this approach sidesteps
| the borrow checker.
|
| If you had a method that 2 mutable `Node` references as
| parameters, the borrow checker would complain if they'd point
| to the same struct. If you pass 2 ints, it won't.
|
| Likewise, since liveness is tracked by user logic, you can
| refer to stale, deallocated `Node`-s or ones that haven't
| been initialized yet.
|
| I've had people argue this is not a true memory bug, since
| you're not causing 'real' memory faults, but in C, `malloc`
| is just a function that hands you pointers into chunks of
| pre-allocated memory space most of the time, when it doesn't
| have to ask the OS for more.
|
| I know from experience some people see this criticism as an
| attack on their favourite language and instantly rebuke it.
|
| But I'd like to argue that there's something there, and it
| bears thinking about how 'memory allocation exisitng outside
| Rust' and 'memory allocating existing inside Rust' behave
| differently might be seen as an interesting dicothomy that
| needs to be resolved and that resolution might improve Rust's
| (or some successor language's) memory model.
| ViewTrick1002 wrote:
| The difference is the checking, and actual enforcement of
| it.
|
| Go and use get_unchecked if you want to and get C like
| behavior. But the safety note tells you the potential
| issues:
|
| Safety
|
| Calling this method with an out-of-bounds index is
| undefined behavior even if the resulting reference is not
| used.
|
| You can think of this like .get(index).unwrap_unchecked().
| It's UB to call .get_unchecked(len), even if you
| immediately convert to a pointer. And it's UB to call
| .get_unchecked(..len + 1), .get_unchecked(..=len), or
| similar.
|
| https://doc.rust-lang.org/std/vec/struct.Vec.html
| raincole wrote:
| > If a project in an unsafe language has ever had a memory bug
| (I'm looking at you, Bun), the maintainers objectively have a
| track record of not being capable of manual memory management
|
| That's an interesting way to navigate the world. Do you hold
| this attitude towards other professionals? For example, if a
| lawyer ever lost a case by misinterpreting a law, they have a
| track record of not being capable to practice laws and should
| be disbarred?
|
| There were (and most likely, still are) even memory bugs in
| Rust standard library[0]. By your logic the standard library
| maintainers objectively can't handle unsafe blocks.
|
| [0]: https://nvd.nist.gov/vuln/detail/cve-2018-1000657
| slekker wrote:
| Following your analogy, if there is a way for the lawyer to
| never lose a case due to misinterpreting the law...
| dminik wrote:
| It's not really that interesting. For instance, we've
| seemingly decided that various blue collar workers are
| incapable of not falling to their deaths and so have come up
| with OSHA and various other national equivalents. Drivers are
| incapable of not crashing and so we started including air
| bags. Woodworkers seemingly can't stop cutting their fingers
| off using a table saw and so we came up with SawStop.
| Ygg2 wrote:
| Fixed since 1.22.0
|
| You're only proving unsafe Rust is tricky. Even for
| experienced maintenaners.
| Moldoteck wrote:
| Is there a difference between c++ and java/go/etc if you
| enforce at code review for C++ to use only auto memory
| management like smart ptrs, containers, etc? I guess the only
| difference would be c++ can have diamond problem that's solved
| in a specific way, but that's relatively easy to spot with
| compilers, but otherwise...
|
| Imo the strong point of rust is compile error if you try to use
| an obj after move (unlike c++ with undef behavior and I guess
| it should be the same for java/c#), or that you can't modify a
| container if you hold a ref/pointer to some of it's
| elements/range which may cause invalidation in C++ case due to
| realloc
| pjmlp wrote:
| Yes, because code review isn't common, it is at the same
| level as writing documentation, or unit tests in most
| companies.
|
| Unless there is some DevOps freedom to at least put something
| like Sonar or clang tidy on the build pipeline breaking PR
| that don't play by the rules, and even then you cannot
| prevent everything via static analysis rules.
| Moldoteck wrote:
| I think it's (mostly) sufficient to have a regex on git
| change-set for "new" "malloc" "calloc" keywords to cut most
| of such stuff if you have such a policy.
|
| Documentation / UT are harder to define (what is good
| documentation, is UT covering everything?), but usage of
| manual memory handling can be spotted relatively easy
| automatically. There can be some exceptions for 3rd party
| libs interaction if it's absolutely necessary but detecting
| such occurrences and keeping track of them is relatively
| easy.
| pjmlp wrote:
| See, already there you missed all the C language
| constructs that C++ is copy-paste compatible with, and
| should only be used inside _unsafe_ code blocks.
|
| Which in C++ good practices means type safe abstractions
| not exposing any kind of C style strings, arrays, casts,
| pointer arithmetic,....
|
| Unfortunely still relatively rare, some of us when we
| were the C++ Striking Force in the 1990's Usenet
| flamewars already advocated for such practices, most of
| them already possible with C++ARM, no need for modern,
| post-modern, rococo, baroque or whatever C++ style is
| going on with C++26 now.
| ben-schaaf wrote:
| > Is there a difference between c++ and java/go/etc if you
| enforce at code review for C++ to use only auto memory
| management like smart ptrs, containers, etc?
|
| Smart pointers and containers are nowhere near memory safe,
| just enforcing their use gets you nowhere.
| `std::vector::operator[](size_t)` doesn't check bounds,
| `std::unique_ptr::operator*()` doesn't check null.
|
| > Imo the strong point of rust is compile error if you try to
| use an obj after move (unlike c++ with undef behavior
|
| The state of a value after being moved is defined by the move
| constructor. It is unspecified by the spec, but it's
| generally not undefined behavior.
| Moldoteck wrote:
| What you mean by smart ptrs not being memory safe? Vector
| access can be done with at method
| pjmlp wrote:
| Which unfortunately most people avoid using, and until
| C++26 there is no at() for span.
|
| The best is really to enable compiler specific hardening.
| pjmlp wrote:
| They do when using hardned runtimes configuration, which
| was compiler specific, and starting with C++26 is
| officially part of the standard.
|
| It naturally doesn't cover C style programming in C++.
| dminik wrote:
| Yes there is. RAII is not a full replacement for GC and you
| will shoot yourself in the foot if you treat it as such. The
| design of C++ also includes many unpatchable holes in the
| standard library which WILL cause errors and UB.
| Moldoteck wrote:
| So how exactly would this shooting in the foot look like
| compared to say java
| dminik wrote:
| Too many to list, but for some examples:
|
| You take a reference to a vector element, which you later
| accidentally invalidate by pushing to the same vector.
|
| You move out of a unique_ptr, but then you accidentally
| use it again.
|
| You create a cycle with shared_ptr causing a memory leak.
|
| If you std::sort a list of floats with NaNs (among other
| things) you can stomp over memory. The sort function
| requires some very specific ordering otherwise you get
| UB.
| pjmlp wrote:
| Zig would be an interesting contender back in the 1990's
| between Object Pascal and Modula-2, nowadays we know better.
|
| For me while Go is definitly better than Oberon(-2), and
| Oberon-07, some of its design decisions are kind of meh, still
| I will advocate for it in certain contexts, see TinyGo and
| TamaGo efforts.
|
| As old ML fanboy, you can find such tendencies on plenty of
| languages not only OCaml. :)
|
| I see Rust as a great way to have made affine types more
| mainstream, however I rather see the mix of automatic resource
| management + strong type systmems as a better way forward.
|
| Which is even being acknowledged by Rust's steering group, see
| Roadmap 2026 proposals.
| j-krieger wrote:
| I've been writing Rust for half a decade now and I'm firmly
| believing that it's just not good for UI. Global state and a
| model that lends itself to inheritance just doesn't fit in the
| language.
| Ygg2 wrote:
| I'm pretty sure the issue isn't Rust but the fact outside
| Browser UI, every native UI sucks.
|
| And the biggest culprit is Apple by far, followed by
| Microsoft, followed by Linux lack of consistency.
| speed_spread wrote:
| We had Delphi and VB thirty years ago and the native UIs
| were pretty good. The web brought a massive regression in
| UI programming, functionality and usability that we
| generally haven't recovered from yet. Not every app can be
| a web site.
| Ygg2 wrote:
| Sure. It was a simpler time.
|
| Web didn't make massive regression in UI, it made minimum
| feature set huge.
| pjmlp wrote:
| So simple that layout managers were already a thing, even
| if Electron kiddies have no idea about them in native
| UIs.
|
| By the 2000's doing pixel perfect native UI was a sign of
| being lazy to learn UI best practices.
| Ygg2 wrote:
| Say what you want but for modern UI localization and
| accessibility are part of minimum feature set. Those two
| massively increase complexity (UTF8, IME, Braile, Text to
| speech, etc.)
|
| The big issue I'm talking about is cross OS UI Toolkit.
| Great your UI supports IME on Windows and Mac. Now do
| that for Linux, BSD, etc.
| pjmlp wrote:
| First they have to decide what distribution actually
| matters for the desktop, out of hundreds that get forked
| for frivolous reasons.
|
| And yes accessibility and localisation were already a
| thing in Windows 3.x, classical Mac OS, OS/2,...
| znkr wrote:
| > If a project in an unsafe language has ever had a memory bug
| (I'm looking at you, Bun), the maintainers objectively have a
| track record of not being capable of manual memory management.
| You wouldn't put a person who has a track record of crashing
| busses at the wheel of a school bus.
|
| If you're serious, you should stop using Rust (which happens to
| contain an unsafe language): https://github.com/rust-
| lang/rust/issues/44800
| g947o wrote:
| Hmm... A bug report from near a decade ago, where the bug was
| fixed within days. Not sure what your point is. If anything,
| it shows how much Rust cares about memory safety, because
| elsewhere it wouldn't be a compiler bug in the first place.
| jmull wrote:
| > Not sure what your point is
|
| I'm not the previous poster but it seems pretty clear the
| point is to show how silly that absolutist pronouncement
| is.
| MindSpunk wrote:
| Being so absolutist is silly but their counter argument
| is very weak. Can I invalidate any memory safe language
| by dredging up old bug reports? Java had a bug once I
| guess it's over, everyone back to C. The argument is so
| thin it's hard to tell what they're trying to say.
|
| It's just as reductive as the person they're replying to.
| jmull wrote:
| > Being so absolutist is silly but their counter argument
| is very weak.
|
| The _entire_ point is that being so absolutist is silly.
|
| The comment reflects the previous poster's logic back at
| them so they (or others) can hopefully see how little
| sense it makes.
|
| You seem to be trying to see some additional argument
| about rust being bad/invalid, but there isn't one... The
| reason that argument is, indeed, "very weak" and "so
| thin", as you say, is that it isn't even there at all.
| Ygg2 wrote:
| > The entire point is that being so absolutist is silly.
|
| You're misinterpreting what Rust people are telling you.
|
| - Rust is safe lang
|
| - Nah, C is safe if you're good
|
| - Rust evangelical gestures towards billions or CVEs
| brought on by overly-sure C programmers
|
| - Yeah, well, a version of Rust was unsafe for few months
| ten years ago. Besides Zig prevents more bugs than C and
| is the successor
|
| - Rust person points to Bun's abysmal record
|
| - Stop being absolutist.
|
| The issue is that in C or Zig few people can write mostly
| UB free code. In Rust anyone can write UB free code as
| long as they don't reach for unsafe.
| ViewTrick1002 wrote:
| Just compare the Buns and Deno issue trackers.
|
| Bun is segfaults galore, I've stumbled upon them.
|
| In Deno they essentially only come from integrating with C
| and C++ libraries.
| sheepscreek wrote:
| > Rust happens to be an extremely good tool. There
|
| Sir (or ma'am), you stole literally the line I came to write in
| the comments!
|
| To anyone new picking up Rust, beware of shortcuts (unwrap()
| and expect() when used unwisely). They are fine for prototyping
| but will leave your app brittle, as it will panic whenever
| things do not go the expected way. So learn early on to handle
| all pathways in a way that works well for your users.
|
| Also, if you're looking for a simpler experience (like Rust but
| less verbose), Swift is phenomenal. It does not have a GC, uses
| ARC automatically. I spent months building a layer on top of
| Rust that removed ownership and borrow considerations, only to
| realize Swift does it already and really well! Swift also has a
| stable ABI making it great for writing apps with compiled
| dynamic components such as plugins and extensions. It's cross
| platform story is much better today and you can expect similar
| performance on all OS.
|
| For me personally, this relegates rust for me to single
| threaded tasks - as I would happily take the 20% performance
| hit with Swift for the flexibility I get when multithreading.
| My threads can share mutable references, without fighting with
| the borrow checker - because it's just a bad use case for Rust
| (one it was not designed for). A part of my work is performance
| critical to that often becomes a bottleneck for me. But
| shouldn't be a problem for anyone else using RwLock<Arc<...>>.
| Anyway - they're both great languages and for a cli tool or
| utility, you can't go wrong with either.
| maxbond wrote:
| 1000x yes. Rust is not a One True Language, there exists no One
| True Language. Rust made some improvements over previous
| languages (many of which were ported over from previous languages
| that demonstrated the value but weren't break out successes) and
| serendipitously those improvements added up to something that was
| really significant and unlocked interesting and useful
| capabilities. I'm never going back to how my workflows were
| before I learned Rust (though I still write in other languages
| everyday).
|
| But there will be other languages in the future that will
| continue to deliver small improvements until one day they result
| in another phase change. The honeymoon with Rust will be over and
| it will start feeling more antiquated.
|
| C, Python, Java, are just a couple random languages that were/are
| similarly influential. (C is of course orders of magnitude more
| influential, the only language more influential is probably
| COBOL?)
| esperent wrote:
| > But there will be other languages in the future that will
| continue to deliver small improvements until one day they
| result in another phase change
|
| I agree, and I'm interested to see what it is in the age of
| LLMs or similar future tools. I suspect a future phase change
| might be towards disregarding how easy it is for humans to work
| with the code and instead focus on provability, testing,
| perhaps combined with token efficiency.
|
| Maybe Lean combined with Rust shrunk down to something that is
| very compiler friendly. Imagine if you could specify what you
| need in high level language and instead of getting back "vibe
| code", you get back proven correct code, because that's the
| only kind of code that will successfully compile.
| echelon wrote:
| If your LLM can output 10-100x the LOC output, and it's equally
| good at all languages, and you're not bound to an existing
| language choice or ecosystem, why not choose Rust?
|
| Rust code will be faster, safer, and easier to ameliorate bugs
| in.
|
| Rust seems like the best language to serialize business logic
| to now that LLMs are so good at it.
|
| If the LLM makes a mistake in Javascript or Python, you
| literally won't know until runtime. With Rust, you'll know
| immediately and have really good compiler recommendations for
| fixes.
|
| I think Rust is the best LLM language. I am somewhat biased:
| I've written Rust code for ten years, and I'm having a blast
| with Claude Code writing it for me instead now. But I've also
| used so many other tools and languages - enough to say that
| Rust has some unique advantages here. And also that Claude does
| a fantastic job emitting Rust.
|
| LLMs emitting Python feels like building with clay. LLMs
| emitting Rust feels like building well-engineered steel
| skyscrapers.
| maxbond wrote:
| I do choose Rust. For now. I write Rust everyday. I'm
| generating Rust at this moment.
|
| But when I learn a better language I will adopt it.
| resonious wrote:
| I'm also having a really good time having LLMs write code in
| Rust. In Typescript they tend to abuse `any` or just cast
| stuff around, bypassing the type system at every corner. In
| Rust they seem to take compiler errors to heart and things
| tend to work well.
| maxbond wrote:
| You might also have success asking your agent to run
| `eslint` at the end of every subtask and instruct it to
| always address lint errors, even if they are preexisting. I
| agree with your diagnosis; there's "implicit prompting" in
| Rust being more strongly typed and the agent "knowing" that
| going in but we can compensate with explicit prompting.
| (You do also have to tell it to actually fix the lints, I
| find, or it will conclude they aren't relevant.)
| wolvesechoes wrote:
| > LLMs emitting Rust feels like building well-engineered
| steel skyscrapers
|
| Oh the irony.
|
| Good thing that real engineers cannot build their skyscrapes
| with LLMs.
| zozbot234 wrote:
| > But there will be other languages in the future that will
| continue to deliver small improvements until one day they
| result in another phase change. The honeymoon with Rust will be
| over and it will start feeling more antiquated.
|
| That language may well be Rust itself, especially if they
| manage to figure out the "how to deprecate standard library
| features across language editions and allow reuse of their
| idiomatic syntax?" problem.
| maxbond wrote:
| Totally true. Similarly I think a C revival is more likely
| than people might think because of Fil-C, improvements to the
| language standard, and maybe hardware improvements like
| CHERI. Eg, maybe there will be a new generation of Fil-C like
| compilers, maybe C will get a lot easier, and maybe that will
| cause C to displace Python as the preffered pedagogical
| "first language" (which would really be reprising it's role).
| Not because it's easier than Python but because it's easy
| enough and we start emphasizing low-level optimization more
| because AI is eating all of our compute. Stranger things have
| happened.
| zozbot234 wrote:
| Fil-C is actually not very low-level efficient, Golang
| probably has better efficiency (being built from the ground
| up for lightweight concurrent GC) and a hypothetical
| support within Rust for "pluggable" GC heaps might be even
| more clearly preferable.
| joe-user wrote:
| I can see some interest in Fil-C, but some will still be
| against it due to the overhead it imposes (1.5x-4x worse
| performance, less deterministic since there's a GC), as
| well as the program will simply crash on arbitrary memory
| reinterpretation, use-after-free, and reading uninitialized
| memory. This is certainly better than it continuing, but
| certainly not as good as it could be.
|
| CHERI has different characteristics in that it will crash
| for buffer overflows, but crashing on use-after-free is
| opt-in, it can only detect double-frees sometimes, it does
| nothing about uninitialized memory access, etc. It also
| requires adopting new hardware, which may be a hard sell.
|
| In all I've mentioned above, I haven't even touched thread
| safety or integer safety which these do nothing about.
|
| So with that being said, do as you please, but understand
| that simply adopting these is a different level of safety
| (program will not be exploitable but will crash) compared
| to something like Rust (program is not exploitable and will
| not crash because these issues are mostly* compile-time
| errors).
|
| * "Mostly" since I mentioned integer safety which will be a
| runtime crash like the C safeguards, you can use unsafe,
| etc.
| maxbond wrote:
| Really what I'm getting at is that people are not done
| innovating on C ergonomics and safety and that there is
| potential there. Not that there is a new shivel-ready
| paradigm shift that has arrived to C. I'm only saying
| that that _may_ happen and that it is more likely than
| most people credit.
| josephg wrote:
| > I can see some interest in Fil-C, but some will still
| be against it due to the overhead it imposes (1.5x-4x
| worse performance, less deterministic since there's a GC)
|
| Yeah this is where I stand with it. Fil-C seems to be the
| worst of all worlds. It combines the performance of an
| immature GC language, with the primitive syntax and
| ecosystem of C. (Eg nullability, void*, no generics, no
| collection types, a bad standard library, header files,
| no good build system, bad cross-OS portability, BYO
| strings, etc).
|
| I don't choose C for its wonderful syntax. I choose it
| because its small, light and performant. If I was happy
| to use a garbage collector, I'd much prefer to go all the
| way and grab Typescript, C# or Go.
|
| The only use case I can see for Fil-C is running legacy
| code that you can't be bothered porting to a better
| language.
| dgrunwald wrote:
| Don't forget the compatibility issues: Fil-C isn't really
| usable if you mix C with other languages in the process.
|
| It's especially problematic to have multiple different
| garbage collectors; so given the desire to reuse
| libraries across language boundaries, there's still a
| strong demand for Yolo-C, C++ or Rust.
| hu3 wrote:
| I think Rust has a big flaw to overcome in the age of LLMs:
| slow compilation.
|
| If they can't fix this, a language with similar guarantees,
| even syntax, but fast compilation is bound to succeed in
| niches where Rust is desireable.
|
| Iteration speed is a big bottleneck in agentic workflows.
| Well, any workflow.
| xlii wrote:
| Sir/Madam/Sovereign... did you hear about Prolog? ;)
| maxbond wrote:
| This isn't the first time someone has said that to me, so I
| really ought to make time to learn it.
| torginus wrote:
| The weird thing about this is many core Rust people agree that
| Rust is not the best language that could possibly ever be, even
| evaluated by the core principles of Rust (that is: no UB, no
| mutable aliasing, no memory bugs).
|
| And if we move outside of Rust's memory model, some people have
| raised issues with the inconsistent syntax, and the module-
| based compilation model which makes compilers inherently slow,
| as you have to parse the whole module every time.
|
| So there's room for improvement, and people are already working
| on putting ideas into practice, and some of these people who
| came from the Rust ecosystem itself.
|
| And if you happen to disagree with Rust's core goals (or just
| place less emphasis on them), then it's obviously not the
| perfect language.
| burakemir wrote:
| A programming language is a medium to communicate programs to
| something that can execute them. That isn't exactly the same
| thing as a tool. A tool in my book is a metaphor for a program
| that helps achieve some well-defined task. Even if we ignore this
| difference, we would still want to talk about tool safety.
|
| In my experience there is a C++ mob that hates Rust. These are
| the people who declare statement of facts as ideology. No good
| faith dialogue is possible.
|
| There are also competent C++ programmers who misunderstand or
| don't know how static checking works.
|
| I also witness normal people who are completely surprised by a
| statement like "C++ is all unsafe" and find that too strong.
| Using the word "safe" with a technical meaning throws normal
| people off because, sadly, not everyone who writes code is an
| academic PL researcher.
|
| "Safe", in Rust and much PL research, means "statically checked
| by the compiler to be free of UB". If you are pedantic, you need
| to add "... under the assumption that the programmer checked all
| conditions for the code that is marked `unsafe`" for Rust. That
| is all there is to it. Scientific definition.
|
| C++ in its current form is full of gross design mistakes, many of
| which could be corrected at the price of breaking backwards
| compatibility. Mistakes happen, aldo to world leading PL
| researcher (the ML language and polymorphic references) which is
| why the field embraced mechanically checked proofs. The
| difference is the willingness to address mistakes.
|
| Academics use "safe" in exactly the meaning the Rust community
| uses. If you don't understand this, go and educate yourself.
| Academics need to communicate effectively which leads to
| technical meanings for everyday words or made up words and
| jargon.
|
| Maybe a statically checked safe low-level language is marketing
| genius. It is also a technical breakthrough building on decades
| of academic research, and took a lot of effort.
|
| Bjarne and friends chose a different direction. Safety was not a
| design goal originally but doubling down on this direction means
| that C++ is not going to improve. These are all facts.
|
| Backwards compatibility is a constraint. Constraints don't give
| anyone license to stop people who don't have those constraints.
|
| We don't have to feel any moral obligation to use statically
| checked languages for programs. But claiming that static checking
| does not make a difference is ignorant, and attaching value to
| one's ignorance certainly seems like an indicator for ideology
| and delusion.
| michaelmure wrote:
| Any recommandation for a quality non-toy rust codebase to study?
| maxbond wrote:
| Two arbitrary picks:
|
| https://crates.io/crates/serde
|
| https://crates.io/crates/regex
|
| Anything covered by Gjengset's "decrusted" series:
| https://youtube.com/playlist?list=PLqbS7AVVErFirH9armw8yXlE6...
|
| Sort of on the border between toy and not-toy; Gjengset
| implements a concurrent hash map:
| https://youtube.com/playlist?list=PLqbS7AVVErFj824-6QgnK_Za1...
| [17hr recorded over 3 streams]
| josephg wrote:
| The rust standard library is excellent. Start more or less
| anywhere, and click "view source". Or open up the source code
| files on github.
|
| There's often a lot more comments than code, which is kind of
| annoying. But it really is the best way to learn how a lot of
| good rust is written.
|
| Vec is a good read: https://doc.rust-
| lang.org/src/alloc/vec/mod.rs.html
|
| Here's the lovely slice::binary_search_by: https://doc.rust-
| lang.org/src/core/slice/mod.rs.html#2967-29...
| anon-3988 wrote:
| Rust is just a tool. A decent tool that I think can be made
| better (by removing stuff and stop adding more stuff to the
| surface syntax). So I am down to criticize Rust.
|
| However, I also don't understand how people don't see the
| usefulness of what Rust put to the mainstream: algebraic data
| types, sum types, traits, etc.
|
| I also get super annoyed when people think Rust is only chosen
| for "safety". Says frustrating things like "so I can just use
| unsafe", because no you don't and if you do I would reject your
| changes immediately.
|
| Honestly, in general, I am just annoyed when people don't use the
| right tool for the right job. And attempts to fix the tool with
| more bespoke stuff on top it.
| HippoBaro wrote:
| > Says frustrating things like "so I can just use unsafe",
| because no you don't and if you do I would reject your changes
| immediately.
|
| This is the kind of hostility (which is frankly toxic) that's
| become associated with parts of the Rust community, and has
| fairly or not, driven away many talented people over time.
| aldanor wrote:
| Yes. To me personally, Rust and both its restrictions and
| features (ie no OOP and prevalence of sum types and hence other
| goodies) makes approaching the implementation of big problems
| differently; eventually the experience with Rust also changes
| (to some extent) the way you write and structure the code in
| other languages. One might argue that Rust is not unique here
| and this would also apply to languages like ocaml etc - sure,
| perhaps; but I can't write in any of those languages at work on
| daily basis since they don't fit performance-wise or for many
| other reasons.
| qsera wrote:
| Rust is boaring! I ll never use Rust for something I build for
| fun.
|
| It will be a shame if new programmers will stay away from C
| because of all the scaremongering regarding the consequences of
| not freeing some memory (in some toy, pet project) in their own
| computers.
| simonask wrote:
| You seem to believe that Rust prevents memory leaks. It does
| not, and that's not what "memory safety" means.
| sheept wrote:
| Yes, Rust does not guarantee that it'll prevent memory leaks.
| But the design of the language does make it harder for you
| (and your collaborators/dependencies) to accidentally leak
| memory compared to, say, C++.
| up2isomorphism wrote:
| Rust is a very very ugly language, this is made worse when it is
| shamelessly promoted by bunch of persistent people with bad
| tastes.
|
| Also trying to fight runtime behavior with compile time
| constraints cannot be a universal treatment. Trying to enforce
| OOP is one of such examples, and it already failed .
| oytis wrote:
| We need more courageous people like him.
| fmajid wrote:
| Overly enthusiastic Rust evangelists can be annoying, but nowhere
| as much as C++ or C advocates defensively claiming memory safety
| isn't a big deal, and they are going to have it in the next
| version of the language anyway.
|
| I find my experience with Erlang has helped with the
| (considerable) learning curve for Rust, but I still prefer Go for
| most use-cases.
| wolvesechoes wrote:
| > claiming memory safety isn't a big deal
|
| There are contexts where it is, there are contexts where it is
| not.
|
| But suddenly everyone out there is dealing only with those
| context where it is.
| ysleepy wrote:
| Rust does not have the best tooling by far imo.
|
| The IDE capabilities are not nearly as advanced as they are for
| Java for example.
|
| Compared to C/C++ or dynamically typed languages, sure.
|
| I love that cargo unifies the ecosystem, no quabble over one
| shitty build tool over another.
|
| I feel like the IDE story still has a long way to go.
| pjmlp wrote:
| Not even C/C++, only if vim and emacs are the only experience
| one has ever had.
|
| See Visual C++ (with hot code reloading, incremental linking,
| AI integration, on the fly analysis), QtCreator, Clion
| (comparable with VS in many options), C++ Builder (with its RAD
| capabilities),....
|
| Cargo is great as long as it is only Rust code and there is
| little need to interop with platform SDKs, then it is build.rs
| fun.
| g947o wrote:
| Java has over 3 decades of history, during which many IDEs were
| developed just for Java, and the ecosystem evolved over that
| long period. Rust is still way too young.
| goku12 wrote:
| I'm curious about the exact exchange that prompted the author to
| say this.
|
| > refuse to admit there are alternatives to RAII
|
| I'm even more curious about this. Can the author or anybody else
| explain what this means specifically? Can anybody list those
| alternatives other than GC and RC?
|
| PS: Computer Science isn't exactly my primary professional
| competence.
| cwood-sdf wrote:
| Batching/arenas can get you very far. If you adopt the zig/c
| object model as "things that have data" most destructors become
| useless. Resource management also can be accomplished at the
| batch level (eg you can free a bunch of fd's all at once with a
| management layer rather than having each File object implicitly
| manage its own fd). For memory management, i believe proper use
| of arenas and batching tends to be faster than each object
| managing its own memory but idrk tbh. What the author is saying
| is that you dont have to have raii, you can use approaches like
| the one i described and they can still be pretty safe if you
| know what youre doing, but rust's model basically prevents this
| if youre using rust idiomatically
| xlii wrote:
| I agree with this (short and sweet) piece. I'm Rust user but the
| crab-hype turned me off for the long time.
|
| Personally I'd prefer writing Haskell but there are sharp edges I
| can't overlook (like constantly breaking LSP of 11/10 difficulty
| on producing distributable binaries).
|
| I cringe every time I spit out 50 lines of boilerplate just to
| get C done Rust, but it's best tool I found that's good enough in
| many scopes.
| alecco wrote:
| Rust is an amazing tool that sadly has the most toxic self-
| righteous community in PL. Like doxxing that kid for daring to
| post he refactored his pet project from Rust to Go.
| speed_spread wrote:
| Every community has these assholes. In my experience, the Rust
| user base is nothing but polite, understanding and pragmatic.
| There's no smugness, explicit or implied. The Rust lore is just
| a joke that's getting less funny every day someone takes it
| seriously.
| wolvesechoes wrote:
| Yet, almost every Rust thread here serves as a evidence that
| your experience doesn't reflect reality.
| speed_spread wrote:
| Frankly, I see _a lot_ more uninformed attacks on Rust than
| actual Rust evangelism / snobbery. And most of these anti-
| Rust comments reek of personal insecurities and low-effort
| trolling. Like saying that Java is slow. It's getting old
| real quick.
| ch_123 wrote:
| I feel like it's far easier to find more zealously anti-Rust
| people than zealously pro-Rust people - hating Rust has
| almost turned into a meme.
| randomint64 wrote:
| Sherlock Holmes liked to say "When you have eliminated the
| impossible whatever remains, however improbable, must be the
| truth".
|
| The same is true for programming languages. When you have
| eliminated all the others for their fatal flaws, only Rust
| remains, so it's not "just a tool", it's the best tool (or less
| worse, depending on how you like the syntax).
|
| You can read more about the technical reasons here:
| https://kerkour.com/rust-software-engineering-reliability
| qsera wrote:
| hah hah hah!
| kshri24 wrote:
| My only gripe with Rust is Rust-Analyzer taking up so much of my
| system's resources. And I know it is not really fixable which is
| a bummer.
| BoingBoomTschak wrote:
| "$LANG is just a tool" has never been right. The Sapir-Whorf
| hypothesis (or the blub lang analogy - and not the smug part -
| for programmers) is still true to this day.
|
| tl;dr: Just a tool, but _" we shape our tools and then our tools
| shape us"_.
| dcminter wrote:
| While these are all reasonable points, there _is_ a distinction
| between criticising _people_ for using ${lang} (bad) and
| criticising _the language_ (neutral).
|
| Some people get their egoes attached to their choices (for or
| against Rust).
|
| Also there's a time and a place for all criticism. If the
| conversation is not fundamentally about language choice then it's
| very irritating to have it brought up.
| ragall wrote:
| Everyone's getting the wrong metaphor. Languages are raw
| material, not tools.
| jurschreuder wrote:
| I don't think Rust/PHP are all that much more safe than Zig/C++.
|
| 80% of memory safety bugs in C++ are just basically "array out of
| bounds", for which you don't need a memory checker at all just
| array bounds checks which LLVM has enabled by default for Rust
| but you can also use it for C++.
|
| 70% of vulns in C++ are memory related but only ~10% of those
| would be caught by borrow checking. Most are already caught by
| forcing object initialisation and array bounds checking. Only
| use-after-free is caught by either borrow checking OR OTHER TOOLS
| like ARM has 4 bits in addresses that can encode if the memory
| location has not been pulled from under you.
|
| So aaaaall this trouble if the borrow checker to have in some
| cases max 10% fewer vulnos.
|
| I'm not going to switch to Rust/PHP just for that little memory
| safety bonus.
| nesarkvechnep wrote:
| We've had memory-safe languages for 50 years, don't act like Rust
| is the first one.
___________________________________________________________________
(page generated 2026-02-28 23:01 UTC)