Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Zen of Parallel Programming

smolnero.com

Post reply on HN
Print view View original

31–40 of 50 posts

Re: The Zen of Parallel Programming

#31

Post by DavidVoid »

roadbuster wrote: post #22
torginus wrote: post #19

I cannot make sense of a single word of this essay. What sort of insight am I missing? There's not a peep here about write barriers, futexes, OS schedulers, critical paths and/or how they relate to Zen or whatever. This article can be easily recycled as the Zen of compiler design or Zen of audio engineering or whatever, without substantially having to chance much of the words, thats how generic it is. I'm genuinely c…

There is no substance. It's navel-gazing dribble. The "about" section of the website is equally vacuous: SmolNero is a philosophical startup rooted in first-principles thinking. We explore how humans relate to technology— how we speak to it, depend on it, thank it, and sometimes forget it’s there at all. We don’t claim expertise. We see ourselves as translators—working at the crossroads of emotion and programming, cu…

Seems to be run by a married couple of (maybe) burnt out account managers. That, in combination with some AI help, explains the empty "LinkedIn slop" writing style I think.

It's not often I comment on blog posts, but this is honestly one of the most meaningless blogs I've ever read (not counting those fully AI-generated SEO ones). I don't get why it ended up so high on Hacker News; it has an interesting title I guess, but pretty much no substance.

Re: The Zen of Parallel Programming

#32

Post by socketcluster »

I try to find an embarrassingly parallel solution to most problems I encounter. Not only because such solutions scale, but because they often produce a simpler, more robust architecture which helps you to avoid future issues. It's great for avoiding single points of failure and performance chokepoints. Also, there is usually little to no overhead for choosing a parallelizable solution (besides a little bit of additional up-front thinking.)

To people who say "You don't need scalability" I say "You also don't need unscalability..."

Re: The Zen of Parallel Programming

#33

Post by alexpotato »

Best quote over on distributed systems as applied to humans (from Dan Luu):

"Everything we've looked at so far is a technical problem. Compared to organizational problems, technical problems are straightforward. Distributed systems are considered hard because real systems might drop something like 0.1% of messages, corrupt an even smaller percentage of messages, and see latencies in the microsecond to millisecond range. When I talk to higher-ups and compare what they think they're saying to what my coworkers think they're saying, I find that the rate of lost messages is well over 50%, every message gets corrupted, and latency can be months or years"

- from https://danluu.com/sounds-easy/

Re: The Zen of Parallel Programming

#34

Post by gwbas1c »

pjio wrote: post #26

Aside from the sentence "How many experiences continue to consume us because they were never allowed to finish burning?", I'm not sure what to make of this article. But the book it mentions, "Zen Mind, Beginner's Mind", seems worth taking a look at (an older one, not a promotion).

Yes, the article really only makes sense if you're both practiced Zen and done some intense parallel programming.

"Zen Mind, Beginner's Mind" makes more sense in a group setting. I read extracts of it with a Zen priest in a meditation group.

Re: The Zen of Parallel Programming

#35

Post by gwbas1c »

torginus wrote: post #19

I cannot make sense of a single word of this essay. What sort of insight am I missing? There's not a peep here about write barriers, futexes, OS schedulers, critical paths and/or how they relate to Zen or whatever. This article can be easily recycled as the Zen of compiler design or Zen of audio engineering or whatever, without substantially having to chance much of the words, thats how generic it is. I'm genuinely c…

> What sort of insight am I missing?

The article makes a lot more sense if you've practiced Zen.

Think of it as someone's way of making sense of Zen teachings by related them to something they already understand.

Re: The Zen of Parallel Programming

#36

Post by bunderbunder »

torginus wrote: post #19

I cannot make sense of a single word of this essay. What sort of insight am I missing? There's not a peep here about write barriers, futexes, OS schedulers, critical paths and/or how they relate to Zen or whatever. This article can be easily recycled as the Zen of compiler design or Zen of audio engineering or whatever, without substantially having to chance much of the words, thats how generic it is. I'm genuinely c…

It is. The next post in the blog expands on the idea in concrete terms. The author doesn’t explicitly say so, but based on the shape of it I would assume all we have right now are the introduction and first full post of what is intended to be a multi-part series.

Re: The Zen of Parallel Programming

#37

Post by bunderbunder »

baud9600 wrote: post #27

