321–330 of 356 posts
Earlier quoted context omitted.
C#, owned by the most ethical company in software. Java is very different and much improved from when c# branched off, but many people haven’t been following along and still think it’s the same as in 2002.
This is 2023 and you are saying that Microsoft is less ethical than Oracle. A lot of things have happened since the 90s, you know?
Earlier quoted context omitted.
I haven't looked into CLR in a long time, but it feels like it has a fraction of JVM's adoption and community size. Microsoft also seems to be prioritizing Typescript and Node internally with its recent moves.
> Microsoft also seems to be prioritizing Typescript and Node internally with its recent moves. You may want to look at Blazor Webassembly ( https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz... ) and Blazor United ( https://devblogs.microsoft.com/dotnet/asp-net-core-updates-i... ) They scrapped the old CLR and started over with a new "CLR Core". Then they ported the new CLR Core along with the framework BC…
Earlier quoted context omitted.
When I’ve asked chatgpt to explain something to me that I’m very knowledgeable about, distributed systems, it was flat out wrong about many fundamentals in a way that would have seemed completely plausible to a novice. It was making up algorithms, complete with fake but believable names, to solve problems that are provably unsolvable. My wife, a physician, reported similar errors when I got her to ask it medical ques…
You have to provide more context, so that it has something to bridge in the high dimensional space. > The Byzantine Generals Problem is a more difficult problem than the Two Generals Problem because it requires a consensus algorithm that can tolerate the presence of faulty actors. There are many solutions to the Byzantine Generals Problem, including Byzantine Fault Tolerance, which is a common technique used in distr…
Earlier quoted context omitted.
Yes. And with "records" (record classes, something with the characteristics of a tuple or struct) you can get further away from getter/setter boilerplate code.
I just wish records had an easy way to facilitate and/or associate a builder with them. Wishful thinking, out of scope for what they are. And of course, it's not hard to write a FooBuilder that's defined to help construct a Foo record. If Java records could be told to have a private constructor, I'd be completely satisfied with them. I just don't like the ability for callers to be able to directly instantiate a recor…
Such validation logic can be enforced in the record's compact constructor.
Structured concurrency looks a lot like C#'s Task library without the async/await sugar but with the exact same footguns. Joining into a synchronous function is an anti-pattern in C# because you consume threads. This seems to be the same, except with the assumption that virtual threads are fine.... But that's not an assumption that can be made by the method writer, right?
Tasks aren't threads in TPL.
Structured concurrency looks a lot like C#'s Task library without the async/await sugar but with the exact same footguns. Joining into a synchronous function is an anti-pattern in C# because you consume threads. This seems to be the same, except with the assumption that virtual threads are fine.... But that's not an assumption that can be made by the method writer, right?
Tasks aren't threads in TPL.
Earlier quoted context omitted.
This is impossible because of *gasp function coloring. You can't just make a sync function async without dealing with the fallout explicitly in c#.
You can make an async function contain an await at more places than it previously had. When writing code in colored languages your code tends towards lots of stuff being marked async, so more 'await' points being introduced can change behavior.
Earlier quoted context omitted.
> low resource usage of async/await Will calling a coroutine do zero heap allocations like async in Rust? > with the ease-of-use experience of threads That's highly subjective. Threads usually require locking which is often hard to get performant and correct at the same time. Async/await allows to write concurrent code with no synchronization.
> Async/await allows to write concurrent code with no synchronization. Hmm,I don't see how async/awaits makes a difference. Care to explain? Like, if you have multiple sources that can add or read from a queue, unless there is a single thread running all your async loops (ala python), you still need some synchronization. At least that's my experience using coroutines heavily in kotlin.
let mut buffer = ... // create buffer for holding data
let mut input: TcpStream = ... // connect to remote endpoint
let mut output: TcpStream = ... // connect to remote endpoint
loop {
select! {
_ = input.readable() => {
input.try_read(&mut buffer)?;
}
_ = output.writable(), if !buffer.is_empty() {
output.try_write(&mut buffer)?;
}
}
}
Synchronization is achieved implicitly by the fact that sequential code executes in only one place at once, so when it executes the reading branch, it does not execute the writing branch. You can apply exactly same reasoning as with any single-threaded, sequential code.
You cannot model this easily with threads. If it was a single thread with blocking I/O, then it could block forever in one branch and stop reacting to events on other branches. If it were multiple threads, then they would somehow need to synchronize accesses explicitly to the shared buffer.
Earlier quoted context omitted.
GNU Pth had "automagically turning blocking operations into non-blocking" ages ago, and it wasn't the first. I think what you probably had in mind is that C libraries of the 90s that did M:N threading didn't turn blocking operations into non-blocking? Using blocking operations to switch contexts is really nothing new. Heck, the cooperative multi-tasking systems of the 80s (Mac, Amiga) all essentially did that for pro…
> I think what you probably had in mind is that C libraries of the 90s that did M:N threading didn't turn blocking operations into non-blocking Yes, mostly, though my history knowledge is definitely lacking so do correct me if I’m wrong. But you are right, there was nothing fundamentally missing, probably just no good OS support for non-blocking IO calls in the early days? Though probably the IO-CPU ratio was also di…