Hacker News Reader

Comment by scaredginger | Hacker News Reader

I gave up only a little beyond where they revealed that they ported line-by-line. I think this is an interesting experiment for those considering a Rust rewrite, but has no utility for a greenfield project. The scales are stacked strongly in favour of C++ here, without a doubt. Software designed for C++ has essentially zero chance of becoming idiomatic Rust without a huge amount of work, and tooling tends to be designed for idiomatic use

View on HN

> I gave up only a little beyond where they revealed that they ported line-by-line.

The commenter you are so dismissively replying to is the author. He did not "give up only a little beyond something" like you did, he made a serious effort that probably took hundreds of hours, and documented it. I am not sure why you are posting such a comment full of disrespect for his work, after reading a couple of paragraphs of his article.

I didn't mean to be dismissive. Like I said, I think it's useful for somebody. I just don't think it's useful to me

But as another commenter pointed out more idiomatic Rust == more borrow checking, less unsafe == more checks.

Is there really reason to believe that would be in advantage of Rust build times?

Ok, you say the proc macros you say.. but it also commented on, and also not unidiomatic?

Why would a project need to become "idiomatic Rust" for a Rust port to be useful?

My wording may have been unclear. I have no doubt you had good technical justification for this port. I'm purely talking about the experimental results regarding builds and toolchains here. For people starting a new project rather than porting, I don't think this is a useful data point

To avoid being hounded by the purity police, of course!

To be useful as a comparison between implementation languages, it should be idiomatic. Otherwise it just tells you what it's like to transliterate one language into another, something which is usually only done for interop purposes - running on a platform which doesn't have a native compiler, or to enable native-level APIs when foreign function support is poor.

Code size after transliteration is a race the target language can seldom win; abstractions that also exist (or close enough) in the target language get translated 1:1, abstractions which don't get broken down 1:n, and abstractions which exist in the target language but don't have analogues in the source language generally don't get used at all. It's hard to end up with a shorter program following this approach. Only boilerplate with redundant repetition and ceremony - code which has little functional effect other than to satisfy declaration order rules, symbol visibility and so on - can get eliminated.

Reply on news.ycombinator.com