4 ms·

> On a side note, I can't help feeling sorry for the people that advocate for C over C++ when I see commits like https://github.com/wasm3/wasm3/commit/121575feb

> On a side note, I can't help feeling sorry for the people that advocate for C over C++ when I see commits like https://github.com/wasm3/wasm3/commit/121575febe8aa1b544fbcb https://github.com/wasm3/wasm3/commit/121575febe8aa1b544fbcb... To be fair, I/O is a place where C++ really dropped the ball, too. The <iostream> part of the C++ library is unfortunately a complete mess. This is not really a “win” for C++ as much as it is a failure for both languages. I think it is hard to advocate for either C or C++, for greenfield projects, these days.

SolarNet 3y ago
I mean you can just not use iostream? A lot of modern C++ projects just ignore it. For either C style IO or more C++ -y IO.
- klodolph 3y ago
  Yeah, but you can equally ignore fgetc and friends in C. My only point here is that IO in the standard library is not very good in either language. IMO a parser should be reading the entire file, and then parsing as a block of memory, by default, for most use cases these days. That way you don’t have to think about IO while you are parsing. Streaming parsers are niche these days for good reasons.
knorker 3y ago
C++20 improves the situation, though. https://en.cppreference.com/w/cpp/utility/format/format https://en.cppreference.com/w/cpp/utility/format/format But yes, in a world where Rust exists, I don't see a need for C or C++ for greenfield.
- pjmlp 3y ago
  There are plenty of greenfield use cases where Rust will need to bind to existing C and C++ libraries.
  - knorker 3y ago
    I guess the field I was imagining was greener than that. But yes. In many cases you can just interface to the C libraries. But cross language coding has never been perfect, and yes, sometimes it's better to continue using the same language. It's not hard to write an RAII wrapper around a C library, and the careful allocate/free is code you have to write either way (e.g. I'd write a wrapper in C++ if I need to use a C library with resource handling). C is the easiest to interface with. Every language has to be C-compatible. I would not choose C or C++ just because I depend on libfftw, or simdjson, or most other things. If the code that needs to talk to the library is less than 10% of the total program (exact percentage just made up), then I'd still use Rust.
    - galangalalgol 3y ago
      So many of the CVEs against rust crates are actually against the bindings for things like ssl, glibc, and libcurl. I think accepting small growing subsets of ssl and curl for native implementation would be a good idea. And relibc too I suppose. Go went this route, and while it caused some headaches porting to new kernels, it has lots of benefits too.
      - pjmlp 3y ago
        Go has had to rollback on that decision. Rust while much safer, also needs care if any crate makes use of unsafe, even in pure Rust. https://thesquareplanet.com/blog/the-story-of-a-rust-bug/ https://thesquareplanet.com/blog/the-story-of-a-rust-bug/ Yes it is in the libc bindings, but the logic error is on Rust side.
        galangalalgol 3y ago
        That story seems to be about missing code/functionality, more than anything about a vulnerability. There is way more unsafe out there than there should be. Bindings are are one of the very few cases that must have it.
    - pjmlp 3y ago

SolarNet 3y ago

I mean you can just not use iostream? A lot of modern C++ projects just ignore it. For either C style IO or more C++ -y IO.

klodolph 3y ago
Yeah, but you can equally ignore fgetc and friends in C. My only point here is that IO in the standard library is not very good in either language. IMO a parser should be reading the entire file, and then parsing as a block of memory, by default, for most use cases these days. That way you don’t have to think about IO while you are parsing. Streaming parsers are niche these days for good reasons.

knorker 3y ago

C++20 improves the situation, though. https://en.cppreference.com/w/cpp/utility/format/format https://en.cppreference.com/w/cpp/utility/format/format But yes, in a world where Rust exists, I don't see a need for C or C++ for greenfield.

pjmlp 3y ago
There are plenty of greenfield use cases where Rust will need to bind to existing C and C++ libraries.
- knorker 3y ago
  I guess the field I was imagining was greener than that. But yes. In many cases you can just interface to the C libraries. But cross language coding has never been perfect, and yes, sometimes it's better to continue using the same language. It's not hard to write an RAII wrapper around a C library, and the careful allocate/free is code you have to write either way (e.g. I'd write a wrapper in C++ if I need to use a C library with resource handling). C is the easiest to interface with. Every language has to be C-compatible. I would not choose C or C++ just because I depend on libfftw, or simdjson, or most other things. If the code that needs to talk to the library is less than 10% of the total program (exact percentage just made up), then I'd still use Rust.
  - galangalalgol 3y ago
    So many of the CVEs against rust crates are actually against the bindings for things like ssl, glibc, and libcurl. I think accepting small growing subsets of ssl and curl for native implementation would be a good idea. And relibc too I suppose. Go went this route, and while it caused some headaches porting to new kernels, it has lots of benefits too.
    - pjmlp 3y ago
      Go has had to rollback on that decision. Rust while much safer, also needs care if any crate makes use of unsafe, even in pure Rust. https://thesquareplanet.com/blog/the-story-of-a-rust-bug/ https://thesquareplanet.com/blog/the-story-of-a-rust-bug/ Yes it is in the libc bindings, but the logic error is on Rust side.
      - galangalalgol 3y ago
        That story seems to be about missing code/functionality, more than anything about a vulnerability. There is way more unsafe out there than there should be. Bindings are are one of the very few cases that must have it.
  - pjmlp 3y ago