5 ms·

>not just tar it by association with C++. To build on this and your last paragraph: I think it's arguably a feature of Rust that it combines: - A syntax that'

>not just tar it by association with C++. To build on this and your last paragraph: I think it's arguably a feature of Rust that it combines: - A syntax that's highly familiar to the legions of C++ programmers already out there - A bunch of features C++ has had in the works but that aren't quite there yet (specifically, a proper module system comes to mind) - Features from ML/OCaml/Haskell, like a first-class option type, first-class (powerful) pattern matching, and an emphasis on immutable-by-default variables Having this without the cruft of the decades of backwards-compatibility that C++ has had (not without good reason, granted) makes Rust the hard refresh of C++ that I and hopefully others have been waiting for for a while.

Const-me 6y ago
.NET has these features for decades. It compiles really fast, much easier to use than C++, and has awesome IDEs. C interop is pretty much same as in Rust. GC is not an issue in modern .NET even for resource-demanding apps running on slow ARM CPUs. Here's an example: https://github.com/Const-me/Vrmac/tree/master/VrmacVideo https://github.com/Const-me/Vrmac/tree/master/VrmacVideo BTW it consumes non-trivial amount of C APIs like V4L2, ALSA, and audio decoders.
- verandaguy 6y ago
  The reasons .NET never really competed with C# for the longest time were a handful: - First-party support for .NET only existed on Windows systems until 2015ish with the release of Rosetta - Third party support across platforms via Mono never really picked up steam for a number of reasons - Early on, .NET code, much like JVM code, wasn't in the same league as C++ in terms of performance - I'd like to be proven wrong on this one, but .NET remains a poor framework to do systems programming in. GC is IMO still a factor because even though modern M&S GCs are impressively performant they still add a degree of unpredictability to your runtime, and sometimes that's not acceptable — so reference counting or something even more basic is preferred, if only for the consistency.
  - Const-me 6y ago
    > .NET remains a poor framework to do systems programming in Have you clicked that link? Essentially, I’ve re-implemented parts of ffmpeg’s libavformat and libavcodec in C#. On Raspberry Pi, the software uses 15% of CPU time while playing 12 mbit/sec 1080p video, on par with VLC, while using 20% less RAM than VLC. If that’s not a system programming, then what is? BTW, I don’t think I allocate any objects on heap while playing the video, therefore no GC is involved, and no degree of unpredictability is introduced. Wasn’t hard at all, just recycling buffers between frames.
    - roca 6y ago
      Object recycling often works fine to avoid GC issues for simple stuff, but in more complicated applications you really do need to dynamically allocate and free memory and GC is going to get involved.
      - Const-me 6y ago
        > for simple stuff, but in more complicated applications Media engine part of the library has 45k lines of code, this is mostly due to the complexity of V4L2 API, and of the MKV and Mpeg4 containers. I wouldn’t call that “simple stuff”. > you really do need to dynamically allocate and free memory Memory allocation in .NET ain’t limited to GC. First of all there’s stack. I use Spans + stackalloc in quite a few places there. Modern .NET even has these `ref structs` where the compiler guarantees they are never accidentally boxed into the heap. Another thing, no one stops you from using malloc/free, like I did in that class: https://github.com/Const-me/Vrmac/blob/master/VrmacVideo/Audio/Queues.cs https://github.com/Const-me/Vrmac/blob/master/VrmacVideo/Aud... Finally, the mere presence of GC doesn’t affect performance in any way, only usage of GC does. Even for latency-sensitive applications like that media engine it’s OK to allocate stuff on managed heap, as long as it only happens on startup, or otherwise rarely. I allocate quite a lot of stuff on the heap, megabytes, when opening a media file.

Const-me 6y ago

.NET has these features for decades. It compiles really fast, much easier to use than C++, and has awesome IDEs. C interop is pretty much same as in Rust. GC is not an issue in modern .NET even for resource-demanding apps running on slow ARM CPUs. Here's an example: https://github.com/Const-me/Vrmac/tree/master/VrmacVideo https://github.com/Const-me/Vrmac/tree/master/VrmacVideo BTW it consumes non-trivial amount of C APIs like V4L2, ALSA, and audio decoders.

verandaguy 6y ago
The reasons .NET never really competed with C# for the longest time were a handful: - First-party support for .NET only existed on Windows systems until 2015ish with the release of Rosetta - Third party support across platforms via Mono never really picked up steam for a number of reasons - Early on, .NET code, much like JVM code, wasn't in the same league as C++ in terms of performance - I'd like to be proven wrong on this one, but .NET remains a poor framework to do systems programming in. GC is IMO still a factor because even though modern M&S GCs are impressively performant they still add a degree of unpredictability to your runtime, and sometimes that's not acceptable — so reference counting or something even more basic is preferred, if only for the consistency.
- Const-me 6y ago
  > .NET remains a poor framework to do systems programming in Have you clicked that link? Essentially, I’ve re-implemented parts of ffmpeg’s libavformat and libavcodec in C#. On Raspberry Pi, the software uses 15% of CPU time while playing 12 mbit/sec 1080p video, on par with VLC, while using 20% less RAM than VLC. If that’s not a system programming, then what is? BTW, I don’t think I allocate any objects on heap while playing the video, therefore no GC is involved, and no degree of unpredictability is introduced. Wasn’t hard at all, just recycling buffers between frames.
  - roca 6y ago
    Object recycling often works fine to avoid GC issues for simple stuff, but in more complicated applications you really do need to dynamically allocate and free memory and GC is going to get involved.
    - Const-me 6y ago
      > for simple stuff, but in more complicated applications Media engine part of the library has 45k lines of code, this is mostly due to the complexity of V4L2 API, and of the MKV and Mpeg4 containers. I wouldn’t call that “simple stuff”. > you really do need to dynamically allocate and free memory Memory allocation in .NET ain’t limited to GC. First of all there’s stack. I use Spans + stackalloc in quite a few places there. Modern .NET even has these `ref structs` where the compiler guarantees they are never accidentally boxed into the heap. Another thing, no one stops you from using malloc/free, like I did in that class: https://github.com/Const-me/Vrmac/blob/master/VrmacVideo/Audio/Queues.cs https://github.com/Const-me/Vrmac/blob/master/VrmacVideo/Aud... Finally, the mere presence of GC doesn’t affect performance in any way, only usage of GC does. Even for latency-sensitive applications like that media engine it’s OK to allocate stuff on managed heap, as long as it only happens on startup, or otherwise rarely. I allocate quite a lot of stuff on the heap, megabytes, when opening a media file.