111–120 of 122 posts
Earlier quoted context omitted.
"Run TypeScript" is misnomer, unless I'm missing something, it compiles TS -> JS and "runs" that.
"Run JavaScript" is a misnomer, it compiles JS -> bytecode and "runs" that.
https://github.com/petkaantonov/bluebird/wiki/Optimization-k...
I have a lot of respect for Jarred and bun. The lean approach of just one person working for a year is rather underrated imo. No funding and therefore no pressure for growth. No overhead from scaling up a team and having to implement process, standards, etc. And at the same time, incredible content marketing by just tweeting about every little detail. Me and many others got hooked just because Jarred was posting inte…
Sounding twitchy and strung out and high strung and histrionic? A filter for sure, but not for the things he thinks he wants.
This is how you get broken, desperate, unhealthy people, and that is reflected permanently in culture, and almost always in product, with poor prognosis for success.
Seriously the guy needs to chill the f--- out.
My moneys on Just-JS. It’s consistently in the top 5 fastest web framework (beating out Rust, etc). Just-JS is already faster than Bun. Additionally, JSCore appears to be a significant reason why Bun is faster than NodeJS (V8). Just-JS is investigating switching to JSCore as well - which will only extend its lead. https://github.com/just-js/just https://www.techempower.com/benchmarks/#section=data-r21 https://twitter…
Bun does ESM, JSX, Typescript and SQLite support out of the box. It also does bundling. It’s quite nice. I’m thinking of building a zero-dependency toolkit on top of it. I rewrote Tailwind this weekend with that in mind, and my 4-second Tailwind build (on a 90k line project) now takes 200ms. That’s mostly due to how I architected my Tailwind library; not Bun, but Bun is fast where it’s been optimized. I love the idea…
Are Bun and Deno in direct competition or do these projects address different markets?
> Oven will leverage end-to-end integration of the entire JavaScript stack (down to the hardware) to make new things possible.
Earlier quoted context omitted.
I am surprised every day at how much raw human effort has gone (and continues to go) into making JavaScript into a good language, when at most 1/20th of that effort could have been used to simply replace it with something that is good to begin with.
The positive interpretation is that this is an example of Gall’s law: https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law Today’s JavaScript works because it has gradually evolved from the primordial JS which (just about) worked; at each stage in the chain it’s seen real-world usage as an in-browser language. The alternative would be to build something better from scratch -- but that never works, says Gall’s…
everyone just continues doing what they are doing on the assumption that either JS is the best that humans can come up with, or that it’s too difficult to unseat it. both are ways of saying “i don't want to think about that problem right now.”
so then someone made the simultaneously laziest and most expensive decision ever: put JS on the server, too. now the code serving the client and the client itself get one thread each. “gosh, performance isn’t great here, but i don’t want to think about that, i have a sprint goal.”
it is only recently that WASM became a thing, and adoption seems slow. it has only succeeded because it did not try to usurp JavaScript’s position, and even requires JavaScript code to interact with the page content or the user in any way. if you can’t beat ‘em, or don’t want to try, join ‘em.
JS has hit zero barriers and has never been strenuously challenged at all. if it had, it would be gone. everyone just keeps throwing money at it because they don't want to think about how awful it is.
Only Google attempted it with Dart, and then they got tired and gave up, because the team was (presumably) minuscule compared to the team working on JavaScript in the same effing browser.
Earlier quoted context omitted.
Despite the "How Safe is Zig"[1] blog post, it's false that there is a spectrum. A lack of temporal safety implies a lack of spatial safety, and vice versa. If one can use a use-after-free, invalid write, time of check-time of use error to write a byte to an invalid location, the program's data structures are now in an inconsistent state, violating invariants required for "spatial safety" such as objects being the co…
Thanks, that's a great insight! Does it follow that the fact that temporal violations could be used to violate runtime spatial checks, therefore means that spatial safety in itself is entirely without value? What are your thoughts also on buffer underflows ? I ask since I take it you also work on offensive security.
To be precise, I don't think the mitigations Zig has, which the author labels as "spatial safety", are entirely without value. Optionals & sum types, range checks are helpful.
Buffer underflows as in writing to negative indices? I wish I could go in a time machine and default early languages to saturating arithmetic instead of wrapping. Even Rust does wrapping arithmetic in release mode, in debug mode overflows will panic.
Earlier quoted context omitted.
The positive interpretation is that this is an example of Gall’s law: https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law Today’s JavaScript works because it has gradually evolved from the primordial JS which (just about) worked; at each stage in the chain it’s seen real-world usage as an in-browser language. The alternative would be to build something better from scratch -- but that never works, says Gall’s…
Javascript has had zero barriers in becoming what it is, specifically because people are afraid to attempt to unseat it. there has never been an adult in the room willing to ask “is spending several hundred thousand person-years on this hack of a language better than starting over with something that is more thought out?” Of course it would be better to replace it, especially so in the early days when people saw what…
Only Google attempted it with Dart, and then they got tired and gave up, because the team was (presumably) minuscule compared to the team working on JavaScript in the same effing browser.
Funnily enough it was the same team! Lars Bak led a small team to build V8, and then when that was a big success, he had enough clout within Google to design a new language that could improve on JS, so he took most of the same team and they created Dart.
Earlier quoted context omitted.
Javascript has had zero barriers in becoming what it is, specifically because people are afraid to attempt to unseat it. there has never been an adult in the room willing to ask “is spending several hundred thousand person-years on this hack of a language better than starting over with something that is more thought out?” Of course it would be better to replace it, especially so in the early days when people saw what…
I don’t think your reading of history is correct at all. There were plenty of attempts to unseat JS in the browser - ActiveX, Flash, Java, Dart. Only Google attempted it with Dart, and then they got tired and gave up, because the team was (presumably) minuscule compared to the team working on JavaScript in the same effing browser. Funnily enough it was the same team! Lars Bak led a small team to build V8, and then wh…
only Dart attempted to replace it.
> Lars Bak led a small team to build V8, and then when that was a big success, he had enough clout within Google to design a new language that could improve on JS, so he took most of the same team and they created Dart.
How many people (original team or not) continued to work on V8? I don't know, but it felt like Dart had about 5% of the workforce that V8 did. If so, there was little chance they could have ever caught up to V8 on any measure in the short time Dart existed in Chrome as a DOM-manipulating scripting language.
I have a lot of respect for Jarred and bun. The lean approach of just one person working for a year is rather underrated imo. No funding and therefore no pressure for growth. No overhead from scaling up a team and having to implement process, standards, etc. And at the same time, incredible content marketing by just tweeting about every little detail. Me and many others got hooked just because Jarred was posting inte…
> The lean approach of just one person working for a year is rather underrated imo It's honestly got me thinking about doing the same thing for my Big Project that I've been squeezing into nights and weekends for the past year and a half