4 ms·
> It's everything C can do, but much better. Are you sure about that? I don't think you'll be running Go on an AVR. Likewise to this day Go still can't pin poi
by vvanders 9y ago
> It's everything C can do, but much better.
Are you sure about that? I don't think you'll be running Go on an AVR. Likewise to this day Go still can't pin pointers so interop with native C libraries is a royal pain(this is something that C# and Java both support).
People love to bag on C but there are domains where it can go that a GC'd language can't. I wouldn't be so quick to equate the two.
- peterevans 9y agoI love C. It's the language I used when I first "got" programming, and it's stuck with me, even though I don't use much professional use for it. I don't think you can count me among those who "love to bag" on it. I don't think Go needs to be a like-for-exact-like analog of C to be a valid replacement. For many C programs, the memory management pattern they use is something that could be handled just as easily with GC, and done so in such a way as to lift a significant burden on the programmer. I mentioned this in another comment, but definitely, if you need to manage your own memory—don't use Go. I must disagree that GC disallows Go as a replacement for the language. But I will respect your opinion if you think it does!
- vvanders 9y agoI agree that you can claim it as a replacement for some sub-domains. However if I can't do embedded programming then it's not an all-up replacement. Much if modern C usage is in this space even if it's not as visible to the average developer. GCs have a host of problems like needing a 2x working set, pauses and the fact that you can't control allocation locations for better cache usage. Go may be fast but it will never unseat C/C++/Rust in performance for the reasons above.