Live data from Hacker News

Viewing profile — constexpr

constexpr

HN member
Joined
Tue, Aug 16, 2011, 1:56 AM UTC
HN karma
853
Public activity
112 items

About constexpr

No profile information was provided.

Recent public activity

  1. 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 …

  2. 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…

  3. 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…

  4. comment
    Comment #31620163

    Carto was a blast and really well made. Loved the humor and world building, and the puzzles were satisfying.

  5. 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 …

  6. 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…

  7. 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…

  8. 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…

  9. 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…

  10. 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…

  11. 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…

  12. 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…

  13. 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…

  14. 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 …

  15. 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. …

  16. 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.

  17. 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…

  18. comment
    Comment #26144707

    It would be great if you could file these as bugs against esbuild! Sounds like these should be easy to fix.

  19. 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…

  20. 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…

  21. 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

  22. 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…

  23. 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…

  24. 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 …

  25. 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…