9 ms·

I admire the passion, but I’m not sure why I would want Rust at all, not just async. When I want memory safety, async-await, I/O performance, easy multithreadi

I admire the passion, but I’m not sure why I would want Rust at all, not just async. When I want memory safety, async-await, I/O performance, easy multithreading, I write C#. When I want performance of CPU bound code, or lots of integration with native libraries/APIs, I write C++. Sometimes I want both in the same software, compile C++ code into a DLL (or shared library on Linux), and consume it from C#. I don’t have experience with Rust in production software, but based on what I know and my limited experience with the language, it’s worse than the above combo. At least for the projects I usually work on. For pieces where performance doesn’t matter too much (often 70-80% of codebase), or for I/O heavy code, or for the stuff that’s in the standard library of .NET (serialization, compression, cryptography, xml, json, zip, etc.), C# is way easier to write and debug than Rust. Tooling is awesome. Even large projects build in seconds i.e. built/test cycle is really fast. For CPU bound or native interop-heavy pieces, C++ is also way easier than Rust. Intel and ARM only support their SIMD intrinsics for C. OS vendors only support their GPU APIs for C (most of them) or C++ (Direct3D). Many libraries I use are only available for C and/or C++. Using C++ for these pieces is the path of least resistance by a large margin, i.e. saves lots of development costs. The interop between the two adds some friction, but not too much, .NET was designed for easy native interop from the very first version. When I want to expose objects instead of [in addition to] just functions, there’re COM interfaces. At least in my experience, usability of C# brings way more profits compared to the losses from the interop across languages.

whb07 6y ago
Do you have any good resources on writing dlls to consume via .net like you’re talking about ? How do you deal with the managed memory when using the gc from .net
- Const-me 6y ago
  > Do you have any good resources on writing dlls to consume via .net like you’re talking about? For C APIs i.e. functions, structures and strings, the good resource is Microsoft documentation, the support is built-in, see “Consuming Unmanaged DLL Functions” section: https://docs.microsoft.com/en-us/dotnet/framework/interop/ https://docs.microsoft.com/en-us/dotnet/framework/interop/ For COM APIs i.e. sharing objects around see this library + demos: https://github.com/Const-me/ComLightInterop https://github.com/Const-me/ComLightInterop It’s only really needed on Linux because the desktop version of the framework has COM support already built-in, but it can be used for cross-platform things just fine, I tested that quite well i.e. not just with these simple demos. > How do you deal with the managed memory when using the gc from .net Most of the time, automatically. When you calling C++ from C#, the runtime automatically pins arguments like strings or arrays. Pinning means until the C++ function returns, .NET GC won’t touch these things. This doesn’t normally make any copies: C++ will receive raw pointers/native references to the .NET objects. Sometimes you do want to retain C# objects from C++ or vice versa i.e. keep them alive after the function/method returns. An idiomatic solution for these use cases is COM interop. IUnknown interface (a base interface for the rest of COM interfaces) allows to retain/release things across languages.
- pjmlp 6y ago
  On Windows, just use C++/CLI or COM. Contrary to urban myths, all major APIs introduced since Vista are mostly COM. On other platforms, P/Invoke provides a very straightforward way to bind into C ABI. You can manage native memory via "using" (since C# 8.0 you don't even need to implement IDisposable), or SafeHandles.
steveklabnik 6y ago
Not everyone needs to use Rust. If you don’t have a desire to, that’s 1000% okay! I am not sure why you’re downvoted. Maybe it’s because it’s sorta kinda off topic?
- Const-me 6y ago
  > Maybe it’s because it’s sorta kinda off topic? Could be, but I find this strange as well. I don’t remember a discussion on HN about any programming language at all without people commenting about Rust. Don’t remember them being downvoted. P.S. As to why I wrote the comment — the article invited the “status quo” stories, so I decided to share my perspective.
  - steveklabnik 6y ago
    They get downvoted and yelled at too. I’ve seen it :)
