Go is blazingly faster than Zig?

The super challenge of languages. Because you subbed i decided to add a couple extra languages.
Twitch
Everything is built live on twitch
Twitch : bit.ly/3xhFO3E
Discord: discord.gg/ThePrimeagen
Editor
All my videos are edited by Flip. Give him a follow! / flipmediaprod He is also open to do more editing, so slide deeeeeeeeep into his dms.
Links
Linode: linode.com/prime
/ discord
Twitch: / theprimeagen
Insta: / theprimeagen
Twitter: / theprimeagen
VimRC & i3: github.com/ThePrimeagen/.dotf...
Keyboard (15% off, I don't earn commission): bit.ly/primeagen-adv2
#vim #programming #softwareengineering

[@ThePrimeagen]

These Blazingly Fast Videos have been fun to make. Should I keep going? Should we keep making more? Also, we are SOOOO close to 100k subs, what should we do to celebrate?

[@jonathanalonso6492]

Write your own UI framework; call it "SmoothBrainJS". As for the catchline? _Blazingly fast_

[@armandsalle8447]

YES keep going please! That's so fun! Thank you for your content ❤

[@armandsalle8447]

Also, nice moustache 🇫🇷🥖

[@iduran]

Yes please. Do one on Carbon!

[@zeebs7163]

we should do a celebration, BLAZINGLYYYY FASTTTT!!

[@Tesserakt8]

I now can't look at framework repos and not laugh when I see blazingly fast.

[@ThePrimeagen]

that was a goal

[@ahmaddynugroho]

me too

[@Mempler]

@@mateusramos1742 the question is, does it "cheat" and interop with C/++/rust/zig or is it purely written in go?

[@mateusramos1742]

@@Mempler purely written in go.

[@whoami5955]

Blazing fast

[@striderstache99]

You and Fireship are my favorite code content creators. Funny and thorough. Need more of this on KZbin.

[@timhoeppner6691]

I'm really enjoying these benchmark style videos, keep up the good work!

[@DiegoVallejoDev]

As a professional node developer I 100% agree, Node is not meant to be super fast and be used on the most crowded/critical endpoints of the application, it has more to do with fullstack's fairly new role in the industry. In the old days companies had front-end and back-end teams that probably never met each other, they would have an internal documentation site with most of the information they needed and at the last steps of the waterfall chain the software it will run mostly fine, but we're talking months of development with no progress being seen by the no-code folks who control the money. In current times the market demands software built faster and progressively, the "no-code folks" want to ensure the feasibility of the project as soon as possible, so we changed to agile methodologies and the fullstack role emerged A developer capable of handling the 4 elements, front-end, back-end, database and whatever the client wants and he has to do it fast, so changing between technologies might not be a good idea - I would say that's pretty stressful in the long therm and can lead to burnout, to mitigate stress and bugs they use the same languages for back-end, front-end and DBmgnt like any business in a free market if they require an specific an team is required for a "blazing fast" backend they will have it but those are very specific cases, 90% of services would not have a significant workload nor care for a 200ms response, and if they do they'll probably scale horizontally or distribute copies across the world. that's the software reality: development time is more important than performance time

[@nivethan_me]

Best argument for node i have seen in a while. I'll save this and going to use this forward 😂

[@hypergraphic]

Yeah, I mean, how fast does Node have to be? 500 requests per second is not nothing. If Ruby on Rails is performant enough for a lot of use cases, I'm sure Node is too.

[@pedrolarosa]

Agree. Thanks for sharing!

[@markhaus]

@@hypergraphic that’s what load balancers are for. Just increase the number of node nodes

[@Justin-fq8dt]

At the end of the day it really isn't a huge deal to use a different language for the backend and still use js/ts on the frontend. Most developers who have been programming for a couple of years probably know js and another language that can be use for backend services, and wouldn't have a problem switching between languages frequently while developing their own full stack project or while working as a full stack developer at a company. I think one of the notable advantages of node is for new devs who want to be able to work on both a frontend/backend of their own software while only knowing one language.

[@ShubhamRao]

While I'm waiting for Elixir, it would be interesting to also explore these numbers on a multicore machine! (Both performance and developer ergonomics)

[@ThePrimeagen]

you people and elixir

[@MarcosVMSoares]

Elixir is life, elixir is Brazil ^^

[@cherryramatis2508]

@@MarcosVMSoares elixir é nois

[@Roupi]

@@MarcosVMSoares elixir é agro, elixir é pop, elixir é tech, tá na globo é elixir.

[@nivaldolemos5280]

@@MarcosVMSoares elixir is from brazil, lua is from brazil, come to brazil

[@bryanenglish7841]

I love watching these experiments. I keep meaning to make my own video about this but they taker forever to make. I admire your commitment.

[@lallenfrancisl]

Programming entertainment at its peak. Dude your videos are hilarious and super information packed at the same time

[@galileo_rs]

It is rare to find a video on KZbin that you do not have to watch at 1.5x.

[@ThePrimeagen]

I try to get to the point. I'm just so sick of videos that are just the most slow roll pieces of content ever.

[@Voidstroyer]

I'm looking forward to that Elixir video. I am really curious to see how it's performance stacks up against Go and Rust. Also, If I recall, in that video you did with Theo regarding unit testing, both of you agreed that you shouldn't touch Elixir and I am curious as to why. I understand that both of you are really picky regarding languages and their type systems, but I feel that Elixir has ways around its dynamic types that in many ways are either similar to typescript, some ways a bit worse, and in some ways a bit better (pattern matching on specific values and types). And Elixir has certain tools such as elixir_ls and dialyzer that help as well to make error detection during development easier.

[@Sairysss1]

For people who are interested in Elixir, here is a comparison between Erlang and Go performance: www.dcs.gla.ac.uk/~trinder/papers/sac-18.pdf Elixir is based on Erlang's BEAM virtual machine so it should be pretty much the same. To summarize: Erlang/Elixir can spawn processes faster, but Go has better throughput than Erlang/Elixir and in general Go is more performant. But keep in mind that Erlang/Elixir is not all about performance, it's main strengths are fault tolerance and reliability. In that regard its much better than Go.

[@qx-jd9mh]

@@Sairysss1 just call Rust through a NIF when you need to speed up Elixir

[@LtdJorge]

@@qx-jd9mh it depends on the type of work. Many small function calls would probably be slow due to the overhead of calling to the NIF.

[@qx-jd9mh]

@@LtdJorge did you actually look at benchmarks that compare the overhead of nifs?

[@marctse3556]

I came here with blazingly fast speed after the notification

[@baxiry.]

hhhh

[@ThePrimeagen]

DO IT

[@buraky16]

This video's thumbnail (gopher licking bun with crazy eyes) is my current favorite developer meme. I can't help it, it's just so funny :D. Also wherever a tech community mentions "blazingly fast", that sound effect plays in my mind automatically lol

[@Pbertrand_dev]

Nice benchmark and amazing 11/10 mustache! Dare you to do a benchmark using PHP 8 and Swoole

[@ThePrimeagen]

nope but yes, its a great mustache

[@Pbertrand_dev]

@@ThePrimeagen 🐔

[@moitoius]

Lock-free is like async/futures/promises. It tends to scale well horizontally (more threads and cores), but does worse per-core - especially if there is a lot of contention on the resource. The new thing is wait-free data structures that are not only lock-free, but also avoid long compare-and-swap loops.

[@ThePrimeagen]

wait free... I am getting too old for this shit

[@cenowador]

This is interesting... But how does one achieve await free in node? Everything in there is a Promise

[@moitoius]

@@cenowador this doesn't apply to node at all.

[@uchennaofoma4624]

You videos always have a way of making me laugh. Thanks 😀

[@PsychoKiller250]

Another banger of a video prime, but a have a question, when the OG of backend languages Java will be tested against node to see which is the slowest language of them all?

[@LeszekZalewski]

Multicore machine is one thing, comparing the memory usage would be another - especially if you built it in a way to compare GC performance (or lack of it)

[@chris-ew9wl]

Love the videos man, especially the last part about frontend stuff 🤣

[@Eysvar]

I don't know whether to be proud or ashamed that as soon as Prime showed the Go code, I immediately noticed it wasn't formatted with gofmt.

[@ThePrimeagen]

it wasn't. I accept the fact that i hate the formatting and i am the only one using the repo, so suck it.

[@avithedev]

@@ThePrimeagen finish him 😂

[@BeardedWrenchh]

been waiting weeks for this video, LETS GO

[@ThePrimeagen]

was it worth it?

[@BeardedWrenchh]

@@ThePrimeagen definitely worth the wait, i will note, i expected Go to do a little better than it did, It also would be cool to rerun these tests on a multi-core server and compare the differences

[@MohitDodhia]

Hello, Prime! I love these videos. I was wondering if a Java vs Node vs Go vs Rust video is in the pipeline or not? Nonetheless, have a nice coconut-oily day!

[@shubhamlatiyan7972]

love this dude, amazing content

[@moumous87]

Love these videos!

[@brilliantdirectoriestraining]

This is the video we wanted, and the video we needed.

[@ThePrimeagen]

and you got it

[@blazinglyfast1233]

Great channel. Love your content

[@ThePrimeagen]

Your name is blazingly cool

[@kevinzunigacuellar]

love your videos man!

[@TheBli7krieg]

dude! the intro, I was almost choking

[@MOON9FLY]

I love you editing XD, Good video as usual

[@ThePrimeagen]

Its the editor that does all the good moves. I am just the good looking model.

[@superhoops540]

would love to see the same benchmark testing in Nim :)

