Building a shared vision for Async Rust
blog.rust-lang.org
blog.rust-lang.org
What I'm doing involves a virtual world viewer with maybe a dozen threads. Some are compute bound. Some are talking to the GPU. Some are waiting for I/O. The normal situation is about 2 or 3 CPUs of work. Sometimes more.
I don't want an async model, which assumes you're I/O bound, interfering with keeping all those CPUs busy. Already I've had to switch from using "reqwest", which now seems to always bring in tokio, to "ureq", a minimal HTTP client. The way to do HTTP requests used to be with "hyper", but that became a lower level for "reqwest", and then "tokio" was slipped in underneath to make it "async". It always uses async, even if you make a blocking request.
"Async" is a specialized tool for web servers with very large numbers of clients. Outside of that niche, it's seldom needed.
Firstly, `reqwest` exposes both an async and a synchronous API, allowing the developer to choose which one to use. They are largely interchangeable code-wise. [1]
Secondarily, and more broadly, async is possible to opt out of. You must understand that most web and network related libraries will be async by default for performance, because people who write in Rust and people who write web servers typically care greatly about performance. This is the intersection of those two groups. That being said, there are options outside of that ecosystem. [2]
If you truly want to use an asynchronous library without migrating your application to run entirely on an async runtime like tokio, you can run it inside of a synchronous function without much trouble. I've put together a playground link for you. [3]
1. https://docs.rs/reqwest/0.11.2/reqwest/blocking/index.html
2. Iron: https://github.com/iron/iron Rouille: https://github.com/tomaka/rouille
3. https://play.rust-lang.org/?version=stable&mode=debug&editio...
You must understand that most web and network related libraries will be async by default for "performance". That's what scares me - async contamination of the low level Rust ecosystem. The async enthusiasts have to be kept in check to prevent breaking Rust as a systems language.
It is unclear to me what you mean by keeping the community "in check". There are a lot of people who rely on and enjoy the async story, and they will continue to produce code that improves that story. Simultaneously, there are people who do not need that, and they are not hindered by this. People will build what they want and need. You've just picked some libraries from some of the biggest async contributors in the community and requested that they be kept in check so that you don't have to switch to a synchronous alternative, of which there are plenty.
- Incoming events UDP packets from multiple servers. These arrive at the client and go into a queue for processing.
- Refreshing the 3D window. This ties up one thread almost full time. At the beginning of each frame, it reads queued events that tell it what needs to change in the GPU. The rest of the time it feeds the GPU.
- Some incoming events require querying external HTTP servers to retrieve assets. When the results come back, they include compressed items which have to be decompressed, processed, and turned into GPU-ready textures or meshes. This is prioritized by how important it is to display that object right now, based on the viewpoint. So there are priority queues along with multithreading.
There's more, but you get the idea.
What's so great about Rust is that you can do stuff like this without crashing all the time, spending your life in the debugger, or recopying big objects to safely pass them around.
The previous implementation, in C++, looked a lot more like an "async" model. It had lots of "coroutines", mostly running off a single thread. It also had a few things running as independent threads because they were so CPU-intensive. It was very prone to short stalls that annoyed players. This happened because something had to do more work than expected and briefly stalled out the coroutine system. The killer in async systems is the subroutine that is usually fast but sometimes slow. So I've seen this problem done in "async" style, and it didn't work well.
I've previously done robotics work which had many asynchronous tasks. I've used QNX for that, and I've used ROS. There, you have a lot of intercommunicating processes, which works but has more overhead.
None of this maps well to an "async" model.
Part of the problem here may be that I've done a lot of multi-thread programming and am used to it. It's an alien approach to programmers who came up from Javascript. That's a big fraction of the web backend crowd.
(Personally, when I have to do a web service, I write it in Go. That's the use case for which Go is designed. It has the libraries for that, and the goroutine concept is well matched to that task.)
I wonder, why is this kind of system a bad fit for the async model? Is it because all threads must be reliably preemptable?
Surely we can all agree that spinning up unnecessary threads is undesirable?
> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
This is not the strongest plausible interpretation of what he said --
He's not asking for people to not develop async code. He's asking for them to not hide it in synchronous code.
If you're expecting a blocking system call, and actually get a brand new background thread that's polling, it's quite reasonable to be frustrated.
It really isn't if the documentation doesn't outright say that it's single threaded and not thread safe. For a lot of simpler use cases where you just want to ship a thread-safe API (e.g. application does not have its own thread pool) then it just makes sense in a lot of cases to use some kind of automatic thread pooling. The caller does not have to know or care how the internal state machine is implemented.
If you have implemented your own thread pool it seems you should know enough to dig down enough to the lower layers to where you can get to that blocking syscall, or least to the point where you can strip off the O_NONBLOCK flags yourself.
Many years ago, well before Rust 1.0, Rust used its own M:N threading system, used segmented stacks, had it's own libuv-based event loop, etc. Also, it had garbage collection built into the language.
These were removed before 1.0, which made Rust a lot better as a systems language: you could reliably embed it into non-Rust programs, you could reliably interoperate with non-Rust libraries that didn't expect to be moved around threads, you didn't need to care about starting up the GC (or handling GC pauses), etc.
This was a good decision for Rust, and it turns out most of the things people wanted to do with these features could be done outside it - e.g., the borrow checker avoided the need for pervasive GC. (Though almost certainly not intentional, one side effect is that it distinguished Rust from Go: Go is great for standalone programs that need lightweight concurrency, but it's very bad at being embedded into other code and not the best choice if you're mostly calling FFI libraries.)
First, it would be good for Rust to stick to that decision. Rust should not regain a pausing GC in the standard library - similarly, it should not regain a thread manager in the standard library.
Second, it would be good for Rust libraries to work within the spirit of that decision. That's a lot harder, because part of the expectation when those features were removed was that some needs - notably around event-based processing - would be met by third-party libraries. As I understand it (and I might be totally wrong!), it was honestly a bit of luck that the borrow checker worked as well as it did and was ready at the right time, and the expectation was that someone would add a GC library and it would be widely used. However, it's very good that no widely-used GC library sprung up. In the same vein, it would be good for there to be no widely-used third-party thread manager library.
This might be hard, possibly requiring a borrow-checker-level miracle, but it's worth aiming for. And if there has to be a thread manager (or a garbage collector), it should not be part of core Rust.
Would you agree with that phrasing?
--
Incidentally, why does reqwest start up a polling thread when called in sync mode? Can't it do the polling on the main thread? (Or in other words, async programming doesn't imply multithreaded programming. I actually sort of expect that async programming is better suited to single-threaded programming with an event loop, because if you're okay with threads, you may as well just write synchronous code on threads! So either there is something subtle and very interesting here, or there's an easy fix, or I'm misunderstanding something badly.)
If the reqwest library indeed spawns a thread for every request, it is a good example of that dynamic. Sync mode kind of works but is clearly a second-class citizen and works in a suboptimal fashion. And if you want to peek under the hood to debug it you still have to deal with the async machinery in all its gory detail.
Or put another way - when Rust removed M:N threading and also shipped out of the box with no event handling support after removing librustuv, the recommendation was that libraries should use threads to handle concurrency and make blocking calls on each thread, and modern OSes make threads perform well, so why not. Isn't the whole point of revisiting async to avoid that answer?
I have the same use cases of wanting Rust to be a close-to-the-metal language with a minimal runtime that you can safely plop in place of any C code, and it seems to me that the way to do that is to get the async story to be so good that people start saying "Well, that's not idiomatic" and "That approach was common but the libraries are all unmaintained" to libraries that spawn threads. What am I missing? Why are we associating "more async" with "more threads" instead of "remain on the calling thread and use an event loop"?
To put it another way, it's unfortunate that particular synchronous API is implemented using threads, but there is nothing about async that implies one way or another that a synchronous method will be implemented using threads -- I've seen plenty of (questionable) C functions that do similar things like using pthread_create and then pthread_join immediately after to fake a blocking task.
Manually scheduling threads seems like a really shitty way to program
But regardless, the GP post was not taking about matrix math, it seems it was talking about sending an HTTP request and waiting for a response, which is something that actually is I/O bound on the TCP socket.
> "I don't want an async model, which assumes you're I/O bound, interfering with keeping all those CPUs busy."
Strongly implies to me that there's a CPU-bound component there.
>Cooperative multitasking is used with await in languages with a single-threaded event-loop in their runtime, like JavaScript or Python.
There's no reason rust can't have an executor that does the same, and you only use that within the event loop on your one or two HTTP worker threads. If you're waiting in a thread for an HTTP request to return, that's never going to be CPU-bound. I still am failing to see what the problem here is besides a complaint about some rust crate only supporting a multi-threaded executor, which again is a different problem than whether it's done with async futures or not. One could just as easily write some C code that forces the use of threads.
The goal is to NOT do what you're suggesting. It's a holdover from when native threads were much more expensive than they are today, and multiple cores on a single cpu were rare.
The problem I see is the current async story is opt-out. It's use async or go find something else. Async should be opt in. As in, the code works regardless of an async runtime, async is added magic if you want it, but it will run like normal single threaded code if not.
That sums this discussion up nicely.
Surely this is only the case if you have picked asynchronous libraries to use?
However, I think what the parent is getting at is the feeling of the total package, not the technical details. If every library you want to use is async, you can't really "opt out" exactly, even if technically the feature is opt out.
Couldn't you have made another hard constraint to make async code work as normal if the programmer wanted?
If aysnc could work like regular blocking code , if we want, and async code when you want, I think rust would be in a better place.
Just because you can do something doesn't mean you should.
This is what many of us want. Sadly this doesn't seem to be a use-case many in rust are interested in supporting as a first class citizen (from what I've read at least).
I remember seeing someone being down-voted into oblivion for the mere suggestion of some sort of basic fallback executor in the standard library.
Rust's async story is a weird one.
Popol is designed as a minimal ergonomic wrapper
around poll, built for use cases such as peer-to-peer
networking, where you typically have no more than a
few hundred concurrent connections. It’s meant to be
familiar enough for those with experience using mio,
but a little easier to use, and a lot smaller.
Web is just 2 ports out of the 65535 TCP/IP ports. Network servers can benefit from an async model depending on the server design.
Let’s not sweep all of networking into “web”.
https://github.com/urllib3/urllib3/issues/1323 is a discussion of this. "Solution: we maintain one copy of the code – the version with async/await annotations – and then a little script maintains the synchronous copy by automatically stripping them out again. It's not beautiful, but as far as I can tell all the alternatives are worse.
https://github.com/python-trio/unasync is the current production implementation of this approach.
Colored functions are a problem in JavaScript because it has to share an event loop with the rest of the browser. For Node.js and Python, that is less of an issue, but those languages are also either practically or actually single-threaded, which also means async behavior is contagious. Rust does not have this problem, at least not until you're writing WASM programs with it (in which case, you're restricted to sharing one thread with the rest of the browser again).
I do somewhat agree with that desire - I don't think that this is a problem for performance, but since most of my use of Rust is dropping it into existing C code, I think that spawning a thread is likely to have annoying visible side effects on the calling code, which might not be expecting me to do that.
Using a proper, single-threaded executor and running it on the current thread seems like it would work, yes. (To be fair, I also feel like just having the sync version of a Python API call "trio.run(self.equivalent_async_api)" would probably also work, and I don't totally follow why that's insufficient....)
Why do I need all this other bloat just to run a function? Why can't I just run the function?
Maybe we should start trying to think about async as being something can use if they want and ignore if they want. Code being async compatible rather than async required.
Let's say I have code like this, in Python asyncio:
class ShardedDBClient:
async def query(self, key):
tasks = [self.query_shard(key) for shard in self.shards]
results = await asyncio.gather(*tasks)
for partial_result in results:
if key in partial_result:
return partial_result[key]
return None
The obvious way to make it not be "async required" is to say, we get rid of the async/await keywords - but what do you do with that "await asyncio.gather" instruction? Do you call each of those callbacks serially?
Generally, even in Rust (perhaps especially in Rust), I would expect this to use some OS facility for waiting on multiple sockets (possibly even just boring select(), but preferably epoll/kqueue) to send a bunch of database requests out in parallel and then wait on all their sockets to handle responses as they arrive. I would expect that even if my own code doesn't involve async/await at all.
The easy way to implement that is
def sync_query(self, key):
return asyncio.run(self.query(key))
This is going to be a lot faster than querying those shards one at a time! And it also can semantically change how the library behaves - imagine that there's a timeout parameter, and I set a 100ms timeout. I probably mean that to be 100ms for the entire operation, not 100ms per request, but I probably also don't expect my calls to always fail if each query takes 10ms and there are more than 10 shards.
The downside is that this library is quietly using asyncio without you knowing. But how exactly is that a downside? I already expect the library to be using select/epoll/kqueue without me knowing. And in a language like Rust, the executor should basically compile out - it should be a "zero-cost abstraction" compared to writing the event-handling code by hand.
And it'd be great to check and optimize away all this at compile time.
The Rust standard library's block_on uses a global ThreadPool, and the docs recommend using a LocalPool if you need finer grained control.
So, to answer your question it depends on the executor (the thing that implements block_on).
So for anyone reading for the correct details: the block_on I was thinking of is part of the futures crate, which is not in std, it's not an "official library".
I like the format of the github Rustlings repo for exposing common beginner pitfalls and pointing developers in the right direction. For the uninitiated, Rustlings is a repo containing a collection of broken code examples that the developer has to fix along their journey to enlightenment. I feel that it would be beneficial to have an "Advanced Rustlings", say Rusteenager ;), for more advanced topics like tricky borrow checker situations and async rust. These examples would be similar to the PR's mentioned in the blog post but may get better exposure imo.
For example, the recent "async doesn't work" blog post was centered around confusion between `fn()` pointer and `Fn()` trait, and misuse of temporary `&mut` where `Arc<Mutex>` was required. If the compiler was smart enough to suggest these fixes, then the whole blog post could have been "async works fine, just needed a couple of lines changed as indicated".
I saw discussed in this talk the intent in allowing developers to provide their own executor based on the specifics of their use case: https://youtu.be/NNwK5ZPAJCk?t=1107
This makes sense to me; however, I feel like the defacto at this point is that most people are using tokio. Is there a possibility that a default executor could be provided, and allow developers to override it with a custom library should they chose?
The problem is that a standard library is a heavy burden for a language, and a huge risk for its longevity (think 40 years from now). It promises that the first stable release of any feature will work forever, and never change. It's an unrealistic promise for anything non-trivial.
In other languages it often played out like this:
1. std added a feature,
2. it turned out that it wasn't the best API, but it couldn't be fixed,
3. people fed up with the poor std API wrote a replacement,
4. everyone has to be reminded "don't use the std version, use the replacement instead" forever.
Rust jumps straight to the point 4.
(There is, at this point, an abstraction library called "anyio" which can run on either an asyncio or Trio event loop, but anyio's model is most strongly influenced by Trio's, because Trio's model is more structured - which means anyio couldn't have been written before Trio was developed and well-received.)
Given that Python has a strong "batteries included in the standard library" approach and Rust has a strong "we shipped a really good package manager with the language, and even the C 'int' type lives outside the standard library, in a package maintained by the Rust core team" approach, it seems like it would be very weird for Rust to repeat the mistake (at least in Rust's worldview) of shipping a default executor in the standard library that would turn into a de facto standard.
And given that Rust does have a really good package manager, adding a third-party dependency is pretty straightforward and doesn't seem like too much of an obstacle. (Frankly, the same is also true of Python, and I would certainly tell a beginner to make a virtualenv and pip install Trio. But since it didn't have it since day one, there's more of a cultural expectation to make the standard library useful out of the box.)
I do hope that it becomes more possible to write async code that is portable between executors. If there were more standard traits around the most common elements of an executor it'd make things a lot better imo.
That said, I think no matter how minimal it is it would still be a mistake. If anything, I think the only thing that would make sense to include is basically a "not-really-async" executor to appease things like the sibling thread where people want to be able to incorporate async code into their sync codebase without spawning a reactor thread. But that would also require the ability to genericize libraries over executors (and would obviously come with some significant caveats around potential deadlocks).
Yes, there have been a couple of ideas floating around, and a couple of older RFCs that needed more revision, such as boat's `#[global_executor]`, and discussion about an extension to task::Context that would allow futures to interact with their environment (timers, etc). There is a lot of work going on in this area, but nothing concrete yet.
This is more difficult than you think, and you probably don't want the current async stuff to anchor to a weak implementation.
For example, at least one of the current Rust async things doesn't work when pointed to UNIX/Linux character device file descriptors.
My general position on this is that all-async (like Javascript) is OK, and all-threaded is OK, and all green threads (like Go's goroutines) are OK. But those concepts do not play well together in the same program.
This claim bothers me. It might be a nitpick, but I think it's an important one. For a given amalgamation, it is fiction in a non-trivial way that there was a person who literally had all the experiences in the blog posts or tweets etc. that inspired that character. Truth values of facts are almost always dependent on the relationship to other facts.
It would be perfectly respectable to simply say that your user stories are rigorously based on real-world experience, which is a good idea BTW, without claiming that they are "nonfiction". That's a needless epistemological liability.
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.
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.
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.
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.
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.
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.
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.
But the great strengths of Rust, like memory and thread safety, are blunted in WASM, which is already memory-safe and thread-crippled. So Rust's success in WASM must be due to other factors.
I'm confused by that statement. Do you not care whether your code works correctly? Do you consider finding and fixing bugs to be separate from writing code?
> "upstream crates may add a new impl" I have satisfied the compiler but no bugs were prevented.
Trial-and-error debugging which version causes a bug is busywork, preventing it right when someone introduces the potential problem is at best annoying, but very fast compared to the alternative.
https://play.rust-lang.org/?gist=84883cb7cdd09acdcd919888cef...
It's especially bad if your type is an enum, since there's no obvious place to put the PhantomData:
https://github.com/rust-lang/rust/issues/32739
> Trial-and-error debugging which version causes a bug is busywork, preventing it right when someone introduces the potential problem is at best annoying
It's a silly limitation. For example, u64 and u128 are not From<usize> because...well I have no idea. But you can't make them From, because Rust wants to reserve the right to make them From in the future. And you can't write a function that assumes they are NOT From, for the same reason.
So it's pointlessly hard to write generics over integers. I encounter lots of weird holes like this.
https://play.rust-lang.org/?gist=600a1ca784ee7df02351e58df43...
> For example, u64 and u128 are not From<usize> because...well I have no idea.
Because usize is not known statically, it's target arch dependent. Yes, it's silly, but that's how technical safety works. (Also, just as a silly technical counter example the AS/400 virtual instruction set has 128 bit sized pointers.)
There's no question about the need for more ergonomics. That's what this whole post is about after all. For example in some cases where currently PhantomData is needed the intent of the programmer can be easily and unambiguously figured out, but for this folks need to be at least sufficiently certain that this makes things easier, makes code readable, doesn't constraint later language evolution, etc. (If I understand correctly some associated trait bound enhancements will lead to more readable code, less PhantomData.)
Sandboxing only secures the boundary between the WASM interpreter and the embedding application (typically the browser). You can still perform significant exploits within the sandbox. See [0]
IIRC, low-level languages need to maintain a shadow stack in the heap because WASM has no native support for stack variable pointers and without ASLR, we're inching dangerously close to classic buffer overflow attacks. Rust still buys you safety in that regard.
[0] https://www.usenix.org/conference/usenixsecurity20/presentat...
Instead I believe they are choosing Rust/WASM because of the Rust ecosystem: familiar package management, tutorials, other resources.
... ?
The web is already full of untrusted JS. WASM is for performance. The added extra security is just the cherry on top.
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#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.
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.
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_.
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 :-)
task.ContinueWith( t => { }, TaskContinuationOptions.OnlyOnFaulted );
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.
Rust's embedded and OS-level capabilities are a big point in its favor, particularly over something like C#.
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?
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.
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.
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.
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 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).
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)
First and foremost ownership shenanigans. The complexity spill over the entire ecosystem. You can't write a fizz buzz without discovering the standard library has 2 types of strings because of that.
> not having exceptions makes code significantly easier to understand
Both error codes and exceptions have their place. Imagine a streaming parser of some XML/JSON/mpeg4/whatever. There's nothing you can possibly do in the parser to handle socket errors. Exceptions make parser's code more readable, essentially you pretend sockets never fail.
> confused about the problem and needed to rethink my whole approach
No amount of rethinking gonna help when you need a graph data structure in your code. Ownership shenanigans making graphs complicated in Rust, fundamentally so.
Disagree, because even if you can't handle errors in your code you have to do things like make sure resources are closed correctly. So you end up having to reason about exception safety, which is notoriously error-prone. If you have to have paths for propagating errors through your code, it's better to have them visible where you can reason about them, even if the actual handling has to take place at a different level.
> No amount of rethinking gonna help when you need a graph data structure in your code.
If you need a graph with cycles and you don't have a clear owner for the graph as a whole, sure. That's a pretty rare situation IME.
Not all code deals with resources. Streaming parsers normally don't. When you don't open/close any resources, manually propagating errors complicates code for no good reason.
> a graph with cycles and you don't have a clear owner
It's hard in Rust even for acyclic graphs with a clear owner, due to updates. Code that mutates the graph often needs to update multiple nodes at once, but Rust only supports a single writeable reference per object instance.
All practical Rust implementations of graphs, trees and linked lists I saw use unsafe to workaround the fundamental language limitation.
That's OK for linked lists because so simple and a standard library implementation is often enough. Graphs and trees however are very different based on use cases, can't implement just once and call it a day.
Code doesn't deal with resources until it does. Similarly with everything else that forces you to reason about control flow - you don't care about thread management until you do, you don't care about action logs until you do, you don't care about performance until you do... and from the other side, code doesn't need to be exception-safe until it does. The trouble with this kind of "magic" language feature is that correctness becomes non-compositional: you can take two working pieces of code and put them together and get something that doesn't work.
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_langua...
There are definitly a couple of things that .NET is catching up with the Java world and could learn from.
Rust is briging ATS and Cyclone ideas into mainstream, and as those ideas prove correct, other languages are improving their type systems to support them as well.
For example D, Swift, Haskell, Chapel, Ada.
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.
People were downvoting the OP not because they were criticizing Rust, but they were off-topic. The article is about Rust async; OPs comment is about Rust.
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.
Are there any C# programs that are regularly used ex-Windows? Something analogous to Docker (written in Go) or ripgrep (written in Rust)?
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.
How do you deal with the managed memory when using the gc from .net
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/
For COM APIs i.e. sharing objects around see this library + demos: 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.
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.
Grace, the only C/C++ dev, does stuff like "Grace has already decided to use a thread-per-core model and minimize cross-thread communication".
Automatically translated.
(And, as linked to in those comments, HN as well)