[mytydev]

We should also talk about why this is the case. JavascriptCore. The reason Bun is so fast is mostly due to the fact that it is using Apple's JavascriptCore and what all of the benchmark comparisons are really doing are comparing Google's V8 engine to Apple's JavascriptCore engine.

So basically, there will never be Windows support until JavascriptCore is able to be used on Windows and I'm not entirely sure on the state of that. My guess is that it has limited to no support for that scenario.

[Hamcha]

Zig, the programming language Bun is written on, is currently having some Windows headaches of its own: https://github.com/ziglang/zig/issues/12420

I wonder how much of Bun's immaturity is due to Zig's own immaturity.

[dimgl]

Why not point the finger at Windows? Development on Windows is archaic.

[_gabe_]

> Why not point the finger at Windows? Development on Windows is archaic.

How so? Zig is a programming language, so I'm guessing the main interactions it needs with the OS are file IO. It shouldn't need to do any GUI work as long as it provides proper bindings to the C functions. And file IO is essentially cross platform in C++ as long as you use the stdlib. Threads are also essentially multiplatform if you're using the stdlib. I also don't know if Zig is written in C, C++, or Zig so it may differ.

Generating binaries is different, but I wouldn't consider windows binaries any more archaic than Mac or Linux binaries, and I'm not sure if zig already uses LLVM backend or something anyways.

But given all that, writing basic Win32 code to do file IO or any sort of OS level interactions isn't any less archaic than what I've had to do in Linux. It's an API, and it's got a lot of cruft built up over the years, but so does any sort of Linux OS API.

Here's the Linux API for creating a file[0] and here's windows[1]. There's more parameters for the Win32 version, but the documentation is solid and gives a lot of tangential information. I actually prefer the Win32 docs to a lot of the Linux docs that I've used because they describe all the details very explicitly. So I wouldn't call Windows any more archaic then any other OS.

Basically what I'm saying is, it takes like 2-3 hours at most to add Windows support to a programming language unless you've architected your code in a way that tangles OS operations with regular operations. It's really not that hard to keep OS code separate from the apps logic to make porting the app to different operating systems trivial.

[0]: https://linux.die.net/man/3/creat

[1]: https://docs.microsoft.com/en-us/windows/win32/api/fileapi/n...

[ripley12]

I was with you until "it takes like 2-3 hours at most to add Windows support to a programming language..."

C'mon.

[_gabe_]

This is all that it took me to port a fairly sizeable code base to Linux[0]. This commit allowed me to run the app with the only problem being some font issues that I needed to fix by modifying how I used a library.

The total:

> Showing 26 changed files with 255 additions and 90 deletions.

If you architect your code well, porting between different systems shouldn't take anymore than a few hours ;)

Edit: I just looked through the diff and remembered that the bulk of these changes was fixing warnings that surfaced from using a different compiler.

The actual code that I changed necessary to get this running on Linux was in File.cpp and consisted of 124 lines of code. Going the other way (from Linux to windows) would have been just as simple, I just would have added the code in the __WIN32__ macro block instead of the code in the __linux__ macro block.

[0]: https://github.com/codingminecraft/StreamMinecraftClone/comm...

[ripley12]

A small game is not even remotely comparable to an average programming language.

[mwcampbell]

Windows isn't archaic; it's just not Unix. So blame the Unix monoculture.

[wffurr]

You can use JavaScriptCore on Windows right now: https://github.com/Lichtso/JSC-Standalone