Goroutines ARE USELESS 

That's what happens when you spend more time whiteboarding than doing actual programming

Concurrency vs parallelism, here we go again.

Just from the first 2 sentences in the meta-video, makes me think that these two goobers have never ever written an IO-bound application.

"Everyone does things the convoluted serverless way that I do things, and I don't find goroutines useful, therefore goroutines are useless to everyone."

Goroutines are completely useless if you go fully serverless for every function. however that isn't an issue because why in the actual flying fuck would you do that for anything more than a trivial application?

How do they think Kubernetes is powered... docker too. 😂

lightweight threads had 10,000 use cases before anyone was running anything in containers, other than BSD jails, or any of their hardware had multiple cores.

What are the guys in the orig vid talking about? Goroutines are not for parallelism, they are for concurrency in applications that are IO bound like your standard webapp when it talks to a db. "And if you use k8s, you scale at the Pod level": Kubernetes, which is written in, ... golang. Ironically, one of the key advantage of goroutines over vanilla threads is precisely in single core machines that need concurrent IO.

Skill issue, parallelism and concurrency are not the same, is sad that that people that actually lack of knowledge are that noisy

Dunning kruger effect on full swing in the podcast. I feel bad for the number of people who will be led astray by such a misguided notion

Goroutines aren't just for parallelism, it's for concurrency in general. Concurrent programs can run on one threads or more. And goroutines are green threads, so you can have multiple goroutines on a single hardware thread. This allows you to have multiple concurrent things going on, even if you just have one hardware thread.

Goroutines are so good Java actually introduced their own variant with virtual threads (Project Loom). They feel nicer to program in compared to async in JS and looks like procedural code, the runtime does the magic. Async just slowly creeps into the entire codebase and is a huge PITA if the framework you are using doesn't support it.

Sounds like the guy just doesn't understand what he's talking about. Goroutines are useful for both concurrency and parallelism.

I love the box I live in. I think inside my box. It's a comfortable box. Nothing exists outside of my box. Outside of my box is the Satan. Therefore, anything outside of my box either does not exist or is evil.

The argument falls apart the second you do litterally anything else then a basic web service

Yes, lightweight threading is the way to go. It's nice to see the model spreading with Java implementing it.

No i think you misunderstood him, even though i dont agree with his statement either. Hes saying the entire long running server is running on one core / thread / hyperthread. so your cpu has no additional resources to run go routines in parallel with your application. the core is either processing your application or processing a go routine. Where as on say a full core , you have the hyperthread as well as other resources that wont get in the way of running in parallel. but i think his argument falls apart especially if youre doing a whole lot of reading and writing like in most web applications (theyre discussing js in the backend afterall). sure parallelism is great for multiple cpu heavy tasks, but for io, concurrency is much more effective for achieving high throughput.

That's how AWS Lambda works - one request per process at any given time (afterwards the process gets reused though).It definitely comes with advantages, for example it eliminates a lot of "accidentally sharing state between requests" type of bugs. However,. even when working with Lambda I found Goroutines useful. E.g. when getting results from multiple upstream APIs.

I think you may have misunderstood this. They do not mean 1 process per request. They probably mean, A single instance of the application is allowed to use maximum 1 core on the machine and you spawn more processes to handle more traffic. It's still a weird take because Horizontal scalers are not instant and the request latency will shoot up for a few seconds to minutes until there are more instances available to handle the traffic. Go's ability to use multiple cores works out much better. I can set it to request 1cpu core and set the limit to 4 cpu core so if there is a more traffic, the same application can use multiple cores to serve it while horizontal scaler creates more instances if it has to. And what happens if the nodejs application does some thing weird with a request and pins the only core it can use to 100% ? That instance is still reporting healthy state and all the traffic directed to it gets delayed responses(HS will spawn more instances but it is not instant and the instance will continue to get more traffic). With Go, that go routine will pin a core to a 100% but it has other cores it can use to serve traffic. Their original point around this just seems silly to me, node's event loop's inability to use multiple cores is a short coming and does not render other async designs "useless".

