Hacker News Reader

Comment by duped | Hacker News Reader

First off there's nothing about Rust here. But this quote:

> In particular, the work on the C++ Core Guidelines specifically aims at delivering statically guaranteed type-safe and resource-safe C++ for people who need that without disrupting code bases that can manage without such strong guarantees or introducing additional tool chains

Tells me he doesn't really "get it." People do not follow the core guidelines, and other languages are designed such that there aren't guidelines. There's a type checker (wave hands here) that proves your code and its dependencies are memory safe (within some sane definition).

Another thing worth mentioning is that "type safety" isn't something other languages need to worry about since it's generally not possible to tell a type checker that it's wrong.

View on HN

There used to be, the document was updated, see these twitter feed,

https://twitter.com/m_ou_se/status/1615736570400890883?s=20&...

At least some people screenshot the original.

> Another thing worth mentioning is that "type safety" isn't something other languages need to worry about since it's generally not possible to tell a type checker that it's wrong.

This seems like it's split between compiled and interpreted languages, no? Typescript and Python (I believe) will let you override types in their type system, I assume because doing so has no effect on the underlying code. I'm assuming that compiled languages with integrated type-checkers actually use the type checker for allocations so changing types has runtime implications.

E.g. Typescript doesn't care if you use `as` to force the type of a variable because it has no impact on the runtime. Javascript will create objects and allocate memory the same regardless of what Typescript thinks the type is. That's not true of something like Go, where changing the type of a variable would require different allocations and changing a struct to a string would break low-level features like GC.

It's not interpreted vs dynamic, it's static vs dynamic typing. Python and Typescript are dynamically typed languages with optional AOT type checking, meaning it is valid to write code that would fail typechecking or is impossible to typecheck at parse-time (in other words, types are only guaranteed to be checked when the code is executed, but types are always checked!).

There's also a sliding scale of "weak" to "strong" typing (I don't want to attempt to define it). C is the canonical example of a "weakly" typed languages, but imo C++ fits that as well - unless you follow the idioms of "type safe" programming, which makes it difficult for a programmer to write code that is not type checked. The difference between a weak-but-statically typed language and dynamically typed language is that it's possible for a programmer to write code that is never type checked, leading to potentially undefined behavior. C++ needs a notion of "type safe" programming because it is possible for a programmer to write such code. Contrast to a language like Rust or Haskell, where it's close to impossible to write type-unsafe code (without explicitly saying you want to).

My point is that implying "safe" programming also implies type safety misunderstands that such safety is close to meaningless in safe programming languages. It's just so much harder to write type-unsafe code it's kind of pointless to bring it up, unless you're writing C and C++.

Many compiled languages with strict type checking still have various sorts of "unsafe" type coercions for when you think you know better than the compiler (things like structs that have the same layout but are still nominally different types). In many of those languages the goal is that you need to opt in to the unsafe type coercion sometimes literally with a language keyword even named something like "unsafe" and know that you are doing something dangerous up front, in direct contrast to a language like C/C++ asking you to opt in to type safety and not doing anything about it up front unless you ask.

> Tells me he doesn't really "get it." People do not follow the core guidelines, and other languages are designed such that there aren't guidelines.

I don't think this is true at all. There are already a few popular static code analyzers and lingers around which integrate quite nicely with your run of the mill build system.

The purpose of these static code analyzers and linters is none other than enforce the adoption of stuff like the C++ core guidelines in a workflow a kin to unit testing.

How do you explain that, based on your personal assertion that no one bothers with those? I mean, even popular C++ IDEs support those out-of-the-box.

I really do not understand this absurd idea that those who care about safety drop everything they're doing to mindlessly migrate all things under the sun to a programming language, and the only ones not doing that are the poor incompetent fools who foolishly don't succumb to this cargo cult nonsense.

There are, people just don't use them as much as they should, see survey results.

Linting exists for C since 1979.

Reply on news.ycombinator.com