Viewing profile — constexpr
constexpr
HN member- Joined
- Tue, Aug 16, 2011, 1:56 AM UTC
- HN karma
- 853
- Public activity
- 112 items
- HN profile
- View on Hacker News ↗
About constexpr
No profile information was provided.
Recent public activity
-
comment
Comment #35267393
That's the only image with a non-zero EXIF orientation. Which probably means you're using an older browser (e.g. Chrome started respecting EXIF orientation in version 81+, which I …
-
comment
Comment #35267307
Hello! I made this. People are talking about not wanting pictures to be initially blurry before they finish loading. I understand that too, and I'm not sure how I feel about it mys…
-
comment
Comment #33441928
There are two performance implications of "modularization": initialization-time and run-time. You are correct that initializing many modules is usually slower than initializing one…
-
comment
Comment #31620163
Carto was a blast and really well made. Loved the humor and world building, and the puzzles were satisfying.
-
comment
Comment #30761997
I came across one of these once without knowing about the phenomenon. It’s in Golden Gate Park near the intersection of JFK Drive and Transverse Drive. Water in the stream next to …
-
comment
Comment #30094718
No, I haven't experimented with generics and esbuild. I hadn't considered whether generics could improve performance or not. Just thinking about it quickly now. I'm not convinced i…
-
comment
Comment #30094498
That comment wasn't about Go exclusively. My point was that porting single-threaded code to a native language doesn't necessarily cause huge order-of-magnitude speed gains, especia…
-
comment
Comment #30094133
Yes that allows for shared memory. But the TypeScript compiler is written in TypeScript, and you can't put JavaScript objects (such as the TypeScript AST) in a SharedArrayBuffer. S…
-
comment
Comment #30079649
Yeah I was afraid of that. Ideally it would be possible to do type checking in parallel at the function level or something, but TypeScript allows you to omit the return type and th…
-
comment
Comment #30079571
The problem is that you can't use shared-memory parallelism in TypeScript. If you could, then the most straightforward way of speeding up the TypeScript compiler would be to parall…
-
comment
Comment #30079403
I'm the author of esbuild. I think this is a very smart, practical choice and is one of the approaches that has the best chance of succeeding (the other being a semi-automated port…
-
comment
Comment #30079299
I'm the author of esbuild. I hadn't written Go before I started esbuild and I thought I would miss generics more, but I didn't. There is literally only one situation in the whole e…
-
comment
Comment #26159862
It is also all custom: https://github.com/esbuild/esbuild.github.io . YAML files that get converted to plain static HTML pages. It's designed to work well without any JavaScript. E…
-
comment
Comment #26159734
I'm the author of esbuild. Rest assured that I am very interested in supporting it and am actively working on it. It's just unfortunately very complicated to correctly, especially …
-
comment
Comment #26151055
Both would be good to file. I’m happy to investigate myself if you don’t have the time. One thing to be aware of is that some other tools that integrate esbuild do so incorrectly. …
-
comment
Comment #26146644
Ah I see, no worries. I assumed you were trying to compare against a production build since that's what "parcel build" does.
-
comment
Comment #26145771
I noticed you changed this to "dev" instead of "production". Just letting you know that this will select the development build of React instead of the production build, which is no…
-
comment
Comment #26144707
It would be great if you could file these as bugs against esbuild! Sounds like these should be easy to fix.
-
comment
Comment #26138698
It's strange that they are comparing output size without passing --minify to esbuild. Why compare the size of the debuggable output? And if you care about output size, you would al…
-
comment
Comment #24096403
I think the odds are pretty good. The TypeScript compiler's performance is not optimal: https://twitter.com/evanwallace/status/1275945317045657602 . Microsoft's TypeScript team has…
-
comment
Comment #23593241
A new JavaScript/TypeScript bundler written in Go that's 10-100x faster than Webpack, Rollup, and Parcel: https://github.com/evanw/esbuild
-
comment
Comment #23176397
Shaking up the JavaScript build tool ecosystem with https://github.com/evanw/esbuild , a bundler and minifier that's 10x-100x faster than industry-standard ones (Webpack/Rollup/Par…
-
comment
Comment #22343375
I'm not sure that this is a CPU bound workload. You're right that if this is CPU bound, LLVM's code generation should come out on top, even if only slightly, but that's not the cas…
-
comment
Comment #22340520
Yeah benchmarks are tricky. I'd rather not tweak the parameters for Rollup in this case because then it wouldn't be a fair comparison. Rollup would then be cheating because it has …
-
comment
Comment #22338858
Both the Rust and Go parsers were written by hand. They are also very similar (basically the Go version was a direct port of the Rust version) so the performance should be very com…