41–50 of 57 posts
Meanwhile, Java just upped the game of virtual thread with https://mail.openjdk.org/pipermail/jdk-dev/2024-October/0094...
https://github.com/dart-lang/language/blob/main/working/333%...
Earlier quoted context omitted.
How do you handle errors when reading from a channel?
data, ok := If ok is false, the channel is closed and data is a zero value.
You do need to use either two channels (horrible code) or some kind of Result{T,error} wrapper (bad language design).
Earlier quoted context omitted.
It's also unintuitive in the sense that if you are racing you usually want to discard/stop the other Promises that didn't finish in time. But the only real way to do this is to pass through an AbortController down into whatever networking/IO task (and your own code for that matter) is happening to "cancel" it that way. Otherwise you just end up with the result of the fastest Promise and the rest will continue when th…
I thought the point of using observables over promises is that they have cancellation, and presumably an implementation of race would cancel any slower request (i.e., handle the abort controller automatically)? Is that not the case?
guy is using unbuffered channel and wonder why it working slow, lol
Concurrency in Go is overrated; channels are error-prone and not as flexible as they probably could/should be. Though, I honestly find moderately complex Go code far easier to maintain than moderately complex RxJS code, having had both in my career at different times. That said I will admit that sometimes having the RxJS toolkit at your disposal makes solving some problems very easy. It's just that when I construct a…
> Concurrency in Go is overrated; channels are error-prone and not as flexible as they probably could/should be. Channels in Go indeed could be better designed and more extensible. However, they are not the only way to use the Go concurrency. There are usual condition variables, mutexes, etc.
Concurrency in Go is overrated; channels are error-prone and not as flexible as they probably could/should be. Though, I honestly find moderately complex Go code far easier to maintain than moderately complex RxJS code, having had both in my career at different times. That said I will admit that sometimes having the RxJS toolkit at your disposal makes solving some problems very easy. It's just that when I construct a…
I argue CSP is far superior to async/await in almost all cases. In Go errors are explicit and always right there. No weird control flow like you see in javascript.
JS concurrency is crap. It should be shot and buried in a lead coffin. Debugging async code is pure hell. With Go, you have a normal debugger that can be used to step over the code. You can get normal stack traces for all threads if needed. There is a race detector that can catch most of unsynchronized object access. With JS? You're on your fucking own. You can't find out the overall state of the system ("the list of…
The workaround? Chuck async code in the bin, in my case replace the await fetch() calls with synchronous XMLHttpRequest requests. Problem solved, even if MDN tries to discourage one to use sync XHR because fetch is the new hotness.
I wish I wasn't so broke that I have to accept JS contract work to pay the bills. JavaScript, and its async/await implementation should be thrown into the flaming sun.
I always found RxJS fairly awkward. I assumed it was a skill issue (and I still think it is), but gradually learned it for personal and professional projects. It's fine. I avoid it now. I think Go is orders of magnitude better in terms of general concurrency tooling, though I know some people straight up hate it. I've recently started using Effect, the TypeScript library, and I find it's so much better than RxJS as w…
My biggest issue with RxJS is that it is so easy, that you can easily make pretty bad bugs. In particular, you can have a `mergeMap` or a `switchMap`, and with RxJS they are very similar in API. But if you pick the wrong one, it can lead to weird bugs in your application. However, if you would manually program promises and maybe debounce helpers, you would be more likely to program the correct behavior. Still, the ea…
export function pipeline(in$: Observable):
Observable {
return in$.pipe(
mergeMap(product => from(product.Images)),
);
}
return in$.pipe(
map(product => product.Images),
);