- fpgaminer 6y ago
  > I am not sure why you’re downvoted. Maybe it’s because it’s sorta kinda off topic? It doesn't follow the HN guidelines: "Have curious conversation" and "Comments should get more thoughtful and substantive". It doesn't add to the discussion about Rust's async story.
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.
      - 6y ago
Ar-Curunir 6y ago
Nobody’s forcing you to use Rust, you can just ignore it.
millstone 6y ago
I would not think to consider C# outside of Windows, but maybe I am wrong and should update my priors. Are there any C# programs that are regularly used ex-Windows? Something analogous to Docker (written in Go) or ripgrep (written in Rust)?
- Const-me 6y ago
  Technically, some from these lists: https://en.wikipedia.org/wiki/List_of_Unity_games https://en.wikipedia.org/wiki/List_of_Unity_games https://dotnet.microsoft.com/apps/xamarin/customers https://dotnet.microsoft.com/apps/xamarin/customers However, the runtimes are unusual there, neither Unity nor Xamarin run traditional net-core CLR, they still use Mono, for some platforms even AOT compiled. About normal .NET core, probably asp.net is the most known. stackoverflow.com have recently migrated to aspnet-core but I’m not sure if they migrated from Windows Server yet.
lmm 6y ago
95% of people who think they want Rust should just be using OCaml or similar, IMO. That said, Rust should mostly be as easy to write and debug as C# - if it's not, that's a problem to be fixed. And interop between two languages causes more subtle issues that you don't notice - your architecture ends up distorted, refactoring across the interop boundaries is painful. I used to work on mixed C++/Python projects and thought I was getting the best of both worlds - it was only when I didn't have to do that that I noticed how much it had actually slowed me down. And of course any nontrivial piece of real-world C++ code is undefined behaviour. So having a memory-safe replacement for that part is a huge improvement.
- Const-me 6y ago
  > if it's not, that's a problem to be fixed I agree, but it’s very expensive to fix. Visual Studio is a de-facto standard in many areas for a reason. > interop between two languages causes more subtle issues that you don't notice I have some experience with python. C interop does work, but the usability is not OK. The languages and runtimes are just too different, which caused non-trivial amount of boilerplate to integrate the two. C# / C++ integration is much easier. I remember a few times when I wanted to move that interop boundary, usually in the direction of “less C++”, but did nothing about that because development overhead was too large. And I agree that’s harmful in the long run. Here’s a famous quote: https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule The idea does apply to all sufficiently complicated programs ever since: MS Office has VBA, game engines have their scripting languages, AutoCAD has LISP, and so on. I’m pretty sure that if in the future some programming language gonna become good enough to rule them all, that language will be much closer to modern C# than to modern Rust. Rust offloads a huge amount of complexity to developers (being such a developer, I don’t like that) and to the compiler (results in slow builds).
  - lmm 6y ago
    > I agree, but it’s very expensive to fix. Visual Studio is a de-facto standard in many areas for a reason. Well sure, and in reality IDE support is a big reason I'm using Scala rather than Haskell. But the fact is that there are maybe 2.5 good IDEs going, and that seems like as much as the programming industry can support. So either we accept that the only way to make your programming language experience any good is to get it picked up by one of the handful of giant companies that can fund those IDEs, or we have to be willing to at least start a promising language without an IDE and hope other advantages can make up for that shortcoming for some use cases, and eventually there'll be enough momentum that one of those giant companies will pick it up. I can't see what other way there is to advance the state of the art, unless your position is going to be that C# is perfect and there's no point trying to do better. > I’m pretty sure that if in the future some programming language gonna become good enough to rule them all, that language will be much closer to modern C# than to modern Rust. Rust offloads a huge amount of complexity to developers What complexity is that? I'd argue that the trait system is a noticeable improvement over what's available in C#, and not having exceptions makes code significantly easier to understand. On linearity I could go either way - in theory it's more work for the developer, but borrow-checker friendly code styles tend to just be good coding style. Most of the time I write the same code I'd write in C#, Scala, or anything else, and it just work - and when it doesn't either the error messages have been clear and the fix has been easy, or it became clear that I was genuinely very confused about the problem and needed to rethink my whole approach. (But yeah actually GC is fine 100% of the time and Scala is already the one language to rule them all, people just haven't realised yet)
