Hacker News Reader

Comment by modshatereality | Hacker News Reader

is this a good way to spend developer time? How about *removing* all of the middle-man bloatware instead of wasting how many dev-years rewriting it (edit: and effectively making it even LESS maintainable now that it's in some new niche language with a vastly smaller dev pool). just give me the direct linux experience we all deserve instead of this garbo spamflinger middlewear that google leverages to keep you dependent on their build methodology and discourage cooperation with other competitive linux-based system.

edit2: wow mods hard at work, already removed one dissenting post.

View on HN

> and effectively making it even LESS maintainable now that it's in some new niche language with a vastly smaller dev pool

How is any language supposed to grow if you're only allowed to use it once everybody does? Somebody has to be first (and google isn't, not by a long shot)

You should at least wait until there is more than one working/usable compiler for the language if you're going to start making systemic changes to your multi-billion-dollar code base responsible for the commerce of multiple billions of people on the planet. It's a weird move at this point for google to be making(edit: considering go is already supported on multiple compilers).

"It should have two compilers" is a pretty arbitrary benchmark for production readiness. I'd suggest the benchmark be based on, idk, something with any fucking meaning.

>something with any fucking meaning

So you claim to have a better metric, feel free to share it?

site broken and wont let me reply any more: "shipped into production" is meaningless, compilers are directly related to language community and complexity.

How about numerous companies shipping Rust to production for years? That metric is actually related to risk with regards to shipping rust in production, unlike number of compilers, which signifies nothing.

Many languages had only a single compiler implementation when they were brought into the limelight for critical development so your benchmark would fail almost everything.

"...wasting how many dev-years rewriting it"

It sounds like you didn't read the blog post. The whole point is that they are not rewriting code, but writing new code in memory-safe languages (including "niche" languages like Java). This strategy is paying off with fewer severe vulnerabilities due to memory safety bugs.

>It sounds like you didn't read the blog post.

where did you get the impression they are not rewriting code in rust? because the author cited some other blog post saying they should focus on new code and not rewriting it? How does that translate to "The whole point is that they are not rewriting code," ???

Obviously they're going to be rewriting whatever they see fit. If YOU actually read the article you would have seen they have "keystore2" listed as new rust code. I WONDER what was keystore1 implemented in? Nice try, but no cookie.

The article says that their focus should be on "new code, not rewriting existing components" and that Rust code is used in "new functionality and components".

Yes, one is named "keystore2" but you don't seem to actually know anything about it (nor do I). It seems doubtful to me that they would rewrite a perfectly working component in Rust just for fun. Most likely the original keystore, whatever language it was written in, was not meeting its requirements and needed to be replaced.

Reply on news.ycombinator.com