Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The JavaScript Oxidation Compiler

oxc.rs

Post reply on HN
Print view View original

101–110 of 147 posts

Re: The JavaScript Oxidation Compiler

#101

Post by pjmlp »

phplovesong wrote: post #68
WD-42 wrote: post #20

Earlier quoted context omitted.

Because Rust makes developers excited in a way that C/C++ just doesn't.

We had many languages that are faster that are not c/c++. Compare Go (esbuild) to webpack (JS), its over 100x faster easily. For a dev time matters, but is relative, waiting 50sec for a webpack build compared to 50ms with a Go toolchain is life changing. But for a dev waiting 50ms or 20ms does not matter. At all. So the conclusion is javascript devs like hype, and flooded Rust and built tooling for JS in Rust. They c…

No worries, when Zig hits 1.0, the RIZ projects from JavaScript, Python and Ruby tooling will start hitting HN frontpage.

Re: The JavaScript Oxidation Compiler

#102

Post by lioeters »

MrJohz wrote: post #90
lioeters wrote: post #67

Earlier quoted context omitted.

> esbuild Another example is the TypeScript compiler being rewritten in Go instead of self-hosting. It's an admission that the language is not performant enough, and more, it can never be enough for building its own tooling. It might be that the tooling situation is the problem, not the language itself, though. I do see hopeful signs that JavaScript ecosystem is continuing to evolve, like the recent release of MicroQ…

I don't think that's necessarily a bad thing, though. JavaScript isn't performant enough for its own tooling, but that's just one class of program that can be written. There are plenty of other classes of program where JavaScript is perfectly fast enough, and the ease of e.g. writing plugins or having a fast feedback loop outweighs the benefits of other languages. I quite like Roc's philosophy here: https://www.roc-l…

True, I agree. It's a good thing to accept a language's limitations and areas of suitability, without any judgement about whether the language is good for all purposes - which is likely not a good goal for a language to have anyway. I like that example of Roc, how it's explicitly planned to be not self-hosting. It makes sense to use different languages to suit the context, as all tools have particular strengths and weaknesses.

Off topic but I wonder if this applies to human languages, whether some are more suited for particular purposes - like German to express rigorous scientific thinking with compound words created just-in-time; Spanish for romantic lyrical situations; or Chinese for dense ideographs. People say languages can expand or limit not only what you can express but what you can think. That's certainly true of programming languages.

Re: The JavaScript Oxidation Compiler

#103

Post by lioeters »

3836293648 wrote: post #95
lioeters wrote: post #37

Earlier quoted context omitted.

I'm going to call it: a Rust implementation of JavaScript runtime (and TypeScript compiler) will eventually overtake the official TypeScript compiler now being rewritten in Go.

In popularity or actually take over control of the language?

Eventually I imagine a JS/TS runtime written in Rust will be mainstream and what everyone uses.

Re: The JavaScript Oxidation Compiler

#105

Post by littlestymaar »

wiseowise wrote: post #92
littlestymaar wrote: post #82

Earlier quoted context omitted.

Sometimes they are the same person. It just take someone to have poor empathy towards your users to ship slow software that you don't use.

I've never met a single person obsessed with performance who goes half the way. You either have a performance junkie or a slob who will be fine with 20 minutes compile times.

I have. They cared a lot about performance for them because they hated waiting, but gave literally no shit about anyone else.

Re: The JavaScript Oxidation Compiler

#108

Post by staticassertion »

philippta wrote: post #61

It always comes as a surprise to me how the same group of people who go out of their way to shave off the last milliseconds or microseconds in their tooling care so little about the performance of the code they ship to browsers. Not to discredit OP's work of course.

TBH I don't know how to do that work. If I'm in the backend it's very easy for me. I can think about allocations, I can think about threading, concurrency, etc, so easily. In browser land I'm probably picking up some confusing framework, I don't have any of the straightforward ways to reason about performance at the language level, etc.

Maybe once day we can use wasm or whatever and I can write fast code for the frontend but not today, and it's a bit unsurprising that others face similar issues.

Also, if I'm building a CLI, maybe I think that 1ms matters. But someone browsing my webpage one time ever? That might matter a lot less to me, you're not "browsing in a hot loop".

Re: The JavaScript Oxidation Compiler

#109

Post by TheAlexLichter »

philippta wrote: post #61

It always comes as a surprise to me how the same group of people who go out of their way to shave off the last milliseconds or microseconds in their tooling care so little about the performance of the code they ship to browsers. Not to discredit OP's work of course.

I personally met a lot of folks who care about both quite a bit.

But to be fair, besides the usual patterns like tree-shaking and DCE, "runtime performance" is really tricky to measure or optimize for

Post reply on HN