4 ms·

Rust requires people to learn how to adapt to Rust’s borrow checker, which can be challenging for programmers coming from other languages, yet this hasn’t stopp

Rust requires people to learn how to adapt to Rust’s borrow checker, which can be challenging for programmers coming from other languages, yet this hasn’t stopped Rust’s rapid adoption in systems programming. In fact, Rust’s safety features are Rust’s selling point. Of course, it helps that Rust came from Mozilla and that it’s used in Firefox. Other than Grammarly and some internal Google products, I don’t know any modern-day high-profile projects written in Common Lisp. What would help bolster Common Lisp would be a high-profile project that would be much more difficult to implement in other languages.

tcmart14 3y ago
I'm not sure if Rust is a good comparison though. Rust is a lot closer to C, it is a language influenced by C, and current popular programming languages tend to also be influenced by C. So while there is a lot different with Rust, a lot of knowledge from, lets say, a C developer can carry over. Say your a C developer, or C++ developer and I am a Rust developer trying to sell you on Rust. You have to learn a new language. No way around it. Even though people may have problems with this statement, at a high level it is close enough, I can sell you on Rust probably by saying, 'it C/C++ with better (subjective) or more modern features and extra constraints (think borrow checker) to guarantee memory safety.' I would not be able to make that same argument with LISP. The next question could be why this could be true, or more importantly, why are so many people using C-like languages. I'd probably place it on portability and UNIX from when C emerged. And LISP machines died. In other words, I don't think it would be appropriate to try to draw a comparison between the two with the two of them in a vacuum. If LISP machines survived and were popular today, we could see Rust today having the same popularity of LISP today.
- shrimp_emoji 3y ago
  I'd argue Lisps are worse today. They encourage a thing that's generally discouraged in C: macro programming and typedefs. You're coding in Lisp, but you're actually coding in your own dialect of Lisp, eventually, with lots of idiosyncratic code that's difficult to reason about. That doesn't scale well in collaborative environments, where many people are touching a vast codebase (which I don't think was really a thing back in the '70s). That's when you want the uniformity and clarity of static type declarations and C++'s <algorithm> header functions. With Rust, you're just adding modernity and safety on top of that. Great! Lisp is crazy lone wizard shit.
  - tcmart14 3y ago
    That is the biggest problem I have with LISP which is why I think a lot of it is historical to some degree. I do like LISP to dabble in, but yea, there are tons of different dialects, it makes it harder to approach. Because while there is 'Common' LISP, there are implementations that can vary slightly between compilers, which compiler do you use? And some of the more popular compilers are sort of dead? There is SBCL, which does get some development, but not much I think? I don't think newer version of SBCL run on most of the BSDs? And yea, you also end up creating your own dialect in the process. Which some of those same problems could have occurred in C at some point, but C eventually converged. I can be confident my fairly simple C programs will compile just fine whether I use GCC/Clang/TCC, etc. If LISP could have converged like C did, it could be a completely different story, I wonder.
    - tmtvl 3y ago
      > There is SBCL, which does get some development, but not much I think? Quoth the website*: > New SBCL versions are usually released at the end of each month Also, the only BSD which has even in the single digits of market share, Darwin, is only 1 point release behind. * <https://sbcl.org/all-news.html https://sbcl.org/all-news.html>
      - samatman 3y ago
        Half of the phones in the US run BSD. Good luck getting SBCL on it though.
        tcmart14 3y ago
        The 'BSD' on phones would be iOS and tons of languages don't mostly due to the platform. I think a better example would be, the amount of embedded/appliances that ship forks of FreeBSD, OpenBSD, or NetBSD. Think of like routers. While Linux is the 1,000 pound gorilla in server space, there is still A LOT of BSD servers also. The person dimising BSD usage is only taking into account desktop share not realizing some OSs run on more than just consumer devices.
dmz73 3y ago
I find that borrow checked in Rust is the easiest part of the language to get used to. Lifetimes on the other hand seem unnecessary in 99% cases where compiler forces you to use them - why can't it just assume that all the required parts have the 'a and complain if something violates that? Event bigger issue is all the missing features that most other languages have - overloaded functions (they kind of exist in generics), ranged integers, arrays indexed by enums, full support for type aliases, some level of inheritance, even if it was the go style, would make Rust much much easier to use.
- samatman 3y ago
  > Lifetimes on the other hand seem unnecessary in 99% cases where compiler forces you to use them - why can't it just assume that all the required parts have the 'a and complain if something violates that? Rust does that, this is lifetime elision. If the compiler complains about missing lifetime annotations, that means it can't infer the lifetime. Granted that it not-infrequently feels like it should be able to, and there's definitely room for improvement on its lifetime inference. It's conservative, meaning that an elided lifetime will always be valid, but some lifetimes which could be elided get missed by inference and need to be added anyway. But most of the times that I've yelled at the compiler for complaining about missing lifetimes, it was right and I was wrong.
  - jpc0 3y ago
    To the contrary I ran into cases pretty quickly that rust just wasn't useful for in my opinion. One of my use cases was something like a mutable borrow of an struct in a struct in a single threaded code path wasn't allowed because the entire struct was mutably borrowed or some nonsense. I believe the "idiomatic" way was to create some weird abstraction to appease the borrow checker that the thing being borrowed once is only being borrowed once. I rewrote the code in C++ and never looked back.
    - lenkite 3y ago
      From what I have observed, most advanced Rust authors don't bother with lifetimes at all. Every pointer becomes an integer index into some slice and they mostly skip the lifetime/borrow checking. Lifetime are only kept on the few, easy-to-reason about cases. Kind of funny actually.

