Live data from Hacker News

Viewing profile — strager

strager

HN member
Joined
Thu, Jan 27, 2011, 8:08 PM UTC
HN karma
300
Public activity
184 items

About strager

strager.nds@gmail.com http://strager.net/

Recent public activity

  1. comment
    Comment #38435734

    > Ideally type-checking, linting, highlighting and formatting would run in one language service doing incremental parsing and updates to a shared AST on every keystroke. I think th…

  2. comment
    Comment #38435675

    Here is the answer I got from vjeux: > There's a lot of fast web tooling being written in rust those days. https://twitter.com/Vjeux/status/1722769322299609565 I don't buy it. I th…

  3. comment
    Comment #36531705

    Sean Baxter is doing a decent job with his Circle compiler, so I hear. https://www.circle-lang.org/

  4. comment
    Comment #34976750

    Unfortunately, we live in the real world where compilers do not do the things that you suggest that they ought to.

  5. comment
    Comment #34285485

    I'm not sure what you mean. Are you talking about the benchmarks? I run `cargo clean` before each benchmark. That should clean up changes to third-party crates, right?

  6. comment
    Comment #34285417

    I'd love to try Zig and Jai for this purpose, but they are not stable yet. If either becomes stable, I'll happily re-run this experiment. Nim doesn't look like the language for me.…

  7. comment
    Comment #34285413

    > Definitely check [Val and Carbon] out if you're looking for a C++ replacement! I don't want to base my project on an experimental language like Carbon or Val. I want a C++ replac…

  8. comment
    Comment #34285399

    > If your main conclusion is based on full builds, i would urge you to re-evaluate. It's not. I show several charts comparing incremental builds too.

  9. comment
    Comment #34285377

    Good question. The author of Zig claims that dev build times will be amazing. One technique is to avoid LLVM. Another technique is to integrate the linker. But all of that is a wor…

  10. comment
    Comment #34285370

    > I don't know enough C++ or Rust to judge but is it possible that they are optimized around Rust that isn't C++ style? I know I have seen articles about other languages where some…

  11. comment
    Comment #34285363

    I have found Clang's -ftime-trace flag helpful in finding bloated #include-s and templates. Also, I have analyzed the .ninja_log file (for CMake+Ninja) to find slow-to-compile .cpp…

  12. comment
    Comment #34285345

    > They seem to have chosen to use mold for C++ and not for Rust after seeing that it gave little benefit for small projects, but I would expect that to change as the project scales…

  13. comment
    Comment #34285311

    > I’m very confident that Rust would fare considerably better with 24 17.1k-line crates (410k lines, larger due to duplicating the entire thing rather than just the lexer) than wit…

  14. comment
    Comment #34285298

    > if I want faster development (among other things), I use an interpreted scripting language. If I want a fast end product (among other things) I compile and optimize to machine co…

  15. comment
    Comment #34285280

    > I assume it also reduces size of created object-files? Normal template instantiations are deduplicated by the linker. Total object file size is smaller with explicit template ins…

  16. comment
    Comment #34283949

    Current settings according to BIOS: Target CPU Speed: 3400MHz Target DRAM Frequency: 800MHz Target FCLK Frequency: 1800MHz DRAM timings: 19/20-19-19-19-39 (The DRAM CAS# Latency se…

  17. comment
    Comment #34273967

    > I would expect an idiomatic implementation to drastically go down in lines of code Can you give an example of where something in the project could be, say, 20 lines of code inste…

  18. comment
    Comment #34273936

    > Raise the FCLK (Fabric Clock) to 1900. Hmm, I think I did this, or something like this. I'llcheck tomorrow. (If I did, then my comment about not overclocking the CPU is misleadin…

  19. comment
    Comment #34273516

    > I just randomly looked at one part: linked vector. How would Rust LinkedVector's implementation have fewer lines than C++'s linked_vector? > It would be a great experiment to use…

  20. comment
    Comment #34273501

    > A recent change[0] on nightly rustc might help with incremental builds. I tested with rustc Git commit c7572670a1302f5c7e245d069200e22da9df0316, which (I think) includes that cha…

  21. comment
    Comment #34273435

    >> Someone has to implement them. Note that they're also implemented in the C++ code, so the comparison is fair. > > I'm not sure I buy this argument in code like yours which almos…

  22. comment
    Comment #34273349

    No, I'll stay far away from them, thanks. ;P

  23. comment
    Comment #34273336

    > Of course it exists in C++, and has done since before Rust even existed. Not in C++'s standard library until C++20.

  24. comment
    Comment #34273332

    It is a beast. I love my MacBook Pro!

  25. comment
    Comment #34273327

    I'd wager that the C++ compiler does more work churning through #include-s than the Rust compiler does tracking borrows.