[@andreagiorgi3512]

It's really mind boggling how people could think a pure interpreted language can be fast like a compiled one. The difference between them, what assembly and machine language are, these are literally among the first things you learn at university during a basic computer engineering course... How in the hell could someone think a language, like Javascript, which uses strings in switch-case statements can be "fast"?

[@steveoc64]

Because even JS gets compiled to machine code at runtime. The slowness comes from dynamic types and gc

[@LtdJorge]

If it hits the JIT, it’s machine code

[@TheWallReports]

💯Exactly. I was thinking the very same thing. Node/JS is blazingly fast when compared with other [interpreted] languages of the same class like Python, PHP, Perl etc. Context matters. It's one of the fastest interpreted languages available. The only language I recall in the interpreted class that beats out Node/JS is Lua. But to pit it against a compiled or even byte-code compiled language like say Java is ludicrous. It says more about the people making such argument than the merits of test. It's like arguing a Crown Victoria can hold it own against a F1 race car.🤷🏾‍♂

[@peezieforestem5078]

It's actually trivial to imagine, if, say, an interpreted language has multithreading and asynchronous features, where's compiled language doesn't.

[@nunofontes3895]

Nice videos, keep them coming.

[@unowenwasholo]

You had me at "Miku with a rocket launcher"

[@davidraymond8994]