tcmart14 3y ago

I'm not sure if Rust is a good comparison though. Rust is a lot closer to C, it is a language influenced by C, and current popular programming languages tend to also be influenced by C. So while there is a lot different with Rust, a lot of knowledge from, lets say, a C developer can carry over. Say your a C developer, or C++ developer and I am a Rust developer trying to sell you on Rust. You have to learn a new language. No way around it. Even though people may have problems with this statement, at a high level it is close enough, I can sell you on Rust probably by saying, 'it C/C++ with better (subjective) or more modern features and extra constraints (think borrow checker) to guarantee memory safety.' I would not be able to make that same argument with LISP. The next question could be why this could be true, or more importantly, why are so many people using C-like languages. I'd probably place it on portability and UNIX from when C emerged. And LISP machines died. In other words, I don't think it would be appropriate to try to draw a comparison between the two with the two of them in a vacuum. If LISP machines survived and were popular today, we could see Rust today having the same popularity of LISP today.

shrimp_emoji 3y ago
I'd argue Lisps are worse today. They encourage a thing that's generally discouraged in C: macro programming and typedefs. You're coding in Lisp, but you're actually coding in your own dialect of Lisp, eventually, with lots of idiosyncratic code that's difficult to reason about. That doesn't scale well in collaborative environments, where many people are touching a vast codebase (which I don't think was really a thing back in the '70s). That's when you want the uniformity and clarity of static type declarations and C++'s <algorithm> header functions. With Rust, you're just adding modernity and safety on top of that. Great! Lisp is crazy lone wizard shit.
- tcmart14 3y ago
  That is the biggest problem I have with LISP which is why I think a lot of it is historical to some degree. I do like LISP to dabble in, but yea, there are tons of different dialects, it makes it harder to approach. Because while there is 'Common' LISP, there are implementations that can vary slightly between compilers, which compiler do you use? And some of the more popular compilers are sort of dead? There is SBCL, which does get some development, but not much I think? I don't think newer version of SBCL run on most of the BSDs? And yea, you also end up creating your own dialect in the process. Which some of those same problems could have occurred in C at some point, but C eventually converged. I can be confident my fairly simple C programs will compile just fine whether I use GCC/Clang/TCC, etc. If LISP could have converged like C did, it could be a completely different story, I wonder.
  - tmtvl 3y ago
    > There is SBCL, which does get some development, but not much I think? Quoth the website*: > New SBCL versions are usually released at the end of each month Also, the only BSD which has even in the single digits of market share, Darwin, is only 1 point release behind. * <https://sbcl.org/all-news.html https://sbcl.org/all-news.html>
    - samatman 3y ago
      Half of the phones in the US run BSD. Good luck getting SBCL on it though.
      - tcmart14 3y ago
        The 'BSD' on phones would be iOS and tons of languages don't mostly due to the platform. I think a better example would be, the amount of embedded/appliances that ship forks of FreeBSD, OpenBSD, or NetBSD. Think of like routers. While Linux is the 1,000 pound gorilla in server space, there is still A LOT of BSD servers also. The person dimising BSD usage is only taking into account desktop share not realizing some OSs run on more than just consumer devices.

dmz73 3y ago

I find that borrow checked in Rust is the easiest part of the language to get used to. Lifetimes on the other hand seem unnecessary in 99% cases where compiler forces you to use them - why can't it just assume that all the required parts have the 'a and complain if something violates that? Event bigger issue is all the missing features that most other languages have - overloaded functions (they kind of exist in generics), ranged integers, arrays indexed by enums, full support for type aliases, some level of inheritance, even if it was the go style, would make Rust much much easier to use.

samatman 3y ago
> Lifetimes on the other hand seem unnecessary in 99% cases where compiler forces you to use them - why can't it just assume that all the required parts have the 'a and complain if something violates that? Rust does that, this is lifetime elision. If the compiler complains about missing lifetime annotations, that means it can't infer the lifetime. Granted that it not-infrequently feels like it should be able to, and there's definitely room for improvement on its lifetime inference. It's conservative, meaning that an elided lifetime will always be valid, but some lifetimes which could be elided get missed by inference and need to be added anyway. But most of the times that I've yelled at the compiler for complaining about missing lifetimes, it was right and I was wrong.
- jpc0 3y ago
  To the contrary I ran into cases pretty quickly that rust just wasn't useful for in my opinion. One of my use cases was something like a mutable borrow of an struct in a struct in a single threaded code path wasn't allowed because the entire struct was mutably borrowed or some nonsense. I believe the "idiomatic" way was to create some weird abstraction to appease the borrow checker that the thing being borrowed once is only being borrowed once. I rewrote the code in C++ and never looked back.
  - lenkite 3y ago
    From what I have observed, most advanced Rust authors don't bother with lifetimes at all. Every pointer becomes an integer index into some slice and they mostly skip the lifetime/borrow checking. Lifetime are only kept on the few, easy-to-reason about cases. Kind of funny actually.