If minor mistakes are corrected without the PR author's input, do they ever learn to stop making those mistakes themselves? It seems like a system where you just never bother to learn, e.g., style conventions, because reviewers just apply edits as needed.
They made a drama comedy faux-documentary about it a few years ago titled _Pinball: The Man Who Saved The Game_. It's cute, regardless of your investment into pinball as a whole.
Not the glib root-commenter, but the two big caveats is that Go is memory-safe provided you import neither `unsafe` nor `c`.
That can end up being a pretty restrictive constraint, if it's not something your dependencies cared about. If it is a concern of yours, it's pretty easy to check for at build time.
Well, unsafe says it all. It's "unsafe". On the other hand, I never had to import "C" in any of my projects, yet.
However, if I'm going to wander into CGo realm, I can always pivot to C++, if speed or things implemented in C is that important for me.
No programming language, incl. a particular one which has an orange mascot, is perfect. I also find trying to solve social problems with technology (i.e. let's make programming languages foolproof to enable lazier-er programmers), pointless, to put it mildly.
Honestly, in my eyes Go is a very nice, little language, and I like how it handles.
In my experience, a typical project in orange-mascot language is also more likely to bring in a C dependency through a -sys dep than a typical project in blue-mascot language. (That might be changing with more RIIR, though.)
Data races can lead to logic bugs that are potentially security sensitive, but memory safety generally refers to getting rid of all control flow hijacking security vulnerabilities which, in many large C/C++ projects, seem to be never-ending. Avoiding data races is more in the category of preventing bugs/crashes while memory safety is about avoiding an entire class of security vulnerabilities.
I've never seen a single control flow hijack PoC from go data races even in a code golf scenario. I've always wondered if this is possible but I don't think it is. Care to share an example?
WASM is a funny case and I don't agree that it's safe.
When people say WASM is "safe" in this sense what they mean is that it won't corrupt your browser process (or other wasm runtime). That's a useful guarantee! But that's sandboxing, not memory-safety as a language property. You can sandbox C too, that doesn't make C a memory-safe language.
As far as I know you can still trigger unsafe access to the WASM heap, and therefore many kinds of of attacks still work. They don't "break out" but also, lots of valuable data or controllable user behavior is in-heap anyway.
Or, for an even more analogous example, see Google's pNaCl which was a native compilation target that provided many of the same security guarantees as wasm does while avoiding the need for complex JITs. pNaCl utilized a set of rules about control flow transitions and address formation which were enforced by a verifier to allow direct native code execution.
Having tools to avoid data races don't make it a memory-safe language, unless you strip that phrase of all meaning.
The more interesting question is, would it be worth it to be memory-safe? Rust says yes, and puts a lot of work into statically preventing data races at the cost of (at least) some language ergonomics. Java also says yes, but put a lot of work into making data race impacts well-defined, and on this tends to incur cost (runtime and language development time) with unclear benefits towards actually reasoning about the programs with such races.
