Mikhail Klemin — that is fair point…the basic example is purposefully terse and leaves out the logic for waiting for all work to complete. I wanted to highlight the main point of how a buffered channel provides semaphore behavior.
Hi Shashank Kharehare,
I would be skeptical for using this particular data-structure in that scenario similar to a Redis use case. The reason is because this data-structure lends itself to read-heavy scenarios where the keys are not changing too much during the life of the service. In that sense, it might be a good candidate…
So even if you have a single writer to this map unsynchronized concurrent reads will lead to a data race. This is a situation that can lead to a crash or worse cause undefined behavior in your app.
The case you describe definitely calls for some type of synchronization. As a test try running your app with the race dectector…
Hi John, the only way to know for sure what is better is if you benchmark your use case and take measurements under your production load. If you have a single writer, multiple reader scenario than I would say yes it’s generally better to stick with the normal map using perhaps a RWLock until you find this to be a point of contention.
Interesting — can you point me to what features or documentation suggest they are moving towards inheritance?
There is a difference in offering ways to simulate OOP vs actually having legit classes with real inheritance in my mind.
Hi Evan Zamir,
I have pretty much zero experience with Haskell but I’d say perhaps that Rust could be a good consideration where you want/need the real-time performance since there’s no GC overhead. Additionally, Rust has some major influence from Haskell but still offers an imperative model with some functional flavors.
You are very welcome! If I helped even just a single person to consider the languages and thoughts in this article I’ve done my job. I really appreciate your feedback and with the limited hours we have each day, hopefully this gets you one step closer to achieving your goal.