I am a bit surprised at Rust versus Go I would have thought they would be a bit closer. I really like Rust but I am using Go for a new project because I couldn't really get up to speed quick enough with Rust.

[@kylegaijin]

Yes, Keep making cool videos. And... I guess that zig is going to be the fastest in this video.

[@philiposdrontzas3725]

I would be quite interested into a comparison between those and Ruby on Rails. Very nice video!

[@ThePrimeagen]

ty. I probably will never touch the gem encrusted sword

[@philiposdrontzas3725]

​@@ThePrimeagen Oh ok, thanks! , although could still be worth wielding it haha

[@sammysheep]

For Go vs Rust and Go being more ergonomic, is it the borrow checker vs GC that hampers things or is it async Rust vs the built in Go concurrency engine that makes Rust more difficult in particular? I think the difficulties of both will improve in Rust over time, but likely the borrow checker has more constraints to evolve than evolving async Rust does.

[@edcoronado]

Great video! I’m curious about how Deno would stack up against these

[@tomasvallotton9264]

@ThePrimeagen Next time you have trouble getting rid of a mutex try using a local executor instead of a multithreaded runtime, that way you can use a non atomic async mutex, and you can use a thread local instead of a lazy static.

[@LuccDev]

Do you have any good light themes recommendation for neovim ? Cool video too ;)

[@hipnotickid12]

I've seen the whole video but now I just mostly come back for 0:00 - 0:14. Cracks me up every time.

[@ThePrimeagen]

It is the greatest intro that has ever happened

[@fedevile]

I'd love to see the same tests in a multicore system, my guess is go would shorten the difference somewhat with rust/zig

[@Omikronik]

I love your thumbnails

[@ThePrimeagen]

ty

[@prestonrasmussen1758]

I’m not familiar enough with the V8 JIT compiler to know exactly when it kicks in. I’m curious if you know whether or not the JS code would have been compiled to bytecode by the time you collected data? There will definitely be a significant performance difference between the interpreter executing the JS code while it’s warming up, and after the JIT compiler kicks in and bytecode is being executed instead.

[@ThePrimeagen]

