Crazy guy here to say that everyone is looking in the wrong direction. Functional, Imperative, Excel spreadsheet-driven, who cares? Computation is not the frontier anymore. Most software is now built across networks and collections of computers (UIs/embedded being the large exceptions). What do we have to gain by min-maxing programming a single machine? The glacial pace of innovation in this space since ~1990 should be a big wake up sign. The future is wrangling distributed systems, which is something that single-machine Turing complete languages like to pretend is somebody else's problem.

you might be interested in this talk about research on distributed programming languages

Not a critical mass for us to find each other I suppose! Thanks for the talk; will watch later today.

I spent time in the past building/maintaining distributed systems in industry before returning/retreating to single-core research in my spare time. Reasons I did so: a) There’s value in building distributed systems out of robust parts that do what they say they’ll do. b) There’s value in being able to state distributed systems guarantees as tests that can run on a single machine (simulating multiple machines). c) There’s value in making it tractable to step through and debug distributed system scenarios simulated on a single box.

I think it's all about what problem you are trying to solve. Different problems may be unrelated. Is biggest problem of our industry UI of computing or hardness of distributed system programming? Other is related how productive one current (significant?) subarea is and other is (mostly?) about how can we empower more people with it. Very different perspectives and I think you cannot say that looking either one you are looking a wrong direction 😛

Distribution brings availability (redundancy, system health, etc.), and as far as I know, that's really the only benefit over massive single machines.

I agree (and have ranted here before) that changing programming languages doesn’t accomplish much. I think improving single-threaded runtimes does help, and may make seemingly difficult problems in distributed computing more tractable. Today you often have to communicate criteria like idempotence in comments, and guarantees can be violated from inexperience, etc. Making it easy to test for such guarantees would be helpful. A language that provided such “type checks” would be huge.

I'm in complete agreement. Not only distributed programming, but other "side effects" are simply left to be solved "somehow" outside the programming environment. Persistence, versioning, authentication, building, I/O, UI all come to mind - old-school ALGOL is like a paradise compared to the tools we have to use to deal with these "extra" concerns, and as a result they take up a disproportionate part of development time

YES! The original comment resonated quite well with me. It's not that I don't prefer certain languages or think they make no difference. But the unquestioned assumption that the way to do large scale computation is to do 'small programs first' individually compiled and then tied together later needs a rethink.

You've all fallen for my trap--now its time to swoop in with the self-promotion! https://strat.world/ is a language for systems, and has the audacity to not even be Turing complete!

My hot take: we should be using the same programming language we use for the 10 LoC of business logic to maintain the specifications we currently use hundreds of lines of yaml, framework code, tooling, etc. And it should all be type-checked. And it should all have tests. (Because the 10 LoC have 40 LoC of tests, right? Right?) And you can prototype these in a single-machine language. It’s about choosing the right interfaces for the syscalls by which a computer interacts with its environment (including for bringing up and sending instructions to other computers). Is that what strat.world does? Or are you assuming a bunch of conventions? In which case the examples I want to see are about how people would go about violating your opinionated conventions.

@Kartik Agaram there's a lot to unpack there; I'll have to think about it and get back to you

I disagree that gcc trying to match hand-crafted assembly has been a net positive for the world. But that’s a lengthy tangent 🙂 Not sure I follow your rephrasing of my comment, so let me try new words: our distributed systems today are not robust because we can’t easily simulate network partitions, high network latency and other such environmental factors. It’s possible to do so but it’s expensive and tests take forever to run so there’s huge pressure against writing lots of such tests. What I want to see is an OS that allows me to easily write tests simulating multiple computers with various settings for the environment between them. The reason it has to be in the OS is to keep the simulation cost low, and to provide verisimilitude in the simulation. The right way to deal with environmental problems actually depends a lot on how your underlying platform responds to various circumstances. You can’t just live at the app layer.

@shalabh How would you start? With a top-down language and follow up with the nitty-gritty bits?

@Charlie yes something like that. I feel distribution is just and implementation detail and there's a larger algorithm/process that may be described without coupling to the distribution mechanism details. It could then be refined by layering on details, perhaps in a separate code artifact. This is a little bit like generic programming, but at the system level. E.g. I code to the List API but then make a separate choice about which specific implementation is used. At a system level I'd describe higher level processes that the entire cluster should implement, and separately define how it maps onto the machines. BTW, I already was intrigued by strat.world when you posted your intro as I'm interested in this space (see also darklang, you might also like the book Vertically Integrated Architectures (Jos Jong)).

End result: hundreds of lines of yaml, framework code, tooling, etc. to host 10 LOC of business logic in a distributed system

Yes, and the logic is tightly couple to the distribution topology as well. This is actually also a problem with single process languages, but less pronounced. E.g. if I change the threading model or persistence strategy (nothing to do with business logic), I still have to fiddle with the business logic bits.

have yall looked into the unison programming language?

Yes, Unison is interesting. Last I looked the focus was more on uniquely identifiable functions that can be run anywhere and not on specifying the higher level processes decoupled from the implementation topology. It's probably worth taking another look.

thank you charlie for this nice provocative post