BuckRogers 6y ago
Downplaying Rust isn’t going to go over well in this thread. I happen to completely agree with you, but I would add or say that Rust is the first new programming language in a very long time that qualifies as technical innovation and not technical churn. Maybe the only one since Java. And I'm a C# guy, I wouldn't want to use anything else, it's Java done right. But standing back and looking at the big list[0], only C, Java and probably Rust qualify as true technical innovation. I'm not saying that's the only thing that matters either. Everything has its contributions, but I'm not sure many rise to my standard of technical innovation (solving a problem), and most are pure churn. Rust solves a real problem that has plagued software for decades (or so I'm told, I'm not a Rust user), but that can be true while everything else you said is also true. I don't plan on picking up Rust either, and yes a combo like C#/C(++) is incredibly potent, and Rust is ages away from replacing C. A language ends up being the sum of its parts though. C# is "write once, jobs everywhere". Great serverside platform with .NET 5. Native on the most popular desktop platform, produces iOS apps and games. It's industrial-strength in language design. Good IDE support, good backwards compatibility (or side by side support). And also importantly, like my experience writing Python, I enjoy writing C#. [0]https://en.wikipedia.org/wiki/Timeline_of_programming_languages#1970s https://en.wikipedia.org/wiki/Timeline_of_programming_langua...
- shock 6y ago
  > And I'm a C# guy, I wouldn't want to use anything else, it's Java done right. It has colored functions. Every async function is turned by the compiler into a class with an embedded FSM. Async is viral in C#, so much so that even main() had to be made async. So, no, it's not Java done right.
  - BuckRogers 6y ago
    Java done wrong? I've always been a Java/C# person, that's the general programming abstraction layer I've spent most of my education and career in and prefer it. I greatly prefer C# (and all that comes with it) over Java. But if C# didn't exist, I would probably prefer Java over all other alternatives. The only reason I'd fall onto Javascript upon C#'s disappearance would be because most of my experience is in web, but definitely not due to the ecosystem or language. So from a language/ecosystem perspective, Java is my 2nd choice, I never hated Java, it's popular for good reasons.
pjmlp 6y ago
That is also my approach, just put Java into the mix, as I hop between eco-systems depending on the customer requirements. I see Rust as a very good candidate for kernel code, drivers, embedded hardware where automatic memory management is a no go (MISRA-C, Ada/SPARK), and that is about it.

whb07 6y ago

Do you have any good resources on writing dlls to consume via .net like you’re talking about ? How do you deal with the managed memory when using the gc from .net

