@@F1nnyF6 Incorrect. C++ is very very fast in terms of compilation and caches everything. Rust is the one that's fucking slow as hell; probably the only thing I hate about Rust is compliation time, which is the worst out of every language in existence.
people complain when devs dont give short concise updates instead of just throwing out mounds of documentation , then people complain when they do and point out ambiguity as if the info should have been a 1 hour video that few would have watched to beyond half way. The poor fellas appear to have tried and got out of there comfort zones , so I appreciate this even tho I probably wont adopt bun until new project just like I havnt adopted deno yet.
22:02 Given how many "Flip take that out" moments have infact, not been taken out over the past few days, it makes you question if Flip takes *_anything_* out?
$ is not Bash spawned in Bun, it's its own minimal semi-compatible Bash-like language that deals with the core of stuff we normally do in CD, and you can pipe stuff hither and dither into JS buffers. But it's NOT Bash, just a lexar and interpreter back into the Bun JS runtime (so any bug-fixes or improvements to Bun also applies to this process), so any tools that works checking JS code can check this. It's really good for offloading a lot of multi-OS scripting into a simpler platform. I use it for a lot of infrastructure stuff, I hate Bash / Ash cross-platform nonsense with a passion.
many of the bun speed gains come from implementing things natively and comparing with JS based packages so they may be actually doing exactly the same thing, just more efficiently
I will never diss on optimizations in software used by many devs. A lot of this may seem inconsequential, but if you've ever worked with a compiler like tcc you'd know how good it feels to compile and run a large project in < 50ms Entire problem sets disappear when you can just do the naive thing and have it be realtime
The dev's might only do "Bun install" once, the CI/CD does it all the time, that 18X improvement will increase your actual velocity when working on large scale project with deployment pipelines.
Last version got me excited to try Bun, to migrate some of my stuff, but quickly found out it didn't run directly on Windows. So this release made me migrate my website to Bun. Unfortunately, I have to say I did not see an improvement in performance. It was ~20% slower than node running "vite build" and "vite dev". Long running functions ran ~20-30% slower. Startup was slightly faster, and so was install, but I really don't care about the performance of my site when it's not even handling requests yet. So I did a little search and found out it's just that JSC optimizes less (faster starts) but runs slightly slower afterwards compared to V8. That said, I still plan on keeping Bun around for package management and the handy one liner to create an .exe from your JS/TS code.
0:40 : (When will we drop Windows?) As soon as none tech affine Project Managers / Company leaders stop thinking that Windows is essential for a "Successfull Company" to have. My Last two bosses had that mindset. Hurray for windows finally getting a usable shell scripting language, that does not require setting up an entire virtual machine. 5:50 : (Just try the command 😏) The command runs fine. It is just a shame, that such a video came out on April 1st. The only day of the year when people question if what they read on the Internet is true. Some of it sounds clearly like BS though, especially some of the Performance stuff. 9:33: (Who uses the same scripts on Mac, Win. and Linux?) That would be me. I'm forced to run Windows at work. I have to use MacOS for debugging PWAs on iPads. I Run Linux at home. Having the same helperscrips just work everywhere sounds amazing.
Windows is the best desktop OS, it's not perfect, but takes next to no effort to get it to be B+ while sure, you can master your Linux install to get it to an A+ but at what cost? that being said: if you have to develop directly on host RUN AWAY we have WSL and full fledged VM's for a reason also powershell is a better scripting language than bash, it saves you from so many string manipulations! but yeah, it's not great either, just slightly less broken
regarding that rm -rf business at around 6:10... Git for Windows distributes a copy of bash and a bunch of common userland tools... am I missing something, or is there a reason not to use them? You can get a surprisingly UNIX-esque terminal experience on Windows this way, even without reaching for WSL.
I would say it's fairly common to have teams of devs some on Windows and some on MacOS. I'm certainly in that type of group. We don't seem to need this tbh as some of the 'scripty' stuff we have done in powershell which runs fine on MacOS.
Same. It's clearly the devs choice and not necessarily the language's fault. You can create a Go project with 100 deps or with just one (postgres driver, e.g. pgx). The same is true for Node. It has everything you need for the basic server except for the postgres driver (postgres.js has no additional deps). When Prime is talking about 100 deps for a web service, then it's not Node's fault but the fault of the sloppy devs who include every piece of crap from NPM. Rust is a different story, as the std lib is not as comprehensive as Go's or Node's. Listing all deps for a basic Axum and postgres backend is a bit disturbing.
@14:18 I used to wait 182 seconds for my react project to cold start when I was using webpack (260K LOC) w/TypeScript. That and the fact that I had barrelled all the exports within Create-React-App because there was no path aliases made it a nightmare. I saw glory when I migrated it out to Vite. Cold Start - 28seconds. Cached, it would boot up in 4 - 5 seconds. It was important when you messed up with tsc and it had to restart to pickup the changes.
19:00 just because different languages compile to an intermediate language, doesn’t necessarily mean the resulting output is comparable in terms of performance. The resulting intermediate code will be different for each language and will be compiled into actual bytecode. And it’s obviously not guaranteed that that last step will always result in identical performing bytecode, given different inputs.
9:42 Well you do work primarily at Netflix, so are going to be using primarily web-server technologies. Most web-servers are linux only. If you work in desktop applications, this is way more common. 10:24 Yes. Cross-platform desktop applications are a maintenance nightmare. But stuff like this is a step towards making it less of a maintenance nightmare imo.
Linux Subsystem for Windows: *exists* Bun < 1.1: *exists* Dev: We have very cool features planned in free near future. [not even a couple seconds later] Users: When will you make it run on Windows Dev: *pauses all planned features and works on windows support*
29:37 I had largely written js/ts with a little bit of py for scripting, but I recently started going cs50x and actually like programming in c (except for the lack of .length)
There is one things between language. They can be more expressive on type and memory access pattern that are reflected in the intermediate language. So even if all language end up using LLVM, they can have different performance outcome. A very excessive example in that regard would be to compare ISPC vs C++ both using LLVM. As ISPC express data parallelism, LLVM can generate SIMD code by default and so the code generated when using ISPC will be faster than a C++ code that just use C++. Same things happen with rust, as it express more information memory access and ownership, the generated IR has more information and LLVM can generate better binary at the end. My understanding is that zig is also better than C++ at expressing this memory ownership and data parallelism problem, so even with a LLVM backend, zig could be better than C++.
I'm a cross-platform developer. My main driver is Windows, my laptop is Linux. Zero interest in ever touching Apple though. Having the lightweight OS on the wesker machine is nice, and making my code work on both is an interesting challenge.
I remember going though benchmarks between the Sun's JVM and IBM 'sJVM this was decades ago. . IBM's was faster, often twice as fast, but it also failed spectacularly on some of the benchmarks. So yea IBM/s was faster because it didn't do the same level of safety checking that Sun's implementation was doing.
Crossplatform devs. Well here! My home machine runs Windows cause I wanna do some proper gaming. So far a WFH I won't dual boot. So Home windows and work Ubuntu. Not to forget that some devs in our company work on Mac, most on windows and a few on Linux.
JavaScript in bash seems like an inevitable step. By this time I wouldn't be surprised if JS was made to run on Twinkies. But i feel reminded a lot of Jeff Goldblum in Jurassic Park....
Bun is in that weird place of performance where it isn't exactly great at edge as it still starts up pretty slowly when compared to edge solutions but once it does it runs so much faster... there's probably a right use for that, but I wouldn't put it on rarely run on demand environments just yet
500 dependencies... I wrote a fullstack go app with templates for frontend. It has only one dependency, the pgx postgres driver. There's no native postgres driver, so I had to.
The thing that makes me not be able to use bun as a node drop-in replacement is that they don't support node-gyp dependency building and they don't automatically insert their bun-specific dependency in imports. *specific actual example*, I have a wrapper around better-sqlite3 with 5+ million views. This wrapper cannot be used in bun because better-sqlite3 isn't buildable in bun, and I'd have to make a branch/more code/environment checker, to change the *import* I'm using in order for my module to be useable in bun. Just to save 30 nanoseconds to run tsc --help, I guess?
If, as a developer, you are installing node_modules 3 times a day, there is something massively wrong with what you are doing or what you are working on. In enterprise, on any existing web application, you are installing node_modules (via npm, yarn, whatever...) once. Maybe a second time SIX MONTHS later. What is wrong with all of you people?! The only thing that this matters for is operationalization. Building environments on the fly. Which, yes, you should have all your dependencies cached and the build server reaches into the cache (which is ideally on the same server) to pull those. This is why `npm ci` exists. Use the package-lock, pull those dependencies from cache, install them. Should be fast. Needs to be as fast as possible, especially if you're building ephemeral environments for test teams constantly.
Mocking is not "tsting your feelings". Mocking allows you to test against the agreed upon design contract. I mean, I know that Primeagen trolls all the way, but people do pay attention to what he says. So once again, good mocking is an excellent addition to a testing suite: implement standard (as pre-determined by the agreed design documentation) expectations in mocks and then test to your heart's content.
I personally am not a fan of mocking, I do use it sometimes but prefer fakes at the service boundaries where possible. Code bases where I have seen extensive use of mocks have had very brittle tests that make refactoring difficult and do not give a high level of confidence that the system as a whole is working. Maybe this is just an issue with overuse of mocks though. Like I mentioned personally I use mocks sometimes but try to do it as little as possible.
You should checkout reports on actual projects replacing node with bun. If you can speed things up that had been slow enough to notice before by just drop-in bun, I would not complain.
9:40 Letting devs choose which platform they prefer is not a bad thing. Many companies let you choose between mac or pc when you join and it means those devs will run into cross platform issues. I mean, this is less than ideal, but I think it is a great addition to be able to support both platforms at once. Also, you may have .NET developers make the jump into other technologies or just be temporarily assigned to another project. It would make no sense to order a 3.5k$ Mac for such a short amount of time. Linux computers are also very hard to manage at scale for enterprise companies with very rigorous security policies, hence the Windows computers. You may call skill issues here, but this is the reality and most of the IT workforce out there is mostly used to manage Windows computers with a mix of Mac. 🤷♂️
Was it really such a necessary feature to use shell scripts on windows? Must have been a lot of work translating each bash command to a windows counterpart. And there will always be some small differences, like different versions of bash, which have different arguments for commands. All that work when there is already a decent solution - wsl lol
Downloaded on windows, tried running my discord bot that used to be run with bun in WSL, instant segfault 😂 tried running it again, the third time it suddenly worked... Since then it runs around 50% of the time
Memes are fun until they are affecting the quality of the video. I would have appreciated an actual review. You're better than this Prime I believe in you 💪💪
@@JannisAdmekI don't have a good *complete* definition, but things like Rusts panic unwinding, or C++'s exceptions definitely are runtime things. Also I think that C might set up some default signal handler. Also C's default IO-buffering might count under runtime. (Also there is something like "life before main".)
I don't understand why support native Windows when you could run this in WSL? I'm currently using Fedora via WSL for my day job because corporate policy forces me to be on Windows. I admit it's no pure Linux but it's usable IMO.
![[#2024MAMA] ROSÉ (로제), Bruno Mars - APT. | Mnet 241122 방송](http://i.ytimg.com/vi/dgGqD28J6aQ/mqdefault.jpg)
Installing node_modules is a great time for a coffee break. Don't take this away from me! Otherwise I'll have to go back C++.
With C++ you can just have a coffee break when it's compiling instead
Sounds like a really sad and infuriating thing to go back to
@@F1nnyF6 *many
@@F1nnyF6thats rust, C/C++ builds fast on modern CPUs, and you often need to rebuild changed files. It's quick pee break at best
@@F1nnyF6 Incorrect. C++ is very very fast in terms of compilation and caches everything. Rust is the one that's fucking slow as hell; probably the only thing I hate about Rust is compliation time, which is the worst out of every language in existence.
in other news, i heard this jia tan guy was making some big performance improvements for bun
Haha u should try his xz package specifically version 5.6.0 or 5.6.1
@Nemesis-db8fl on a production server. Apparently they really optimized it for that /s
Huge features coming
@@no_name4796Yeah seriously, it is SPEEDY!
I heard that jia tan became a kernel contributor for more big performance improvements
people complain when devs dont give short concise updates instead of just throwing out mounds of documentation , then people complain when they do and point out ambiguity as if the info should have been a 1 hour video that few would have watched to beyond half way.
The poor fellas appear to have tried and got out of there comfort zones , so I appreciate this even tho I probably wont adopt bun until new project just like I havnt adopted deno yet.
They probably should do both. One concise and one 1 hour vid for technical people.
I use bun for personal projects and it’s really good, I use it with sveltekit and I still to encounter issues
@@fieldtrip2178just release docs.
22:02 Given how many "Flip take that out" moments have infact, not been taken out over the past few days, it makes you question if Flip takes *_anything_* out?
Flip sleeps through Prime's videos it seems
Flip is a chad, don't let us lose this perfect moments
flip does takes some stuff out, which i'm guessing is because prime took him to the basement
$ is not Bash spawned in Bun, it's its own minimal semi-compatible Bash-like language that deals with the core of stuff we normally do in CD, and you can pipe stuff hither and dither into JS buffers. But it's NOT Bash, just a lexar and interpreter back into the Bun JS runtime (so any bug-fixes or improvements to Bun also applies to this process), so any tools that works checking JS code can check this. It's really good for offloading a lot of multi-OS scripting into a simpler platform. I use it for a lot of infrastructure stuff, I hate Bash / Ash cross-platform nonsense with a passion.
The cross platform bash compat is so Windows devs can cut and paste from any tutorial online and expect it to work.
many of the bun speed gains come from implementing things natively and comparing with JS based packages so they may be actually doing exactly the same thing, just more efficiently
bun videos give me the same vibe as Silicon Valley (the tv series)
Indeed. You bet these people share a startup house, and live a real life sitcom-life. At least, that's what I like to imagine.
the biggest win for Bun is the ability to run typescript directly without any issues or silly ESM/CommonJS issues.
I will never diss on optimizations in software used by many devs. A lot of this may seem inconsequential, but if you've ever worked with a compiler like tcc you'd know how good it feels to compile and run a large project in < 50ms
Entire problem sets disappear when you can just do the naive thing and have it be realtime
Compiling and running a large project in < 50ms is cool, but is it especially noteworthy that your 20 second build now finishes in 19.9 seconds?
@@Hwyadylaw a 50ms build is a 50ms build. where are those extra 20 seconds of yours coming from?
"You only do it like three times a day" 🤣🤣🤣
Maybe I’m just high, but I swear the second guy in the video looked like he was an animation and not a real person at first.
Definitely looked like AI
He tried so hard to make mimic apple wwdc videos that he seemed non human, ai like.
It's something with the voice over.
developer charisma
“The bun logo is his head” made me laugh the exact same way and at the exact same time as prime
The dev's might only do "Bun install" once, the CI/CD does it all the time, that 18X improvement will increase your actual velocity when working on large scale project with deployment pipelines.
22:20 classic "Flip take it out" 👌
Last version got me excited to try Bun, to migrate some of my stuff, but quickly found out it didn't run directly on Windows.
So this release made me migrate my website to Bun.
Unfortunately, I have to say I did not see an improvement in performance.
It was ~20% slower than node running "vite build" and "vite dev".
Long running functions ran ~20-30% slower.
Startup was slightly faster, and so was install, but I really don't care about the performance of my site when it's not even handling requests yet.
So I did a little search and found out it's just that JSC optimizes less (faster starts) but runs slightly slower afterwards compared to V8.
That said, I still plan on keeping Bun around for package management and the handy one liner to create an .exe from your JS/TS code.
This reminds me a little of the deceptive graphs of Rust statistics that Primeagen looked at a while back.
0:40 : (When will we drop Windows?)
As soon as none tech affine Project Managers / Company leaders stop thinking that Windows is essential for a "Successfull Company" to have. My Last two bosses had that mindset. Hurray for windows finally getting a usable shell scripting language, that does not require setting up an entire virtual machine.
5:50 : (Just try the command 😏)
The command runs fine. It is just a shame, that such a video came out on April 1st.
The only day of the year when people question if what they read on the Internet is true.
Some of it sounds clearly like BS though, especially some of the Performance stuff.
9:33: (Who uses the same scripts on Mac, Win. and Linux?)
That would be me. I'm forced to run Windows at work. I have to use MacOS for debugging PWAs on iPads. I Run Linux at home.
Having the same helperscrips just work everywhere sounds amazing.
Windows is the best desktop OS, it's not perfect, but takes next to no effort to get it to be B+ while sure, you can master your Linux install to get it to an A+ but at what cost?
that being said: if you have to develop directly on host RUN AWAY
we have WSL and full fledged VM's for a reason
also powershell is a better scripting language than bash, it saves you from so many string manipulations! but yeah, it's not great either, just slightly less broken
@@Z4KIUS but it's impossible to get windows to A+, that's the problem
I think he meant that "just putting stuff into your terminal" is a security nightmare
@@konstakuosmanen The thing is that it doesn't have to considering most people don't need it to
@@ZedDevStuff i dont care about most people, only myself
Windows Support - probably a big enabler for organisations that still do endpoint management with SCCM/Intune right?
Mac supports intune…
It also supports Linux apparently, but still I imagine that there is hesitance from internal IT teams
PowerShell is infinitely better than Bash, they should have made that the cross platform standard.
I can say word "bun" 27% faster then "node" which can save up to 3 seconds during the day. Huuuge performance boost
I'd say that a great place for bun scripts is the "npm scripts" used to centralize useful commands for devs
regarding that rm -rf business at around 6:10... Git for Windows distributes a copy of bash and a bunch of common userland tools... am I missing something, or is there a reason not to use them? You can get a surprisingly UNIX-esque terminal experience on Windows this way, even without reaching for WSL.
Don't forget MSYS and MinGW
tfw I have those utils from raylib devkit...@@Hwyadylaw
Nice 41
"Use anything other than bash", Perl support confirmed.
When you mock into the abyss the mock mocks at you
Lets just appreciate for a moment the cartoon characters that present the Bun! They look like AI decided to make a joke!😂
I would say it's fairly common to have teams of devs some on Windows and some on MacOS. I'm certainly in that type of group. We don't seem to need this tbh as some of the 'scripty' stuff we have done in powershell which runs fine on MacOS.
Having installs run fast in pipelines is a very attractive thing. Not just locally on your dev computer.
24:40 if I see more than 10 dependencies in something I import in any sane language, it's getting uninstalled.
Same. It's clearly the devs choice and not necessarily the language's fault. You can create a Go project with 100 deps or with just one (postgres driver, e.g. pgx). The same is true for Node. It has everything you need for the basic server except for the postgres driver (postgres.js has no additional deps). When Prime is talking about 100 deps for a web service, then it's not Node's fault but the fault of the sloppy devs who include every piece of crap from NPM. Rust is a different story, as the std lib is not as comprehensive as Go's or Node's. Listing all deps for a basic Axum and postgres backend is a bit disturbing.
BUN will not be able to compete with anything
29:37 - One of the best takes Prime has ever had. It is valid for other languages too, but especially if you only do JS/TS.
prime: flip, take it out, flip, take it out!
flip: yeah, right
@14:18
I used to wait 182 seconds for my react project to cold start when I was using webpack (260K LOC) w/TypeScript.
That and the fact that I had barrelled all the exports within Create-React-App because there was no path aliases made it a nightmare.
I saw glory when I migrated it out to Vite. Cold Start - 28seconds. Cached, it would boot up in 4 - 5 seconds.
It was important when you messed up with tsc and it had to restart to pickup the changes.
19:00 just because different languages compile to an intermediate language, doesn’t necessarily mean the resulting output is comparable in terms of performance. The resulting intermediate code will be different for each language and will be compiled into actual bytecode. And it’s obviously not guaranteed that that last step will always result in identical performing bytecode, given different inputs.
Jared at 22:00 looks like one of the three green heads in the Yubaba's room in Spirited Away.
9:42 Well you do work primarily at Netflix, so are going to be using primarily web-server technologies. Most web-servers are linux only. If you work in desktop applications, this is way more common.
10:24 Yes. Cross-platform desktop applications are a maintenance nightmare. But stuff like this is a step towards making it less of a maintenance nightmare imo.
The video was released on 1st April
how do you react 30min on a 5min video
Flip you the bro!🤘
What's going on with prime, this video was pure negativity, he was just looking for reasons to hate
Linux Subsystem for Windows: *exists*
Bun < 1.1: *exists*
Dev: We have very cool features planned in free near future.
[not even a couple seconds later]
Users: When will you make it run on Windows
Dev: *pauses all planned features and works on windows support*
@29:00 you don't need to build trust, you need to build VC moneyz!
29:37 I had largely written js/ts with a little bit of py for scripting, but I recently started going cs50x and actually like programming in c (except for the lack of .length)
There is one things between language. They can be more expressive on type and memory access pattern that are reflected in the intermediate language. So even if all language end up using LLVM, they can have different performance outcome. A very excessive example in that regard would be to compare ISPC vs C++ both using LLVM. As ISPC express data parallelism, LLVM can generate SIMD code by default and so the code generated when using ISPC will be faster than a C++ code that just use C++. Same things happen with rust, as it express more information memory access and ownership, the generated IR has more information and LLVM can generate better binary at the end. My understanding is that zig is also better than C++ at expressing this memory ownership and data parallelism problem, so even with a LLVM backend, zig could be better than C++.
I love bash when I use it, because it saves me time I don't do complex bash scripts
28:50 That's why I have two articles explaining why Penna is faster than the other SLF4J backends...
"An irony" is a new knowledge for me. Anyway, back to writing a monumentous code...
500ms difference in install time is the difference between having a backdoor or not.
So much neg energy in this one, Prime. Don’t be mad. Get glad!
4:00 You can also skip frame-by-frame with , and . :)
Bun is fantastic, great update video!
Our company (a consultancy) allows you to use Windows or Macs, so we need cross OS support all the time for things.
I'm a cross-platform developer. My main driver is Windows, my laptop is Linux. Zero interest in ever touching Apple though. Having the lightweight OS on the wesker machine is nice, and making my code work on both is an interesting challenge.
I know some open source contributors that think that bash is great
I remember going though benchmarks between the Sun's JVM and IBM 'sJVM this was decades ago. . IBM's was faster, often twice as fast, but it also failed spectacularly on some of the benchmarks. So yea IBM/s was faster because it didn't do the same level of safety checking that Sun's implementation was doing.
"Bun logo is his head" is priceless. It was the first thing I thought when I've seen that vid (and he has that logo on his t-shirt!)
Crossplatform devs. Well here! My home machine runs Windows cause I wanna do some proper gaming. So far a WFH I won't dual boot. So Home windows and work Ubuntu. Not to forget that some devs in our company work on Mac, most on windows and a few on Linux.
JavaScript in bash seems like an inevitable step. By this time I wouldn't be surprised if JS was made to run on Twinkies. But i feel reminded a lot of Jeff Goldblum in Jurassic Park....
Why do we need yet more JavaScript stuff in the world 😢
Bun is in that weird place of performance where it isn't exactly great at edge as it still starts up pretty slowly when compared to edge solutions but once it does it runs so much faster... there's probably a right use for that, but I wouldn't put it on rarely run on demand environments just yet
are the actors AI rendered versions of their younger selves?
500 dependencies... I wrote a fullstack go app with templates for frontend. It has only one dependency, the pgx postgres driver. There's no native postgres driver, so I had to.
I'm with you. Pretending that Windows is UNIX always ends badly. Building bash into Javascript seems like a further recipe for disaster :)
4:10 boomer Prime trying to ninja pause when he can press comma/period to move forward/backward one frame
Windows developers aren't even using windows any more, they're using WSL2
You mean fake linux? 😂
If there's a mock'in, don't come knock'in
"The bun logo is his head"
bun is going to be a new test runner and package manager for node
BUN IN BIO
Bio in your buns?
5:48 “just put it in bro” 😂
The thing that makes me not be able to use bun as a node drop-in replacement is that they don't support node-gyp dependency building and they don't automatically insert their bun-specific dependency in imports. *specific actual example*, I have a wrapper around better-sqlite3 with 5+ million views. This wrapper cannot be used in bun because better-sqlite3 isn't buildable in bun, and I'd have to make a branch/more code/environment checker, to change the *import* I'm using in order for my module to be useable in bun.
Just to save 30 nanoseconds to run tsc --help, I guess?
If you're running bun install in your pipeline I can see that making a huge difference.
There is nice progress there, maybe I try Bun once they get to 1.5 release and are still relevant and Node hasnt began to fix their issues.
what's up with the people in their video? i feel like they're incomplete or ai generate 💀💀💀
Uhm.... they usually don't get out much?
UGH all this Windows! Puke!
Tried bun a couple of times (last time a few weeks ago). It’s a buggy mess. Got sick of tracking down errors Went back to pnpm
The bash in JS is cursed for sure. But I love it
Once is a mistake, twice is a pattern, three times is enemy action
If, as a developer, you are installing node_modules 3 times a day, there is something massively wrong with what you are doing or what you are working on. In enterprise, on any existing web application, you are installing node_modules (via npm, yarn, whatever...) once. Maybe a second time SIX MONTHS later. What is wrong with all of you people?! The only thing that this matters for is operationalization. Building environments on the fly. Which, yes, you should have all your dependencies cached and the build server reaches into the cache (which is ideally on the same server) to pull those. This is why `npm ci` exists. Use the package-lock, pull those dependencies from cache, install them. Should be fast. Needs to be as fast as possible, especially if you're building ephemeral environments for test teams constantly.
Let windows me windows is the best advice I’ve heard in a long time. For once let them implement their own solutions like other operating systems.
i will never get over the way prime says qwerty 😂
reminds me of when people use boot times as a performance parameter as if i restart my computer more than twice a month
Mocking is not "tsting your feelings". Mocking allows you to test against the agreed upon design contract. I mean, I know that Primeagen trolls all the way, but people do pay attention to what he says. So once again, good mocking is an excellent addition to a testing suite: implement standard (as pre-determined by the agreed design documentation) expectations in mocks and then test to your heart's content.
I personally am not a fan of mocking, I do use it sometimes but prefer fakes at the service boundaries where possible. Code bases where I have seen extensive use of mocks have had very brittle tests that make refactoring difficult and do not give a high level of confidence that the system as a whole is working.
Maybe this is just an issue with overuse of mocks though. Like I mentioned personally I use mocks sometimes but try to do it as little as possible.
You should checkout reports on actual projects replacing node with bun. If you can speed things up that had been slow enough to notice before by just drop-in bun, I would not complain.
I've been waiting for this video.
Bun is a good example of a product that is over funded. They're solving problems nobody have.
9:40 Letting devs choose which platform they prefer is not a bad thing. Many companies let you choose between mac or pc when you join and it means those devs will run into cross platform issues. I mean, this is less than ideal, but I think it is a great addition to be able to support both platforms at once.
Also, you may have .NET developers make the jump into other technologies or just be temporarily assigned to another project. It would make no sense to order a 3.5k$ Mac for such a short amount of time.
Linux computers are also very hard to manage at scale for enterprise companies with very rigorous security policies, hence the Windows computers. You may call skill issues here, but this is the reality and most of the IT workforce out there is mostly used to manage Windows computers with a mix of Mac. 🤷♂️
definitely qwerty. My right hand is basically always on 'pok' when i randomly input characters.
Feel so enterprisey.
if I have to move from Node ecosystem, I would switch to Go for performance rather than use Bun or Winter JS
Node has a test runner btw
Was it really such a necessary feature to use shell scripts on windows? Must have been a lot of work translating each bash command to a windows counterpart. And there will always be some small differences, like different versions of bash, which have different arguments for commands.
All that work when there is already a decent solution - wsl lol
With this pace, Bun 2.0 will be standalone OS ;)
It's like motorizing a trash bin, yes, it carries trash faster, but do you need it?
Downloaded on windows, tried running my discord bot that used to be run with bun in WSL, instant segfault 😂 tried running it again, the third time it suddenly worked... Since then it runs around 50% of the time
Memes are fun until they are affecting the quality of the video. I would have appreciated an actual review. You're better than this Prime I believe in you 💪💪
My game development pipeline will be unironically using bun. It's for web-based games so make sense huh.
"You reinstall node_modules 3x a day" 😂😂😂
18:00 Here I am "well actually"ing the primagen: *Technically* Rust, Zig, C++ and C all have a runtime. Albeit a small one, they still have one.
I don't disagree but how do you define runtime?
@@JannisAdmekI don't have a good *complete* definition, but things like Rusts panic unwinding, or C++'s exceptions definitely are runtime things.
Also I think that C might set up some default signal handler. Also C's default IO-buffering might count under runtime.
(Also there is something like "life before main".)
I don't understand why support native Windows when you could run this in WSL? I'm currently using Fedora via WSL for my day job because corporate policy forces me to be on Windows. I admit it's no pure Linux but it's usable IMO.