6 ms·

I think people want a language with C performance and are willing to sacrifice effort but not safety. Pouring effort into C++ does not guarantee safety. I thi

by jayd16 6y ago

I think people want a language with C performance and are willing to sacrifice effort but not safety. Pouring effort into C++ does not guarantee safety. I think that's why something like Rust is desired.

Const-me 6y ago
> Pouring effort into C++ does not guarantee safety. Indeed, but porting to C# does. For many practical applications, modern C# is already a language with C performance. The only large area where C# lags behind is SIMD. They made a good progress in .NET 3 and 5, but still somewhat worse than C/C++ with intrinsics. Here’s a library which implements media player component for ARM Linux: https://github.com/Const-me/Vrmac/tree/master/VrmacVideo#performance https://github.com/Const-me/Vrmac/tree/master/VrmacVideo#per... It calls native code to present decoded video frames with GLES, and decode audio with third-party DLLs. Also consumes kernel C APIs like V4L2, ALSA, message queues from librt.so, and a few things from libc.so. Everything else is in C#: file I/O, containers parsing, decoders configuration, multithreading, buffering, A/V sync. The performance is same as VLC player which is written in C.
- wffurr 6y ago
  C# ties you to CLR and is also garbage collected by default. That’s very different from C++ and Rust both.
  - Const-me 6y ago
    > C# ties you to CLR C++ and Rust have runtimes as well. For C++ that’s normally a DLL like libstdc++ or msvcrt. CLR is larger but still reasonable, for 64-bit Windows VC_redist.x64.exe is 14 MB, dotnet-runtime-3.1.13-win-x64.exe is 25 MB. > and is also garbage collected by default By default yes, but that’s avoidable. Modern .NET with their spans, value tuples, ref structs, ArrayPool, etc., make it relatively easy to write C# code which doesn’t allocate much. Or even at all, as you can see on the link in my previous comment.
    - pianoben 6y ago
      I strongly disagree. The vast majority of extant .NET APIs encourage or require allocating memory dynamically, thereby requiring GC. Sure, if you rewrite everything that isn't already defined in terms of `Memory` or `Span`, you can do it, but that's a _tall_ order. Even supposing you still mange to write a whole program that doesn't allocate dynamic memory, or that quickly stabilizes around a finite `ArrayPool`. You're still pulling in all the runtime GC machinery. Further, the minute someone _else_ contributes code, you run the risk of allocating again. As much as I love C#, _this isn't its niche_.
      - Const-me 6y ago
        > vast majority of extant .NET APIs encourage or require allocating memory dynamically A lot of APIs in modern .NET already supports spans. They can be backed by anything, not just GC-managed memory. For that project, some of these spans are backed by the memory mapped by V4L2 or ALSA API calls. Others are backed by unmanaged buffers allocated on startup with Marshal.AllocHGlobal. For small temporary stuff I use stackalloc, e.g. both mp4 and mkv use tons of variable-length encoded integers. > the minute someone _else_ contributes code, you run the risk of allocating again. Good point. On the other hand, someone else contributing code can introduce any bugs at all, not just GC-related performance issues. > As much as I love C#, _this isn't its niche_. A while ago some people were saying the same about C, and were instead coding assembly :-)
    - jayd16 6y ago
      Relevant to the topic, annoyingly, you still can't cancel a task without a ton of garbage.
      - Const-me 6y ago
        You can easily forget pending tasks. That’s a single line of code like this: task.ContinueWith( t => { }, TaskContinuationOptions.OnlyOnFaulted ); However, graceful cancellation is indeed hard. Doable in .NET but not easy, you gonna need to manually pass these cancellation tokens all the way down. Do you have an example of a language/runtime/etc where the cancellation's easy? It's easy to kill processes from the outside, but even for threads it's borderline impossible without horrible side effects.
- SAI_Peregrinus 6y ago
  Last I checked STM32 microcontrollers can't run .Net, and thus can't use C#. They can run Rust. Rust's embedded and OS-level capabilities are a big point in its favor, particularly over something like C#.
  - Const-me 6y ago
    Indeed, you need a reasonably capable OS kernel to use .NET runtime. And enough RAM. And I wouldn’t want .NET for hard realtime use cases. Even in embedded, for some products the tradeoff is good enough. A while ago I’ve shipped embedded software that uses .NET Core and runs on RK3288, worked quite well for us. BTW, do you have good experience with Rust on bare metal STM32? I would expect STM-supported C toolset and libraries to be generally better?
    - SAI_Peregrinus 6y ago
      I find the Rust embedded-hal to be quite good. STM's HAL code is a horrible inefficient mess, though their LL library isn't bad. I'd much rather use Rust's hal crates and probe-run. That said, CubeMX's configuration tool is very nice. But that's used (hopefully) once at board bringup and never again, so not worth sticking with C for.
  - pjmlp 6y ago
    Depends, .NET => https://www.wildernesslabs.co/hardware https://www.wildernesslabs.co/hardware Oberon => https://www.astrobe.com/boards.htm https://www.astrobe.com/boards.htm Java https://www.microej.com/ https://www.microej.com/ https://www.aicas.com/wp/ https://www.aicas.com/wp/ https://www.ptc.com/en/products/developer-tools/perc https://www.ptc.com/en/products/developer-tools/perc