Const-me 6y ago
> Do you have any good resources on writing dlls to consume via .net like you’re talking about? For C APIs i.e. functions, structures and strings, the good resource is Microsoft documentation, the support is built-in, see “Consuming Unmanaged DLL Functions” section: https://docs.microsoft.com/en-us/dotnet/framework/interop/ https://docs.microsoft.com/en-us/dotnet/framework/interop/ For COM APIs i.e. sharing objects around see this library + demos: https://github.com/Const-me/ComLightInterop https://github.com/Const-me/ComLightInterop It’s only really needed on Linux because the desktop version of the framework has COM support already built-in, but it can be used for cross-platform things just fine, I tested that quite well i.e. not just with these simple demos. > How do you deal with the managed memory when using the gc from .net Most of the time, automatically. When you calling C++ from C#, the runtime automatically pins arguments like strings or arrays. Pinning means until the C++ function returns, .NET GC won’t touch these things. This doesn’t normally make any copies: C++ will receive raw pointers/native references to the .NET objects. Sometimes you do want to retain C# objects from C++ or vice versa i.e. keep them alive after the function/method returns. An idiomatic solution for these use cases is COM interop. IUnknown interface (a base interface for the rest of COM interfaces) allows to retain/release things across languages.
pjmlp 6y ago
On Windows, just use C++/CLI or COM. Contrary to urban myths, all major APIs introduced since Vista are mostly COM. On other platforms, P/Invoke provides a very straightforward way to bind into C ABI. You can manage native memory via "using" (since C# 8.0 you don't even need to implement IDisposable), or SafeHandles.

steveklabnik 6y ago

Not everyone needs to use Rust. If you don’t have a desire to, that’s 1000% okay! I am not sure why you’re downvoted. Maybe it’s because it’s sorta kinda off topic?

Const-me 6y ago
> Maybe it’s because it’s sorta kinda off topic? Could be, but I find this strange as well. I don’t remember a discussion on HN about any programming language at all without people commenting about Rust. Don’t remember them being downvoted. P.S. As to why I wrote the comment — the article invited the “status quo” stories, so I decided to share my perspective.
- steveklabnik 6y ago
  They get downvoted and yelled at too. I’ve seen it :)
fpgaminer 6y ago
> I am not sure why you’re downvoted. Maybe it’s because it’s sorta kinda off topic? It doesn't follow the HN guidelines: "Have curious conversation" and "Comments should get more thoughtful and substantive". It doesn't add to the discussion about Rust's async story.

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.
    - 6y ago

Ar-Curunir 6y ago

Nobody’s forcing you to use Rust, you can just ignore it.

millstone 6y ago

I would not think to consider C# outside of Windows, but maybe I am wrong and should update my priors. Are there any C# programs that are regularly used ex-Windows? Something analogous to Docker (written in Go) or ripgrep (written in Rust)?

Const-me 6y ago
Technically, some from these lists: https://en.wikipedia.org/wiki/List_of_Unity_games https://en.wikipedia.org/wiki/List_of_Unity_games https://dotnet.microsoft.com/apps/xamarin/customers https://dotnet.microsoft.com/apps/xamarin/customers However, the runtimes are unusual there, neither Unity nor Xamarin run traditional net-core CLR, they still use Mono, for some platforms even AOT compiled. About normal .NET core, probably asp.net is the most known. stackoverflow.com have recently migrated to aspnet-core but I’m not sure if they migrated from Windows Server yet.

lmm 6y ago

95% of people who think they want Rust should just be using OCaml or similar, IMO. That said, Rust should mostly be as easy to write and debug as C# - if it's not, that's a problem to be fixed. And interop between two languages causes more subtle issues that you don't notice - your architecture ends up distorted, refactoring across the interop boundaries is painful. I used to work on mixed C++/Python projects and thought I was getting the best of both worlds - it was only when I didn't have to do that that I noticed how much it had actually slowed me down. And of course any nontrivial piece of real-world C++ code is undefined behaviour. So having a memory-safe replacement for that part is a huge improvement.

