7 ms·
I wish they hadn't picked go. Go isn't a bad language really, but it's a huge pain to integrate a go library into an app written in another language.
by lachlan-sneff 6y ago
I wish they hadn't picked go. Go isn't a bad language really, but it's a huge pain to integrate a go library into an app written in another language.
- echelon 6y agoC or Rust would be perfect. No GC runtime, no name mangling, fast, great ffi story. Rust needs to start edging out Go for new tools. Kubernetes, Envoy, IPFS, etc. would have benefitted from it. It might not have been time four years ago, but it's time now.
- momack2 6y agoThere's actually a new Rust-IPFS implementation looking for more contributors. Seems to be moving pretty fast - https://github.com/ipfs-rust/rust-ipfs https://github.com/ipfs-rust/rust-ipfs
- spsoto 6y agoEnvoy is written in C++, not Go.
- echelon 6y agoI'm aware. The creator occasionally pokes fun at the Rust folks for arguing that Envoy should have been written in Rust. And rightly so--Rust wasn't mature at the time Envoy was written. If we revisit that now, C++ is the wrong language to start Envoy in today.
- ncmncm 6y agoCitation needed.
- keeganpoppen 6y agoa citation is most definitely not needed. it's obviously a fucking opinion. and they are under absolutely no obligation to meet your standard of proof to demonstrate anything to you. clearly citations are not a necessary condition to posting-- this comment has no citations, but yet... hey look-- it's been posted! the horror! classic HN obnoxious "citation needed" commentary strikes again. i swear i'm just gonna keep doing this every time i see this... until i get bored and give up, i guess.
- ncmncm 6y agoJeez, calm down. "Citation needed" generates no more obligation than the original unsupported opinion did. Would you blow up the same way about "I disagree"? The fact is, most opinions about what language somebody else ought to write their next library in are worth about what they cost to post. Another is that, trendiness notwithstanding, Rust right now is best suited for a library few people will need. That may change in five or ten years. It might well not.
- keeganpoppen 6y agoCitation needed.
- tadfisher 6y agoKeybase and KBFS as well.
- stryan 6y agoRust will start edging out Go once Rust becomes easier than Go to prototype/start projects. Rust is a great language, but right now I can start a project in Go and have someone else start a project in Go and have something up and working in a week. Rust still takes significantly longer to learn and/or find skilled developers for. Go is up there with Python in terms of "Get something out now".
- thefounder 6y ago>> Rust will start edging out Go once Rust becomes easier than Go to prototype/start projects. I guess that time will never come...unless Go somehow looses its way
- rosywoozlechan 6y agoRust isn't that difficult to prototype or start projects with? What trouble do you run into? I think the hardest parts to understand are the concepts of borrowing, lifetimes, and ownership, but you don't have to know all the subtleties of that to prototype. A basic understanding is fine to get started with. Just like a developer doesn't have to understand all the subtleties of generics to get started with either, lots of devs don't know what covariant or contravariant means and use generics.
- plerpin 6y agoUnderstanding the concepts is one thing, applying them is another thing entirely. The Rust compiler is an incredibly difficult beast to placate.
- drudru11 6y agoRust does name mangling by default. However, you can turn it off per symbol just like in C++.
- correct_horse 6y agoThey also picked javascript ¯\_(ツ)_/¯
- hecturchi 6y agoBrowsers picked... until recently it was the only way to run in browsers.......
- wwright 6y agoI used to hate JS, but honestly, it made a lot of really smart decisions for dynamic documents. Some decisions weren’t great, but somehow they didn’t go as far wrong as C++ managed to in the same era…
- Groxx 6y agoJS has a better library-integration story than Go does, since there are so many JS implementations in other languages. Go drags all its runtime threads along with it. But fair point :)
- hecturchi 6y agoGo can handle 100k goroutines (green threads) without a sweat. This is useful for p2p systems in which you are connected to thousands of peers multiplexing several p2p protocols with each concurrently. You want to be able to switch threads as fast as possible. The concurrency model is a bit easier to reason about too. It would be good to see how Rust and others do. Other languages excel at other things (i.e. embedded devices ).
- lachlan-sneff 6y agoRust can easily do the same.
- jzoch 6y agoRust can handle the same thing though the typical model now is using async-await and scheduling tasks on a threadpool. While I won't say its conceptually as simple as go can be, Rust also has channels, mutexes, and other concurrency primitives that allow you to create a similar story. It will also end up being more performant and less work to make correct (typically) due to its small runtime and extensive compile-time checking.
- hecturchi 6y agoMaybe if IPFS had started today they would have picked Rust. Honestly I'm not sure why Go was picked specificall, but if you put things in the context of 5 years ago it doesn't seem a crazy choice.
- SparkyMcUnicorn 6y agoThe Discord team wrote an article (or a few), and I think you'd find them very interesting.Specifically about their Go implementation, porting to Rust, and then the decision to use Rust wherever it makes sense as a result. They're very sensible about it, and advocate using the right tool for the job.
- m-p-3 6y agoI'm not sure if that applies here, but Discord switched a portion of their backend from Go to Rust because of some performance issues. https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f https://blog.discord.com/why-discord-is-switching-from-go-to...
- karatestomp 6y agoSame thing that turned me off. There’d have been lots of cool and useful integrations popping up “for free” all over the place if they’d written it in a good library/integration language. Good language for a daemon, bad language for the reference (so, for anything halfway complicated, usually only) implementation of something intended to become a foundational protocol.
- momack2 6y ago...there are a lot of cool and useful integrations popping up: https://blog.ipfs.io/weekly-84/ https://blog.ipfs.io/weekly-84/. go-ipfs is where the majority of new development happens right now as the desktop/server implementation (compared to js-ipfs=browser & rust-ipfs=IoT) - but if you want to prove that Rust is clearly better/faster _in general_ - have at it: https://github.com/ipfs-rust/rust-ipfs https://github.com/ipfs-rust/rust-ipfs ;) I think the thing jbenet was selecting for back in 2013 was concurrency support & modularity, and golang is still a decent choice for that. Rust 1.0 didn't happen until 2015 after the go-ipfs alpha was already out - but agree it's made awesome progress since then!
- karatestomp 6y agoI don't care about performance, exactly, it's just that with (say) a C implementation if you're even halfway popular you'll end up with modules in a dozen languages (wrapping your C lib) and an apache module and a storage backend for a few databases, maybe a Linux kernel module, and so on, in no time, and they'll all be pretty much in sync with what's
- matheusmoreira 6y agoAny language that lacks a simple and stable binary interface ultimately can't be used to build reusable code. If it's not simple, only compiler hackers will be able to work with the objects produced. If it's not stable, compatibility between two binaries isn't guaranteed and people won't even try to integrate existing libraries into their own software. A big reason why C is still widely used. A library that's written in C can be used in any other language.