3 ms·
> data race conditions impossible. Are you sure? Using message passing doesn't magically make stuff immune to races. You Still have to think about atomicity.
by devxpy 8y ago
> data race conditions impossible.
Are you sure? Using message passing doesn't magically make stuff immune to races. You Still have to think about atomicity.
Here is an excerpt from the documentation on my multiprocessing library, zproc.
http://zproc.readthedocs.io/en/latest/user/atomicity.html http://zproc.readthedocs.io/en/latest/user/atomicity.html
- jaytaylor 8y agozproc looks like am interesting approach to concurrency in python. For anyone else curious about it, here is the github project: https://github.com/pycampers/zproc https://github.com/pycampers/zproc
- devxpy 8y agoHonestly though, it Just a really fancy wrapper over zmq. I just gave everything I learned from the zmq guide a pythonic interface. :)
- YorickPeterse 8y ago> Are you sure? Using message passing doesn't magically make stuff immune to races. > You Still have to think about atomicity Sure, _just_ using message passing doesn't do much. But Inko doesn't have shared memory (well apart from a permanent heap, but that's a different story and it has a very specific purpose). Perhaps I phrased things the wrong way, but the idea is that because there's no shared memory, you can't have data races due to concurrent modifications.
- devxpy 8y agoHappens with me too. I sometimes don't realize how my words come out. Anyway, is there any reason as to why one would not use more mature languages like erlang and recently, dart? They also have the concept of isolates, that can't share memory. Apart from the written in rust part which is really cool.
- YorickPeterse 8y ago> Anyway, is there any reason as to why one would not use more mature > languages like erlang and recently, dart? Considering Inko is still very new, right now there isn't really a reason that justifies using it in production. Of course in a year or two (depending on how fast things go) that might completely changes. Ignoring the maturity aspect, Dart and Inko are pretty different. Dart focuses more on browsers and mobile (with Flutter), whereas Inko focuses more on backend services (a web app, a key/value store, that kind of thing). In case of Dart the focus directly affects the language, as for example symbol mangling (to compress the source code) means reflection is harder (IIRC Dart's mirror implementation is in a state of limbo because of this). Erlang is much closer to Inko conceptually, though the two languages are quite different, with Erlang being functional and Inko being object-oriented. Competing with Erlang will be very hard: it's well established, mature, has a healthy ecosystem, etc. Apart from the paradigm, I hope that Inko will eventually have three big benefits over Erlang: 1. A better garbage collector, which translates to shorter pause timings, better use of memory, etc. 2. A JIT. Inko doesn't have one at the moment, but it will have one eventually. How long this takes I don't know. I'm not comfortable using LLVM as its GC support is spotty (at least last I checked it was pretty much still a nightmare), it breaks APIs every release, and every Linux distribution ships a different (incompatible) version. I'm hoping somebody writes a somewhat decent JIT library in Rust that I can use, but so far there have only been basic building blocks made such as https://crates.io/crates/dynasm https://crates.io/crates/dynasm. For Erlang there have been various attempts at writing a JIT, but I believe none of those ever made it to a production state. 3. Inko will be simpler. It's error handling model means you don't have to monitor processes, as they can't crash unexpectedly (unless there is a bug, which you shouldn't handle at runtime). Combined with the gradual typing aspect I can see Inko being much less frustrating to use, be it for a small prototype or a large application.