[HN Gopher] 55,000 lines of Rust code later: A debugger is born
___________________________________________________________________
55,000 lines of Rust code later: A debugger is born
Author : ibraheemdev
Score : 22 points
Date : 2021-05-12 21:52 UTC (1 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| v8dev123 wrote:
| What's with the people who still use the term C/C++?
|
| C++ and C are separate languages. I'd be grateful for the author
| to reflect it in the Readme.
|
| Further, Bragging about LoC is bad. LoC is a poor measure of both
| quality and functionality.
|
| "C/C++ - a mythical language referred to by people who cannot or
| do not want to recognize the magnitude of differences between the
| facilities offered by C and C++" -- Stroustrup
| fioawjpoifajio wrote:
| Concretely, rr uses both C and C++, so the term is perfectly
| valid, given that the two languages interoperate just fine.
| smoldesu wrote:
| > C++ and C are separate languages. I'd be grateful for the
| author to reflect it in the Readme.
|
| I agree, but we could honestly be as granular as we want here.
| We could ask the author to delineate between C99 and C11, but
| it ultimately doesn't really matter. The point of referring to
| "C/C++" is to cast a blanket statement over the traditional
| compiled mainstays and use them as a point of reference. While
| they are indeed different, they're more alike then they are
| dissimilar. I think the author is perfectly justified here.
|
| > Further, Bragging about LoC is bad. LoC is a poor measure of
| both quality and functionality.
|
| Rust is a language that is extremely verbose, and properly
| formatted Rust code often uses more lines than necessary to
| improve readability (expanding match arms, removing inlined if-
| statements, etc.). Hell, if you look at the repo, it looks
| almost identical to a default Rust project: src is clearly
| exposed at the root, and everything else is pretty well
| organized into distinct folders. I disagree with the first part
| of your statement ("Bragging about LoC is bad") but agree with
| the second part ("LoC is a poor measure of both quality and
| functionality.")
|
| Honestly, I think LoC-shaming originated in languages like Java
| and Python, where more lines of code almost guaranteed more
| complexity. Rust's focus on zero cost abstraction ultimately
| means that even massive programs can run with minimal overhead.
| I'm not here to parade Rust's achievements in front of you, but
| I figured it was worth pointing out at least here.
| lmilcin wrote:
| > Honestly, I think LoC-shaming originated in languages like
| Java and Python, where more lines of code almost guaranteed
| more complexity. Rust's focus on zero cost abstraction
| ultimately means that even massive programs can run with
| minimal overhead.
|
| Zero-cost abstractions are meant to be zero physical cost,
| not zero mental cost. LoC still translate to mental overhead
| and "LoC shaming" is appropriate for any language, not just
| verbose like Java or Python.
| lmilcin wrote:
| > Further, Bragging about LoC is bad. LoC is a poor measure of
| both quality and functionality.
|
| It is not a measure of quality but rather size of the project.
| Scuds wrote:
| > In my opinion, debuggers are under-appreciated and under-
| invested tools in a programmer's arsenal.
|
| Oh yeah - microsoft's time travelling debugger is under
| appreciated, even with their quality tooling. But, it's on the
| windows platform. So anything like this on Linux sounds like a
| very positive step forward.
| triska wrote:
| Wow, this looks awesome already at this early stage! Thank you a
| lot!
|
| _Record-replay_ debugging is a great approach, and will allow
| very convenient and reliable debugging!
| jeff-davis wrote:
| From one of the linked pages:
|
| "Lack of garbage collection was a problem but runtimes are more
| troublesome...Linux signal handling becomes very
| complicated...Runtimes also often force layout of data structures
| be tuned to the needs of the garbage collector..."
|
| https://github.com/sidkshatriya/me/blob/master/002-why-rust....
|
| That sums up my experience using a lot of higher-level languages.
| The pitch is always that language X should replace C because it's
| just as fast in most practical cases but much easier and safer.
| But the reason I use C is because of the pain of complex
| runtimes, especially when interoperating with other languages.
|
| And that's also why I'm interested in Rust. It's the first high-
| level language (I use the term loosely) that doesn't interfere
| with anything you're trying to do. It can even do dynamic
| dispatch on ordinary pointers to structures with a C memory
| layout, because it doesn't add a vtable pointer to structs (like
| C++ does).
|
| "I don't know much about dlang -- it could have been the best of
| both worlds"
|
| Yeah, I skipped over dlang, too. And I don't have a good reason
| for that, aside from a lack of time to really explore both. I
| hope dlang keeps growing and eventually I'll look into what it
| has to offer.
| jeff-davis wrote:
| Is the goal to replace rr or coexist somehow?
___________________________________________________________________
(page generated 2021-05-12 23:01 UTC)