www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - =?UTF-8?B?QW50aHJvcGlj4oCZcw==?= Restraint Is a Terrifying Warning

reply twkrimm <twk invalidemail.com> writes:
I am wondering if D code safety could make it the prominent 
programming language in the future.

If this article is not click bait, then its message is quite 
concerning.


"https://www.nytimes.com/2026/04/07/opinion/anthropic-ai-claude-mythos.html"

...

"
The good news is that Anthropic discovered in the process of 
developing Claude Mythos that the A.I. could not only write 
software code more easily and with greater complexity than any 
model currently available, but as a byproduct of that capability, 
it could also find vulnerabilities in virtually all of the 
world’s most popular software systems more easily than before.

The bad news is that if this tool falls into the hands of bad 
actors, they could hack pretty much every major software system 
in the world, including all those made by the companies in the 
consortium.

This is not a publicity stunt. In the run-up to this 
announcement, representatives of leading tech companies have been 
in private conversation with the Trump administration about the 
implications for the security of the United States and all the 
other countries that use these now vulnerable software systems, 
technologists involved told me.

For good reason. As Anthropic said in its written statement on 
Tuesday, in just the past month, “Mythos Preview has already 
found thousands of high-severity vulnerabilities, including some 
in every major operating system and web browser. Given the rate 
of A.I. progress, it will not be long before such capabilities 
proliferate, potentially beyond actors who committed to deploying 
them safely. The fallout — economics, public safety and national 
security — could be severe.
’’
Apr 08
next sibling parent reply Sergey <kornburn yandex.ru> writes:
On Wednesday, 8 April 2026 at 10:09:59 UTC, twkrimm wrote:

 I am wondering if D code safety could make it the prominent 
 programming language in the future.


How does this relate to D?
Apr 08
parent reply twkrimm <twk invalidemail.com> writes:
On Wednesday, 8 April 2026 at 10:23:05 UTC, Sergey wrote:

 On Wednesday, 8 April 2026 at 10:09:59 UTC, twkrimm wrote:

 I am wondering if D code safety could make it the prominent 
 programming language in the future.


 How does this relate to D?


It is my understanding that D has less vulnerabilities then other 
programming languages.
This can be a big "selling point" for the D language.

example:

https://dlang.org/spec/memory-safe-d.html

Memory-Safe-D-Spec

Memory Safety for a program is defined as it being impossible for 
the program to corrupt memory. Therefore, the safe subset of D 
consists only of programming language features that are 
guaranteed to never result in memory corruption.
...
Apr 08
next sibling parent twkrimm <twk invalidemail.com> writes:
On Wednesday, 8 April 2026 at 10:48:37 UTC, twkrimm wrote:

 On Wednesday, 8 April 2026 at 10:23:05 UTC, Sergey wrote:

 On Wednesday, 8 April 2026 at 10:09:59 UTC, twkrimm wrote:

 I am wondering if D code safety could make it the prominent 
 programming language in the future.


 How does this relate to D?


 It is my understanding that D has less vulnerabilities then 
 other programming languages.
 This can be a big "selling point" for the D language.

 example:

 https://dlang.org/spec/memory-safe-d.html

 Memory-Safe-D-Spec

 Memory Safety for a program is defined as it being impossible 
 for the program to corrupt memory. Therefore, the safe subset 
 of D consists only of programming language features that are 
 guaranteed to never result in memory corruption.
 ...



Other examples are:
https://dlang.org/spec/betterc.html
https://dlang.org/spec/importc.html
Apr 08
prev sibling next sibling parent reply Serg Gini <kornburn yandex.ru> writes:
On Wednesday, 8 April 2026 at 10:48:37 UTC, twkrimm wrote:

 It is my understanding that D has less vulnerabilities then 
 other programming languages.
 This can be a big "selling point" for the D language.


Yeah, I've seen rumors that some big projects like Palantir and 
Anthropic already started rewriting their internal solutions from 
Rust to D
Apr 08
parent reply madwebness <qount25 protonmail.com> writes:
 Yeah, I've seen rumors that some big projects like Palantir and 
 Anthropic already started rewriting their internal solutions 
 from Rust to D


