Hacker News Reader

Comment by theamk | Hacker News Reader

Linux has 8MB thread stacks by default, Windows apparently has 1MB ones, and that space is not going anywhere. As long as people are worried about memory, they will need something lighter than threads. (Yes, golang managed to create dynamic stacks, but this required major support from compiler and so unlikely to appear in existing languages).

Also, I think that single-threaded programs, even with co-routines, are just so much nicer than multi-threaded ones. You write "index = last_index++;" and it Just Works (tm), no need to worry about locks or atomics or other thread access.

View on HN

Both windows and Linux let you configure the thread stack size

> Yes, golang managed to create dynamic stacks, but this required major support from compiler and so unlikely to appear in existing languages

That's true but I'm puzzled by the decision rationale. It's undeniably a major undertaking to add first class, fine-grained processes to a language and its runtime. But time invested there gets the multiplicative upside that all language users benefit from the investment. Instead, Async/Await transfers the complexity to users of the language, as TFA describes.

As an Erlang and now gleam developer, I'm continuously grateful for the BEAM's support for fine-grained processes (note these are VM processes, not OS level). If I want to do things in parallel, I spawn a new process to do it. Do I want that concurrency because of io latency or parallel computation? Doesn't matter. Processes handle both. If I want an actor - a long(ish) lived "object" that responds to messages sent to it - I spawn it as a process. If I want to communicate between processes, I send a message. That's the only choice. No shared memory so no semaphores, locks and whatnot.

I never have to think "hmm, should this function be sync or async?" and reason about the transitive implications through the entire call stack. I write functions to calculate values. If I want function A to be called after function B in program 1, I write them sequentially. If I want to run them concurrently in program 2, I spawn them in separate processes. Concurrency is a decision at the calling site, not when writing the function being called.

One concurrency primitive that meets all the needs. The reduction in cognitive load is palpable compared to Python (the other language I use regularly).

The usual reaction is "yeah but performance". I've never found this to be an issue in real life. Sure there are benchmarks that show C/Rust/C#/whatever is faster, often meaningfully so. In practice, for my needs: never been a problem.

I'm ever more grateful for the elegance and consistency of the BEAM concurrency model. From an ergonomic perspective, Async/Await feels like a poor abstraction by comparison.

That's not to say the BEAM (or its languages) is the final word in concurrency. The strong encapsulation boundaries from Structured Concurrency[0] would be a useful addition. Though even there, Erlang's supervisor hierarchies provide a a similar mechanism. Dataflow is another interesting area (many task-concurrent design questions are essentially dataflow problems).

Even without improvement though I'd still take Erlang's approach over Async/Await every day.

[0] https://en.wikipedia.org/wiki/Structured_concurrency

More people think they need a web framework that serves a million requests per second than actually do.

More people think they need the latest and hottest in manual memory management than actually do.

More people think they need a hundred thousand threads than actually do.

If you do have one of those cases, by all means prepare for it and deal with it. But be sure you have one first. The program that exceeds so much as a 100 threads is not only exceptional, but very exceptional. The exceptions are cognitively available and leap to mind, but are nevertheless the exceptions. And, again, if you have one, deal with it, but be sure you have one.

If you're sitting there in TypeScript land writing "async" code you've already surrendered on Ultimate Efficiency anyhow. Deciding what is more efficient between a threaded program in a runtime that doesn't box everything and JIT-optimized JS code is difficult but it isn't that hard for the threaded program that isn't boxing to win out on all runtime measurements, including consumed RAM.

"You write "index = last_index++;" and it Just Works (tm), no need to worry about locks or atomics or other thread access."

That goes back to my comment about using better threading techniques. I write a lot of "index = last_index + 1" (mutably incrementing like that in a single expression is just bad style anywhere you see it) in my threaded code all the time without thinking much about it, because I use the model where by default a value belongs to the one actor process that has access to it at all. The problem isn't that mutation is dangerous in threaded code, the problem was people writing threaded code based on a ton of threads running around shared data structures with locking. Not only is that not the only way to write threaded code, it is literally the worst. There are many other options, all of them better in some way, many of them much better.

Contrasting the difficulty of writing threaded code to something else based on the assumption that "lots of shared state locked by semaphores" is the only way to write code is like a Haskell advocate talking about the amazing benefits of functional programming while writing as if literally every imperative program is just one big pile of unmitigated, pure spaghetti code where everything is linked together with gotos and every variable in the program is a global variable. That's not the relevant comparison any more. It hasn't been for a long time. If anyone's program is scrambled because they did write a big pile of gotos and global variables or they did write a big pile of shared state with semaphores everywhere, that's on them. A vast array of better techniques of all shapes and sizes was available to them.

> More people think they need a hundred thousand threads than actually do.

This is fair, but is a hundred thousand OS threads really a reasonable load on reasonable OSes?

I've (helped to) run systems with millions of Erlang processes on a node, so I'm not most people and my attitudes might well be skewed. I would expect that the reasonable ceiling for OS threads is closer to 10k than 100k, although I don't think I've seen many articles about findinf the limits... maybe everything just quietly works?

If the limit is 10k, I think there's a lot of real situations where thread per connection or thread per task runs out of headroom. If the limit is 100k, a lot fewer people are going to hit that. Common wisdom is "thread per connection doesn't scale", but it has a desirable programming model, so the question becomes how to get the programming model and scale, at least to modest size.

If it's fine to mostly just use threads (hopefully without so much of the shared everything model that makes everything hard), it would be great if people knew that instead of spending so much time adding async/await to everything. :P

Just to nitpick, it's a 8MB-sized mapping, not 8MB of RAM.

Likewise, on Windows, it's 1 MB of reserved memory but only 4 KB of initially committed memory.

https://learn.microsoft.com/en-us/cpp/build/reference/stack-...

Reply on news.ycombinator.com