'Compile and Run C in JavaScript', Promises Bun (thenewstack.io)
- Reference: 0175101201
- News link: https://developers.slashdot.org/story/24/09/22/011240/compile-and-run-c-in-javascript-promises-bun
- Source link: https://thenewstack.io/node-removes-corepack-bun-runs-native-c-from-javascript/
And Bun 1.1.28 now includes experimental support for [1]">compiling and running native C from JavaScript , according to [2]this report from The New Stack :
> "From compression to cryptography to networking to the web browser you're reading this on, the world runs on C," wrote Jarred Sumner, creator of Bun. "If it's not written in C, it speaks the C ABI (C++, Rust, Zig, etc.) and is available as a C library. C and the C ABI are the past, present, and future of systems programming." This is a low-boilerplate way to use C libraries and system libraries from JavaScript, he said, adding that this feature allows the same project that runs JavaScript to also run C without a separate build step... "It's good for glue code that binds C or C-like libraries to JavaScript. Sometimes, you want to use a C library or system API from JavaScript, and that library was never meant to be used from JavaScript," Sumner added.
>
> It's currently possible to achieve this by compiling to WebAssembly or writing a N-API (napi) addon or V8 C++ API library addon, the team explained. But both are suboptimal... WebAssembly can do this but its isolated memory model comes with serious tradeoffs, the team wrote, including an inability to make system calls and a requirement to clone everything. "Modern processors support about 280 TB of addressable memory (48 bits). WebAssembly is 32-bit and can only access its own memory," Sumner wrote. "That means by default, passing strings and binary data JavaScript WebAssembly must clone every time. For many projects, this negates any performance gain from leveraging WebAssembly."
>
> The [3]latest version of Bun , released Friday, builds on this by adding N-API (nap) support to cc [Bun's [4]C compiler , which uses TinyCC to compile the C code]. "This makes it easier to return JavaScript strings, objects, arrays and other non-primitive values from C code," wrote Sumner. "You can continue to use types like int, float, double to send & receive primitive values from C code, but now you can also use N-API types! Also, this works when using dlopen to load shared libraries with bun:ffi (such as [5]Rust or C++ libraries with C ABI exports)....
>
> "TinyCC compiles to decently performant C, but it won't do advanced optimizations that Clang or GCC does like autovectorization or very specialized CPU instructions," Sumner wrote. "You probably won't get much of a performance gain from micro-optimizing small parts of your codebase through C, but happy to be proven wrong!"
[1] https://slashdot.org/ahref=
[2] https://thenewstack.io/node-removes-corepack-bun-runs-native-c-from-javascript/
[3] https://bun.sh/blog/bun-v1.1.29
[4] https://bun.sh/docs/api/cc
[5] https://thenewstack.io/meet-val-a-new-language-alternative-to-c-rust/
insanity (Score:4, Insightful)
Webassembly with js as the glue is the way to go. All this cross compiling is insanity. JS shouldn't be making anything huge and certainly should not be treated like it is a virtual machine.
Re: (Score:2)
This is really how javascript devs think. Once your "stack" is 8 deep and you're still targetting only one language and only work in one browser, one begins to wonder.
Re: insanity (Score:2)
Webassembly is java like bytecode in a fancy dress. I really dont get the fuss. Craplets failed first time around, they'll fail 2nd time too.
Re: (Score:2)
> Webassembly is java like bytecode in a fancy dress. I really dont get the fuss. Craplets failed first time around, they'll fail 2nd time too.
Webassembly is just pre-parsed javascript.
And there are plenty of C compilers to Webassembly. Because there are plenty of C programs running under Webassembly already.
Many of them you already know. Like DOSBox, MAME and a few others are already running great on Webassembly, as demonstrated by the Internet Archive's playable DOS, console and arcade games that just run o
Yavascript (Score:3)
This is straight out of [1]"The Birth and Death of Yavascript" [destroyallsoftware.com]
[1] https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript
Or... (Score:2)
....just build C apps without JavaScript, and skip the gigs of memory and hundreds of megs of space required, not to mention the CPU overhead, and limitations of the "app platform" of the browser.
Y'know, this is how the world got so fucked. People compromising, doing the easy thing that they knew was wasteful, because they were too comfortable and lazy to do the hard thing that was right. This is why technology is so shitty now, and products have so many bugs.
If you told me 20 years ago that every new appli
Re: (Score:2)
The upside of everyone layering things 13 levels deep is that it's easy to look like a genius, simply by solving the underlying problem directly rather than going through 13 levels of "convenience layering". Look guys, a 1,000,000% speedup in 200 lines of C code! Amazing!
Re: Or... (Score:2)
This is what you get when every 2nd rate code monkey who learnt some HTML in college thinks they're a software engineer.
But Why The Fuck (Score:3)
Would you want to do this? *Why* do you want to run C from JS? Surely at that point you already fucked up big time. JS is a shitty language designed to render UI in a browser. If you need to do system level stuff then you need to either write a server with services end points your browser hits, or an actual desktop application with its own UI.
Re: But Why The Fuck (Score:1)
You don't need to run a new client and/or server every time an end user wants to *do_something(*wtf) which is a little funny to since I feel like that is exactly what javascript is for.....
Re: (Score:2)
Bun is a Node.js/Deno alternative. I.e. it's made to run JavaScript code *on the server*.
Re: (Score:2)
You probably have legacy c code that you don't feel like rewriting/debugging and you want to run it server-side but with sandboxing and some support code not in c.
Re: (Score:2)
> You probably have legacy c code that you don't feel like rewriting/debugging and you want to run it server-side but with sandboxing and some support code not in c.
So what you are basically saying is "This invention allows truly pathetically lazy programmers to become EVEN MORE SLACK."
Methinks this invention was truly created by a devout devotee of J.R. "Bob" Dobbs
The new ActiveX/Applet/Plugin (Score:2)
Except the embedding layer is integrated into the browser through endless translation layers. We are already at this point where we can run translated executables in the browser, and even whole operating systems in browser vms, the madness will continue.
Oh good (Score:2)
Now I can run one shitty language inside another, even shittier, language for absolutely no upsides.
Re: (Score:2)
Well, other than being able to leverage the vast (and I mean vast) amount of existing C code. And the fact that most other important languages already have C interop, and...
Hey, remember Flash? (Score:1)
Hey, remember Flash?
Raw, inscrutable, hexadecimal. Indirectly. (Score:2)
When are they gonna be able to run 6502 assembly inside javascript, on top of bun, inside a docker container, in a vm.
Re: (Score:2)
Already done. You can run Apple II software in your browser on archive.org right now.
He is right that C is the real thing (Score:2)
Sure, too many wannabees cannot handle it and mess up when they touch it. But the very fact of the Linux kernel shows that C is not a problem, but an asset. Sure, there are some areas, like drivers, are where code by less capable people comes in and here Rust could help (as far as you can write drivers without going "unsafe"), but the core? It could realistically not be written in anything but C.
The search for a better systems programming language is as old as the need for systems programming languages. Not
Re: (Score:2)
Yep. At the end of the day, Microsoft is still shipping compiled C/C++ code. Apple is still shipping compiled C/Objective-C code (they're *trying* to switch everything to Swift, but they're still a long, long way from that, 10 years later). As you note, the Linux kernel is still C code. Just about every embedded device on the planet is running compiled C code.
To a first approximation, everything that isn't running C is running JavaScript (which is, of course, generally implemented in compiled C code).
I'm
For some reason (Score:3)
All these shenanigans attempting to run one language inside or along with another reminds me of [1]the English language [imgur.com].
[1] https://i.imgur.com/FyqJZiO.mp4