4 ms·
Nice to see that he linked to rust as a safe alternative to the C's (C, C++, Objective-C). There is a place for Go and Java as well above the system level. Both
by _wldu 5y ago
Nice to see that he linked to rust as a safe alternative to the C's (C, C++, Objective-C). There is a place for Go and Java as well above the system level. Both perform well and are safe.
- zozbot234 5y agoGo is not safe for concurrent code, unfortunately. Specifically, it does not protect against data races on non-atomic types, which can lead to torn writes and break invariants that are required for safety.
- lu4p 5y agoTrue, but still memory safe, also Go has a race detector included which is really easy to use https://blog.golang.org/race-detector https://blog.golang.org/race-detector
- roca 5y agoNo, Go is not memory safe for concurrent code. Race detection is good but can't eliminate races altogether.
- pjmlp 5y agoSame applies to Rust as well actually. Its type system only prevents data races for in-memory data structures, on the same OS process. There are plenty of other concurrency races.
- roca 5y agoIt's true that there are "higher level" races that Rust can't prevent. But in-memory races are particularly important to prevent, because a) they're a common and very nasty kind of bug and b) it means unlike Go, Rust (the safe subset) is memory safe (and in general, free of undefined behaviour) for concurrent code.
- novok 5y agoCan you do a security exploit with a concurrency bug although in golang? You may corrupt data, but can you cause remote code execution with it?
- kortilla 5y agoRCE in that process maybe not, but security exploit absolutely. Things like that are how can be the difference between admin and non admin privileges or an “authenticated/not-authenticated” scenario.
- mattgreenrocks 5y agoCorrupt data may break invariants, which widen the attack surface.
- yellow_lead 5y agoYes, not all RCEs are caused by memory bugs.
- staunch 5y agoCan you point to some examples of RCEs caused by Go concurrency bugs?
- yellow_lead 5y agoI don't have a real world example. I was just stating it's possible.
- staticassertion 5y agoTo be clear, yes. The issue is with how Go's "interface{}"s (and some other types - like slices, etc) work - it's two pointers that can't be written to atomically, which means you can get into a situation where your objects are invalid. https://blog.stalkr.net/2015/04/golang-data-races-to-break-memory-safety.html https://blog.stalkr.net/2015/04/golang-data-races-to-break-m... Here you can find a POC. You could argue that this is contrived, but it's also not going to be fixed. This is in contrast to Rust, where there may be implementation flaws leading to unsafety in safe code, but the language retains the right to fix those, even if it breaks code. Still, I think there's really no question that Go is a major step up over C and C++.
- azakai 5y agoYou're right that Go has those flaws, and it would be nicer if they didn't exist. However, in practice Go is still far, far safer than C and C++. Use after free etc. are far easier to exploit than Go's races. If you can write in 100% safe Rust, Swift, C#, Java, etc. - and not use any of the unsafe escape hatches they provide at all - that would be best. But using some small amount of unsafety in any of those languages, or using Go, would still be a huge improvement over the typical C or C++ codebase.
- mikewarot 5y agoIt was in this context for the first time that I saw how Rust was something other than an overly complex replacement for C. I've heard all sorts of things about how it's memory safe, but nobody ever explained why that was important. So thanks for that. This marks the place where I acknowledge my mind was changed about the value of Rust. [Update] Upon reading [1], I think that memory safety is still vital, but Rust has a very strange and cumbersome way of doing it. [1] - https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html https://doc.rust-lang.org/book/ch04-01-what-is-ownership.htm...
- meowface 5y agoRust has a strange way of doing it because it's trying to be as performant as C but as safe as a garbage-collected language. Maybe there'll be a language that achieves both without having to worry about ownership, but I'm not aware of any that exist at the moment.