Hacker News Reader

Comment by kleiba | Hacker News Reader

I don't agree with your "way more robust" argument per se, but I also didn't buy that point in the original article. It's unclear to me why the choice of programming language -- unless it was a very obscure and rarely used one, or one that's specifically used in one (unrelated) domain -- should be of any significance.

View on HN

> It's unclear to me why the choice of programming language -- unless it was a very obscure and rarely used one, or one that's specifically used in one (unrelated) domain -- should be of any significance.

I'd rather use a language where e.g. a buffer overflow couldn't be turned into a remote exploit that would let you steal coins from every client on the network. Mistakes in cryptocurrency code has the potential to be very costly so you'd think minimising mistakes at all costs would be worth it.

Yet, the original author finds it fishy that IOTA is not implemented in C++.

The article doesn't make much sense. It starts with the author saying the IOTA whitepaper was indecipherable, that the language choice was a bad idea, the code is undocumented etc. and then (ignoring massive red flags like the IOTA devs creating their own hash function) the author bought into and sold out of IOTA multiple times while experience major issues.

Personally I think C++ is a bad choice. A safer language that is easier to verify is preferable when small bugs have the potential to wipe out a cryptocurrency. Imagine Bitcoin got hit with a bug that allowed wallets to be emptied or took down the network such that a hard fork was required to fix it; it would wipe out confidence if this happened enough times. Maybe I'm missing something beyond the developers being very disciplined but I'm impressed this hasn't happened yet.

What's even more bizarre is that with C and C++ it can take many years for these kinds of bugs to unravel.

Anyone remembers Heartbleed?

Most likely it's that the majority of experienced crypto devs (aka people who have been around since it was "fork bitcoin and change PoW algo + logo") will be familiar with C++, so a Java implementation is an odd choice that strongly hints that it was written by a lowest-cost contractor - or at least someone unfamiliar with cryptos. Since there is an awful lot of trust in devs to provide future support/improvement, both are bad.

(Lot of "write my dumbass cryptocurrency" requests on Upwork, so I assume this is very common.)

As for technical superiority, maintaining consensus is critically important. If one set of users (miners) requires a high-performance implementation, it makes a lot of sense to use that implementation everywhere.

> Most likely it's that the majority of experienced crypto devs (aka people who have been around since it was "fork bitcoin and change PoW algo + logo") will be familiar with C++, so a Java implementation is an odd choice that strongly hints that it was written by a lowest-cost contractor

If you're an experienced developer writing a new cryptocurrency that's radically different from Bitcoin, why would you want to fork from Bitcoin and why would you find Java code harder to make safer than C++ code?

It's an explanation of why a Java client would be suspect as an "investor" - experienced dev teams don't release them. Most of these projects are primarily marketing ventures ("look, we're the next Ethereum!"), a lot of code is outsourced, and the average "investor" expects a handwavy explanation of how it's The Future with lots of big words that that they trust is correct. Making odd/different choices (DIY crypto, Java reference implementation) hurts that idea.

Reply on news.ycombinator.com