91–100 of 101 posts
Earlier quoted context omitted.
> I am surprised it hasn't caught on better in the multi-core world, it being older than even Erlang. Because multicore support in Ocaml has been "just a couple years away" for many years now.
Occam, not Ocaml. They are two different languages. Although I have no idea if Occam can utilize multiple cores.
People having been saying this for decades and while it's true, concurrency is still widely regarded as 'too hard'. I'm not sure if this is justified (e.g. concurrency is inherently too hard to be viable), or due to the lack of tooling/conventions/education.
The rise of async programming in backend web dev is making some people even more confused about models. For instance, many senior engineers out there don't understand the difference between sync multithreaded and async single threaded.
Earlier quoted context omitted.
> no programs needed changing at all to get the full advantage of all the cores (barring some special cases) Some programs just don't have any available parallelism in them - no matter how many processes you split them up into. You need to build parallel algorithms and data structures. That's still often a research-level topic. Erlang's not going to magic parallelism out of thin air in a program that doesn't have any…
Kind of strawmanning here, no? Obviously sequential tasks are run sequentially. The OP isn't saying "magic" happens. Just, Erlang was written from the beginning to encourage parallelized code. Its whole programming model is around that. Unlike pretty much every language it was contemporary with, which assumed that the default was a single unit of execution (and that code running in parallel was the exception). Think…
People having been saying this for decades and while it's true, concurrency is still widely regarded as 'too hard'. I'm not sure if this is justified (e.g. concurrency is inherently too hard to be viable), or due to the lack of tooling/conventions/education.
The rise of async programming in backend web dev is making some people even more confused about models. For instance, many senior engineers out there don't understand the difference between sync multithreaded and async single threaded.
Earlier quoted context omitted.
Shared memory spaces. Your "slick tooling" is one of the hacks I mentioned that history will forget, by the standard of "if a new language emerged that tried to call that 'concurrency' nobody would take it seriously". I should say that "hack" here isn't necessarily a perjorative. There are reasons for communities to create and deploy those. There are plenty of cases where existing code can be leveraged to work better…
You're saying that shared memory concurrency is the future? I think you've got it completely wrong. Shared memory concurrency is the past. It was thought to be a good idea in the 80s and 90s, but we now know that it's both hard to program, and that it works poorly with highly-parallel, high-performance hardware. In the future, we'll see more and more programming systems which don't provide shared memory concurrency a…
Earlier quoted context omitted.
You're saying that shared memory concurrency is the future? I think you've got it completely wrong. Shared memory concurrency is the past. It was thought to be a good idea in the 80s and 90s, but we now know that it's both hard to program, and that it works poorly with highly-parallel, high-performance hardware. In the future, we'll see more and more programming systems which don't provide shared memory concurrency a…
Shared memory space , not necessarily shared memory. I referenced Erlang & Pony after all so it's not like I'm unaware of the issues here. You don't need a full OS process boundary to separate things; it is a very crude and blunt instrument and there are much better options available. Separation is nice but paying to cross OS boundaries with every message kills performance dead. A full OS process boundary between all…
One thing I’d love to do is a Smalltalk implementation where every message is processed in a separate thread. Could be a nice educational tool, as well as a great excuse to push workstations with hundreds of cores.
Snarkiness aside, that would be interesting. Not just as an educational tool, but it might be useful in the same way as erlang is (large, fault-tolerant, massively parallel systems). But with OOP instead of FP (Elixir attempts to be the "friendly"/more conventional version of erlang, but it is still very much a functional language).
Earlier quoted context omitted.
Shared memory space , not necessarily shared memory. I referenced Erlang & Pony after all so it's not like I'm unaware of the issues here. You don't need a full OS process boundary to separate things; it is a very crude and blunt instrument and there are much better options available. Separation is nice but paying to cross OS boundaries with every message kills performance dead. A full OS process boundary between all…
"Memory space" is usually called "address space". And I think you're confused - context switching is expensive but there's no context switching involved when you're running in parallel across N cores. We're talking about parallelism, not concurrency.
But I guess we'll just have to leave it there.
One thing I’d love to do is a Smalltalk implementation where every message is processed in a separate thread. Could be a nice educational tool, as well as a great excuse to push workstations with hundreds of cores.
Isn't that just erlang? Snarkiness aside, that would be interesting. Not just as an educational tool, but it might be useful in the same way as erlang is (large, fault-tolerant, massively parallel systems). But with OOP instead of FP (Elixir attempts to be the "friendly"/more conventional version of erlang, but it is still very much a functional language).
One thing I’d love to do is a Smalltalk implementation where every message is processed in a separate thread. Could be a nice educational tool, as well as a great excuse to push workstations with hundreds of cores.
Another idea is this: in the ST-80 VM, the only "real" thing at the OS level is SmallInteger. Everything else is a true object reference. One could imagine expanding the base integer size to 128 bits and having all references also described at that size. The reason to do this would be that IPv6 uses 128-bit addresses, and therefore we could bind object references to IP addresses at a lower level.
That aside, the fact that the Opensmalltalk VM is made inside of Smalltalk means that -- in theory -- a team could iterate to that point using the environment itself.