March 08

On Friday, 8 March 2024 at 09:09:12 UTC, Monkyyy wrote:

>

Python and java, and js are not exactly safe languges, there no way to inturpt the high ranking as being coherently designed around safety.

They are safe languages, as far as the common definition goes. What they lack compared to likes of D, Rust or Nim enable is the ability to forgo the GC and allocate memory / cast types manually when you have to.

Well, there usually is some way to do that even in those languages if you're determined enough, but it tends to be much harder than in a purpose-built systems programming language. Plus, in all likelihood the low-level controls are completely implementation-specific, as opposed to standard part of the language.

C and C++ are the opposite: you can go low-level easily enough, but they don't have a standard safe subset of the language.

March 08
On Friday, 8 March 2024 at 06:29:17 UTC, Walter Bright wrote:
> C could become far more memory safe it it adopted slices:
>
> https://www.digitalmars.com/articles/C-biggest-mistake.html

D biggest mistake is NOT to be a better C++.


March 08
On Friday, 8 March 2024 at 10:43:39 UTC, Paulo Pinto wrote:
> 
> Just wait until delivering software written in C or C++ requires a biohazard symbol "handle with care" kind of regulation

Why would this happen? Is there a reason to expect it to happen? How do you square this with mircosoft being a friend of the cia, and mircosoft also has a gaint pile of c and c++ its up for debate if they are capable of rewriting
March 08

On Friday, 8 March 2024 at 14:16:14 UTC, Dukc wrote:

>

On Friday, 8 March 2024 at 09:09:12 UTC, Monkyyy wrote:

>

Python and java, and js are not exactly safe languges, there no way to inturpt the high ranking as being coherently designed around safety.

They are safe languages, as far as the common definition goes

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=javascript

"5146 CVE Records"

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=c

"1748 CVE Records"

Python and js have more mechanisms to run giant stacks of insane code of depenency hell and that insane to call safe; I'm pretty sure js is the main cause of malware spreading, but if it isn't it's up there.

March 08
On Friday, 8 March 2024 at 17:14:00 UTC, monkyyy wrote:
> On Friday, 8 March 2024 at 10:43:39 UTC, Paulo Pinto wrote:
>> 
>> Just wait until delivering software written in C or C++ requires a biohazard symbol "handle with care" kind of regulation
>
> Why would this happen? Is there a reason to expect it to happen? How do you square this with mircosoft being a friend of the cia, and mircosoft also has a gaint pile of c and c++ its up for debate if they are capable of rewriting

Yes, that is the expected outcome of US and EU cybersecurity bills that make companies liable for security exploits.


Rust is now the official systems programming language for Azure infrastructure teams, alongside managed languages. Use of C and C++ is constrained to existing code bases.

Rust is also shipping on Windows kernel  already.

March 08

On Friday, 8 March 2024 at 17:20:22 UTC, monkyyy wrote:

>

On Friday, 8 March 2024 at 14:16:14 UTC, Dukc wrote:

>

On Friday, 8 March 2024 at 09:09:12 UTC, Monkyyy wrote:

>

Python and java, and js are not exactly safe languges, there no way to inturpt the high ranking as being coherently designed around safety.

They are safe languages, as far as the common definition goes

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=javascript

"5146 CVE Records"

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=c

"1748 CVE Records"

Python and js have more mechanisms to run giant stacks of insane code of depenency hell and that insane to call safe; I'm pretty sure js is the main cause of malware spreading, but if it isn't it's up there.

Those exploits fail under the 30% attack surface, after we get rid of the 70% caused by memory corruption exploits.

March 08
On Fri, Mar 08, 2024 at 06:59:28PM +0000, Paulo Pinto via Digitalmars-d wrote: [...]
> Rust is now the official systems programming language for Azure infrastructure teams, alongside managed languages. Use of C and C++ is constrained to existing code bases.
> 
> Rust is also shipping on Windows kernel  already.

Like I said, the inevitable has begun. It's just a matter of time now. The clock is already ticking for memory-unsafe languages. It may not be as fast as some may think/want, but that day undoubtedly will come when these languages will fade away in the rearview mirror.


T

-- 
Старый друг лучше новых двух.
March 08

On Friday, 8 March 2024 at 19:01:06 UTC, Paulo Pinto wrote:

>

Those exploits fail under the 30% attack surface, after we get rid of the 70% caused by memory corruption exploits.

how is 5k vs 1.7k turn into 30%?

March 09
On Friday, 8 March 2024 at 10:43:39 UTC, Paulo Pinto wrote:
> Just wait until delivering software written in C or C++ requires a biohazard symbol "handle with care" kind of regulation, and insurance companies high premiums on software developed with such languages.

This isn't going to happen in this century.

You're talking about an absolutely *gigantic* amount of software - an utterly, unfathomably, big amount. Many thousand lifetimes' worth of work.

A quick estimate tells me that my computer is running several *hundred* million lines of code just for firmware, OS, drivers, shell/GUI, browser etc. so that I can write this message. Mandating a rewrite of all of that is both a fool's errand and economic suicide for whatever nation that wants to enforce such a mandate.

To my knowledge, the last major OS kernel that was started from scratch was Linux (I believe that the roots of the current MacOS/iOS/visionOS... kernel are actually older and NT certainly is). No newer kernel has reached a similar level of maturity. All major browsers that are currently in use have their roots in the 90s or early 2000s. It's quite easy to continue this list with all kinds of application software and stuff.

It would be a major miracle if even a single one of these chunks of software would get replaced by a rewrite from scratch within the next one or two decades. Replacing all of them at once is so much effort that it would mean complete industry-wide stagnation for decades.

The best that can happen is a glacially slow migration of single components to other languages that are (perceived to be) more modern. At worst, we end up with a stack that stays the way it is and gets another layer of glossy paint poured over it. Given the state of our industry, that's the more likely outcome. Any attempt to politically enforce anything more radical than that will be met with enormous and vicious resistance from companies, which I would expect to be successful.
March 09
On Saturday, 9 March 2024 at 02:33:16 UTC, Gregor Mückl wrote:
> On Friday, 8 March 2024 at 10:43:39 UTC, Paulo Pinto wrote:
>> [...]
>
> This isn't going to happen in this century.
>
> You're talking about an absolutely *gigantic* amount of software - an utterly, unfathomably, big amount. Many thousand lifetimes' worth of work.
>
> [...]

I've first hand informations about the insurances that one big consultancy company (I mean, one among Accenture, PWC, Deloitte, NTT, etc) is paying for cybersecurity risk, and the amount  is simply skyrocketing. And there's also a big reputational risk for their customers.