That podcast is called JavaScript Jabber, and it was started years ago by a Rubyist. The Rubyist has a network of podcasts about his programming focus, like Ruby and JS and other stuff. Now you do understand where their opinion stems, their lack of understanding of coding on more than one core, they are defending Ruby.

Their argument is two step process: 1) goroutines are stack based concurrency 2) there is no hardware capability of runing parallel code Conculsion: all parallel code on sigle core computer has to be of the form of cooperative multi-tasking (event based concurrency). Thus goroutines - a stack based semantics - is usless. They are not wrong in philosophical sense. They are completly wrong in practical sense. Programming is not philosopy, implementation details matter. Explanation of point 2: They are not saying 1 request by 1 process. They are not using apache's mod_php. They are deploying to containers which use single threaded code only. And given that modern CPU-s are SMT threaded - cores ar virtualized at hardware level - at system level you see more cores than there are physical instances. So your single thread process is not even running on one full core.

The kind of conversation that gets a junior dev thrown out of the team.

Goroutines of course make sense. Consider this example of a web crawler, you can have multiple coroutines running "at the same time" some of them are blocked waiting for a server response, and some of them are processing. And just because your server might have a single core, you still have multiple threads within that single core.

This is a bad take, scheduling is separate from the processes it runs on. We ran computers on single cores before 2006, and without concurrent scheduling, computers would've been bricks. Scheduling is what enabled concurrency on single core machines. The guy from the pod cast is confusing concurrency and parallelism. Prime is correct here, what the guy said is factually incorrect.

So, this is coming from a sysadmin perspective: I feel like the guy's take is from about a decade ago. Everything is being "optimized" (shoehorned?) to run on AWS micro nodes (because cheapest) and scale-out is being handled by "spin up another VM and add it to the load balancer". He says "everything runs on one hyperthread" (even quoting that hurts my soul) is because 1 hyperthreaded core = 2 cores in the hypervisor, and the VM has 1 core assigned. So, it's running with not even a whole dedicated core.

i hate when somebody talk out of thier a** but those podcast idiots takes the cake : 1) goroutines model is for concurrency problems not parallelism and if you don't know the difference ...then i feel sorry for your clients and team 2) goroutines tasks are optimised for IO bound applications with the possiblity to await ,synchronise and return access to data when needed using channels, it has nothing to do with serveless functions 3) what is more efficient ? runing multiple pods and maintaining an exspensive kubernetes system OR spawning multiple lightweight goroutines that can scale in both horizental and vertical . 4) i hate the word "skill issue" but in this case those 2 definitely have it when coding backend system

Goroutines are useful for creating servers with multiprocessing input and output data. Imagine processing several data received at the same time by the client one by one, goroutines allow parallelize this task.

Ahhhh this was the stream we were joking about top and bottom devs. I couldn't remember what prompted that but I'd already changed my linkedin from "Full stack" to "Switch"

C# async is nice that it doesn't really colour your functions and it allows both cooperative and pre-emptive multi-tasking.

I'm just happy I'm getting far enough along in my journey that I at least feel like I understand what is happening when you switch to vim and start throwing some code at us❤

Being able to utilize multiple cores without tools like docker swarm, kubernetes is a huge win for simplicity. He also doesn't realize go combines concurrency and parallelism. Also confusing them. skill_issue/10 podcast

I don't know if I am wrong, but goroutines don't depend on the number of cores, because they are not running in parallel. They are "virtual threads"(not exactly, but I think this is the easiest way to understand it) and they are running asynchronously (without waiting for some routine to finish before starting another one), but not in parallel. That's why even if you have just one core, you can use multiple goroutines.

Using a fan out pattern(throw a go routine to every request) gives you the possibility to utilize the way that go works and how it manages the different types of work

Yea, try doing some mapping of 1000 DB rows in JS. Your entire site will freeze because its single thread will be stuck on this CPU-heavy task and V8 won't give a hecc about muh async

