Path: csiph.com!weretis.net!feeder9.news.weretis.net!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail From: cross@spitfire.i.gajendra.net (Dan Cross) Newsgroups: comp.programming Subject: Re: Informal discussion: comp.lang.rust? Date: Mon, 28 Jul 2025 15:16:00 -0000 (UTC) Organization: PANIX Public Access Internet and UNIX, NYC Message-ID: <106847g$33e$1@reader1.panix.com> References: <1067ndk$qka$1@reader1.panix.com> <1067o6p$24rjd$2@dont-email.me> Injection-Date: Mon, 28 Jul 2025 15:16:00 -0000 (UTC) Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80"; logging-data="3182"; mail-complaints-to="abuse@panix.com" X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: cross@spitfire.i.gajendra.net (Dan Cross) Xref: csiph.com comp.programming:16815 In article <1067o6p$24rjd$2@dont-email.me>, Julio Di Egidio wrote: >On 28/07/2025 13:37, Dan Cross wrote: > >> 50 years of empirical evidence has shown that, sadly, this is >> just not true. Even our best and brightest C programmers still >> regularly make mistakes that simply impossible to represent in >> Rust, along with other languages. > >Conversely, that are things that cannot be represented in (e.g.) >Rust, I'm not sure what this means. It is true that valid Rust programs are not allowed to violate it's rules about, say, memory aliasing, which means that some kinds of data structures are difficult (or impossible) to represent using references (for instance, circular lists using intrusive pointers). But that doesn't mean that those programs, or programs that are substantially equivalent, cannot be written. For the circular list example, one could use raw pointers, and Rust will be perfectly happy with this: the tradeoff is that the onus shifts to the programmer to ensure that the program doesn't violate the language's rules. But that's really no different than the C case. But more often than not, it turns out that using a different data structure may actually be better anyway. A lot of people who look at Rust and dismiss it because it's difficult to implement something like an intrusive doubly linked list are just trying to do that because that's the data structure they are most familiar with, and not really considering whether it's a good fit for the problem at hand or not. It may be that Rust already gives you something that solves the problem, and may be more efficient to boot. >plus the bugs are still potentially there, just now in the >Rust compiler and runtime itself... Rust doesn't really have a runtime, per se. You give it a stack and jump to an entry point, and you're pretty much done; sure, there's a standard library, but that's different than (say) a managed language with a garbage collector etc. >IOW, the idea that programmers in general need to be baby-seated I wouldn't phrase it as "babysitting". Rather, it's professionals making conscious choices about their tools to most effectively do their jobs. >instead of given control I find not just self-defeating but really >fallacious. In what way do you feel you have less control (and over what?) in Rust than in, say, C? I find this line of reasoning both odd, and based on a logical fallacy unsupported by empirical evidence: specifically, it is not the case that just because something _can_ happen, that it _will_ happen, let alone at the same rate as other things that are known to happen regularly. Yes, there is always the possibility that bugs exist in a compiler or library. But a) those tend to be rare compared to bugs introduced by programmers in any given system, and b) the toolset and library for a language is a much smaller surface area than the aggregate of all programs that use that toolset and library. That is, taken together, there is much, much more source code written in a language out in the world than there is in a compiler and library for that language. Also, because the compiler and standard library for a language are used so heavily, bugs in them tend to be noticed and addressed quickly. But beyond that, if the position you have presented is true, there should be data that supports it, and there's not. Rust has been used in production systems now for about 10 years; there's plenty of code out there written in it, in a bunch of different domains from embedded firmware to web services and user applications, and the available data suggests that it _is_ a win in those domains; not just in safety or reduced defect rates, but even in performance of generated code and productivity. For example, here's a presentation from Google engineering director Lars Bergstrom about it: https://www.youtube.com/watch?v=QrrH2lcl9ew And here's post from the Android security team about memory safety that talks about wins from Rust: https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html Does this mean that the language is perfect, and will prevent all bugs? No, of course not; it's not magic. But this line of reasoning that says, "well, you can still have bugs, so what's the point?" inevitably ignores the relative rate of those bugs between languages, which does matter. It's the same argument that says, "you can still die in a car crash, so we don't need seatbelts or airbags." Yet all available data shows that those things _do_ in fact save lives. - Dan C.