3 ms·
Mostly through either self-inflicted pain of languages that got its concurrency primitives wrong or ended up having it too complex to be useful before we arrive
by neonsunset 3y ago
Mostly through either self-inflicted pain of languages that got its concurrency primitives wrong or ended up having it too complex to be useful before we arrived upon better ways.
Naturally, this is not to say the language designers were bad at it, far from it! It just took the benefit of the hindsight and time due to non-uniform knowledge propagation throughout the industry to nail them down as can be seen in Rust and C# in the form of async/await and Futures+Tasks and CSP-style in the form of Elixir and Go.
Today, Rust makes it trivial (given the tradeoffs) to achieve such even in bare metal scenarios with custom executors, while C# offers zero-effort model for general purpose scenarios:
using var http = new HttpClient();
var req1 = http.GetStringAsync("https://news.ycombinator.com");
var req2 = http.GetStringAsync("https://lobste.rs");
Console.WriteLine(string.Concat(await req1, await req2));
- kaba0 3y ago(Safe) Rust only gives you data race freedom, you can still deadlock and livelock. Don’t pretend that it’s a solved problem, because it is not even close to that.
- neonsunset 3y agoI don't, locks are hard. But the impact of locks tends to be way more focused/limited than the area of application of concurrency.
- whaleofatw2022 3y agoAnd yet there is dangerous usage of HttpClient (in parent defense the situation is a mess)
- neonsunset 3y agoHttpClient is thread-safe. The above use case, while not ideal, will work perfectly fine in 95% of situations. (Of course, the "right" way to use HttpClient is to have it be injected via DI or retrieved from IHttpClientFactory, but if all you are doing is writing a script-like CLI utility, there is no advantage to that)