Julia implements both channels and async await (that is actually sugar syntax to await for the first value in the channel).

BEAM (VM) is still the greatest engine for running concurrent tasks in a parallel environment (since it actually gobbles up those cores baby [and can be run across machines!!]), simply because it's way too easy to do so using languages such as Elixir or Erlang. It's actually very hard to fuck up because the virtual processes in them don't share memory [except for message passing if you want since they are usually run as actors] and are independently garbage collected (no STW GC).

c# tasks also let you synchronously wait for the value with .Result property blocking the current thread until the task completes and then giving you the value, writing multithreaded code in c# is honestly not that bad and function coloring is relatively low which is quite nice. and before anyone asks, no, i never had the opportunity to try go yet, or rust, my experience is with c#, c, cpp, python, js, and ts (if you could even count them seperately) and a tiny tiny bit of assembly oh and obviously the best language, scratch, scratch is a perfect programming language and you cant convince me otherwise

wtf is that statement

The goroutines are amazing for how easy it could be to run parallel processes and control them, terminate, or wait until they complete their tasks. I'm amazed constantly when I run one more... I love it. Cheers! P.S> I use them, for example, to download 20 movies simultaneously since my internet uplink capacity is sufficient. This significantly shortens the downloading time. There are numerous examples of how incredible goroutines can be.

The guys in the video also don't understand that Concurrency is not Parallelism. Concurrency is a way of describing work, not an assumption on parallelism (though in go, concurrency patterns are easy to parallelize).

What do you guys think of Kotlin's coroutines ? Functions are still colored, but calling them is identical. The compiler figures out when to await.

very technically c is also non-colored functions, but that's a completely different story.

the first 30 seconds, nodejs came up at the back of my mind like right away

I…sigh…I hate how little the average developer knows about modern computers. Absolutely clueless. What are they even talking about? No idea what they are talking about.

