You've thrown away all credibility.

Edit: for me this post appears on the front page of HN. OP this is mission success - add this project to your résumé and stop spamming.

Most people that have read a mathematics textbook have also read and enjoyed Harry Potter.

Given you have enjoyed drinking water and breathing in the past, there is a high likelihood that you will enjoy watching the Star Wars films.

You spent $10m or $100m on a building that's now half empty.

Either you downsize or commit to enterprise scale sunk cost fallacy and enforce RTO so your real estate investment isn't "wasted".

City centres also thrive on RTO, with high street shopping on a generational decline it's up to office workers and their employers to prop up the economy of the CBD one overpriced lunch at a time.

It's extremely stable, installed almost everywhere, and has much fewer insane idosyncrasies than shell.

I can write some Perl and confidently hand it to a colleague where it will almost certainly work on their machine.

It's a shame it's so dead, for a scripting language there's nothing else that ticks the same boxes.

I would never write systems software with it, of course

Not enough IMHO.

We run all tests on developer machines and CI with -race. Always.

It's probabilistic, so every developer 'make test' and every 'git push' is coverage.

https://en.wikipedia.org/wiki/Hackney_carriage

I think this would be similar to the medallions of yellow NYC cabs

I work at an Erlang shop.

For Erlang to be useful you need to have massive scale, millions of DAU. Yes Elixir might run your website serving thousands of DAU but Erlang and the BEAM was not invented for you. Few companies have the scale that makes Erlang a reasonable choice.

More pressing these days I believe is that the Erlang ecosystem is all or nothing, the BEAM is like its own little operating system and has extremely (IMHO) complicated setup and configuration with many moving parts: ERTS, epmd, Rebar,... You don't need or shouldn't use container tech and k8s with Erlang because it's already doing that stuff in its own Erlang way - but it's the Erlang way it's extremely unique and unfamiliar to most.

When you have the right use case for Erlang and you see it in action it is truly like black magic, it's been a highlight of my career to work with it.

>I find it useful for some coding tasks but think LLMs were overestimated and it will blow up like NFTs

No way. NFTs did not make any headway in "the real world": their value proposition was that their cash value was speculative, like most other Blockchain technologies, and that understandably collapsed quickly and brilliantly. Right now developers are using LLMs and they have real tangible advantages. They are more successful than NFTs already.

I'm a huge AI skeptic and I believe it's difficult to measure their usefulness while we're still in a hype bubble but I am using them every day, they don't write my prod code because they're too unreliable and sloppy, but for one shot scripts <100 lines they have saved me hours, and they've entirely replaced stack overflow for me. If the hype bubble burst today I'd still be using LLMs tomorrow. Cannot say the same for NFTs

Thank you. I've fixed a lot of bugs in code that assumes because a channel is buffered it is non-blocking. Channels are always blocking, because they have a fixed capacity; my favorite preemptive fault-finding exercise is to go through a codebase and set all channels to be unbuffered, lo-and-behold there's deadlocks everywhere.

If that is the biggest mistake, then the second biggest mistake is attempting to increase performance of an application by increasing channel sizes.

A channel is a pipe connecting two workers, if you make the pipe wider the workers do not process their work any faster, it makes them more tolerant of jitter and that's it. I cringe when I see a channel buffer with a size greater than ~100 - it's a a telltale sign of a misguided optimization or finger waving session. I've seen some channels sized at 100k for "performance" reasons, where the consumer is pushing out to the network, say 1ms for processing and network egress. Are you really expecting the consumer to block for 100 seconds, or did you just think bigger number = faster?

I apologize, that should've said 2^14, each sub-benchmark is a doubling of goroutines.

2^14 is 16000, which for contention of a shared resource is quite a reasonable order of magnitude.

CSP is really in the realm of formal methods. No you wouldn't formulate your server program as CSP, but if you were writing software for a medical device, perhaps.

This is the FDR4 model checker for CSP, it's a functional programming language that implements CSP semantics and may be used to assert (by exhaustion, IIRC) the correctness of your CSP model.

https://cocotec.io/fdr/

I believe I'm in the minority of Go developers that have studied CSP, I fell into Go by accident and only took a CSP course at university because it was interesting, however I do give credit to studying CSP for my successes with Go.

The article that the OP article references does not show the code for their benchmark, but I must assume it's not using a large number of goroutines.

https://go.dev/play/p/qXwMJoKxylT

go test -bench=.* -run=^$ -benchtime=1x

Since my critique of the OP is that it's a contrived example, I should mention so is this: the mutex version should be a sync.Atomic and the channel version should have one channel per goroutine if you were attempting to write a performant concurrent counter, both of those alternatives would have low or zero lock contention. In production code, I would be using sync.Atomic, of course.

On my 8c16t machine, the inflection point is around 2^14 goroutines - after which the mutex version becomes drastically slower; this is where I believe it starts frequently entering `lockSlow`. I encourage you to run this for yourself.

> Do you have any more details about this? Why isn’t sync.Mutex implemented with that same mutex channels use?

Why? Designing and implementing concurrent runtimes has not made its way onto my CV yet; hopefully a lurking Go contributor can comment.

The channel mutex: https://go.dev/src/runtime/chan.go

Is not the same mutex as a sync.Mutex: https://go.dev/src/internal/sync/mutex.go

If I had to guess, the channel mutex may be specialised since it protects only enqueuing or dequeuing onto a simple buffer. A sync.Mutex is a general construct that can protect any kind of critical region.

> What is the rule of thumb your Go shop uses for when to use channels vs mutexes?

Rule of thumb: if it feels like a Kafka use case but within the bounds of the local program, it's probably a good bet.

If the communication pattern is passing streams of work where goroutines have an acyclic communication dependency graph, then it's a no brainer: channels will be performant and a deadlock will be hard to introduce.

If you are using channels to protect shared memory, and you can squint and see a badly implemented Mutex or WaitGroup or Atomic; then you shouldn't be using channels.

Channels shine where goroutines are just pulling new work from a stream of work items. At least in my line of work, that is about 80% of the cases where a synchronization primitive is used.

If you run a microbenchmark which seems like what has been done, then channels look slow.

If you try the contention with thousands of goroutines on a high core count machine, there is a significant inflection point where channels start outperforming sync.Mutex

The reason is that sync.Mutex, if left to wait long enough will enter a slow code path and if memory serves, will call out to a kernel futex. The channel will not do this because the mutex that a channel is built with is exists in the go runtime - that's the special sauce the author is complaining doesn't exist but didn't try hard enough to seek it out.

Anecdotally, we have ~2m lines of Go and use channels extensively in a message passing style. We do not use channels to increment a shared number, because that's ridiculous and the author is disingenuous in their contrived example. No serious Go shop is using a channel for that.

The author has attempted to fix their unidiomatic error handling with an even more unidiomatic error framework.

New Go users: most of the time returning an error without checking its value or adding extra context is the right thing to do