5 ms·

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 res

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.

randomdata 3y ago
Importing `C` declares that you intend to use Cgo instead of Go. Cgo is not Go[1]. [1] https://go-proverbs.github.io https://go-proverbs.github.io
bayindirh 3y ago
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.
- oefrha 3y ago
  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.)
morelisp 3y ago
What language is memory-safe even if you use unsafe and/or arbitrary C linkage? (I rather suspect triyambakam was referring to undefined behavior on data races.)
- slimsag 3y ago
  Formally verified C code, or WASM[0] [0] https://news.ycombinator.com/item?id=38613031 https://news.ycombinator.com/item?id=38613031
  - morelisp 3y ago
    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.
    - sweetjuly 3y ago
      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.
      - actionfromafar 3y ago
        Such a shame this didn’t take off. Couldn’t LLVM in theory be made to target pNaCL instructions?
- bayindirh 3y ago
  IIRC, Go has support for atomics, which are handled at the processor directly and effectively eliminates data races. So, I don't see a problem here.
  - morelisp 3y ago

randomdata 3y ago

Importing `C` declares that you intend to use Cgo instead of Go. Cgo is not Go[1]. [1] https://go-proverbs.github.io https://go-proverbs.github.io

bayindirh 3y ago

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.

oefrha 3y ago
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.)

morelisp 3y ago

What language is memory-safe even if you use unsafe and/or arbitrary C linkage? (I rather suspect triyambakam was referring to undefined behavior on data races.)

slimsag 3y ago
Formally verified C code, or WASM[0] [0] https://news.ycombinator.com/item?id=38613031 https://news.ycombinator.com/item?id=38613031
- morelisp 3y ago
  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.
  - sweetjuly 3y ago
    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.
    - actionfromafar 3y ago
      Such a shame this didn’t take off. Couldn’t LLVM in theory be made to target pNaCL instructions?
bayindirh 3y ago
IIRC, Go has support for atomics, which are handled at the processor directly and effectively eliminates data races. So, I don't see a problem here.
- morelisp 3y ago