Goroutines, and generally speaking, concurrency, sound really cool on paper. In backend development I've had the experience that the complexity isn't worth the minimal gains. The complexity being that where you could previously pass around crosscutting context (for example, request information or user infos for logging/tracing) by simply making them Threadlocal (aka every thread gets it's own version), you now have to possibly pass it around by hand to every single function all the way down your call stack. The gains are in theory that you can wait for multiple IO bound things in "parallel" or even just "give" the CPU to someone else that's not waiting on IO. In my personal experience, most things in the backend end up being highly sequential. You get the user auth, THEN get the user info, THEN get the user settings, THEN get the users Todo List (or whatever). Rarely are two steps actually independent enough. Caveat: This is all just from working with Java, so if Go (or other languages with coroutines) have a smart solution to the complexity and maybe other experiences with the potential gains, I'd loove to hear it.

just for perspective, our homebrew policy-enforcing + OIDC proxy go reverse proxy did 2000rps on 400mCPU, and it wasn't even that optimized.

what they talk about is kubernetes which is gnu parallel on steroids. I still disagree with this take because of what Rob Pike said about them in the first place, that designing with concurrency in mind, even if it won't run in parallel is useful due to the organization it provides for the application.

I made a test awhile back, making blocking single requests to an outside API, or spawn 25 workers to send these requests simultaneously, one goroutine for each. To no surprise, the latter was more than 50 times faster. Of course that in a single core single thread, the OS scheduler will do its magic

That's like saying epoll is useless syscall. That's nonsense, it's base of any concurrent event loop thing

idk what's worse: a board ripping out the icon of a company (for good or bad reasons) or a board that didn't even have the gumption to stick with. their choice. they were screwed in the public eye for firing Sam... but now they are double screwed for walking back on it they should definitely be replaced

This is like running a program that was 32 bit on a 64-bit computer and it only uses half of your CPUs and then the program crashes when it break 50% CPU

One pattern I find with go developers is they sometimes lack basic computer science knowledge. Like they don't understand the difference between blocking and nonblocking IO, the difference between parallelism and concurrency.

You can treat serverless JS lambdas (or really any language lambdas) as a single process. They do indeed serve one request at a time. Goroutines make the program crash if they modify a map at the same time without a mutex. Not sure if that's great. Channels are great in theory, not very useful in practice. They also have some pitfalls. I also wonder... Why is IO as values function coloring that sucks, but Result is not? We like the benefits of errors as values, right? I also like the benefits of IO as values. I do want to know if you are going to do some random IO to compute the value you're giving me instead of entirely using things passed as arguments. Helps me know how large the surface area for errors is.

According to this guy in the JavaScript Jabber podcast (which is part of Top End Devs network) Kubernetes is "writing Go to avoid writing Go" just like HTMX is writing JavaScript to avoid writing JavaScript

LOL, yeah, cause software is always deployed to K8s to serve HTTP requests.

when you are using apache, every request will be a fork of apache

Javascript schedules async functions. Go schedules goroutines (functions). One of those two can utilize multiple CPU cores and provides more ergonomic abstractions.

This feels related to the "Death by 1000 MicroServices" video

This is your brain on JavaScript. Any questions?

These two are what we call highly abstracted Frameworkers drunk on the Kuber juice

I don't think they're saying that a new process is start/killed for each request, the processes can be long-running, just that they only serve one request at a time. It still doesn't make much sense though.

This is kind of a necro-post at this point since the video is from 4 months ago... Since they mentioned Kubernetes and the "half hyper-thread microservices" part, I don't think that they're talking about a single request to a single instance of the application. I feel like they're talking about how they scale the application. In most cases they're wrong and end up calling me at some point. I've seen many developer groups deploy applications on Kubernetes allocating partial CPU requests and limits. The thought process is that as the request traffic of the application increases they just scale up the number of pods. The trouble that many end up running into is when they have not done any kind of profiling of the application. They have never put forth the effort to determine what resource allocations the application actually uses when it runs at its peak performance. What they mentioned has been at the core of every single engagement I've had where people crash and burn using Kubernetes.

I feel like Prime completely misunderstood what they're saying. They're talking about a pod instance of a long running program per thread. The process itself just uses no threading. Basically, think of how NodeJS scales.

Go routines are godsent even on single core instances

I kinda understood the thing the podcast people said differently? I feel like what they're saying is that they're not running 1 thread per request, but *1 thread per logical core*. As in, if you have 24 logical core CPU, you just run 24 containerized copies of the single-threaded server and load balance it, instead of running 1 golang process with tons of goroutines that utilize all the cores. It's like GNU parallel that Primeagen loves so much: single-threaded program + external parallelization = program that utilizes all the resources efficiently. And no, you don't need goroutines for IO, all you need is regular async/await, even in the single-threaded way like how JS does it. And all the internal complexity of the goroutines and all these green threading and stuff becomes useless if you can just parallelize with an external tool and use single-threaded async for IO (which is much simpler internally and also faster). There is that function coloring deal with async/await, sure, but there are ways to solve it (like whatever Zig does with color-blindness or a proper effect polymorphism that some experimental functional languages have)

It's quite an amusing argument, 'go threads are useless because of kubernetes' ... which is written in go, and is working very hard behind the scene, to save the bacon of some rather less efficient languages.

That might be true for serverless functions/lambda infra. Batch runners (Azure Batch) and containerized workloads could have arbitrary scale per worker. It kind of depends on how the workers are set up. For Azure Batch, the cores scale with mem, so for 16gb of ram, there is a minimum of 4c per node, I think. Each job is remarkably simple copy code/binary to node and run powershell/bash command -> so we're able to take advantage of async stuffs.

also since you brought up serverless, that's not how serverless works either. so for this example I'm going to specifically use aws lambda and golang, but the exact same thing applies no matter what serverless system you were using. so basically what happens is that when a request comes in, the serverless system checks to see if there is a function that is available to handle the request. if not it creates a new one. so let's say that it's a service that only gets one request per hour, so everything is scaled to zero and there are no currently running functions whenever a request comes in. what will happen is it will always spin up a new instance, it will handle the one request, then it will get torn down. but if we say it gets two requests back to back every hour, it will still only spin up one instance of the function. this is because it keeps the function around for a bit. and with golang in particular, but you can also do the same thing with Python, you can actually set up all of your database connections and such and then share them between requests. to get a bit more specific about what happens in between requests, this is AWS lambda specific by the way, what happens is that you get an initial grace period during startup that lets you do things like set up database connections, global variables, etc and you get about 100 milliseconds to do all that. then your process gets sent a sig stop, so it can't run on the CPU anymore. then a request comes in and AWS lambda sends your process a sig cont allowing it to be on the processor again. this is how AWS enforces their billing and keeps you from basically getting free background compute. while your process is not sigstop'd, your program is free to do whatever it wants. so as long as requests are coming in at some rate, you can maintain all of your database connections and stuff. you can actually even do true multithreading if they give you enough CPU.

Re: change my mind - As an alternative: Fibers as the execution model for functional effect systems (Scala's ZIO and Cats effect, or TypeScript's effect.ts). Fibers allow for concurrency while solving the function coloring problem, and the effect system gives type-safe, pure composability and explicit, typed failure-handling. Writing concurrent programs in ZIO is syntactically no different from writing non-concurrent programs - it's almost trivial. Without some extra work go will have the smaller footprint of course, but with Scala native compilation you can also get high performance, small executables and tiny memory overhead.

What about scenarios where a user request can be split into two separate "processes" whereby one is deemed critical for application success and the other is not? Lets imagine you receive a request on an api and you want to save the event in a DB, publish a message to a queue and add a log entry? Out of those, only the insertion on to the DB may be deemed as critical to respond back to the user with a success. Why not make the publishing to a queue/logging the event as non blocking-processes that can be run on a separate goroutine? You are still running on a single core but you've dramatically reduced latency because you've accepted that publishing to the queue and logging are non-critical and if they fail you can retry on your own volition. This is a very blind-sighted take on processing speed - sure if you have all the money in the world you can horizontally scale infinitely and have everything running on a separate lambda function but that is not necessarily smart or possible most of the time.

So the way they propose this should be done instead of doing go-routines makes some sense to me. Generally when i write backend code in a microservice architecture the services are designed to be small and have as little CPU and memory footprint as possible. In those scenarios, instead of scaling out "internally" in the microservice by using go-routines. You should scale within the Kubernetes cluster instead. And from a architecture standpoint, that makes sense I think. That said, I don't agree with them that go-routines are useless. I've had plenty of use for them even within that type of architecture. Every single time reach out to multiple different external source, where the calls are not dependent on each other, I of course reach for go-routines. Every time I create a API server and I want the ping endpoint to live on a separate port, I use go-routines. There are still plenty of scenarios where go-routines makes a lot of sense.

Oh my goodness, many people criticize Go programming without even having a basic understanding of how some fundamental concepts work!

I run my async node apps multithreaded. You fork out to like 60% of available cores to account for uncontrollable node threads like io and gc stuff but otherwise you can totally use multiple threads with both Cluster which even allows you to share entities like a server handle across workers and then actual worker threads if you need to do anything cpu heavy. Like no one else does this though, maybe like 1% of developers. Lol

>junior java developer Meanwhile java: >are virtual threads we released yesterday a joke to you?

This is why I am satisfied when I change the like button color and call it a day

Go's best feature is better than Rust's best feature

As @theprimeagen said, I'm not an infrastructure expert and it is not totally clear which setup are they talking about. That being said, if goroutines are useless since some time ago, people developing Kotlin and Java should be stupid, as they developed coroutines and virtual threads afterwards. That sounds like a proof by contradiction to me (as I don't think people developing Kotlin and Java are stupid).

