3 ms·
> 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 (unrela
by seanwilson 9y ago
> 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.
- kleiba 9y agoYet, the original author finds it fishy that IOTA is not implemented in C++.
- seanwilson 9y agoThe 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.
- tasubotadas 9y agoWhat'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?
- asddddd 9y agoMost 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.
- seanwilson 9y ago> 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?
- asddddd 9y agoIt'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.
- y_u_no_rust 9y agoNot to mention integer overflows/memory allocation issues in a lot of the code that's common within p2p networks