Const-me 6y ago
> if it's not, that's a problem to be fixed I agree, but it’s very expensive to fix. Visual Studio is a de-facto standard in many areas for a reason. > interop between two languages causes more subtle issues that you don't notice I have some experience with python. C interop does work, but the usability is not OK. The languages and runtimes are just too different, which caused non-trivial amount of boilerplate to integrate the two. C# / C++ integration is much easier. I remember a few times when I wanted to move that interop boundary, usually in the direction of “less C++”, but did nothing about that because development overhead was too large. And I agree that’s harmful in the long run. Here’s a famous quote: https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule The idea does apply to all sufficiently complicated programs ever since: MS Office has VBA, game engines have their scripting languages, AutoCAD has LISP, and so on. I’m pretty sure that if in the future some programming language gonna become good enough to rule them all, that language will be much closer to modern C# than to modern Rust. Rust offloads a huge amount of complexity to developers (being such a developer, I don’t like that) and to the compiler (results in slow builds).
- lmm 6y ago
  > I agree, but it’s very expensive to fix. Visual Studio is a de-facto standard in many areas for a reason. Well sure, and in reality IDE support is a big reason I'm using Scala rather than Haskell. But the fact is that there are maybe 2.5 good IDEs going, and that seems like as much as the programming industry can support. So either we accept that the only way to make your programming language experience any good is to get it picked up by one of the handful of giant companies that can fund those IDEs, or we have to be willing to at least start a promising language without an IDE and hope other advantages can make up for that shortcoming for some use cases, and eventually there'll be enough momentum that one of those giant companies will pick it up. I can't see what other way there is to advance the state of the art, unless your position is going to be that C# is perfect and there's no point trying to do better. > I’m pretty sure that if in the future some programming language gonna become good enough to rule them all, that language will be much closer to modern C# than to modern Rust. Rust offloads a huge amount of complexity to developers What complexity is that? I'd argue that the trait system is a noticeable improvement over what's available in C#, and not having exceptions makes code significantly easier to understand. On linearity I could go either way - in theory it's more work for the developer, but borrow-checker friendly code styles tend to just be good coding style. Most of the time I write the same code I'd write in C#, Scala, or anything else, and it just work - and when it doesn't either the error messages have been clear and the fix has been easy, or it became clear that I was genuinely very confused about the problem and needed to rethink my whole approach. (But yeah actually GC is fine 100% of the time and Scala is already the one language to rule them all, people just haven't realised yet)

BuckRogers 6y ago

Downplaying Rust isn’t going to go over well in this thread. I happen to completely agree with you, but I would add or say that Rust is the first new programming language in a very long time that qualifies as technical innovation and not technical churn. Maybe the only one since Java. And I'm a C# guy, I wouldn't want to use anything else, it's Java done right. But standing back and looking at the big list[0], only C, Java and probably Rust qualify as true technical innovation. I'm not saying that's the only thing that matters either. Everything has its contributions, but I'm not sure many rise to my standard of technical innovation (solving a problem), and most are pure churn. Rust solves a real problem that has plagued software for decades (or so I'm told, I'm not a Rust user), but that can be true while everything else you said is also true. I don't plan on picking up Rust either, and yes a combo like C#/C(++) is incredibly potent, and Rust is ages away from replacing C. A language ends up being the sum of its parts though. C# is "write once, jobs everywhere". Great serverside platform with .NET 5. Native on the most popular desktop platform, produces iOS apps and games. It's industrial-strength in language design. Good IDE support, good backwards compatibility (or side by side support). And also importantly, like my experience writing Python, I enjoy writing C#. [0]https://en.wikipedia.org/wiki/Timeline_of_programming_languages#1970s https://en.wikipedia.org/wiki/Timeline_of_programming_langua...

shock 6y ago
> And I'm a C# guy, I wouldn't want to use anything else, it's Java done right. It has colored functions. Every async function is turned by the compiler into a class with an embedded FSM. Async is viral in C#, so much so that even main() had to be made async. So, no, it's not Java done right.
- BuckRogers 6y ago
  Java done wrong? I've always been a Java/C# person, that's the general programming abstraction layer I've spent most of my education and career in and prefer it. I greatly prefer C# (and all that comes with it) over Java. But if C# didn't exist, I would probably prefer Java over all other alternatives. The only reason I'd fall onto Javascript upon C#'s disappearance would be because most of my experience is in web, but definitely not due to the ecosystem or language. So from a language/ecosystem perspective, Java is my 2nd choice, I never hated Java, it's popular for good reasons.

pjmlp 6y ago

That is also my approach, just put Java into the mix, as I hop between eco-systems depending on the customer requirements. I see Rust as a very good candidate for kernel code, drivers, embedded hardware where automatic memory management is a no go (MISRA-C, Ada/SPARK), and that is about it.