I'm curious to hear your thoughts about Bun/Civet integration to explore improvements to the language frontend as well as the language backend?
I've worked with hundreds of scientists from different domains over the past two decades and I've literally never once heard of wanting to use Javascript for anything remotely scientific.
Furthermore, given that WebAssembly seems poised to (eventually) make strides in how browser-oriented applications are built then the logical conclusion is a sort of reduce function on languages where you choose the language that's the most pleasant to write and maintain since you will eventually be able to just target the browser from anything. For the life of me, I can't see a future where large, STEM-educated groups and agencies decide "Well yeah, I guess if we can use this cooked-in-a-weekend piece of $^&# then why would we ever use Python?"
I think a lot of language enthusiasts see python projects entering into spaces where it wasn't previously viable and think that the same principle applies to their language, which misses something fundamental about why Python has so deeply entrenched itself into the STEM/ML world, and why it will NEVER be uprooted. When I see things like Brython/Pyscript/Pyodide, it's obvious to me that people would rather write Python for ~accomplishing the task they set out to~ than have to muck around with another language entirely. Python is a winner in so many spaces because of that element of taking the programmer from Point A to Point B the easiest way. It's a language designed for accomplishing tasks, for getting stuff done, for being understood at a glance. Javascript was made up by one guy, in a very short period of time, for a singular purpose that it didn't even do well when it was introduced and has stuck around due to sheer coincidence and convenience. All languages on a long enough timescale converge to a point of usefulness but if we're pitting Python against JS I just can't see the scales tipping enough to warrant choosing it for real work.
Instead of using a wasm runtime for python for that it might also make more sense performance-wise to at least write that part in js if not an even faster language compiled to wasm. Either way if it ends up on a webpage some js will be needed to at least glue things together.
Also, from the perspective of just wanting to write some code and get what I want, I really don't see much of a difference between python and js.
For the rest of us, it's kinda the other way around. We can't figure out why scientists prefer python over all the other many options. I'm assuming it's just a lot of cobbled together legacy code nobody wants to breathe on.
JavaScript was never really known for admin or file manipulation (Perl replacement), so that was what probably established the dominant ecosystem for Python. I also don't think the runtime overhead is applicable due to native C/C++ part, and download time doesn't have to be bad since modules can be split just like in JavaScript ecosystem today. For an AI app, the model inference weights might be larger than the compiled WASM code itself. However, I'd agree with you that porting legacy apps might not be possible without something close to a rewrite.
There is a reasonable chance that once WASM GC is implemented, then direct DOM access will be provided [1], which I believe could pretty much halt interest in new JavaScript development for web frameworks overnight. WASM is the reincarnation of the Java Applet, but better. And a more typed language like Go or Dart could become the most widely used programming language. Either compile it to WASM as plugin for something like the browser, compile to JavaScript for "legacy browsers", or to native code for a standalone app. There are probably a handful of developers already assuming this and trying to write a version of React running in WASM already.
[1] https://github.com/WebAssembly/design/blob/main/Web.md#gc
I’ve got honestly no idea how long it took to write the first ‘version’ of the Python interpreter or whatever. It’s not as much a piece of tech lore that was later (mis)appropriated for Internet arguments. Even after acknowledging that JS being a browser-based language causes let’s say ‘less well-considered’ language quirks to hang around for longer than we’d like, I’d never use that as such a central argument.
To be clear: in my day job I predominantly write Python. It’s a web project, which I have control over the architecture of, and it’s for the most part oldschool server-side rendered Django views, in no small part because JavaScript scares me. I am FAR from a fanboy. Having recently spent a solid month writing TypeScript - which for contexts like this should be considered ‘JavaScript’ - it’s (way too late) become clear to me that it’s a language worthy of respect and consideration.
If we want to get into the comparative qualities of JS you dislike, well, I still don’t think I’d be interested in a language wars back and forth. However at least we’d be getting closer to a productive conversation. And, to be clear, I’m not jumping to take up arms arguing that JavaScript is as suitable for ML/scientific computing as Python is. Even if we pretend that e.g. pandas and numpy were available for JS, I’m still not confident that JS is up to the task, but I also don’t feel confident arguing against it either.
What I will say is that, coming back to writing Python after being deep in JS for just a little while, there are JS language features that I felt myself missing. Just like there are Python language features I felt myself missing in JS. My point is, again, that modern JS is in my eyes within the realm of respectable general purpose language, ESPECIALLY with TS.
I relate to this a lot. If I've been doing Python a lot, JS can feel clunky. If I've been doing JS/TS a lot, Python feels clunky. I think TS tips the scales here for me though
The only language that I really feel is actually really elegant and readable and lives up to the "get stuff done" mantra in a way that goes beyond "this is what I know already" is Ruby
The thing is a lot of scientists are going to have to learn FE technologies eventually. The push to make scientific work more presentable and accessible means JS' place in academia is cemented for a long time.
WebAssembly is still a long way off and given that even Rust WASM was found to usually do worse than JS, I highly doubt Python WASM will outperform it any time soon. Even once it does become worth it, tooling has a long ways to go
> people would rather write Python for ~accomplishing the task they set out to~ than have to muck around with another language entirely.
your argument seems to boil down to: people know Python so they wanna use Python. People can just as easily know JS/TS. If I'm a botanist and I really don't wanna invest too much of my time in learning languages I can choose between Python, the language with all the scientific libraries, and JavaScript, the language of the web. If I choose the former, I'll likely have to bother someone to help me present my work to the web anyways. If in the near future JS also reaches good support for scientific/ml libraries it seems like entering that ecosystem is an obvious advantage. I get to learn the web and access scientific libraries at the same time
Also I don't really find Python all that legible. The language you're describing isn't Python nor JavaScript. It's something like Ruby. Modern javascript has some obvious advantages when it comes to syntactic sugar like arrow functions. It's also easier to teach because you don't need to install anything. Just open up your html file in any browser
Fully agree with this sentiment. To that end, I’ve been contributing to Shumai (linked by someone else in the comments) to enable torch-like machine learning for Bun
In the same way that Python developers are interested in extending their ecosystem to other spaces, JavaScript developers are interested in growing into the data science space. But that doesn't happen unless there's a clear benefit for switching.
What advantages do a native JS solution have over Python? Performance: There are arguably many more developers and companies focused on pure JS performance than python. Community: A JS solution opens up a much larger pool of talent to build innovative solutions. Cost: Running heavy computations client-side, in the web browser, reduces costs for service providers.
PS: We're hiring for this and other related problems https://sheetjs.com/careers
Let's say you want to a small notebook in the browser, JavaScript is nicer there, even with WebAssembly. Or the user is not a scientist, and already knows JS, and it lets them discover ML. It's not taking anything away from those Python projects.
A scientist that doesn't want to give whoever is responsible for deploying their software a massive headache and ops problems.
One who has a reason to?
All languages have their strengths and weaknesses. Popular languages have a positive balance. JS is great for the web, and there's surely >0 applications in science that require web interoperability...
The statement "mucking around with learning another language entirely", comes across as someone who hasn't experienced other languages to the point they see they often have more similarities than differences, become easier and easier to learn as a result, and are best used - at that point - like a box of tools, rather than the situation most programmers start with of using a screwdriver for everything because it's all they have.
This is where more than a few scientists seem to have got stuck with Python, and possibly part of why the language itself has accelerated into becoming a bit of a mess - though they often do, anyway. (So much for that "just getting from A to B" thing, I hope it sticks around, but it's not looking good.)
While many might not presently be in a position to, any scientist who could choose to use something more readily suited to a particular use-case, such as JS, or C, or Perl/Ruby, or Elixir (particularly with regard to ML lately), may find themselves reaching higher heights than they could have when limited to only Python.
As with anything, those with more options have an edge over those with fewer.
I can see the validity of such an argument for languages like R or Matlab or Julia (EDIT: or Fortran), wherein the languages were designed with scientific use cases in mind. Python is not in that category; it's rather in the category of Perl (EDIT: and not Fortran): languages that happened to be useful to scientists by happenstance, and around which a library ecosystem developed in support of that usefulness. No fundamental reason why Javascript would somehow be ineligible if Python is eligible.
I can also see that your comment fails to address the meat of mine, despite being a reply to it.
Python is extremely easy to get tasks done with, there's a minimal amount of ceremony and PLT background knowledge needed to program it. I love Perl, but explaining how $ and @ work differently given the point of usage is annoying, and if I taught Perl all day every day, it'd be a continuous annoyance.
I don't have the studies and data to back up my opinion, but a lifetime of work has taught me the certainty that Python is one of the greatest languages ever created, that quite literally ANYBODY who can type and read English can learn to become effective with it, and that it blows every competitor out of the water by a large margin with regards to getting from Point A to Point B as a novice programmer. As more of the world becomes programmers, that facet alone cements Python's continued success and its place in PLT history. It's the human part of the language, not the object system or type theory or compiler internals or any of the esoteric technical bits. Nobody can teach someone to program in anything other than Python quicker than I could teach them to program in Python.
But anyhow, this is well below my time to spend in a discussion like this. I mean this in the nicest way possible: I've probably spent more time teaching and training people who weren't programmers to write good programs then you've spent programming throughout your life. People who work in the White House, DARPA, the FDA, DOT, IRS, you name it. I know I can't PROVE my position, but time will. Python will always win eventually.
Most of the data scientists I've worked with are programmer hobbyists as well. We've used Javascript/Python/Go/R. Maybe this will exist for people in that demographic, those who are data scientists that already are solid in programming.
Regardless, more cool toys are good.
Surely you know the saying about what happens when you ass-u-me.
But hey, if that's the tone you'd like to set, then I'm happy to oblige...
> I can also see that your comment fails to address the meat of mine
There was no meat to yours. "Python is good for scientific uses because reasons and JS is not because reasons; also, here are some cheap shots at JS being a weekend project despite there having been literal decades of work since Brendan Eich invented it". That's the sort of drivel I'd expect from novices using tribalism as a substitute for an informed opinion, not someone who claims to have sufficient expertise in programming to competently educate someone else.
> I love Perl, but explaining how $ and @ work differently given the point of usage is annoying, and if I taught Perl all day every day, it'd be a continuous annoyance.
Explaining to beginners why their programs break if they don't get indentation perfectly right strikes me as no less of a continuous annoyance.
On that note, Ruby lacks either of those issues. Same with Lua. Same with Javascript.
> ANYBODY who can type and read English can learn to become effective with it
That's true of pretty much every scripting language out there; that's indeed what usually sets scripting languages apart from systems languages.
> it blows every competitor out of the water by a large margin with regards to getting from Point A to Point B as a novice programmer
Not every competitor. It's one of a category of languages which novices in significant numbers successfully learn reasonably quickly - and significant numbers of novices do become successful with Ruby or Lua or - yes - JS just as quickly as novices do with Python.
> I mean this in the nicest way possible: I've probably spent more time teaching and training people who weren't programmers to write good programs then you've spent programming throughout your life.
I mean this in the nicest way possible: if your comments here are representative of your teaching and training of others, then you owe your students refunds and apologies. I would hope that you don't teach your students blatant misinformation like JS being merely a weekend project (as if Python wasn't?) or fanboyishly insist that "Python will always win eventually" as if programming is all about winners and losers rather than using the right tool for the job. If you do teach your students such, then they are worse off for it, and deserve someone who actually educates rather than misinforms.
If you're as good a teacher as you claim to be, then the language doesn't matter; the differences between the various scripting languages out there are minute in comparison to the fundamental concepts like "how do I write and call functions?" or "how do I store data and use it later?".
Likewise, to your average non-programmer, the language doesn't matter. What matters is the path of least resistance between "I need to do this thing" and "I have done this thing". Sometimes that's Python. Sometimes that's JS. Hell, sometimes that's something totally bonkers like Haskell. Python is one of several paths of least resistance for scientists in particular not because of anything to do with the language itself, but rather because of a library and tooling ecosystem that formed around it by happenstance; no reason why that couldn't happen for JS, or any other scripting language.
This literally happened to me the other month. I had a tiny problem which I realised was a perfect fit for the List monad. Guess which language has the best support for that?
I rewrote my little script in JS afterwards using flatMap, and it was much uglier.
From https://en.wikipedia.org/wiki/Fortran : "Fortran was originally developed by IBM in the 1950s for scientific and engineering applications"
JavaScript is turning complete and I prefer it’s semantics to the lawless land of Perl, but it ultimately does not serve its users as a general purpose programming language for getting things done - it serves the web foremost, and as a distant second there’s specialized programming environments like Node and Bun with priorities like “asynchronous” that struggle with POSIX/system scripting basics like fork(2), execve(2), working with files in simple ways. Don’t even get me started on FFI/calling into dynamic libraries, which is the bread and butter of scientific computing. FFI is in the stdlib in Ruby; but requires writing or compiling C++ for Node, or a monstrous stack of compilers for the web.
JavaScript is interesting because there are so many healthy alternative runtimes, but when it comes to getting things done with data, both Python and Ruby are much more straightforward and prioritize developer happiness & utility, instead of standardized web compatibility.
Which is, incidentally, one of the things Bun provides.
Like you said: there are indeed healthy alternative runtimes. Said runtimes can (and often do) readily provide a richer standard library, or break web compatibility to resolve footguns, or what have you. Bun seems to be making good progress to that effect, and my point in the previous comment presupposes that it succeeds.
But the scientific strength of "Python" comes not from Python itself. It just offers a nice interface to tons of C, C++, and Fortran code that implement the core of numpy, pandas, keras, pytorch, etc. That's what STEM and ML crowds use. Moving that code to WASM must be possible, but likely for demo purposes, not for serious work.
And thanks for bun! It's been impressive and inspiring to watch.
For now you can do
bunx bun-replI mean, I wish bun all the best, but trying to wrap my head around - who the heck and on what basis gave to bun project a money :-)
- zig.news has some good posts https://zig.news/
- Zig's language docs: https://ziglang.org/documentation/master/
- Zig's standard library code https://github.com/ziglang/zig/
If you're familiar with Node, Bun should feel familiar except you don't need as much tooling to use it.
Things like TypeScript, jsx, loading .env files, Jest-like test runner etc just work. You can use the builtin TypeScript/JS LSP in your text editor instead of installing a separate extension. You can import packages from npm without the "npm:" specifier. It's worth mentioning that Bun doesn't support HTTPS imports yet, so you'll need to use npm - but bun has a very fast builtin npm client. Like deno, you can often skip running `bun install` or `npm install` entirely for bun because bun will automatically install dependencies from npm when there is no node_modules folder
Tracking issue: https://github.com/oven-sh/bun/issues/1822
1) using JavaScriptCore instead of V8
2) porting esbuild from Go to Zig
I have a couple of questions about (2):
1. How long did it take you to port esbuild?
2. Why did you choose to port esbuild to Zig instead of another language e.g. V?
He chose Zig because it's a good language for performance sensitive applications and found himself to be very productive in it.
Different strokes for different folks
Some people really enjoy working. I know, it's hard to believe :)
How are you funded? Is speed enough of a concern to take a risk on using this vs Node ? From my experience with Node your lucky if it works at all, I don't know if I'd like to add another variable when things go wrong.
I can't imagine this supporting every single npm module.
That said, god speed. If you can really make JavaScript fast as a complied language, I and many other JS devs will be happy.
Missing some of the other general purpose use cases/servers that devs would want to build - which wouldn't fit into bun's flavor of hosting.
Getting early funding is cool , but I'm not sold on the business model. Tons of hosting providers exist, corps are unlikely to switch meaning your stuck selling to hobbyist / small developers.
That said, they just need to stay alive until aquired
Another thing is that he intends for Bun to be a drop-in replacement. Why •wouldn't* you switch hosting providers for a free massive boost in performance?
So I'm going to convince upper management to let me host our apps in a new unknown hosting provider vs the AWS contract we already likely have ? Maybe if your a CTO at a startup you could pitch this, but for the most part I'd imagine people will end up using Bun on existing hosts like AWS and Azure.
Nothing stops AWS from implementing whatever makes Bun hosting faster on their own platform. Don't get me wrong, I REALLY love Bun as an idea. I'm just not sure it'll make money.
I feel like compatibility-wise both projects are mostly there already
Why is Bun fast?
... Zig's low-level control over memory and lack of hidden control flow makes it much simpler to write fast software. ...
Is there something about C++ that makes it less well-suited than Zig for what Bun does?
Or is the problem with Node.js that it relies too much on JavaScript rather than C++ in hot paths?[2]
[1] https://bun.sh/
https://medium.com/deno-the-complete-reference/node-js-vs-de...
1) That benchmark appears to be bottlenecked by the HTTP client — that’s why the numbers are so close for each runtime. Effectively, it is benchmarking the http client and not the http server.
The benchmarking tool has to be at least as fast the server and it needs to support HTTP keep alive. That means popular Node.js-based benchmarking tools like autocannon don’t produce useful results in benchmarks like these
Instead, a tool like oha or wrk or bombardier is better
2) That benchmark is not using the ReactDOM server build for Bun's runtime, which is used in Bun's benchmark and is part of the next release of react-dom.
PR: https://github.com/facebook/react/pull/25597#issuecomment-13...
Source of Bun's homepage benchmark: https://github.com/oven-sh/bun/blob/9ef33312b1b199931c29c182...