Many programmers feel the same way about Lispers. It's best to set aside your gut feelings about the community and think primarily about the technical and organizational merits and disadvantages of the technology.

Yes, but we're not making a push to make everything a bilingual c/lisp code base.

Rust people for some reason are.

Not a Rust or even a systems language guy but it’s not “for some reason”. The reason is actually incredibly clear and about removing the single largest surface area of security problems in the entire history of Linux.

Is it the largest though? Based on https://owasp.org/www-project-top-ten/, it would be part of #6 or #8. While one can always walk and chew gum at the same time (and those rewriting system software are likely not the same people who need to design systems with less flawed access control), replacing stable software is not without risk (e.g. https://lwn.net/Articles/1043103/, which is an instance of #6 caused by rust). Would you trust a rewrite of OpenSSH in rust (absent any information about its authors)?

Owasp deals with web security only. That whole area is biased towards php/ruby/js/python/beam where those issues don't exist outside of native modules.

https://www.cvedetails.com/vulnerabilities-by-types.php is a bit more clear. It's xss, SQL, then memory. The first two are not possible to enforce a fix on - you can always make a decision to do something bad with no visible annotation. Even then, rich types like in rust make safe interfaces easier to produce. But rust tackles the next class of issues - one that you can verify to be safe or require an explicit "unsafe" around it.

But how many breaches get CVEs (or are caused by them)? Given how much users (and their data) interact via the web vs any other platform, reducing the breaches of services is going to improve users lives more than reducing the number of CVEs (does mongodb defaulting to not have username/password to access have a CVE).

As for preventing XSS and SQL injections, that's what good web frameworks do. If your framework encourages you to write raw unescaped SQL, or doesn't provide sensible defaults around content policies, then no matter what language it's in, there are going to be issues (and maybe if we called these frameworks "unsafe" then we'd get somewhere with fixing them).

Pretty consistently [1] [2] [3] [4] it comes out that nearly %80 of security vulnerabilities come from memory safety vulnerabilities. I would consider that largest. Especially Microsoft's doc is pretty telling that this ratio was pretty consistent since 2006 so no amount of external tooling and training solves this. [1] https://langui.sh/2019/07/23/apple-memory-safety/ (albeit apple solving this with an another language and a really nice cpu extension) [2] https://www.microsoft.com/en-us/msrc/blog/2019/07/we-need-a-... [3] https://security.googleblog.com/2019/05/queue-hardening-enha... [4] https://x.com/LazyFishBarrel/status/1129000965741404160

In which code though? What counts as a security vulnerability (does the design of the play store such that searching for an app and the top result not being that app count)? I like everyone else want a secure browser, but my secure browser isn't going to prevent my email (or passwords) from appearing on https://haveibeenpwned.com/. I like rust, and want to write more rust, but if I were to port openssh to rust, I guarantee my rust code would have more CVEs than openssh.

My feeling is in the specific instance of using rust in apt, this is most likely a good thing (though I hope existing well tested rust libraries are used rather than NIHing them and introducing new bugs), but so far Ubuntu's rustification has not gone smoothly, so I'm more wary of the changes that e.g. improvements to Firefox via rust.

I don't agree with openssh take but yeah we don't need to migrate everything to rust and yeah a migration not always goes smoothly I am using sudo-rs on my arch install for over a year havent had any issues yet.

> though I hope existing well tested rust libraries are used rather than NIHing them and introducing new bugs

I think that's much more likely to introduce bugs.

Think of it that way, a lot of the Rust libraries are rewriting existing copyleft libraries in permissive licenses, so they cannot look at the original code, dooming them to repeat the mistakes that were made in the original code and having to fix them all over again on their own (as both go from "oh this is simple" to "oh another corner case").

I just want to translate code 1:1 to Rust, reusing my existing knowledge, design decisions, and tests. It should behave _exactly_ the same as before, just memory safe.

> The reason is actually incredibly clear

There is no guarantee that other bugs do not flurish in the rust echosystem. There are no publicly known quality code checks of rust programs except a big "trust us"(see firefox with all its CVEs, despite "rust"). And combined with the Cargo echosystem, where every malicious actor can inject malware is a big warning sign.

AFAIK Linux is using rustc directly, without cargo.

And just an anecdote, Asahi Linux devs said that Rust made it very easy (maybe relative to working with C) to write the drivers for the Apple M1 and M2 series, so it seems that the language has his merits, even without the cargo ecosystem.

Also Rust will only minimize certain kinds of bugs, others are impossible, a few years ago (I believe was Microsoft) that said that 70% of the bugs found were memory related [0], it means that Rust would have prevented most of those.

Maybe Rust is not the best answer, but as for now it the most proven answer for this particular problem, who know of Zig or other language will replace both C and Rust in the future.

[0] https://www.zdnet.com/article/i-ditched-linux-for-windows-11...

Firefox is 29% Javascript, 28% C++, 22% HTML, 10% C, 3% Python, 2,6% Kotlin and 5% other

> There is no guarantee that other bugs do not flurish in the rust echosystem.