Using golang you shouldn't immediately worry about the number of core or cpu-threads there are. The biggest advantage to go routines is the time saving (concurrency) on things not just isolating inbound requests. But if you have nothing that can benefit from concurrency then there isn't a use for them, but it's hard to stretch that into "useless".

They allow me to send hundreds of thousands of requests though 😈

The original statement was insane but the casual agreement blew my mind. I bet their backend has over 10k microservices...

They aren't suggesting a process per request. Just that a process only handles a single request at a time. The lifecycle of the process is not coupled to that of the request.

He thinks the while word runs in lambda functions?

Aren't functions still colored in that they need to use channels? How is it different from promises?

To be honest: The two people who agree that Go routines are obsolete these days lack, in my opinion, a deeper understanding of what they are talking about. The differences between parallelism and concurrency, the cost of switching tasks, the cost of waiting for IO, and the design of algorithms by composing threads or Go routines, and so on. This may be because they come with a JavaScript/NodeJS background.

In JavaScript, async await has such an non-intuitive naming. I want to write a synchronous code, yeah? But it happens that I need to call an asynchronous function. No problem, I just await, so my function stays synchronous as before and runs everything line by line. But no! Not I have to set that function to async, so it's not sync anymore, and the ones calling that too and the ones calling that too. I just want to wait for a Promise to return but I can't do that, because only a promise can pause itself to "await" and it makes no fcking sense. On the other hand, sync code can fire multiple ASYNC functions like crazy if it does not need the return value later in the function.