so for small functions it is ~1 - 3 runs, large functions (1000+ chars) it tends to be 7 - 15 (all depending on size). All code was jitted within the first couple requests. :)

[@prestonrasmussen1758]

@@ThePrimeagen awesome, thanks for the info!

[@TheHellishFrog]

I did much simpler tests - like counting to one billion in a cycle - the (best) results: Node-Js = 11.5 sec, Bun = 12.0 sec, Go=5.7 sec, Java=5.2sec, Rust=110nano, Zig=52nano, Python - some ten minutes :). All code variants were written as simply and close to the basic example as possible, compiled, and optimized for speed. All tests were running on the same laptop i7 Ubuntu 22.

[@Luuucaa]

Excited for the Elixir vid

[@jsimonlarochelle]

Nice analysis. I'm not a fan of Go. The syntax is weird (I think they worked too hard not to look like Java). However, ..., GOs benchmark would have looked better on a multicore CPU which is what most PC are running except maybe on small embedded systems. If I am not mistaken, GO (like Java) uses a tracing GC and this will usually run on a separate thread and if this thread can actually map to an actual separate core then you get your memory management running in parallel. That is why languages and/or runtimes that use something like a tracing GC are normally very good for high throughput software on appropriate hardware. Whereas things like Python, Swift, ... which use a reference counting based memory manager, or Rust, Zig and others where you manually manage your memory will (in common implementation) actually trace the heap and manage memory on the same thread that is executing your code (except for a thread to manage circular references in Python, Swift, ...). On a single core, the tracing GC will still use an additional thread (at least one) but this will grab execution time from the single core and still involve context switching between the treads whereas Zig and Rust will not have this. So ... if you love GO's syntax and your not running your software on a hand held calculator chip, you will get good productivity and good performance.

[@driden1987]

I laughed at node's intro, well played

[@ThePrimeagen]

i thought it was great

[@idylls]

What are your thoughts on the ergonomics of async Rust? Personally, for me it's bad enough to push me towards using Deno for most web-y things, but I would really like to go "all-in" on Rust.

[@ThePrimeagen]

i really don't mind it. it takes a moment to get use to, but once you do, its pretty straight forward.

[@hogstudio4819]

If you don't mind Boxing, I'd say

[@godDIEmanLIVE]

You mind taking a look at Nim? Seems to me to be the Ring to rule them all.

[@DiegoVallejoDev]

It's time for a collaboration with Dave Plumber

[@hivemind9643]

I actually would love to see your take on Svelte. Looking forward

[@AlexandreAbreu1]

This is a backend benchmark, Svelte is used in fronted. Doesn't make sense

[@wety789]

The no compliments for node really got me 😂

[@hck1bloodday]

That silence afer saying node got me, jajajajaja

[@fabienpenso]

You should definitely add memory usage for each on top of speed performance. Memory has a higher cost than when we used bare metal servers, and it adds up quickly. Rust has massive pros for that compared to go and even more to node.

[@steffen2592]

True. We have a Java server solution and CPU usage was never the problem, RAM is the issue.

[@andredasilva6807]

love the intro. node...

[@ThePrimeagen]

great moment

[@arminrosic9550]

Thank goodness you mentioned Elixir at the end … the whole time I’m thinking … I suspect Erlang/Elixir could crush this, especially on multi-core machine

[@LtdJorge]

Erlang would never be able to beat Rust, but you could have distributed servers working as one and 9 9s of reliability basically for free. Not so much in Rust.

[@js-ny2ru]

He should use muli-core machine with Node also. That's where he shine. He keep testing it wrong...

[@MrR8686]

any more zig videos? it would be nice to see you try out more languages

[@wlockuz4467]

Would be interesting to see something similar with JS (node) vs Python.

[@dandymcgee]

They're both so blazingly slow that the profile would never finish and there would be nothing to report.

[@AaronMartinColby]

I may have missed it from the live stream or an earlier video, but were you using the standard http library or fasthttp for Go?

[@ThePrimeagen]

good questions! I just followed the GIN guide.

[@AaronMartinColby]

@@ThePrimeagen Go Fiber is basically ExpressJS for Go and uses fasthttp under the covers. Brings it to within 25% of Rust, at least with my tests using Actix. Gnet is apparently faster but I have not yet used it. Very interesting, though.

[@eventslooped7376]

Can you throw in some classic for comparison? Like C# and Java?

[@scottb4029]

Prime , do you have any recommendations for videos or books for learning go?