It’s true that “zen of” is bolted onto many topics… it’s a tired cliche to suggest “simplicity” when things are complex. Does it help or is it faux spirituality? I’ve enjoyed reading the comments here and I think there’s truth in how the technical problem is divided and teams are arranged. The idea of frequency of features (or builds) being a reflection of our division of the problem, is interesting. It made me think…

(Speaking as a lapsed participant in a zen community. Opinions are my own, so others may disagree.)

The challenge for these “Zen and my job” types of work is that much of Zen practice is (deliberately) a bit of an inkblot test. If there’s any real Big Truth to it, it’s that it’s all one big muddle that everyone has to muddle through for themself. Unlike in many Western religious traditions, there is no presumption of univocality - even within the canonical literature, every opinion is understood to be the author’s alone and represents their own personal attempts at muddling things through. It’s just that some people and works are regarded as being particularly worth a read.

But that’s never explicitly stated. Which can be particularly confusing to people who grew up in religious traditions that do presume univocality and a greater degree of spiritual authority. Hence these works by people who see one particular bit that clicks for them and conclude, “Ah, this is what Zen is really about, I must go tell others!” without realizing that perhaps they just stumbled across an inkblot that they found to be particularly evocative.

Re: The Zen of Parallel Programming

#38

Post by rramadass »

torginus wrote: post #19

I cannot make sense of a single word of this essay. What sort of insight am I missing? There's not a peep here about write barriers, futexes, OS schedulers, critical paths and/or how they relate to Zen or whatever. This article can be easily recycled as the Zen of compiler design or Zen of audio engineering or whatever, without substantially having to chance much of the words, thats how generic it is. I'm genuinely c…

You are absolutely right.

It is just some daydreaming verbiage trying to connect totally disparate domains in a fanciful manner; nonsense and drivel.

As I continue reading An Introduction to Parallel Programming, I cannot help but notice a connection between communication among processors, communication among human beings, and communication within the individual self.

I say ... Whut?

Re: The Zen of Parallel Programming

#39

Post by trollbridge »

reinitctxoffset wrote: post #16
trollbridge wrote: post #15

Earlier quoted context omitted.

What are you talking about? A properly prompted agent generates a project with a fast, reproducible, and isolatable build. One of the best things about agentic AI is that I spend far less time on devops and on waiting on builds.

There are low-insensity regimes where it's all Python or whatever, and if you're in one, great. When you're dealing with multiple platforms, or hardware accelerators, or mostly all of economically relevant shit in the AI era you don't get a small, clean, fast build. Fable can't print a Tauri faux-native app without dragging in half of LLVM.

For greenfield work, we are using mostly Rust, although small utilities built with Go or Python are also acceptable provided they have a comprehensive set of unit tests, an integration test suite, well-defined specifications and acceptance criteria, and thorough documentation. Once you have that, it's much easier for the AI to work on it. (Our main motivation for doing this is that it takes far fewer tokens now to get stuff done since we have all that, to the point I can leave Qwen 3.6 running in 24/7 loops accomplishing things.)

If your build is bloated and slow, it would seem prudent to go and fix that, possibly converting a codebase from some other language or build system to something that can be built and tested very quickly. Slow builds and slow unit tests are a choice.

Re: The Zen of Parallel Programming

#40

Post by reinitctxoffset »

trollbridge wrote: post #39
reinitctxoffset wrote: post #16

Earlier quoted context omitted.

There are low-insensity regimes where it's all Python or whatever, and if you're in one, great. When you're dealing with multiple platforms, or hardware accelerators, or mostly all of economically relevant shit in the AI era you don't get a small, clean, fast build. Fable can't print a Tauri faux-native app without dragging in half of LLVM.

For greenfield work, we are using mostly Rust, although small utilities built with Go or Python are also acceptable provided they have a comprehensive set of unit tests, an integration test suite, well-defined specifications and acceptance criteria, and thorough documentation. Once you have that, it's much easier for the AI to work on it. (Our main motivation for doing this is that it takes far fewer tokens now to ge…

I'll contend that any Rust build involving Cargo is bloated and slow. `rustc` is impressively slow on a translation unit basis, and Cargo is basically a build recursion bingo card. Throw in about 900 micro point releases in flight at any given time?

If you're not running an elite `bazel` or `buck2` RBE with `nativelink`? You're not even playing.

Post reply on HN