81–90 of 145 posts
There is dialyzer, a static type (and not only) analysis tool for Erlang. It is part of Erlang/OTP (i. e. built-in.)
I'm a bit surprised that there didn't appear to be any mention of Clojure's built-in concurrency support outside of basic immutability. core.async gives a nice channel-based system, agents give an actor-ish system, and STM/atoms let you mutate the variable safely, without having to manually work with locks. This is definitely a good high-level article, just something I was surprised by, since core.async is what drove…
Whether or not this is "fearless" depends on your point of view. As a long-time pthreads programmer, these systems feel like skittish concurrency. It's for folks who are too afraid to use the underlying concurrency primitives, like shared memory, synchronization of some kind provided by OS, threads.
I've done a fair amount of pthread work, and I coded myself into enough hard-to-debug issues in C that when I discovered I could fairly-easily structure my stuff around ZeroMQ, and then later discovering a book on different process calculi, I decided that there's no way I can go back to doing the low-level stuff. I'm just not smart enough to handle any kind of elaborate threaded programming.
Earlier quoted context omitted.
The idea of STM has nothing todo with strong types. You can have STM with types or without. Clojure has a full STM since version before version 1.0. Simple example: (def stm (refs {})) (alter! stm assoc :testkey "testvalue") (println @stm) See: https://clojure.org/reference/refs
Important part of STM is that the retry mechanism requires functions to be pure - which haskell compiler will check for you.
What's great about the actor model is that you can kinda apply it in languages not having such native support. Even if it will not be a strict model, with some education from the programmer it can do wonders and can be backed by lock free queues. What I see as a problem is always they for a thread to wait on new items a syscall must be executed which is costly. But one could use a spinlock a few cycles and later degr…
* they really do need M:N threading (M green threads for the actors, N system threads where N ~= #CPUs),
* message queues have some complexities; it's not hard to get into a situation where messaging costs overwhelm actual work. Also, you need some form of back-pressure to keep a fast producer/slow consumer from killing everything.
Pony is actually a pretty sweet design for all of these. Complicated, though.
I'm a bit surprised that there didn't appear to be any mention of Clojure's built-in concurrency support outside of basic immutability. core.async gives a nice channel-based system, agents give an actor-ish system, and STM/atoms let you mutate the variable safely, without having to manually work with locks. This is definitely a good high-level article, just something I was surprised by, since core.async is what drove…
It’s also worth noting that almost nobody uses agents or STM (except for some highly specific use cases, but I’ve never seen them in years), and core.async is a library, not a part of Clojure (which is a good thing, because it promotes choice and keeps the language small).
As for the general use case, atoms and core.async are great tools, and I haven't needed to use refs (aka the STM) for years.
I'm a bit surprised that there didn't appear to be any mention of Clojure's built-in concurrency support outside of basic immutability. core.async gives a nice channel-based system, agents give an actor-ish system, and STM/atoms let you mutate the variable safely, without having to manually work with locks. This is definitely a good high-level article, just something I was surprised by, since core.async is what drove…
It’s also worth noting that almost nobody uses agents or STM (except for some highly specific use cases, but I’ve never seen them in years), and core.async is a library, not a part of Clojure (which is a good thing, because it promotes choice and keeps the language small).
I mentioned in an edit that I realized core.async is a library. It's still first-party, so it's still somewhat idiomatic.
I'm a bit surprised that there didn't appear to be any mention of Clojure's built-in concurrency support outside of basic immutability. core.async gives a nice channel-based system, agents give an actor-ish system, and STM/atoms let you mutate the variable safely, without having to manually work with locks. This is definitely a good high-level article, just something I was surprised by, since core.async is what drove…
Earlier quoted context omitted.
It’s also worth noting that almost nobody uses agents or STM (except for some highly specific use cases, but I’ve never seen them in years), and core.async is a library, not a part of Clojure (which is a good thing, because it promotes choice and keeps the language small).
I did use agents in the past, but stopped since core.async became available: it addresses the use cases for agents in a much more flexible way. Also, I found that handling errors in agents is difficult. As for the general use case, atoms and core.async are great tools, and I haven't needed to use refs (aka the STM) for years.
I was really excited to discover Pony a couple of years ago, sadly there is negative momentum with this project. So much potential, yet the world isn’t ready for it yet.
Or Pony is not ready for the world. I mean, they don't even have arithmetic operator precedences [1]. If you're doing things concurrently it must be something uber-important, like censoring cat pictures, but apparently not arithmetics. [1] https://github.com/aksh98/Pony_Documentation#precedence
Does have a nice readline integration, though.