Not a question, mostly a comment. Excited to see the crypto speed improvements. Makes me hopeful about projects like scikit.js[0] toppling Python's ML dominance
What scientist is going to want to write JS when they can choose Python?
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.
Not JS, but I much prefer TS over Python. I've used all 3 pretty extensively for scientific work as well as webscraping
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
> If in the near future JS also reaches good support for scientific/ml libraries it seems like entering that ecosystem is an obvious advantage
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
Super exciting! I'd love to see Bun take a focus on this. Tbh with Deno's recent massive expansions to npm support it's kinda hard to see what role Bun plays in the ecosystem. Focusing on performance critical work like ML and crypto would cement it's place and fill a niche that's underserved. At least until WASM works as advertised but it seems that's kind of a ways off
The irony of this comment, given that there is precisely nothing about Python itself as a language that makes it particularly suitable for "anything remotely scientific", is thick enough to spread on toast.
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.
JavaScript has a very weak standard library. The language & standard library lacks essentials like structural equality, until 2015 or so very weak class-based object-oriented programming, and to this day has numerous footguns that are tricky to remove without breaking the web, like `==`, `this` scoping, and Array.prototype.sort() being in-place.
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.
> Don’t even get me started on FFI/calling into dynamic libraries, which is the bread and butter of scientific computing.
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.
I can see based on your perspective that you haven't collaborated with hundreds of STEM professionals, postdocs, or researchers.
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.
Honestly though, the original comment was just a plea for more competition to drive innovation it seems.
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.
> I can see based on your perspective that you haven't collaborated with hundreds of STEM professionals, postdocs, or researchers.
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.
> Hell, sometimes that's something totally bonkers like Haskell.
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.
I don't know what scientific hole this peg fits into, but it might make more sense to run something in the browser than on the backend (scalability).
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.
> Furthermore, given that WebAssembly seems poised to (eventually) make strides in how browser-oriented applications are built
Also, this isn't really true. The proposals and implementations out there suggest the goal is to use wasm for libraries and specialized optimizations. Nobody wants to wait for a massive binary to download. You can try to port legacy junk apps, but making it usable on the web (not a canvas) might turn out to be more work than it's worth in many cases.
Scientific performance critical code isn't written in Python, it is written in C/C++ which is used by Python. Python in ML usually merely describes the calculation not unlike React describes the DOM that should be displayed in the browser.
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.
JavaScript has a massive and unrivaled ecosystem outside of core data analysis. The main hurdle to adoption is ecosystem and community. A generation of applied mathematicians and data scientists were trained on Python. Python overcame older ecosystems like Matlab and Fortran for its ease of use for other general computing tasks (Matlab is a decent language for large array manipulation but soft tasks like string processing are kludgy compared to Python).
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.
Performance where, exactly? Most Python data munging I've seen just punts it all to C based libraries anyways. Are people doing things in pure python these days?
Under the hood, numpy and friends punt to native code. FFI / native module performance becomes a bottleneck, and Bun is correctly focusing in this area. Shumai [1] is a cool library for Bun that also punts to native code
Given your extremely outsized reply I can tell this is something you feel passionately about or whatever, but the “JS was built in x days” line is a thought-terminating cheap shot. It doesn’t acknowledge the vast amounts of work that have gone into subsequent ES versions. The JS that a typical remotely-modern-tech-stack developer is writing these days is not the JS that you’re belligerently referring to.
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.
> 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
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
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.
> What scientist is going to want to write JS when they can choose Python?
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.
Python is great and ergonomic for interactive fiddling.
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.
[0] https://scikitjs.org/