Lol, good one.

But on a serious note, I think the real issue isn't programming 
languages, but OS design. I am entirely convinced the real 
problem is that Unix and Windows are by definition vulnerablt 
because of how it's possible for them to just launch a program 
that has access to whatever user has access to. If we had a 
proper first-class sandboxing / capability in an OS, this 
wouldn't even be a problem. A well designed capability OS would 
literally be so safe that a package manager could just download 
stuff from random urls and run it and the system would still be 
largely uncompromised. The problem is that modern systems are 
"good enough", people largely don't care and there's so much 
stuff written for the existing systems - the inertia is real and 
almost inescapable.

Was honestly thinking going full Terry Davis at some point and 
start writing that OS, because it's very interesting to me 
personally, but I'm still a little less unhinged than him as of 
right now, so I have to come up with some path wherein there's 
some adoption.
Apr 08
parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Thu, Apr 09, 2026 at 02:57:17AM +0000, madwebness via Digitalmars-d wrote:
[...]

 But on a serious note, I think the real issue isn't programming
 languages, but OS design. I am entirely convinced the real problem is
 that Unix and Windows are by definition vulnerablt because of how it's
 possible for them to just launch a program that has access to whatever
 user has access to.


This is old news.  Linux already has built-in ability to restrict
programs by capabilities.  You can use this to, say, restrict the
browser process' permission to a much smaller subset than the full
permissions of the user who launched it.  And these policies can apply
to arbitrary processes, subprocesses, process groups, and can be
arbitrarily complex.

It also makes it a royal pain to configure.



 If we had a proper first-class sandboxing / capability in an OS, this
 wouldn't even be a problem. A well designed capability OS would
 literally be so safe that a package manager could just download stuff
 from random urls and run it and the system would still be largely
 uncompromised.


Also old news. Things like Snap run individual applications inside their
own encapsulated sandbox, and they literally cannot break out because
it's enforced at the OS level.

It also makes it a royal pain to use, because you cannot even access the
local filesystem without jumping through hoops.

And when something is inconvenient to use, guess what happens?  That's
right, it motivates the user to disable the protections so that he can
just download files of questionable origin into his home directory
without navigating a labyrinth of prohibitions.

Also, just because something runs in an unbreakable sandbox does not
stop them from causing chaos from inside the sandbox.  Consider the case
of a compromised browser doing crypto mining, spam forwarding, and being
a member of a botnet.  You cannot stop this, because the whole point of
the browser is to talk to the internet.  Yes, it cannot harm the host
OS, but it *can* wreak havoc online.  Restrict this, and the browser
becomes useless, nobody will use it, and will go back to "insecure"
systems.



 The problem is that modern systems are "good enough", people largely
 don't care and there's so much stuff written for the existing systems
 - the inertia is real and almost inescapable.


People are also lazy, and prone to make compromises in the name of
convenience.  You can have the world's most secure OS with the strictest
protections ever, but either nobody will use it, or users will disable
(some of) the protections because they find it too inconvenient to work
with strict permissions.  As long as convenience is a deciding factor,
you cannot escape this.

Same applies to programming languages.  Most programmers will not bother
writing secure code, because it gets in the way of getting the job done
before the boss fires you. It takes you away from the parts you enjoy
working on.  The incentives are wrong, and so no matter what you do,
vulnerable systems will always be the default.  It takes effort to be
secure, and most people are not ready to pay that price. Until this
mindset changes, the security situation will not change.



 Was honestly thinking going full Terry Davis at some point and start
 writing that OS, because it's very interesting to me personally, but
 I'm still a little less unhinged than him as of right now, so I have
 to come up with some path wherein there's some adoption.


I used to be young and foolish, and opinionated to think that had I been
the one to write the OS, things would be different.  Now that I'm a
little less young and less foolish, I've come to concede that writing an
OS is Hard(tm), and probably I wouldn't do much better than what's out
there today.  Of the hundred things that I think I can do better, there
are probably a thousand things I overlooked that others have plugged
long ago, and if were to write my own OS from scratch, my OS would have
these thousand security holes even if I successfully plugged the hundred
I criticize other OSes for.