millstone 6y ago
I don't think safety is driving Rust's ascent. For example, WASM has more momentum with Rust than with C++. But WASM is already sandboxed, and does not support threads; so what is Rust bringing to the WASM table? I think it's a monoculture phenomenon. Rust has a website and a pitch; C++ does not. Rust has a single compiler and one way to do things; C++ is overly diverse. Rust has learned from npm, etc. and has made package management first-class with a single package manager; C++ has not. Rust is just a much more familiar experience for developers coming from other monoculture languages.
- adwn 6y ago
  > what is Rust bringing to the WASM table? Unless you have to interface with a lot of mostly-header/header-only libraries written in C or C++, Rust is just so much more productive to work with than C or C++, even if you don't have to worry about memory unsafety.
  - millstone 6y ago
    How do you find Rust to be so much more productive than C++? I find C++ more productive. In C++ I mainly fight with template error messages. In Rust, I fight with typechecked generics, inserting & and '_ here or there, adding and deleting imports, refactoring to add Some and Ok - tons of nonsense housekeeping. These features have value but are quite a slog when writing code.
    - adwn 6y ago
      Those "tons of nonsense housekeeping" help me detect and avoid bugs. Memory unsafety is not the only category of incorrect code – a bug is a bug, even if it doesn't enable an attacker to gain access to your system. Some of the kinds of bugs that are much easier to accidentally write in C++ than in Rust are: use-after-free, use-after-move, out-of-bounds array accesses, data races and other synchronization errors. I want my code to be correct, even if it runs in a sandbox.
      - millstone 6y ago
pjmlp 6y ago
Thing is, when you write Java and .NET, it is already possible to be almost C like, specially .NET given the improvements since C# 7. https://devblogs.microsoft.com/aspnet/grpc-performance-improvements-in-net-5/ https://devblogs.microsoft.com/aspnet/grpc-performance-impro... So when we dive into C++ to write a small DLL/.so to be consumed by those languages, it is basically for doing exactly the same that would be a bunch of unsafe code blocks in Rust.
- jayd16 6y ago
  Right, but the goal and promise is to get C perf in Rust _without_ the unsafe blocks. Rust may or may not make good on that goal but the idea is why people are interested.
  - pjmlp 6y ago
    I don't see how that would be possible, given that there is always unsafe at some level of the stack, even if only on the runtime implementation. Ada also has unsafe (unchecked).

by jayd16 6y ago

Const-me 6y ago

> Pouring effort into C++ does not guarantee safety. Indeed, but porting to C# does. For many practical applications, modern C# is already a language with C performance. The only large area where C# lags behind is SIMD. They made a good progress in .NET 3 and 5, but still somewhat worse than C/C++ with intrinsics. Here’s a library which implements media player component for ARM Linux: https://github.com/Const-me/Vrmac/tree/master/VrmacVideo#performance https://github.com/Const-me/Vrmac/tree/master/VrmacVideo#per... It calls native code to present decoded video frames with GLES, and decode audio with third-party DLLs. Also consumes kernel C APIs like V4L2, ALSA, message queues from librt.so, and a few things from libc.so. Everything else is in C#: file I/O, containers parsing, decoders configuration, multithreading, buffering, A/V sync. The performance is same as VLC player which is written in C.

wffurr 6y ago
C# ties you to CLR and is also garbage collected by default. That’s very different from C++ and Rust both.
- Const-me 6y ago
  > C# ties you to CLR C++ and Rust have runtimes as well. For C++ that’s normally a DLL like libstdc++ or msvcrt. CLR is larger but still reasonable, for 64-bit Windows VC_redist.x64.exe is 14 MB, dotnet-runtime-3.1.13-win-x64.exe is 25 MB. > and is also garbage collected by default By default yes, but that’s avoidable. Modern .NET with their spans, value tuples, ref structs, ArrayPool, etc., make it relatively easy to write C# code which doesn’t allocate much. Or even at all, as you can see on the link in my previous comment.
  - pianoben 6y ago
    I strongly disagree. The vast majority of extant .NET APIs encourage or require allocating memory dynamically, thereby requiring GC. Sure, if you rewrite everything that isn't already defined in terms of `Memory` or `Span`, you can do it, but that's a _tall_ order. Even supposing you still mange to write a whole program that doesn't allocate dynamic memory, or that quickly stabilizes around a finite `ArrayPool`. You're still pulling in all the runtime GC machinery. Further, the minute someone _else_ contributes code, you run the risk of allocating again. As much as I love C#, _this isn't its niche_.
    - Const-me 6y ago
      > vast majority of extant .NET APIs encourage or require allocating memory dynamically A lot of APIs in modern .NET already supports spans. They can be backed by anything, not just GC-managed memory. For that project, some of these spans are backed by the memory mapped by V4L2 or ALSA API calls. Others are backed by unmanaged buffers allocated on startup with Marshal.AllocHGlobal. For small temporary stuff I use stackalloc, e.g. both mp4 and mkv use tons of variable-length encoded integers. > the minute someone _else_ contributes code, you run the risk of allocating again. Good point. On the other hand, someone else contributing code can introduce any bugs at all, not just GC-related performance issues. > As much as I love C#, _this isn't its niche_. A while ago some people were saying the same about C, and were instead coding assembly :-)
  - jayd16 6y ago
    Relevant to the topic, annoyingly, you still can't cancel a task without a ton of garbage.
    - Const-me 6y ago
      You can easily forget pending tasks. That’s a single line of code like this: task.ContinueWith( t => { }, TaskContinuationOptions.OnlyOnFaulted ); However, graceful cancellation is indeed hard. Doable in .NET but not easy, you gonna need to manually pass these cancellation tokens all the way down. Do you have an example of a language/runtime/etc where the cancellation's easy? It's easy to kill processes from the outside, but even for threads it's borderline impossible without horrible side effects.
