4 ms·

Should have named it Steele since it's dragging Rust users half-way to Lisp :).

by ghc 3y ago

wolverine876 3y ago
Yes! I just posted https://news.ycombinator.com/item?id=38510054 https://news.ycombinator.com/item?id=38510054
bitwize 3y ago
Why would you want to do that? Lisp is dynamically typed and has a GC.
- Jtsummers 3y ago
  It's a joke that you seem to have missed. > We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp. Guy Steele on Java
  - bitwize 3y ago
    I'm familiar with the Steele quote. The manner in which C++ programmers were "dragged halfway to Lisp" concerns primarily manual memory management and all the bugginess attending thereto (Java came out before the STL and smart pointers were widely adopted). Concerns about memory safety were a significant part of the impetus for developing Java in the first place. Steele was responding to complaints that he had turned his back on Lisp, by countering that he was instead bringing the C++ crowd closer to Lisp with a C++-like language that had Lisp-like memory management. But the reason why Rust is such revolutionary computer science and, quite possibly, the most interesting thing to happen to PL design in decades is because with safe Rust you get all the memory-safety advantages of Java or Lisp, without a GC because the borrow checker statically guarantees object lifetimes. So Rust programmers don't need to be dragged halfway to Lisp the way C++ programmers were in the mid-90s, because Rust has the same memory-safety guarantees with none of the drawbacks of GC.
    - zozbot234 3y ago
      > with safe Rust you get all the memory-safety advantages of Java or Lisp, without a GC Safe Rust does not protect against memory/resource leaks when reference cycles are present. To avoid those, tracing GC is still needed - and most likely unavoidable in the general case. Note that avoiding reference cycles is a global concern that can't be localized to any single part of the program, so trying to ensure this statically is roughly as hard as proving that a random piece of C/C++ code does not corrupt memory. You can of course stick to tree-like allocation patterns where object lifecycles nest cleanly, and that's what the borrow checker is all about. You can also use arenas/regions, and future Rust versions will hopefully make those easier to use.
    - throwaway2037 3y ago
      Java came out before the STL and smart pointers were widely adopted. This is a strange comment. Java 1.0 was released in Jan 1996. (Java wasn't very useful before 1.1) However, Stepanov proposed STL to ANSI/ISO committee in Nov 1993, and HP released a working version to the Internet in Aug 1994. "[W]idely adopted" is an editorial term. It is meaningless without some backing evidence. ("Never been worse" has a similar sentiment.) How do determine what counts? I worked on enterprise C++ for years in the mid-2000s that didn't use any smart pointers. There are many huge, old enterprise C++ projects that don't use STL or smart pointers. And, there are still many huge old Java enterprise projects that use shitty cast-from-Object-type to pass around typed data, instead of generics, or something better. Not much being said here! the most interesting thing to happen to PL design in decades "[D]ecades" is a wild overstatement. In the last 10 years, I would vote for LLVM, which greatly improved the velocity of (experimental) programming language development. Would Rust have developed so quickly without LLVM? Probably not. Look at the speed of development in Rust, Swift, Zig, and many others that use LLVM as their backend. It is night-and-day compared to 20 years ago in a GCC-only open source compiler world. I remember the bad old days where GCC was the elephant in the room, but so hard to add and maintain frontends, that few did it. Rust has the same memory-safety guarantees with none of the drawbacks of GC I never saw this before. Are there any counterpoints?
      - ColonelPhantom 3y ago
- trealira 3y ago
  Cases when you might prefer a garbage collected programming language rather than Rust: - When garbage collection is the optimal or near optimal memory allocation pattern for your program. - When you care less about minimizing memory usage than minimizing implementation complexity, development speed, and compile time speed. - When your program deals with cyclic data structures. - When you want green threads (like Goroutines) I can say that I would rather use Lisp to write any program that manipulates tree or graph structures simply because it has a garbage collector.

Should have named it Steele since it's dragging Rust users half-way to Lisp :).

by ghc 3y ago

Should have named it Steele since it's dragging Rust users half-way to Lisp :).

wolverine876 3y ago

Yes! I just posted https://news.ycombinator.com/item?id=38510054 https://news.ycombinator.com/item?id=38510054

bitwize 3y ago

Why would you want to do that? Lisp is dynamically typed and has a GC.

Jtsummers 3y ago
It's a joke that you seem to have missed. > We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp. Guy Steele on Java
- bitwize 3y ago
  I'm familiar with the Steele quote. The manner in which C++ programmers were "dragged halfway to Lisp" concerns primarily manual memory management and all the bugginess attending thereto (Java came out before the STL and smart pointers were widely adopted). Concerns about memory safety were a significant part of the impetus for developing Java in the first place. Steele was responding to complaints that he had turned his back on Lisp, by countering that he was instead bringing the C++ crowd closer to Lisp with a C++-like language that had Lisp-like memory management. But the reason why Rust is such revolutionary computer science and, quite possibly, the most interesting thing to happen to PL design in decades is because with safe Rust you get all the memory-safety advantages of Java or Lisp, without a GC because the borrow checker statically guarantees object lifetimes. So Rust programmers don't need to be dragged halfway to Lisp the way C++ programmers were in the mid-90s, because Rust has the same memory-safety guarantees with none of the drawbacks of GC.
  - zozbot234 3y ago
    > with safe Rust you get all the memory-safety advantages of Java or Lisp, without a GC Safe Rust does not protect against memory/resource leaks when reference cycles are present. To avoid those, tracing GC is still needed - and most likely unavoidable in the general case. Note that avoiding reference cycles is a global concern that can't be localized to any single part of the program, so trying to ensure this statically is roughly as hard as proving that a random piece of C/C++ code does not corrupt memory. You can of course stick to tree-like allocation patterns where object lifecycles nest cleanly, and that's what the borrow checker is all about. You can also use arenas/regions, and future Rust versions will hopefully make those easier to use.
  - throwaway2037 3y ago
    Java came out before the STL and smart pointers were widely adopted. This is a strange comment. Java 1.0 was released in Jan 1996. (Java wasn't very useful before 1.1) However, Stepanov proposed STL to ANSI/ISO committee in Nov 1993, and HP released a working version to the Internet in Aug 1994. "[W]idely adopted" is an editorial term. It is meaningless without some backing evidence. ("Never been worse" has a similar sentiment.) How do determine what counts? I worked on enterprise C++ for years in the mid-2000s that didn't use any smart pointers. There are many huge, old enterprise C++ projects that don't use STL or smart pointers. And, there are still many huge old Java enterprise projects that use shitty cast-from-Object-type to pass around typed data, instead of generics, or something better. Not much being said here! the most interesting thing to happen to PL design in decades "[D]ecades" is a wild overstatement. In the last 10 years, I would vote for LLVM, which greatly improved the velocity of (experimental) programming language development. Would Rust have developed so quickly without LLVM? Probably not. Look at the speed of development in Rust, Swift, Zig, and many others that use LLVM as their backend. It is night-and-day compared to 20 years ago in a GCC-only open source compiler world. I remember the bad old days where GCC was the elephant in the room, but so hard to add and maintain frontends, that few did it. Rust has the same memory-safety guarantees with none of the drawbacks of GC I never saw this before. Are there any counterpoints?
    - ColonelPhantom 3y ago
trealira 3y ago
Cases when you might prefer a garbage collected programming language rather than Rust: - When garbage collection is the optimal or near optimal memory allocation pattern for your program. - When you care less about minimizing memory usage than minimizing implementation complexity, development speed, and compile time speed. - When your program deals with cyclic data structures. - When you want green threads (like Goroutines) I can say that I would rather use Lisp to write any program that manipulates tree or graph structures simply because it has a garbage collector.