4 ms·

This is a good rundown of the pain of rust development. I had imagined that I'd reach a nirvana of rust dev where I could just write the code and feel like I kn

by lumost 2y ago

This is a good rundown of the pain of rust development. I had imagined that I'd reach a nirvana of rust dev where I could just write the code and feel like I knew what I was doing. This ultimately never happened after N learning attempts and M side projects. A nascent startup idea died due to the time spent on rustisms. I don't doubt that some people experience this zen, and I'd take rust over c/cpp every day for a new app if that was my choice… but that's not really my only choice. The article also nails the performance topic, while rust gives you all of the insight and control over what your code is doing - its exceptionally rare that all of the libraries and modules in your program agree enough on these interfaces to not end up with memory copies everywhere.

PaulHoule 2y ago
Some people say they like C++. It's little appreciated how revolutionary the garbage collector is, in that it probably contributes more to software reuse than every other innovation put together. If you were trying to please everybody in C, for instance, a library should be able to accept a buffer from the application, or allocate a buffer using a malloc/free passed in from the application, as well as many other scenarios. For very simple libraries it is not complicated but as libraries and applications get more complex the library can never be sure if the application is done with a buffer and the application can never be sure if the library is done with it. For a framework, which calls the application, it gets worse. However, the garbage collector always knows. Memory allocation is a global problem but Rust tries to treat it as a local problem which can be solved for any particular program but gets harder and harder as programs get larger and if you want to compose a program out of independent parts it is intractable: sure you can RC all the things (no cycles!) and copy a lot but you lose many of the reasons why you gave up on the garbage collector.
- triknomeister 2y ago
  It is a local problem when you're doing HPC. Not for most business apps though I agree.
  - PaulHoule 2y ago
    FORTRAN lumbers on because its memory model is simpler than C and many other languages so it runs faster. If you write Java programs that allocate a few huge arrays and don't allocate anything after that they run pretty fast too. I wrote a Python chess program in two weekends that was good enough to beat a serious beginner but that I didn't feel I could take to the chess club because it couldn't respect time control the way it was written. I started rewriting it in Java and realized that if I wanted decent performance I had to not allocate anything in the inner loop. Transposition tables using Java hashtables are a net loser at the depths it is working at, I really gotta write something that works at the bytearray level off-heap but it's not that hard of a project because, like the typical HPC code, it's not really that complex/complicated.
    - lumost 2y ago
      This is pretty much it. When you are at HPC performance requirements, the rust pain doesn't matter too much - but... You can also get decent perf in any language by being careful about the allocations. The lack of gc provides an at most 2x benefit for a reasonably well optimized java program in this setting.
      - PaulHoule 2y ago
        Some people thought Java was the new COBOL as early as the early 2000s but it was one of the first computer languages designed and specified by adults (I'd add Common Lisp to that list, if you look at the CL spec and the Java spec you realize they are both nicely structured with none of the strange circularity that plagues The C Programming Language) Threads in Java are just great, you really can write programs that get a 14x speedup on a 16-core machine. Web servers can use threads for managing concurrency and for parallelism handling individual requests. I look at how much pain people go through with async in Rust (another global-local problem where they'll be pushing that bubble around under the rug when they give up) and contrast that to the ease of threads in Java, so long as you get to understand all the primitives that Java offers to deal with common problems and don't get seduced by the false promises of Fork-Join, Scala actors and such.

by lumost 2y ago

PaulHoule 2y ago

Some people say they like C++. It's little appreciated how revolutionary the garbage collector is, in that it probably contributes more to software reuse than every other innovation put together. If you were trying to please everybody in C, for instance, a library should be able to accept a buffer from the application, or allocate a buffer using a malloc/free passed in from the application, as well as many other scenarios. For very simple libraries it is not complicated but as libraries and applications get more complex the library can never be sure if the application is done with a buffer and the application can never be sure if the library is done with it. For a framework, which calls the application, it gets worse. However, the garbage collector always knows. Memory allocation is a global problem but Rust tries to treat it as a local problem which can be solved for any particular program but gets harder and harder as programs get larger and if you want to compose a program out of independent parts it is intractable: sure you can RC all the things (no cycles!) and copy a lot but you lose many of the reasons why you gave up on the garbage collector.

triknomeister 2y ago
It is a local problem when you're doing HPC. Not for most business apps though I agree.
- PaulHoule 2y ago
  FORTRAN lumbers on because its memory model is simpler than C and many other languages so it runs faster. If you write Java programs that allocate a few huge arrays and don't allocate anything after that they run pretty fast too. I wrote a Python chess program in two weekends that was good enough to beat a serious beginner but that I didn't feel I could take to the chess club because it couldn't respect time control the way it was written. I started rewriting it in Java and realized that if I wanted decent performance I had to not allocate anything in the inner loop. Transposition tables using Java hashtables are a net loser at the depths it is working at, I really gotta write something that works at the bytearray level off-heap but it's not that hard of a project because, like the typical HPC code, it's not really that complex/complicated.
  - lumost 2y ago
    This is pretty much it. When you are at HPC performance requirements, the rust pain doesn't matter too much - but... You can also get decent perf in any language by being careful about the allocations. The lack of gc provides an at most 2x benefit for a reasonably well optimized java program in this setting.
    - PaulHoule 2y ago
      Some people thought Java was the new COBOL as early as the early 2000s but it was one of the first computer languages designed and specified by adults (I'd add Common Lisp to that list, if you look at the CL spec and the Java spec you realize they are both nicely structured with none of the strange circularity that plagues The C Programming Language) Threads in Java are just great, you really can write programs that get a 14x speedup on a 16-core machine. Web servers can use threads for managing concurrency and for parallelism handling individual requests. I look at how much pain people go through with async in Rust (another global-local problem where they'll be pushing that bubble around under the rug when they give up) and contrast that to the ease of threads in Java, so long as you get to understand all the primitives that Java offers to deal with common problems and don't get seduced by the false promises of Fork-Join, Scala actors and such.