6 ms·

Rust is not a GC language. It can and does achieve the same perf as any modem C++ with the latest flavor of the C++ safety guardrails. The set of reasons to st

by kiratp 3y ago

Rust is not a GC language. It can and does achieve the same perf as any modem C++ with the latest flavor of the C++ safety guardrails. The set of reasons to start a new project in C/C++ are few and the list is shrinking by the day.

overgard 3y ago
I phrased it poorly, I didn't mean to imply Rust is GC'd. I mean that it's still niche. C++ very much is not niche, which is my point. The other non-niche languages generally are GC'd (java, C#, javascript, etc.) > The set of reasons to start a new project in C/C++ are few and the list is shrinking by the day. That'd be true if every project started from scratch with only the language standard library. And yet..... almost any project you start is going to be dependent on a large chunk of code you didn't write, even on greenfield projects.
- haberman 3y ago
  > That'd be true if every project started from scratch with only the language standard library. And yet..... almost any project you start is going to be dependent on a large chunk of code you didn't write, even on greenfield projects. I think this is true, and I'd refine my original statement accordingly. My original comment was thinking more from first principles, not as much about pragmatic considerations of ecosystem support. If we were to disregard the momentum of existing ecosystems, I think C/C++ would be niche choices today: very important for certain, focused use cases, but not meant for the masses. Taking into account the momentum of existing ecosystems however, they still play a large role in many domains.
MarkMarine 3y ago
I love Rust, but as a daily C++ user (embedded microcontrollers, not supported by Rust yet, and then native Linux tooling to interface with them) what I find most frustrating about Rust is the number of crates that need to be knit together to make working software. Often these crates are from a single dev who last committed in 2020 or something. I really wish there was something like go’s standard library in Rust. That has been my barrier to adoption, and believe me I WANT to use it at work and I don’t want to juggle chainsaws anymore.
- Ar-Curunir 3y ago
  Er how is that different from C++? It doesn't have a go-like std library either, and you can totally use Rust without crates.io in the same manner.
  - xedrac 3y ago
    In C++, you'll often see projects just use boost, which is a big monolith of useful libraries.
    - tumdum_ 3y ago
      Embedded microcontrollers are not the place where boost is used.
      - oasisaimlessly 3y ago
        Counterpoint: I use Boost on embedded microcontrollers. (Albeit only header-only components of Boost.)
  - MarkMarine 3y ago
    I suppose that wasn’t clear. My mistake. I use C/C++ for micro controller code every day, because Rust doesn’t support my microcontroller, doesn’t have a real RTOS, and I’m making real hardware. Something that needs to run in the field for 10+ years and I can’t get out there and ensure it’s updated, and my company doesn’t want to invest millions of dollars on beta testing embedded rust on. So embedded is out for now but I’m looking forward to when it’s supported fully and out of beta. Most embedded controllers come with some RTOS and libraries they support, written in C. For tooling, I can context switch out of C++ which does have boost, into [rust, go, python… etc] and deal with that switch, or just be lazy and write it in C++. I’ve tried to write three tools in Rust so far, and the pain of not having a good stdlib, of essentially searching the internet for a blog post that solves my issue then finding the blog post was written by one dev 4 years ago to pump up their library that was written 4 years ago and then never supported after that… it’s a bit exhausting. Again, before ya’ll attack. This is from the perspective of a willing, excited customer. I want to use Rust at work and advocate for it. Just saying, it’s not easy in the state it’s in.
bayindirh 3y ago
However, Rust doesn't have a "I know what I'm doing, let me be" switch. No, "unsafe" is not that. I have a couple of languages in my belt C, C++, Go, Python, Java are the primary ones. C and C++ are reserved for "power use". For power use, I mean scientific, HPC stuff or any code I need the full capacity of the processor. To get that, sometimes you need -ffmast-math, sometimes said undefined behavior, or code patterns which translate to better code for the processor you target. Rust doesn't allow any of that, moreover limits me the way I can write my programs, no thanks. For security-sensitive compiled code, I can use Rust, but I can't use Rust anywhere, and everywhere. It also has its niche, and it can't and won't replace C or C++ at the end of the day. It'll get its slice (which might be sizeable), a couple of compiler implementations, and will evolve to become another mainstream , boring language, which is good. Also, if you give half an effort, C++ is pretty secure and robust to begin with, esp. on the pointers department. Just be mindful, and run a couple of valgrind tests on your code, and you're set. Been there, done that.
- andrepd 3y ago
  In what sense does rust not expose the full power of the processor to the user? Can you give a concrete example? > Just be mindful, and run a couple of valgrind tests on your code, and you're set. Thousands of severe CVEs every year attest to the effectiveness of that mindset. "Just git gud" is not a meaningful thing to say, as even experienced devs routinely make exploitable (and other) mistakes.
  - bayindirh 3y ago
    Rust probably won’t allow me to implement a couple of lockless parallel algorithms I have implemented in my Ph.D., which are working on small matrices (3K by 3K). These algorithms allow any number of CPUs do the required processing without waiting for each other, and with no possibility of stepping on each other, by design. In the tests, it became evident that the speed of the code is limited by the memory bandwidth of the system, yet for the processors I work with that limit is also very near to practical performance limit of the FPUs, as well. I could have squeezed a bit more performance by reordering the matrices to abuse prefetcher better, but it was good enough (~30x faster than the naive implementation with better accuracy) and I had no time. Well, the method I verify the said codebase is here [0]. Also, if BSD guys can write secure code with C, everybody can. I think their buffer overflow error count is still <10 after all these years. [0]: https://news.ycombinator.com/item?id=31218757 https://news.ycombinator.com/item?id=31218757
deterministic 3y ago
New large scale C++ projects are started every single day. There are more than 5 million C++ programmers out there. Compared with that Rust is but a drop in the ocean.

by kiratp 3y ago

overgard 3y ago

I phrased it poorly, I didn't mean to imply Rust is GC'd. I mean that it's still niche. C++ very much is not niche, which is my point. The other non-niche languages generally are GC'd (java, C#, javascript, etc.) > The set of reasons to start a new project in C/C++ are few and the list is shrinking by the day. That'd be true if every project started from scratch with only the language standard library. And yet..... almost any project you start is going to be dependent on a large chunk of code you didn't write, even on greenfield projects.

haberman 3y ago
> That'd be true if every project started from scratch with only the language standard library. And yet..... almost any project you start is going to be dependent on a large chunk of code you didn't write, even on greenfield projects. I think this is true, and I'd refine my original statement accordingly. My original comment was thinking more from first principles, not as much about pragmatic considerations of ecosystem support. If we were to disregard the momentum of existing ecosystems, I think C/C++ would be niche choices today: very important for certain, focused use cases, but not meant for the masses. Taking into account the momentum of existing ecosystems however, they still play a large role in many domains.

MarkMarine 3y ago

I love Rust, but as a daily C++ user (embedded microcontrollers, not supported by Rust yet, and then native Linux tooling to interface with them) what I find most frustrating about Rust is the number of crates that need to be knit together to make working software. Often these crates are from a single dev who last committed in 2020 or something. I really wish there was something like go’s standard library in Rust. That has been my barrier to adoption, and believe me I WANT to use it at work and I don’t want to juggle chainsaws anymore.

Ar-Curunir 3y ago
Er how is that different from C++? It doesn't have a go-like std library either, and you can totally use Rust without crates.io in the same manner.
- xedrac 3y ago
  In C++, you'll often see projects just use boost, which is a big monolith of useful libraries.
  - tumdum_ 3y ago
    Embedded microcontrollers are not the place where boost is used.
    - oasisaimlessly 3y ago
      Counterpoint: I use Boost on embedded microcontrollers. (Albeit only header-only components of Boost.)
- MarkMarine 3y ago
  I suppose that wasn’t clear. My mistake. I use C/C++ for micro controller code every day, because Rust doesn’t support my microcontroller, doesn’t have a real RTOS, and I’m making real hardware. Something that needs to run in the field for 10+ years and I can’t get out there and ensure it’s updated, and my company doesn’t want to invest millions of dollars on beta testing embedded rust on. So embedded is out for now but I’m looking forward to when it’s supported fully and out of beta. Most embedded controllers come with some RTOS and libraries they support, written in C. For tooling, I can context switch out of C++ which does have boost, into [rust, go, python… etc] and deal with that switch, or just be lazy and write it in C++. I’ve tried to write three tools in Rust so far, and the pain of not having a good stdlib, of essentially searching the internet for a blog post that solves my issue then finding the blog post was written by one dev 4 years ago to pump up their library that was written 4 years ago and then never supported after that… it’s a bit exhausting. Again, before ya’ll attack. This is from the perspective of a willing, excited customer. I want to use Rust at work and advocate for it. Just saying, it’s not easy in the state it’s in.

bayindirh 3y ago

However, Rust doesn't have a "I know what I'm doing, let me be" switch. No, "unsafe" is not that. I have a couple of languages in my belt C, C++, Go, Python, Java are the primary ones. C and C++ are reserved for "power use". For power use, I mean scientific, HPC stuff or any code I need the full capacity of the processor. To get that, sometimes you need -ffmast-math, sometimes said undefined behavior, or code patterns which translate to better code for the processor you target. Rust doesn't allow any of that, moreover limits me the way I can write my programs, no thanks. For security-sensitive compiled code, I can use Rust, but I can't use Rust anywhere, and everywhere. It also has its niche, and it can't and won't replace C or C++ at the end of the day. It'll get its slice (which might be sizeable), a couple of compiler implementations, and will evolve to become another mainstream , boring language, which is good. Also, if you give half an effort, C++ is pretty secure and robust to begin with, esp. on the pointers department. Just be mindful, and run a couple of valgrind tests on your code, and you're set. Been there, done that.

andrepd 3y ago
In what sense does rust not expose the full power of the processor to the user? Can you give a concrete example? > Just be mindful, and run a couple of valgrind tests on your code, and you're set. Thousands of severe CVEs every year attest to the effectiveness of that mindset. "Just git gud" is not a meaningful thing to say, as even experienced devs routinely make exploitable (and other) mistakes.
- bayindirh 3y ago
  Rust probably won’t allow me to implement a couple of lockless parallel algorithms I have implemented in my Ph.D., which are working on small matrices (3K by 3K). These algorithms allow any number of CPUs do the required processing without waiting for each other, and with no possibility of stepping on each other, by design. In the tests, it became evident that the speed of the code is limited by the memory bandwidth of the system, yet for the processors I work with that limit is also very near to practical performance limit of the FPUs, as well. I could have squeezed a bit more performance by reordering the matrices to abuse prefetcher better, but it was good enough (~30x faster than the naive implementation with better accuracy) and I had no time. Well, the method I verify the said codebase is here [0]. Also, if BSD guys can write secure code with C, everybody can. I think their buffer overflow error count is still <10 after all these years. [0]: https://news.ycombinator.com/item?id=31218757 https://news.ycombinator.com/item?id=31218757

deterministic 3y ago

New large scale C++ projects are started every single day. There are more than 5 million C++ programmers out there. Compared with that Rust is but a drop in the ocean.