And yes, adoption is a big question. Because, as I said, people are lazy
and want convenience; security requires effort and is often
inconvenient.  These are contradictory requirements; *some* compromise
has to happen somewhere.  We may disagree on exactly what is permissible
to compromise on and what's not, but make no mistake, there will be
compromises.  Otherwise, you will have zero adoption.

The only truly 100% secure system is one that does not connect to the
internet and does not allow the user to do anything useful.  Once you
have the requirement that it also be useful, security has to be
compromised in *some* way.  And here reasonable people will disagree on
exactly what these compromises should be.


T

-- 
If lightning were to ever strike an orchestra, it'd always hit the conductor
first.
Apr 08
parent madwebness <qount25 protonmail.com> writes:
On Thursday, 9 April 2026 at 04:09:49 UTC, H. S. Teoh wrote:

 On Thu, Apr 09, 2026 at 02:57:17AM +0000, madwebness via 
 Digitalmars-d wrote: [...]


This is old news.  Linux already has built-in ability to restrict 
programs by capabilities.

Not aware of anything on linux, but if it's anything like 
Capsicum on FreeBSD, it's laughable in that it requires programs 
to be capsicum aware and if they're not, then nothing actually 
works.


 Also old news. Things like Snap run individual applications 
 inside their own encapsulated sandbox, and they literally 
 cannot break out because it's enforced at the OS level.


Snap/flatpak are containers. This isn't what I'm talking about. 
Capabilities are not containers. If an OS had first-class 
capabilities design, it wouldn't be as cumbersome as you imagine. 
There are capability OSs out there, but as far as I'm aware, 
they're very academic and pretty difficult to use. I did spend 
some considerable time thinking about proper design of such an OS 
and I'm fairly certain it's possible to have it both get out of 
your way as a user and be secure/sandboxed. I think people 
haven't thought about it hard enough precisely because they don't 
want to (I get it, many other problems to solve, OS design ain't 
one of them!). But I think it's mistake to believe we can't do 
better.


 I used to be young and foolish, and opinionated to think that 
 had I been the one to write the OS, things would be different.


Yeah, I get the sentiment. I'm not very young myself either. I'm 
just trying to stay excited about things (isn't it why we use 
D?), but I'm fully aware of how much other people actually don't 
care.
Apr 08
prev sibling parent reply Kagamin <spam here.lot> writes:
On Wednesday, 8 April 2026 at 10:48:37 UTC, twkrimm wrote:

 It is my understanding that D has less vulnerabilities then 
 other programming languages.


Less than "old good" C dialect. Pretty much everything else is 
better.
Apr 09
parent Kagamin <spam here.lot> writes:
https://forum.dlang.org/post/clliljdqfkqbijxyruyo forum.dlang.org
hmm, it was fast
Apr 09
prev sibling parent reply C# Nullable Fan <someone email.com> writes:
On Wednesday, 8 April 2026 at 10:09:59 UTC, twkrimm wrote:


 This is not a publicity stunt.


Yet when Anthropic tried to use Claude Code to write the Claude C 
Compiler they failed miserably.

If they now have such a powerful tool, hopefully they can 
complete what would be a rather basic task for such a powerful 
tool.

Clearly, they won't be doing this only because they can't, as 
their tools are smoke and mirrors.

This looks exactly like a publicity stunt, and I suspect it is 
designed to help them in their next round of funding as they find 
themselves burning through endless quantities of cash trying to 
find something they can sell.

What is terrifying is the vast amounts of money pumped into the 
current AI bubble, which will end badly when that bubble finally 
pops.
Apr 09
parent Guillaume Piolat <first.name gmail.com> writes:


 Yet when Anthropic tried to use Claude Code to write the Claude 
 C Compiler they failed miserably.


It's not that much that it failed. Rather than the end result is 
not superior to hand-coded alternatives that have an actual place 
on any market. So you take a risk investing into something that 
has a capped upside.
Apr 09