It seems to me that where we really ended up was distributed systems. We solve problems by not just making our code concurrent to use more cores, but by also making it use more computers.
The free lunch is over: a fundamental turn toward concurrency in software (2005)
81–90 of 101 posts
Re: The free lunch is over: a fundamental turn toward concurrency in software (2005)
#82I find it interesting that the language that best deals with parallelism (IMO) was invented significantly before we moved in the multi-core direction. The programming language landscape evolved and developed in the face of multi-code - async being a classic example. But the language that's often held up as the best solution to any given parallelism problem is Erlang. Erlang was built as a good programming model for c…
But the language that's often held up as the best solution to any given parallelism problem is Erlang.
Occam implements a lot of similar ideas very neatly too. The code looks a lot like programming with Go channels and CSP. I am surprised it hasn't caught on better in the multi-core world, it being older than even Erlang.
Re: The free lunch is over: a fundamental turn toward concurrency in software (2005)
#83I agree with this article a lot. The layers over layers of software bloat increased with the hardware speed. The general trade-off is: We make the software as slow as possible to have the shortest development time with the least educated programmers. "Hey web dev intern, click me a new UI in the next two hours! Hurry!" This intern-clicks-a-new-UI works because we have a dozen layers of incomprehension-supporting-tech…
The point about skill is absolutely key.
Two types of engineer now exist: Those that are largely "code monkeys" implementing features using high level tooling and guard rails and those that are responsible for building that tooling and low level components. FWIW I've met plenty of engineers even from FAANG companies with fairly limited exposure to writing performant software.
Over time, the former bucket has grown significantly as barriers to entry have dropped but this has led to extremely bloated and inefficient codebases. Deployment patterns like micro services running on container orchestration platforms mean that it's easier to scale bad code horizontally pretty easily and these "high level frameworks" are generally "good enough" in terms of latency per-request. So the only time efficiency ever becomes a concern for most companies are when cost becomes an issue.
It'll be interesting to see how this all unfolds. I wouldn't be surprised if the huge incoming supply of unskilled engineers doesn't cause compensation to drop significantly in general.
Re: The free lunch is over: a fundamental turn toward concurrency in software (2005)
#84It seems to me that where we really ended up was distributed systems. We solve problems by not just making our code concurrent to use more cores, but by also making it use more computers.
There are security and latency issues that make distributed over multiple cores != multiple processors != multiple computers.
Each step adds more complexity.
Re: The free lunch is over: a fundamental turn toward concurrency in software (2005)
#85I find it interesting that the language that best deals with parallelism (IMO) was invented significantly before we moved in the multi-core direction. The programming language landscape evolved and developed in the face of multi-code - async being a classic example. But the language that's often held up as the best solution to any given parallelism problem is Erlang. Erlang was built as a good programming model for c…
But the language that's often held up as the best solution to any given parallelism problem is Erlang. Occam implements a lot of similar ideas very neatly too. The code looks a lot like programming with Go channels and CSP. I am surprised it hasn't caught on better in the multi-core world, it being older than even Erlang.
> 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.
Re: The free lunch is over: a fundamental turn toward concurrency in software (2005)
#86Earlier quoted context omitted.
But the language that's often held up as the best solution to any given parallelism problem is Erlang. Occam implements a lot of similar ideas very neatly too. The code looks a lot like programming with Go channels and CSP. I am surprised it hasn't caught on better in the multi-core world, it being older than even Erlang.
> 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.
Re: The free lunch is over: a fundamental turn toward concurrency in software (2005)
#87Earlier 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.
Occam was designed for the Transputer, which was intended to be used in arrays of processors, hence it being based on CSP principles.
So, yes. it can.
Re: The free lunch is over: a fundamental turn toward concurrency in software (2005)
#88Earlier quoted context omitted.
Occam, not Ocaml. They are two different languages. Although I have no idea if Occam can utilize multiple cores.
Occam was designed for the Transputer, which was intended to be used in arrays of processors, hence it being based on CSP principles. So, yes. it can.
TIL
Thank you!
Re: The free lunch is over: a fundamental turn toward concurrency in software (2005)
#89I find it interesting that the language that best deals with parallelism (IMO) was invented significantly before we moved in the multi-core direction. The programming language landscape evolved and developed in the face of multi-code - async being a classic example. But the language that's often held up as the best solution to any given parallelism problem is Erlang. Erlang was built as a good programming model for c…
But the language that's often held up as the best solution to any given parallelism problem is Erlang. Occam implements a lot of similar ideas very neatly too. The code looks a lot like programming with Go channels and CSP. I am surprised it hasn't caught on better in the multi-core world, it being older than even Erlang.
I had to double check, the last Occam release was in 1994. I think the language was way to niche, and global communication way too poor still (compared to the '00s and '10s with ubiquitous or near ubiquitous internet access) to catch on. It was nearly a decade later that the first consumer multicore x86 processors started coming out (2003 if I've tracked down the right dates). And multicore didn't become common for a few more years and then the baseline near the end of the '00s, beginning of the '10s.
That time gap and relative unknown of Occam pretty much doomed it even if it would have been wildly useful. By that point you had lots of other languages to come out, and Google pushing Go.
Re: The free lunch is over: a fundamental turn toward concurrency in software (2005)
#90I agree with this article a lot. The layers over layers of software bloat increased with the hardware speed. The general trade-off is: We make the software as slow as possible to have the shortest development time with the least educated programmers. "Hey web dev intern, click me a new UI in the next two hours! Hurry!" This intern-clicks-a-new-UI works because we have a dozen layers of incomprehension-supporting-tech…
The point about skill is absolutely key. Two types of engineer now exist: Those that are largely "code monkeys" implementing features using high level tooling and guard rails and those that are responsible for building that tooling and low level components. FWIW I've met plenty of engineers even from FAANG companies with fairly limited exposure to writing performant software. Over time, the former bucket has grown si…
To save money on infrastructure you need to pay your engineers more. Companies are choosing to hire cheaper engineers as they are the ones that are harder to replace.