[@zuzuz18]

Sllllurpin up the content

[@eheh5748]

I love how I know how to make a Message Queue now thanks. (I'm about to steal your job eheheh)

[@elvor8512]

I’m not sure I really understand the method of this experiment, could somebody explain in a bit more detail? How does an increasing size of the queue mean faster speed? (the method in the rust vs bun vs node video with requests/second made more sense to me, at least)

[@peezieforestem5078]

Evidentially, nobody understands it either.

[@thebrowhodoesntlift9613]

Bro really went: Zig 🏃💨 Go 🏃💨 Node 🤨

[@madsxcva]

I wish this also had a language that was actually used in the industry to see how these flavor of the month languages (except node) compare to them and if its worth actually learning them

[@andrewrobie620]

Both Rust and Go are used extensively in the industry though? Sure they're not at Java/Python levels of adoption, but they're well past flavor of the month.

[@arcanernz]

I’ve seen a lot of KZbinrs but ThePrimeagen is the most blazingly fast one.

[@fitzgerald1337x]

i would love to see Deno vs Node vs Bun. the JavaScript space needs a new back-end king!

[@charlesselrachski34]

I hope they call the conference "burning buns"

[@grantwilliams630]

I think elixir is a pretty good language for simple request handling. (It’s kinda garbage for actual computation though)

[@ThePrimeagen]

i know nothing about elixir, we will see

[@verified_tinker1818]

@@ThePrimeagen You'll love it! It's an incredibly fun language; a mix of Erlang, Ruby, Haskell, and I think even a bit of Prolog.

[@harleyspeedthrust4013]

@@verified_tinker1818 what a rollercoaster. I pooped when you said ruby and splooged when you said haskell

[@luccahuguet]

@@ThePrimeagen do Julia too sometime!

[@js-ny2ru]

@@ThePrimeagen Check Elm also.

[@_thehunter_]

comparison was fair enough

[@n0kodoko143]

Zig is gaining some traction

[@grantwilliams630]

Zig actually has some pretty good container implementations in its stdlib

[@ThePrimeagen]

i was pleasantly surprised

[@SportSync_official]

How do you like your keyboard, and how do you manage vim with dvorak like the positions of the keys.

[@ThePrimeagen]

love the keyboard managing key positions? Its the same thing as qwerty, just different positions.

[@SportSync_official]

@@ThePrimeagen Yeah but vim is designed with qwerty in mind so isn't "ideal" to press j & k or l & h (and any other vim command) on dvorak like it is on a qwerty keyboard. So do you remap your keys or did you just learn vim on dvorak? (sorry for the odd question)

[@bendotcodes]

You forgot to mention that Go has an insane concurrency model with go routine. It makes building multi threading code 1000% easier. To me this is the big selling point. I would be curious to see the benchmark with more vCPU. Were you on only 1?

[@anomaliespatiale6023]

I’m an absolute beginner with Go but was thinking the same thing. Maybe the experiment’s parameters are not a good fit for the concurrency model of Go?

[@steveoc64]

You will find that zig and rust do the same thing as go … async frames (coroutines) spread over cpu cores using a thread pool.

[@bendotcodes]

@@steveoc64 Oh didn't knew about that, thanks for sharing! I know nothing about Rust maybe it's time to get my hand dirty 😅.

[@steveoc64]

@@bendotcodes rust does it via 3rd party packages - Tokio. Zig has it built into the stdlib, where it’s a bit easier to find and follow the code. It’s encouraged ( idiomatic even ) to roll your own custom event loop based on the stdlib example. I’ve been doing go professionally for just on 7 years now, but I never really understood the internals of how goroutines work, until learning zig. It’s awesome for that.

[@SimonBuchanNz]

@@steveoc64 it's weird to say "you need third party packages", when Rust put a lot of work into making the native async code work completely customizably. It's not "you need to", it's "you get to". Keep in mind, this same system works when you're building a kernel, or in a 1kB ram microcontroller. Although I wouldn't recommend it (for performance), it's not even that hard to implement an executor, it's logically just a queue of work to do and a way to go to sleep and wake up.

[@caseyclayton01]

I've caught myself using blazingly fast at work, so thanks for that. Not in a serious context, we primarily use Rails and Elixir.

[@mpldr_]

I like the Gopher from the thumbnail who vomits an upside down Nike logo at a bun

[@act0r399]

I don’t see yet video, but I think that Zig is blazingly fast😃

[@civetbutlemonbutmouse6087]

going into this i predict zig

[@halfman58]

LOL you said it at the end... Please do the same thing for Elixir or Erlang if possible :) Love you vids...

