Comment by pjmlp | Hacker News Reader

Comment by pjmlp | Hacker News Reader

Parent Full thread

So here is a sample,

Chapel, HPC language mostly sponsored by Intel and HPC

https://chapel-lang.org/

D programming language,

https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in...

Ada/SPARK,

https://docs.adacore.com/spark2014-docs/html/ug/en/source/la...

Swift,

https://github.com/apple/swift/blob/main/docs/OwnershipManif...

ParaSail

http://www.parasail-lang.org/

Project Verona from Microsoft Research

https://www.microsoft.com/en-us/research/project/project-ver...

Project Snowflake from Microsoft Research

https://www.microsoft.com/en-us/research/publication/project...

And finally your favourite C++

"Implementing the C++ Core Guidelines’ Lifetime Safety Profile in Clang"

https://llvm.org/devmtg/2019-04/slides/TechTalk-Horvath-Impl...

Also the "Clang Static Analyzer - A Tryst with Smart Pointers" talk at 2021 LLVM Developers Meeting.

For the Visual C++ part of the story

https://devblogs.microsoft.com/cppblog/lifetime-profile-upda...

And GCC as well, although they are late to the party

https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer

Finally a couple of CppCon 2021 talks that touch on the subject in various ways,

Type-and-resource safety in modern C++

Code Analysis++

Static Analysis and Program Safety in C++: Making it Real

Finding Bugs Using Path-Sensitive Static Analysis

> Chapel, HPC language mostly sponsored by Intel and HPC

Minor correction: Intel hasn't traditionally been a sponsor of Chapel (though we'd love to see that change). Chapel was pioneered at Cray Inc. and continues on even stronger at HPE after its acquisition of Cray.

-Brad

Thanks for the correction, I thought seeing them referenced in some talks.

All the best.

At least most of these don't seem to be added language features, but separate "static analyzers" that rely on inference from existing language structures.

Sounds like a lot of "contemporary automation today" to me - automation that would often apply about as well to C code bases as well as horrifically overcomplex C++ codebases.

Also, why even draw a stark contrast between "a language" and "its tooling"? As a dev, you get to use both.

What is even the line..? Almost every compiler for anything provides options. Does gcc -fsanitize=.. not count because it's not "standardized" or only because its not activated in "typical" deployments like Rust integer overflow checks?

The line is very, very easy: if it is in the language, you can see it represented syntactically in the source code, and programmers using the language write it there. If not, not.

Clang and Visual C++ static analysis tooling can be represented on the source code via C++ attributes and blessed library types, so...

So... not in the language, but in proprietary, non-portable extensions.

With exception of C++, they certainly aren't.

C++ type system is impossible to fix while keeping backwards compatibility, so static analysis tooling is the only possible solution.

Reply on news.ycombinator.com