well, less likely than in C thanks to a advanced type system, e.g. allowing authors of abstractions make their API much more fool proof.

> where every malicious actor can inject malware is a big warning sign.

Very much doubt that is the case...

I might be misunderstanding here but... what you're saying is that Rust programs can still have bugs? Isn't that the same as other programs except Rust prevents the most disastrous and common bugs that lead to most CVEs?

If I got that right, how is "it's still not perfect" an argument?

Agree with the Cargo objection.

If perfect isn't needed, we might as well stick with the 20+ years old mature codebase, there's no need to move to another language.

Use Rust for evergreen projects by all means, just leave mature tested systems alone, please.

OK? So, is your position that Debian is only for software that's old enough to vote?

Or maybe Debian should never rely on any software written after 2015?

I don't follow how from "better but not perfect is better than worse" you conclude that.

There are guarantees that many types of bugs won't happen in Rust code. That alone is a great progress.

a bunch of major projects have conclusively shown that moving to memory safe languages without any doubt whatsoever results in more secure software.

Are there guarantees that "other bugs" do not flourish in the C ecosystem?

Firefox is not even close to 100% Rust.

This is a wildly misinformed comment.

One of the most iconic lisp saying is literally about how every other languages are supposedly inferior to lisp, so I don't think it's a particularly good example here.

You mean the one that all languages eventually converge to Lisp? That's a fact though :)

Yes, the blind stumble down hill eventually. But we let them do it in their own time.

I have similar feelings about the go community. I like go on the whole, but certain aspects are atrocious. The 'go community' is strangely cult-like and complaining about the language is generally poorly received. As a result I very rarely interact with them and just do my own thing.

How can lisp be fast if it doesn't have static typing and uses GC?

As a GC language Common Lisp is slow as molasses. However, in the realm of languages which are slow as molasses it's got quite acceptable performance. I suppose it's in part because it's alien technology from beyond the bounds of the multiverse, but also in part due to the fact that we had really interesting tech back in the '70s and '80s that kinda got lost during the so-called AI winter.

To add on to that, with declarations the programmer can tell the Lisp compiler that (for example) a variable can be stack allocated to help improve performance. The fact that Lisp code is just data is another benefit towards performance as it means macros are relatively easy to write so some computation can be done at compile time. There are also various useful utilities in the spec which can be used to help profile execution of a program to aid in optimization, such as time and trace.

News flash, but Lisp compilers have gotten better since the 80's. In general, normal, unoptimized Lisp is probably on-par with Java, while optimized Lisp with a good compiler can get on par with C++. SBCL is a very good compiler, and GC technology has come a long way.

SBCL is fantastic, but the resources being poured in GCC and LLVM combined with CPU manufacturers including architectural features to help C and related procedural languages work better make it a massive uphill battle. I suppose that with proper use of things like sb-simd and arena allocation you can get in the ballpark of C, but with some tweaking C, C++, and Rust can get insanely fast (of course Fortran's better, but nothing compares to it, so let's leave that aside for now).

> Christian missionaries trying to convert the savages

Fast forward 5 centuries, it turns out they were in fact pretty successful as South America central Africa are the places where Catholicism is the most active today, far more than in Europe.

Yes, by doing a lit of killing in those places.

Not from religious people, by a very large margin.

Less killing, considerably more buggery: https://www.abc.net.au/news/2025-01-29/former-bishop-broome-...

The Christian Brothers missions were hell holes across the undeveloped regions.

* https://www.theguardian.com/uk-news/2017/mar/02/child-migran...

* https://www.childabuseroyalcommission.gov.au/case-studies/ca...

Well, so far this thread has 0 people shilling Rust, a couple shilling Common Lisp and a bunch complaining about Rust shills (you included).

Makes you think, huh?

It’s a preemptive strike. By complaining about the Rust shills before they can show up, it prevents Rust shilling before it can happen. It’s a more humane approach and it saves lives. You don’t realise the social service the anti-Rust-shills are performing.

> I don't get the need for Rust since I happily compile common lisp to machine code when I need fast binaries.

Not sure how that’s relevant when CL is basically dead and no one wants to work with it, while Rust is flourishing and delivering value

Rust isn't 'delivering value', people are just drinking the koolaid. CL has its niches, and it still fills them well: it's never been that successful as a general-purpose language.

> Rust isn't 'delivering value'

Citation needed.

Or, what can be asserted without evidence can be dismissed by pointing to ripgrep.

Oh wow a replacement for a tool I already have. It's slightly faster, even if I seldom ever worry about its speed. Who cares?

57000 people who have starred its repository on Github care.

More evidence than you have provided for your claim "Rust isn't delivering value", what did you use to come to that conclusion?

It's a toy. Cool project, but it's a replacement for something that already exists and does its job well. All it demonstrates is "we micro-optimized our libraries more than GNU". It doesn't say anything about the advantages of Rust itself.

If the value proposition is internet drama, then it certainly does.

Rust community is Jehovah's Witnesses of software.

"why use C when I could simply link to node?"