WinterJS - A New Javascript Runtime
Summary
TLDRThe video script discusses the rapid emergence of new JavaScript frameworks and runtimes, focusing on Winter JS 1.0, a fast, fully compatible JavaScript runtime written in Rust. It questions the claims of speed and compatibility, highlighting the importance of real-world workloads over synthetic benchmarks. The speaker emphasizes the limitations of JavaScript for general-purpose programming and suggests that the choice of language or runtime often doesn't matter as much as the actual implementation and workload.
Takeaways
- 🚀 Introduction of Winter JS 1.0, a new JavaScript runtime claiming to be the fastest.
- 💡 Winter JS is written in Rust and uses the Spider Monkey engine to execute JavaScript and Tokyo for HTTP requests.
- 🌐 It can be compiled to WebAssembly, making it runnable in web browsers like Edge.
- 🔥 Winter JS 1.0 claims to handle 150,000 requests per second when executed natively.
- 🔄 The script questions the 'fastest' claim, comparing it to other technologies like Bun and Node.js.
- 📊 Discussion on benchmarking and how it may not always reflect real-world performance.
- 🛠️ The importance of real-world workloads and applications over synthetic benchmarks.
- 🔧 Mention of compatibility issues with Winter JS, noting that it's not fully compatible with all JavaScript features.
- 🔄 The script suggests that the real value lies in ecosystems and tooling, rather than raw speed.
- 🤔 A call for more meaningful tests, such as building and running a real application to truly measure performance.
- 🎯 The emphasis on understanding the practical implications of using different technologies in development.
Q & A
What is the main topic of discussion in the transcript?
-The main topic of discussion is the introduction of a new JavaScript runtime called Winter JS 1.0, and its comparison with other JavaScript frameworks and runtimes in terms of speed and compatibility.
What is the difference between a JavaScript runtime and a framework according to the transcript?
-A JavaScript runtime is an environment that executes JavaScript code, handling memory management and other system tasks, whereas a framework is a set of pre-written code that provides a structure for developers to build upon.
What does the speaker find questionable about Winter JS 1.0's claim of being the fastest?
-The speaker questions Winter JS 1.0's claim of being faster than other runtimes like Bun, which is written in Zig, because at the end of the day, Winter JS is still running JavaScript code.
What are the key features of Winter JS 1.0 mentioned in the transcript?
-Winter JS 1.0 is described as a fast, fully compatible JavaScript runtime written in Rust, using the Spider Monkey engine to execute JavaScript and Tokyo to handle underlying HTTP requests and JS event loops. It can also be compiled to WebAssembly.
What is the speaker's main concern about the compatibility of Winter JS 1.0?
-The speaker is concerned that Winter JS 1.0 claims to be fully compatible with JavaScript, but it does not implement certain features like back pressure and transform streams, which are not yet supported.
How does the speaker feel about the benchmarks provided for Winter JS 1.0?
-The speaker is skeptical about the benchmarks, as they believe they are synthetic and do not represent real-world workloads. They argue that the actual performance of a runtime matters more than just raw speed in benchmark tests.
What is the speaker's suggestion for a more meaningful test of Winter JS 1.0?
-The speaker suggests building a real application, such as a to-do application driven purely by server components, and then comparing the performance of that application running on Winter JS 1.0 with similar applications on other runtimes.
What does the speaker think about the importance of using a fast runtime or framework?
-The speaker believes that while efficiency is important, it is not the most crucial factor. They argue that in many cases, the choice of runtime or framework does not significantly impact the actual performance when dealing with real-world applications and workloads.
How does the speaker describe the performance of Go and Rust in handling a real-world workload?
-The speaker describes Go and Rust as being able to handle a significant number of games running simultaneously without dropping frames, with Rust being able to maintain 60 frames per second for 2,000 games and Go having a 1% frame drop rate.
What is the speaker's overall opinion on the significance of the new JavaScript runtime, Winter JS 1.0?
-The speaker is skeptical about the significance of Winter JS 1.0, questioning its claims of speed and compatibility, and suggesting that such advancements may not be as impactful as they seem in practical, real-world scenarios.
Outlines
🚀 Introduction to Winter JS 1.0
The paragraph introduces Winter JS 1.0, a new JavaScript runtime that claims to be the fastest. It discusses the difference between a runtime and an engine, and highlights the announcement of Winter JS as a fast alternative to existing JavaScript frameworks and runtimes like Node.js. The speaker expresses skepticism about the 'fastest' claim, especially when comparing it to other technologies like Bun, which is written in Zig.
🤔 Technical Details and Compatibility Concerns
This paragraph delves into the technical aspects of Winter JS, questioning its compatibility and the practicality of its claims. It mentions that Winter JS is written in Rust and uses the Spider Monkey engine to execute JavaScript, with Tokyo handling HTTP requests. The speaker points out that while Winter JS claims to be fully compatible, there are certain features like back pressure and transform streams that are not yet implemented.
🏃♂️ Performance Benchmarks and Comparisons
The speaker discusses the performance benchmarks of Winter JS, comparing it to other technologies like Bun and Node.js. It mentions that Winter JS can handle a high number of requests per second, both when executed natively and when compiled to WebAssembly. However, the speaker also raises concerns about the validity of these benchmarks, questioning the type of requests being measured and the conditions under which these tests were conducted.
🔧 Implementation and Practicality
This paragraph questions the practicality of implementing Winter JS, especially in comparison to using a fast language like Go for general-purpose programming. The speaker argues that JavaScript may not be the best choice for performance-critical applications and shares personal experiences with game programming to illustrate the point that performance can degrade significantly with more complex workloads.
🧐 Real-World Testing and Ecosystem
The speaker calls for real-world testing of Winter JS by building a server-driven application and measuring its performance. They emphasize the importance of considering the entire ecosystem and tooling around a technology, rather than just its raw performance. The paragraph also discusses the challenges of convincing developers to switch from JavaScript to a new runtime like Bun or Winter JS.
📉 Synthetic Benchmarks and Real Workloads
The paragraph criticizes the focus on synthetic benchmarks and emphasizes the importance of testing with real workloads. The speaker shares a personal story of testing different technologies with a complex application and stresses that the performance difference between technologies becomes negligible when dealing with actual workloads. They argue that the hype around fast runtimes is overblown and that it's more important to focus on building a usable and efficient system.
Mindmap
Keywords
💡JavaScript runtime
💡Spider Monkey engine
💡Rust
💡WebAssembly
💡Cloudflare workers
💡React Server Components
💡Performance benchmarking
💡Async hooks
💡Compatibility
💡Synthetic benchmarks
💡Startups
Highlights
The introduction of Winter JS 1.0, a new JavaScript runtime.
Winter JS is宣称为最快的JavaScript运行时,但作者对此表示怀疑。
Winter JS 1.0是用Rust编写的,使用Spider Monkey引擎执行JavaScript。
Winter JS声称在四个月内取得了显著的速度提升。
Winter JS的全面兼容性受到质疑,因为它尚未实现某些功能。
Winter JS的云原生API兼容性和对React服务器组件的支持。
Winter JS 1.0能够处理每秒150,000个请求,当本地执行时。
Winter JS在编译到WebAssembly时,性能下降,每秒只能处理20,000个请求。
作者对Winter JS的性能基准测试表示怀疑,并认为这些测试没有意义。
作者通过比较不同语言的性能,强调了JavaScript在处理复杂逻辑时的性能局限。
作者提出了一个观点,即在JavaScript中,即使是简单的任务也可能导致性能大幅下降。
作者对JavaScript作为通用编程语言的选择表示质疑。
作者认为,尽管某些语言可能在性能上更快,但它们并不一定能提供更实际的价值。
作者强调了在实际应用中,性能基准测试的结果可能并不可靠。
作者建议,应该通过构建真实的应用程序来测试性能,而不是依赖于合成的基准测试。
作者对JavaScript运行时的快速迭代和新框架的频繁出现表示困惑。
作者通过个人经验,比较了不同语言在处理高负载应用程序时的性能。
作者对编程语言的选择提出了建议,强调了工具和生态系统的重要性。
作者对当前JavaScript框架和运行时的性能竞争表示失望,并认为这并不是正确的发展方向。
作者分享了自己的游戏编程经验,以此来说明在实际应用中性能的重要性。
作者对编程社区中对某些语言的过度炒作表示批评,并提倡更加实际和有意义的性能测试。
Transcripts
I don't know how this keeps happening
but how do we go one month just just one
month and we have a new JavaScript
framework already okay or not JavaScript
framework but JavaScript runtime okay
not even a framework for those that
don't if you don't know the difference
between a runtime or what a runtime is
let me just say this so remember
JavaScript executes in like a little
engine okay this thing takes care of
memory management it takes care of like
keeping track of acing tasks and all
that kind of stuff okay uh whereas you
need the ability to actually interact
with like the file system right you need
to be able to actually make requests out
somewhere you need to be able to do like
a bunch of extra stuff so this would be
like
V8 this is node okay so someone has
Rewritten node and potentially swapped
out the engine let's find out the thing
that they've done winter JS 1.0
announcing winter JS the fastest
javasript damn they actually went for
the fastest now that's kind of a bold
move because at the end of the day
you're still running
JavaScript right and you're claiming to
be faster than bun which is written in
Zig so I don't even know what is this is
this is this written in Rust is this
rust versus Zig the fastest JavaScript
web uh server now also supporting
cloudflare applications and react server
components
speed winter JS 1.0 is finally here
winter JS is an incredibly fast winter
CG compatible JavaScript runtime written
in Rust using spider monkey engine to
execute JavaScript and Tokyo to handle
underlying HTTP requests and JS Event
Loop winter JS runtime can also be
compiled to web assembly and as such is
the first production grade runtime fully
runnable in wer
Edge okay okay here's what we have
accomplished for winter uh JS 1.0 in
just four months after our first
announcement blazing fast speeds faster
than bun worker D and node well I mean
being fast than node we've all learned
is not that bad and all you to do is
just not Implement any of the async
hooks that bun does or that node does
and boom you're faster winter JS is now
fully compatible you can't put an aster
you can't you can't say this and then
throw an aster I just want to let you
know you cannot do that that's not
allowed okay that's not allowed right
there no I don't care what is what's the
aster what's the aster
mean well where the hell do they Define
the asteris
what it can't be that one
okay it is it this one back pressure and
transform streams and some non-common
crypto algorithms are not implemented
yet oh it is this okay yeah that sounds
like you're not fully compatible just
throwing that out there fully means full
shaft here okay I mean I get it you I
get it is you're not like Loosely
compatible 97% compatible yeah 35ths
compatible uh just wrap it with quotes
compatible uh let's see
okay oh well oh I'm stupid I'm stupid
I'm stupid it says with the winter GC
spec okay I said there we go I thought
it was just I my bad but still you still
can't say fully compatible you still
can't say this you still can't do that
cloud flare API compatibility web
framework support nextjs supporting
react server components hono Astro seel
kit uh now let's see more detail each of
these features ridiculously fast winter
JS 1.0 is able to handle 150,000 request
per second when executed natively
natively just means running JavaScript
right is that what this means in this in
this L plus ratio plus stupid
potentially that that literally just
means running JavaScript right no no
compiled to WX no I don't think so
because it says 20K request per second
when compiled uh to wasm using wasix
wasix is just like a wasm spec right
it's like extended wasm spec right uh as
of today winter JS can handle more
requests per second than bun 117,000
requests per second worker D 40,000
requests per second and noj has 75,000
requests per second
okay what kind of requests are we
talking about here I do like that you
put the lightning bolt on here okay
lightning bolts you know this kind of
lightning bolt holds a very special
place in my heart because when I was a
kid there was no greater feeling in the
universe than getting the lightning bolt
while playing Mario for the Super
Nintendo Mario Super Mario Kart for the
Super Nintendo okay there's no greater
feeling so when I see that lightning
bolt it makes me feel warm
inside
okay all right I do want to see The
Benchmark all right what's the Benchmark
here where do you simple is kind of
confusing to me because where do you
where do you specify stuff is it
something like this what is this worker
C oh this must be some sort of cloud
flare bsas flake oh man they're nixing
oh my goodness Nix boners are in the
chat as we speak Speak oh no Nick boners
here it comes um all right so no
simple
ah but hold on May I say may I say hold
on May I say hold on look at what's
Happening Here everybody look at this
new response hello I guess we're going
to have to what what is a response I'd
have to look at the source code for
response to understand this okay but
look at this one you have to create an
object right here
something tells me these these don't
feel like necessarily the same that's a
web standard I hear that but is that is
that header being set by doing an object
merge here or is that header being set
in the zig level hey I'm just saying
there's a difference okay writing a
header at the point of
request at like the the deep down Zig
level versus writing writing that header
in as an object free floating in node
remember I mean there there's just a
simple there is a difference okay uh
this is stupid if you're running native
just use a fast language for
sake that's a lot of going
on here buddy I can't take it anymore JS
is objectively poor choice for a general
purpose programming language I do agree
it is a very great language for UI just
like Lua I think Lua is a great D I mean
I think dynamic programming languages
are great glue languages that's the
point of dynamic programming languages
um why is there code uh uh true I agree
base take out fast server that's
the that's the F like that's the thing
hey thank you P PP PPH PP
hav what a name what a name can we
just get some claps in the chat for PP
hav coming in tier three oh my goodness
just give me the exe baby um anyway so
that's one thing I just see right away
that makes me a little bit like Curious
and this also right here what's going on
right here how's this how is this
implemented right like I don't feel like
in my opinion I again I we talked about
this earlier right where there's these
things that end up happening I think I
actually already have the diagram uh
yeah I already have the diagram right
here which is these these dumb examples
that are just these like super super
super tiny examples and they're just
saying like look how fast we are the
reality is is like if you do anything
like anything in JavaScript you're going
to massively slow it down you run react
one time to render a div which remember
they're saying they support server side
uh server server components right you
write a by the way this is in invalid
syntax uh sorry here let me properly
close that div for us all right there we
go you write a singular div right just
one guess what like your 100K requests
or whatever these things that they're
trying to tell you is is going to happen
it's going down lit by potentially 100x
you might only be able to do this a,
times maybe 2,000 times maybe 10,000
times who knows but whatever is
happening this is getting dominated one
of the greatest exercis I ever did in my
lifetime was when I first started off
trying to learn how to do game
programming in XNA you may have heard of
it game studios Microsoft C baby I was a
c Andy at one point I did years of Z I
absolutely loved it but one of the first
things that I was taught is you always
make a FPS counter right away and you
paint it in your upper left hand corner
of the screen right that's like the
first thing you build so when I first
started off I saw man I had 3 thou I was
going at like 3,000 frames a second oh I
have I have frames for days and then I
wrote a triangle and it's like 3,000 to
like 500 or something like that you know
just like a just a just a massive you
know jump down in the amount of frames
that I was having available and that's
when I realized oh crap like you
actually have to be really thoughtful
about what you're doing you can't just
simply assume that just because it
starts off as a huge number that that
number nicely goes down slowly over time
even though you're adding tons of
features no it's like a logarithmic
curve it goes it it dies fast and then
slowly goes down just add one Json
string of five Json pars and the request
Handler and it's all over exactly the
curse of FPS I know and so it's one of
those things that you get sold these
kind of crappy examples of why this is
super awesome the thing like I don't
know what spider monkey has done does
spider monkey have as good of Json uh
stringification and parsing that V8 does
like V8 has some of the best Json
parsing there is it's Sim deed out of
its mind it's super fantastic it's
faster at parsing jesson than it is at
parsing JavaScript it is fast it is
smooth and it can go really really quick
uh you know for JavaScript and and and
and and Json and all those things right
simd nuts exactly and so it's like one
of those things where
these kind of tests don't mean anything
what about noes URL parsing I hear it's
I hear it's the tippity top I hear it's
the tippity
top um yeah spider monkeys the Firefox
runtime yeah I I know um but this is
just like why this whole thing is just
so uninteresting in the sense that when
they say this it means nothing they need
to show you a real thing right so what I
want to see is
build an application a to-do application
that's purely server driven
and then take that purely server driven
application use your little react server
components or whatever you want to use
and see how fast you can run
that that makes way more sense right I
don't want to clone it investigate
because I don't want to spend three
hours investigating into something that
I just don't really care okay I can just
tell you right now this it's just like
it's just it it's just plainly wrong and
I bet you there's already somebody out
there that has now coming and saying hey
it's impossible watch this here comes I
benchmarked using my main branch on
Apple silicon mini M2 bun on a single
core serves
192,000 uh requests per second winter JS
utilizing three cor serves 880,000
requests per second so approximately 6X
slower than bun I don't know where this
claim is coming
from and this guy's name is just JS a
very small V8 JavaScript runtime oh it's
another runtime damn I just got owned by
another runtime but hey I'll follow you
what a great thing but I mean I think
this is correct but also this is very
interesting utilizing multiple cores
H uh but this is a good point again this
is why you don't trust any just don't
trust benchmarks okay because who am I
supposed to trust now should I trust
winter JS or should I trust just JS
which one should we
trust like how do you even know uh this
was used let's see uh this was using 64
connections two threads uh for work if
you look at the bench they describe uh
how they are obviously running on a
machine with at least 12 cores and
comparing bun and others to running on a
single thread oh no did we miss that oh
no oh no oh no this Benchmark is a
MacBook Pro M3 Max laptop with 64 GB of
RAM okay so that must that must that's
them saying this how do you know that
it's working with that my my question is
up let's see worker D Darwin arm 64
serve do this thing uh like how do you
know how many how many cores are being
used cuz this thing say 12 threads this
one 12 threads this one bun 12 threads
this one oh this is how many threads are
obviously being oh this is the what's it
called This is the uh this is the work
this is how many threads they're using
for connections so that's the I mean
that's the thing I don't get is how do
you know how how do you know that this
is using more more resources with winter
JS than the other one T12 yeah the t2
that's just that's just the worker
threads right that's these guys right
here that's this thing that's that's
like uh you know like any of the any of
the HTTP testing Frameworks you just
know this so from this you don't know
right cuz they're all they're all saying
12 threads because they're all testing
with the same amount of threads you have
to look at htop you have to look at
something else that actually is doing it
all right OS threads uh potentially not
equaling Hardware threads winter JS is a
side project why Bob left the IT
department six scores uh is pitifully
slow anyways 19 uh 17.1 n megabytes per
second is pitifully slow got him um I
haven't figured out how to compile it on
Linux there's a C++ compiler error when
it compiles a MJS CIS after hanging for
about 10 minutes tried using Nick shell
uh and ALS let's see and also without
that yeah I don't even have yeah
happened to be on Ubuntu 2204 see I only
have Ubuntu uh anyways are you comparing
uh Native bun what what is this
native what is this native business they
keep saying uh it also seems to have
some kind of massive memory leakage
around 30 gigabytes RSS after a few work
runs let's go let's go uh again this is
why be careful what you say I mean the
wasar people are pretty smart people I'm
not saying I I'm not like knocking them
but this is why you should be very very
careful saying these
things okay I like the tweets so people
can see it right when I like the tweet
it shows up everywhere um it's very
interesting another JavaScript runtime
another disappointment in the end I mean
I mean like bun is bun is pretty cool
but again bun still has this problem
where it's just like how are you going
to convince everybody to switch over
from no. JS to bun JS like I just
foresee that being very very difficult
um not only that but like what are you
really buying yourself if you have any
sophisticated logic at all in JavaScript
you actually haven't bought anything I
couldn't really tell a difference and I
played with it for hours upon hours upon
tens of hours trying to get a difference
between V8 and Bun and I could not
really find a strong difference in the
the actual JavaScript execution now
there is a big difference when it comes
to you know the runtime and how they
handle async stuff and Bun is just
faster but bun has less things that you
can hook into like data dog if I'm not
mistaken does not work on bun because
they don't have all the hooks now I
could be wrong at this point in life I
don't know if they've changed things but
when I last looked at it you couldn't do
all that but now you get into this whole
idea that like we're competing on the
dumbest possible access right like
writing a fast JavaScript runtime and
trying to like compete with bun or no.
JS I think you're just fundamentally
doing the wrong thing cuz all you're
really testing is how fast is my native
code compared to your native code and
it's just not real right it's just like
not a it's just not a real test yes the
only nice thing about bun is the tooling
they built for like that's that's the
reason that's honestly the reason to use
bun is that they have an entire
ecosystem and tooling around it right
like that's much
better the thing is is that you could
write the world's most simple go server
and you're going to be able to do you're
going to be able to do a massive
amount right you're just going to be
able to do a really good job here you
know what you know what forget about it
I have let's see let's go like this
let's go to personal hey flip you're
going to have to edit this to make it
like quick you know what I mean don't
have all of this on here because this is
way too much make uh go test go test uh
go mod anit suck it.t v/ just it all
right there we go we have this one uh uh
command all right and main.go okay P
perfect package main bum uh main here we
go and just to make sure I have the
exact same thing I don't even know if I
have work uh installed on my computer
all right so here's the command that
they're running fantastic I love it uh
and then let's see uh I don't even know
how to do the HTTP uh server right what
is it it's uh no no no no it's HTTP
handle Funk this guy
and then what did they have I think it
was just hello right what was it it was
just hello right we have a writer so we
have a what is it format F print can I
just do
that can I just print is that like is
that something we can do is that all I
need to do I you know that's the that's
the thing I don't even know if I have to
do that I never raw dog a little uh
format server uh oh and then I have to
go like this HTTP what do we have to
listen and serve on 80 okay
fantastic go run command mang go and
this may be in debug but who cares for a
second HTP uh whoopsies get out of here
curl HTTP uh 12700
01 8080 okay so we got the same hello I
got a capital letter they don't got a
capital letter can I do
verbose uh real question does it
set how do I view the headers
response headers content length five
text there you go see there we go so we
have we're getting everything in here
okay so we got we got it all we got it
all good IP leaked 20 uh 127 okay so do
I have
work no I don't have work okay uh hold
on I'm going to pseudo app and we'll do
this for a quick second hold on there we
go first off I think I'm in debug build
right now right this is just like
nothing fantastic going on here
okay so we destroy just
destroyed absolutely just
wrecked hands down destroyed demolished
debug builded uh we go what how do you
do a good what's like what's a good
debug how do I do a debug build and go
or a release build release build go I I
don't even know I always have to look
this up cuz I write this like once per
Docker file and I never look at it again
uh default go build combin symbols and
debug information however you can remove
all this stuff and do go this one right
here okay is that the one we want to do
uh common go just just go build but it
has all that extra crap in there I want
like the the most the most smoothest
most smallest
possible one okay I got the same thing
destroyed absolutely wrecked I'm on a
sign I'm on a very my CPU is
significantly weaker than anything
they're running right uh first off
if you uh cat uh Pro CPU info right like
I'm on a I'm on not nearly the same I am
not nearly the same I only have I'm on
like a little liir Pro okay I'm I I am
not on a very fast CPU
right okay I mean good CPU nice but
still a a it's a couple years old this
there's nothing fantastic FC going on
here right this guy seems mobile Weare
yeah exactly I'm not using a fantastic
computer this guy's on an M3 Max laptop
with 64 gigs of of of
ram okay right so it's like I'm not
using a lot and I just destroyed it okay
wrecked wrecked it apparently we can't
get was Winter JS to easily build is
that what we saw let's see if they may
have fixed it already let's let's find
out can I can I just do this H I don't
want I don't want to I honestly I don't
want to deal with building it and all
that okay I'm not even going to do it
I'm not cuz I got to go like we got to
go like read stuff and build it and it's
going to take forever to do stuff I
don't want to do this we're not going to
do it we'll do it later but just use the
nyck flake I have to get NX install then
understand how to Nix it yeah just give
me the exe all right there you go that's
how I feel about the whole situation do
with bun fine here I I'll do with bun
there you go I think I have bun right
yeah yeah yeah I I have bun bun update
is that how you do it uh bun
uh is there a way to oh upgrade there
you go I'll make sure yes there we
go there we go we upgraded upgrade
upgrade upgrade all right so we'll this
will give us a some light into what's
happening here okay some light not like
a ton of light but you know some
light and then we'll do a bun
simple uh bun. TS is that what you call
these things I assume so bun bun
TS
fair fair
okay there we go actually let's run it
over here bun bun TS all right there we
go so we got that 8080 and then now
let's let's do a little
work
wrecked destroyed
annihilated wck them um so there you go
absolutely Grand absolutely
Grand not even
close again but it's doesn't matter cuz
again it it just it again it just does
not matter everything we did here
doesn't matter because none of it
actually makes any sort of sense or is
Meaningful okay none of it's actually
meaningful okay so again don't buy test
okay see a real appload see a real
workload okay like a real workload you
actually have to have something that it
does okay so here's a good here's a good
story is I I had this like little
example app that I built of few times
it's a shooter app where you have two
like computers come up and they shoot
and they use websocket connections to do
all that and we ran a test between how
long can I maintain 60 frames per second
updating in node versus Go versus rust
at rust I could have like 2,000 games
running and I didn't drop a single frame
everything was 60 milliseconds on the
dot or uh 60 frames per second on the
dot for 2,000 running games in go it was
like I was dropping like 1% of frames
that means when I say dropping that
means going um up above 17 milliseconds
per frame that was wild right and so
it's just like okay only 1% of them with
node I couldn't get to 2,000 games and
when I did get to like, 1500 games or
whatever it was I was at like 20% of the
frames were more than 17 milliseconds
and so it's one of those things where
when somebody tells you like a it's like
so blazingly fast it's so amazing it's
so this and so that it doesn't matter
guys it doesn't matter shut the hell up
about rust shut the hell up about Russ
cuz it doesn't matter okay it doesn't
matter I was just showing you a basic
point that if you can just launch up any
other language it go super duper Ultra
dang fast okay just shut up it doesn't
matter we're going to launch up rust and
Bam wow it's going to be like 220 holy
cow it's so fast but nobody actually
cares because it's not actually doing
something amazing okay can we just stop
with it like I was I was really hoping
you would understand the point of this
which is that these type of tests are
synthetic and they mean nothing okay
because when we add a bunch of workload
you know what Go's going to do it's
going to drop by like 50% but bun is
going to drop by like
90% And it's going to have much more
variation in requests which is all very
very very important to understand okay
it's very important because that's where
it matters it doesn't matter when it's
just hello world it matters when you're
actually doing something like actually
doing something you assumed I understand
anything think shame on you no no I will
not coat in Rust I will not my hair is
not blue yeah guys I dyed I I I dyed my
hair blue a long time ago okay I no
longer have blue hair we don't program
rust around here anymore uh benchmarks
are more or less uh assume optimized
code uh in reality that's rare yes like
you should make things efficient because
at the end of the day like inefficient
code will truly cost you a lot of money
as you actually get real users most of
you don't even have real users okay you
guys just just have a bunch of startups
that have zero users it has only your
test user so it doesn't really matter
okay it doesn't really matter how you
write your code so just use winter JS or
bun or go or rust or whatever the hell
you want to use because it's not going
to it's you know 95% of all startups
fail anyway so it's not like you're
actually getting anywhere you know I
hate to tell you this you're dead on a
Ral buddy um words hurt man sorry for
just sorry for dropping at all only
95% what would be a real test in your
opinion oh something that's rendering
something something that's doing
something Ser how about this one simple
serving HTM X page with enough elements
on it to be useful right like that's not
that's not crazy that's like simple
right it's easy it's not that bad okay
do it then I again I'm not going to
spend two hours trying to make this
really great example because again I
don't care we've already done it I
already have YouTube videos doing it if
you want to go do it do go go go is
faster than typescript one okay I did a
whole thing on it we've already looked
at this this is already a well
understood problem if you don't
understand the problem go do a little
bit of reading go do a little bit of
experimenting yourself doesn't even need
oh I was just saying put HTM X in there
right do something do a little bit do do
like put something in there right
YouTube's chat ignored but they got
videos this is true YouTube sorry the
Bots that destroy my WordPress site at
the same time every day are real users
the
name is Winter's
coming JS s Jen
Ver Más Videos Relacionados
Node.js Tutorial - 2 - ECMAScript
How Much Memory for 1,000,000 Threads in 7 Languages | Go, Rust, C#, Elixir, Java, Node, Python
Bun1.1 Released!
err != nil Is GOOD? (And Why)
Setting up environment in local machine for Javascript | chai aur #javascript
Python vs JavaScript | What to Choose? | ft. Toolify.ai
5.0 / 5 (0 votes)