Hacker News Reader

Comment by sudb | Hacker News Reader

One of the tradeoffs of Rust is its verbosity I think (in return for which Rustaceans would say you gain explicitness).

Verbosity compared to C?

Only in extra syntax constructs.

But Rust can absolutely do the same thing as C in fewer lines, especially when comparing each's standard features like string support.

Rust is not a very verbose language. I translated (without AI) a medium sized program I'd written from Python to Rust and it was 10% longer. Hardly worth mentioning.

I absolutely despise that C convention if abbreviating absolutely every single thing as much as possible. Yeah yeah, that was necessary back in the day when memory was scarce and editors were awful, but come on those days were almost half a century ago by now.

Rust may be verbose, but at least you can read it without turning into a cynical greybeard subject matter expert first.

I've found that the less real estate my eyes need to scan, the faster I understand the code, even if its more tersely expressed and requires a little decoding. Relatedly, I've come to appreciate a line of code that does the thing rather than one that calls a function whose name might express what the function does, but I might need to go find it and and read its code. That works well if your language supports a terse expression. So I prefer you tersely multiply/reduce a list rather than call a function, but some languages just aren't friendly to that and demand verbosity.

This is why kotlin is so amazing, unusually concise and unusually clear in meaning.

Rust does so a lot of abbreviation, though. fn, ptr, mut, etc.

It's ok to abbreviate things that are a) standardised, and b) used extremely frequently. Keywords are the best case here. Standard library functions are often ok (e.g. I wouldn't say renaming `memcpy` to `memory_copy` gains you much).

The problem with many C programmers is they tend to abbreviate identifiers in code that they write, which have neither of those properties. It really slows down reading code.

It's actually even worse for hardware (SystemVerilog) developers. For some reason they have to abbreviate everything as much as humanly possible. In some cases it is acceptable (clk/rst for clock/reset) again because it's standard and common. But often you'll end up with nonsense like `dma_ctn_tlul_rsp_intg_err`. Good luck figuring that out if you don't know all the acronyms (it's DMA ConTrol Network ReSPonse INTeGrity ERRor). Obviously you don't need `dma_control_network_response_integrity_error` but there's a middle ground (probably e.g. `dma_control_resp_integrity_err`). (And sorry to pick on OpenTitan; their code isn't actually as bad for this as some of the closed source stuff I've seen.)

What is the `tlul` part? Just a typo? I don't see it in your expansions.

Yeah I forgot about that actually. It's TileLink-UltraLight, a SoC bus (basically an open version of AXI). It's probably an acceptable acronym in this context because it's used all over the chip. But also I dunno if it adds much to the name to include the bus that it's connected to.

I kinda love it, because verbosity means you have to rely on completion and that has a negative impact on retention.

And the terseness is good when you’re familiar with the code.

>"Rust may be verbose, but at least you can read it without turning into a cynical greybeard subject matter expert first."

Actually stuff like fn, mut etc. feels like mutilation to me. I guess it is highly individual.

Reply on news.ycombinator.com