[@ThePrimeagen]

elixir will happen

[@LaPingvino]

Have you ever done some of these tests with TinyGo?

[@caiofelix623]

hey prime, what do you think about make a video benchmarking go versus java (using quarkus or springboot as it framework)?

[@ThePrimeagen]

i just wont do java. sowwy :(

[@whorudra]

You hate java?

[@__idan__]

I can contribute a spring boot version

[@DiegoVallejoDev]

@@ThePrimeagen admirable, a man of principles refusing to go into the java path

[@DiegoVallejoDev]

@@ThePrimeagen but what about Kotlin?

[@jakobbouchard]

The first time I learned about Zig was when I looked at ncdu's page. ncdu 2.0 uses it instead of C, which is interesting

[@peezieforestem5078]

Zig is just a superior C, even if all you do is use it as a compiler. Just the build system alone is worth it.

[@andrewdunbar828]

Just what I would've expected. But I wonder how managed languages like Java and C# compare to Go. I'm guessing they'd be neck and neck but between Node and Go.

[@krige]

Could you share the source code of this experiment? I would like to replicate it in Java

[@ivanmartinezalberte6089]

You are speaking blazingly fast! I had to change video's speed to 0.25. Oh my Go!

[@ThePrimeagen]

i will always speak fast, sowwy

[@quachhengtony7651]

I would like to formally request a video on C# vs Go

[@ThePrimeagen]

i will literally never do c# :)

[@senpos]

@@ThePrimeagen Why not? You don't like the .NET / Microsoft ecosystem? The language is too... "fancy" / Java-like? .NET Core seems to be blazingly fast!

[@betajoudi1440]

@@ThePrimeagen 😂😂

[@quachhengtony7651]

@@ThePrimeagen Can you tell me why?

[@200KGHantel]

@@quachhengtony7651 +1

[@ryanseipp6944]

Really want to see what happens when you go multi-core. I'd imagine rust/zig/go would pull away further but would highlight differences in how they handle concurrency across cores.

[@ThePrimeagen]

correct, i would have to come up with a multicore strat with node first

[@ryanseipp6944]

@@ThePrimeagen potentially multiple instances of the node server equal to number of cores and hit them on different ports

[@BosonCollider]

If you need parallelism, Rust will likely win, simply because it is written specifically for the fast-multithread-code usecase.

[@Cookie-mv2hg]

I lost it in Node....`silence`...`blinggg effect`

[@TheSulross]

Go is probably adequate for most server oriented apps - there are a lot of scenarios that the garbage collection overhead just comes out in the wash and is not a big deal. Manual mem mgt is where need deterministic behavior (embedded, OS kernels, device drivers, IoT, maybe ML) and where don't want significant overhead of an embedded runtime (e.g., Zig has no required runtime)

[@ArnabAnimeshDas]

But in the long term switching to bare metal languages will save a lot of infrastructure costs.

[@Roupi]

so if you will go to the trouble of doing elixir, you could take the chance and compare it with ruby (for the same purpose you have node in this comparison, show how it is slow in a scale). it would be even better to have a ruby and node comparison.

[@ComputationalArt]

Blazingly Fast!

[@avithedev]

I spat out my drink when he introduced node 🤣

[@cryptic1692]

I love the script kiddies roast

[@heroe1486]

When playing your character you sound like the Japanese voice of Tobi in Naruto, yes the one with the orange mask who disappears blazingly fast !

[@jackscheffel1509]

Prime -- have you checked out Nim? I would be interested to see how you feel about it and what you think about the DX.

[@ThePrimeagen]

no! NO!

[@jackscheffel1509]

@@ThePrimeagen What do you not like about nim?

[@Big_bangx]

Really really fast ain't enough ... I want BLAZINGLY FAST

[@piecodez5584]

Loved the intro XDXD

[@ThePrimeagen]

best work yet

[@diegolikescode]

NODE. (Uncomfortable silence)

[@samuelcatlow]

subbed for that elixir vid...

[@nathanie1637]

Have you ever tried worker threads with node?

[@ThePrimeagen]

no, very curious with them.

[@nathanie1637]

@@ThePrimeagen I read an article where Node was able to outperform Go with the use of worker threads.