81–90 of 253 posts
Totally off topic but I am getting tired of the AI generated images used on nearly all blog posts nowadays. They are instantly recognisable, it just seems low effort and lowers the feeling of quality one might otherwise have
Stock images used to hide this "quality" better than I thought.
Earlier quoted context omitted.
I prefer AI generated images over stock photos though. You can tell that both are phony, but at least the AI can be a bit more creative.
I prefer no images over IA stolen/generated images.
> Does your page design improve when you replace every image with William Howard Taft?
> If so, then, maybe all those images aren’t adding a lot to your article. At the very least, leave Taft there! You just admitted it looks better.
Erlang is based on virtual threads (confusingly called processes). The Erlang virtual machine schedules them on OS threads. Erlang processes communicate using message passing, preventing deadlocks. You can use millions of Erlang processes without problems, e.g., to handle millions of Elixir LiveView sessions.
I am extremely confused. > There are two scenarios in which a virtual thread cannot be unmounted during blocking operations because it is pinned to its carrier: > When it executes code inside a synchronized block or method Isn't 'synchronized' effectively sugar for taking a kind of lock? Why can't it be treated uniformly by the scheduler?
No, synchronized is a very primitive lock implementation compared to what's available in java.util.concurrent.Locks. However, it's built directly into the JVM specification, so it's difficult to change while keeping compatibility, while j.u.c.Locks is just a library. In other words, they can't change synchronized schematic, so they created j.u.c.Locks as a replacement.
Actually, it is trivial to change. Just embed a ReentrantLock into every object and rewrite all calls to "synchronized"/"Object.wait" to use that lock.
Unfortunately, this would result in a bit of performance regression (increasing per-object memory footprint). To solve that would require turning ReentrantLock into a magical intrinsic, fully integrated with lock bytes in the object header. Which is actually not that hard either — other runtimes like Golang or Android VM solve problems like this on daily basis. Oracle, however…
Earlier quoted context omitted.
Not really. I wish the trend of giant generic hero images on every blog post would go away, they almost never add any value. I think it was Medium that started the trend.
Unfortunately all social media sharing requires a thumbnail for easy clicking, no real way around it. (with Hacker News as the lone exception of course) The default thumbnails in lieu of your own aren't good.
"Don't replace platform/native threads with virtual ones, replace tasks (without further explanation) instead"?!
Combine that with the fact that they chose to implement the scheduler in Java instead of C(++) and you're set for performance problems.
Remember that NIO took from 1.5 to 1.7 to be usable/performant and that was native!
Edit: Finally figured out why: https://news.ycombinator.com/item?id=39010648
Totally off topic but I am getting tired of the AI generated images used on nearly all blog posts nowadays. They are instantly recognisable, it just seems low effort and lowers the feeling of quality one might otherwise have
Earlier quoted context omitted.
Is that all that's happening here? There's an implicit limit on real threads, where before it was unlimited by virtue of not using the virtual thread's limited pool? If it doesn't spawn threads when all of them are blocked, that seems kinda dumb. And a severe change in semantics. It can be conservative and try running unpinned ones on fewer threads and shuffle them around and slowly spawn more to ensure eventual prog…
My long held belief: green/user-level/M:N threading schemes never work at first, and only work reliably after extreme effort has been put into fixing all the cases where blocking code gets called underneath. afaik there are only two modern working implementations: golang and erlang. This article is consistent with that belief.
For example, https://pkg.go.dev/runtime#LockOSThread