top | item 38692924

(no title)

PurelyApplied | 2 years ago

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.

discuss

order

bayindirh|2 years 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|2 years 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|2 years 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.)

pa7ch|2 years ago

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.

bayindirh|2 years 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.