Goroutines ARE USELESS 

Concurrency vs parallelism, here we go again.

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

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."

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 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?

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.

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.

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

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

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.

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.

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

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

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.

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

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.

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".

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.

aws lambda is in a similar situation with reactive/async code. aws is going to block on a req/resp, it's not going to reuse that 'vm' for the next request as aws will give that request its own 'instance' of the 'vm' (could be code, image, etc). Java virtual threads don't color your functions. I know, right?

Could you tell me if C#'s async await or Go's goroutines are better? C# also uses multiple threads. That's why I wonder the difference.

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".

wtf is that statement

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

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

Is it good to use goroutine for sending emails from backend or fetch 3rd party api?

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.

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.

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 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

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

What plugin is he using to make the errors/warnings appear on/under the line as he types. In my Neovim I only get an icon on the left hand side of the line.

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❤

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

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.

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.

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

05:23 why `async` when you don't use await inside?

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"

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.

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

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

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).

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.

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

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.

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.

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.

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.

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

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.

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).

This guy makes me exited about go. Does he have a course or something ?

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

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

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.

Just test, try read 50 different files with goroutine vs without goroutine. Performance is huge difference.

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

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

I think gos concurrency model without colored functions is prerty much perfect for go, but would be garbage for C++ or Rust. Not coloring the functions does make it kind of magic and requires some kind of runtime in every program.

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)

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.

Goroutines are very useful. Lots of horrible system designs ignore in-process parallelism at the expense of performance. Performance matters. The problem I have with them is being a built-in language feature instead of a library. There are lots of concurrency patterns, we shouldn't be tied to a programming language on that specific need. Yeah, it is nice that it is standard and part of learning Go, but not to the level that it should be a language feature. Instead, the language should have generic facilities that can be used in any library.

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

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.

Is this guy suggesting that you spin up an entire server instance for each user request?

aren't goroutines userspace threads? so they wouldn't necessarily be using different threads/cores anyways. You can run multiple coroutines on 1 core and it's still useful. The whole point is to avoid the mode switching afaik.

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.

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.

I think goroutines are not the best solution. You can call functions asynchronously but you can't get there result. To get the result, you have to pass a channel for communication. Having to pass the channel makes it colored in some sense. The way zig does it is the best of both worlds. You can call any function synchronously or asynchronously. If you call it synchronously (`const x = foo()`), it will return the normal value. If you call it asynchronously however (`const x = async foo()`), it will return a frame. This is a special zig type which encapsulates a function frame. You can await the frame afterwards to get the result. Even better is that you can specify how the frames will run (your own event loop), or you can use the one the stdlib provides. (It worked on zig 0.9, but with the new self hosted compiler they are rewriting it should work again in the next release)

go routine and go channel can meaning full for data aggregation. with in source file.

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

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.

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)

Bit of a misunderstanding there by Prime, the guy on the podcast was saying they just run 1 process per pod, which handles requests (which is very different to spawning a process for each request). Still, I agree that it is a bad take that this is the only use case ever. Also does not really make goroutines useless. Running a single process per pod is definitely not as efficient as sharing resources(memory, cpu spikes, io) between requests, but if feasible, it is a great way to reduce maintenance effort. It also makes it really simple to scale, even though it is expensive.

He thinks the while word runs in lambda functions?

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 for 500m users they'd need 2m physical servers? I'm going to guess others do it with less.

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.

Channel on golang functions is same as coloring

after watching this I am now even more confused and doubting my knowledge of Node and golang :(

The title useless reminds me of the situation where my company is hard selling lean six sigma to team of SWEs. Do you believe in that? I feel that it’s pretty useless.

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.

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

they meant allocation half of a CPU to a kubernetes pod. So goroutines would be concurrent but there are no parallel benefits.

I want some of that kush the podcast host was smoking

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

This is your brain on JavaScript. Any questions?

Go routines are godsent even on single core instances

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

Just because you can run Go or Rust or whatever, in cheap environments, and don't gain extra performance, doesn't mean there aren't scenerios where you squeez more from your hardware. Especially when allocating more resources for your running environment

But what if I'm web scrapping?...

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).

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!

Hot take: Objective-C has an extremely ergonomic threading model. … Might just rival go.

He's assuming zero waiting on IO?