SAI_Peregrinus 6y ago
Last I checked STM32 microcontrollers can't run .Net, and thus can't use C#. They can run Rust. Rust's embedded and OS-level capabilities are a big point in its favor, particularly over something like C#.
- Const-me 6y ago
  Indeed, you need a reasonably capable OS kernel to use .NET runtime. And enough RAM. And I wouldn’t want .NET for hard realtime use cases. Even in embedded, for some products the tradeoff is good enough. A while ago I’ve shipped embedded software that uses .NET Core and runs on RK3288, worked quite well for us. BTW, do you have good experience with Rust on bare metal STM32? I would expect STM-supported C toolset and libraries to be generally better?
  - SAI_Peregrinus 6y ago
    I find the Rust embedded-hal to be quite good. STM's HAL code is a horrible inefficient mess, though their LL library isn't bad. I'd much rather use Rust's hal crates and probe-run. That said, CubeMX's configuration tool is very nice. But that's used (hopefully) once at board bringup and never again, so not worth sticking with C for.
- pjmlp 6y ago
  Depends, .NET => https://www.wildernesslabs.co/hardware https://www.wildernesslabs.co/hardware Oberon => https://www.astrobe.com/boards.htm https://www.astrobe.com/boards.htm Java https://www.microej.com/ https://www.microej.com/ https://www.aicas.com/wp/ https://www.aicas.com/wp/ https://www.ptc.com/en/products/developer-tools/perc https://www.ptc.com/en/products/developer-tools/perc

millstone 6y ago

I don't think safety is driving Rust's ascent. For example, WASM has more momentum with Rust than with C++. But WASM is already sandboxed, and does not support threads; so what is Rust bringing to the WASM table? I think it's a monoculture phenomenon. Rust has a website and a pitch; C++ does not. Rust has a single compiler and one way to do things; C++ is overly diverse. Rust has learned from npm, etc. and has made package management first-class with a single package manager; C++ has not. Rust is just a much more familiar experience for developers coming from other monoculture languages.

adwn 6y ago
> what is Rust bringing to the WASM table? Unless you have to interface with a lot of mostly-header/header-only libraries written in C or C++, Rust is just so much more productive to work with than C or C++, even if you don't have to worry about memory unsafety.
- millstone 6y ago
  How do you find Rust to be so much more productive than C++? I find C++ more productive. In C++ I mainly fight with template error messages. In Rust, I fight with typechecked generics, inserting & and '_ here or there, adding and deleting imports, refactoring to add Some and Ok - tons of nonsense housekeeping. These features have value but are quite a slog when writing code.
  - adwn 6y ago
    Those "tons of nonsense housekeeping" help me detect and avoid bugs. Memory unsafety is not the only category of incorrect code – a bug is a bug, even if it doesn't enable an attacker to gain access to your system. Some of the kinds of bugs that are much easier to accidentally write in C++ than in Rust are: use-after-free, use-after-move, out-of-bounds array accesses, data races and other synchronization errors. I want my code to be correct, even if it runs in a sandbox.
    - millstone 6y ago

pjmlp 6y ago

Thing is, when you write Java and .NET, it is already possible to be almost C like, specially .NET given the improvements since C# 7. https://devblogs.microsoft.com/aspnet/grpc-performance-improvements-in-net-5/ https://devblogs.microsoft.com/aspnet/grpc-performance-impro... So when we dive into C++ to write a small DLL/.so to be consumed by those languages, it is basically for doing exactly the same that would be a bunch of unsafe code blocks in Rust.

jayd16 6y ago
Right, but the goal and promise is to get C perf in Rust _without_ the unsafe blocks. Rust may or may not make good on that goal but the idea is why people are interested.
- pjmlp 6y ago
  I don't see how that would be possible, given that there is always unsafe at some level of the stack, even if only on the runtime implementation. Ada also has unsafe (unchecked).