91–100 of 139 posts
Earlier quoted context omitted.
Er? No, the point is that threads are what you want for cpu-bound tasks. Async does not deal well with long running cpu intensive jobs that hog the cpu without yield points.
Why not? The fix there sounds like it's as simple as adding some yield points.
Manually scheduling threads seems like a really shitty way to program
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…
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.
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…
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.
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.
Earlier quoted context omitted.
> 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/Vrma…
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#.
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…
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…
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.
Earlier quoted context omitted.
You're replying to John Nagle, as in https://en.m.wikipedia.org/wiki/Nagle%27s_algorithm -- perhaps it would be worth considering his words further, before dismissing his concerns? Surely we can all agree that spinning up unnecessary threads is undesirable?
Doesn’t matter who he is, if he’s mad that libraries made for and by web and network developers are using a concurrency model that works well for their applications, he should use different libraries.
> 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.
Earlier quoted context omitted.
I don't get it - what library? I may have an `async` function and this is part of the Rust language, not tied to any library. Can I make it into a blocking function without 100% CPU?
"async/await" is just syntactic sugar for a function that returns a Future plus a state machine at yield points. You need a library (executor) to run that Future (execute that function). 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).
Is there any thought to including a default executor in the standard library? I think it's kind of an obstacle for beginners when the language/stdlib provide all the tools to write async code, but not to run it. 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 fe…
I really really hope this never ever happens. Tokio is great and all, but enshrining it as the default would have a stifling effect and impose a lot of design decisions all over the place. 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.
We poor embedded developers are always forgotten :( 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".
Earlier quoted context omitted.
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#.
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…
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.