I wonder if you changed your mind on this. Golang network is non-blocking. So you don't wait - Golang scheduler uses those resources to run other code. You don't have to do it manually!

The first time I tried go I was so confused. How do you do an async call? lol. Oh you just don't. Well....JS is stupid then.

But all microservices and cloud architecture is built on Go

As a hobbyist dev and enterprise architect professionally, this guy is full of it. In most cases, a vCPU is a single thread of execution virtualized on hardware. I've never seen anyone deploying a farm of servers with single vCPU instances. At the least, most people are using 2 vCPUs worth, which gives you the possibility of at least 2 parallel threads of execution. Especially when it comes to the cloud, you'd want so much RAM for handling requests, and the vCPU count and RAM count are tied together as a bundle with instance sizes. Now, in terms of serverless, that's a bit opaque to the end user, but it is possible to have multi-threaded execution environment all the same. Furthermore, multi-threading can be useful on a single threaded execution environment as well - see blocking IO.

It is more expensive (cost wise especially) to create multiple server instances than utilizing all of the cores and threads of a single server instance.

blocking a thread just to wait for the result of an async function result is a waste of a thread.

Kotlin has this, too and it's called Coroutines.

He's assuming zero waiting on IO?

@11:50 Saying Rust's async is leaky is fair, but I think saying that Results are leaky isn't. Fallibility is _inherently_ leaky. Hiding away which functions can fail behind exceptions that may or may not be handled is not an improvement and like... the overhead to calling a function that returns a Result from a function which doesn't is perfectly simple. Yeah, you need to handle the error, but it's trivial to go from "function which might fail" to "function which handles all downstream errors" by just using any of the many tools which isn't the ? operator.

He’s lost in aws lambas, god help I’m his aws bill

This is the devops equivalent of virtualizing linux on each CPU core.

So for 500m users they'd need 2m physical servers? I'm going to guess others do it with less.

Yes, a single-thread CPU can only do one thing at a time, but by using routines you split your program up into smaller tasks/processes. That ONE CPU/Core/Thread now sees 2 processes and can schedule which one needs more resources/execution time. It's more efficient and thus faster. That even works in real life. Your Brain is a "Single-Core" machine so to speak, but it is still easier to tackle a to-do list, that has many small points, than one that has only a single point encompassing everything to do (Or maybe that is just because of my ADHD Brain)

K8s is the new Apache running PHP 😂😂😂. One milli core per request?!? 😢

I got the impression those devs thought goroutines are purely for parallel programming.