3 ms·

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 organ

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.

noosphr 1y ago
Yes, but we're not making a push to make everything a bilingual c/lisp code base. Rust people for some reason are.
- mdhb 1y ago
  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.
  - hulitu 1y ago
    > 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.
    - bestouff 1y ago
      There are guarantees that many types of bugs won't happen in Rust code. That alone is a great progress.
    - kaoD 1y ago
      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.
      - kasabali 1y ago
        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. I mean the "code to parse .deb, .ar, .tar," is done and whatever memory bugs should've been already fixed . Use Rust for evergreen projects by all means, just leave mature tested systems alone, please.
        tialaramex 1y ago
        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?
        kaoD 1y ago
        I don't follow how from "better but not perfect is better than worse" you conclude that.
    - mdhb 1y ago
      a bunch of major projects have conclusively shown that moving to memory safe languages without any doubt whatsoever results in more secure software.
    - tcfhgj 1y ago
      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...
    - norman784 1y ago
      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-for-one-week-and-found-9-big-problems/ https://www.zdnet.com/article/i-ditched-linux-for-windows-11...
    - IshKebab 1y ago
      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.
  - aragilar 1y ago
    Is it the largest though? Based on https://owasp.org/www-project-top-ten/ 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/ 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)?
    - viraptor 1y ago
      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 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.
      - aragilar 1y ago
        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).
    - dvtkrlbs 1y ago
      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/ 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-safer-systems-programming-language https://www.microsoft.com/en-us/msrc/blog/2019/07/we-need-a-... [3] https://security.googleblog.com/2019/05/queue-hardening-enhancements.html https://security.googleblog.com/2019/05/queue-hardening-enha... [4] https://x.com/LazyFishBarrel/status/1129000965741404160 https://x.com/LazyFishBarrel/status/1129000965741404160
- dicytea 1y ago
  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.
  - Keyframe 1y ago
    You mean the one that all languages eventually converge to Lisp? That's a fact though :)
  - noosphr 1y ago
    Yes, the blind stumble down hill eventually. But we let them do it in their own time.
lsaferite 1y ago
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.

noosphr 1y ago

Yes, but we're not making a push to make everything a bilingual c/lisp code base. Rust people for some reason are.

mdhb 1y ago
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.
- hulitu 1y ago
  > 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.
  - bestouff 1y ago
    There are guarantees that many types of bugs won't happen in Rust code. That alone is a great progress.
  - kaoD 1y ago
    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.
    - kasabali 1y ago
      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. I mean the "code to parse .deb, .ar, .tar," is done and whatever memory bugs should've been already fixed . Use Rust for evergreen projects by all means, just leave mature tested systems alone, please.
      - tialaramex 1y ago
        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?
      - kaoD 1y ago
        I don't follow how from "better but not perfect is better than worse" you conclude that.
  - mdhb 1y ago
    a bunch of major projects have conclusively shown that moving to memory safe languages without any doubt whatsoever results in more secure software.
  - tcfhgj 1y ago
    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...
  - norman784 1y ago
    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-for-one-week-and-found-9-big-problems/ https://www.zdnet.com/article/i-ditched-linux-for-windows-11...
  - IshKebab 1y ago
    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.
- aragilar 1y ago
  Is it the largest though? Based on https://owasp.org/www-project-top-ten/ 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/ 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)?
  - viraptor 1y ago
    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 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.
    - aragilar 1y ago
      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).
  - dvtkrlbs 1y ago
    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/ 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-safer-systems-programming-language https://www.microsoft.com/en-us/msrc/blog/2019/07/we-need-a-... [3] https://security.googleblog.com/2019/05/queue-hardening-enhancements.html https://security.googleblog.com/2019/05/queue-hardening-enha... [4] https://x.com/LazyFishBarrel/status/1129000965741404160 https://x.com/LazyFishBarrel/status/1129000965741404160
dicytea 1y ago
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.
- Keyframe 1y ago
  You mean the one that all languages eventually converge to Lisp? That's a fact though :)
- noosphr 1y ago
  Yes, the blind stumble down hill eventually. But we let them do it in their own time.

lsaferite 1y ago

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.