Years ago after talking with the US Cybersecurity and Infrastructure Security Agency after our applications were being used by a few military medical labs we removed all access to Microsoft DLL and Windows features, returning to the original environment of just writing internal code irrelevant to any operating system "features" - they were happy and approved everything and ever since then I've had nothing hacked.

Basically I don't see the language as the problem, it's normally just the way the code is written to access any external environment "features" (aka problems too often).

The problem with making things idiot proof is that we keep getting better idiots.

The fact that rust has this "unsafe" directive (or what ever it is called) means that the language designers absolutely know that the language cannot do what people want to do with in in a memory-safe manner. The claim that reasoning about unsafe behavior can be limited to these blocks is farcical. If you want to argue otherwise, pass your mathematics prelims & get back to me.

There are plenty of reasons to avoid C++. And, for many applications C. But using memory safety as the reason to switch to a language which proponents claim is safe when it is plainly not? Pull the other one.

#BEGIN UNSAFE BLOCK

.

.

(your entire Rusty program here)

.

.

#END UNSAFE BLOCK

Problem solved, and CISA are happy you've used their approved language!

It might just be a bit easier to:

#pragma pretend-to-be-rust=on

int main ()

....

return 0;

#pragma pretend-to-be-rust=off

ON ERROR RESUME NEXT;

I remember when the US DoD was ADA ON EVERYTHING

There was a missile guidance system that was "written in Ada" that just called a C routine that never returned.

"It's compliant!"

I agree, AC. I was part of the military-software complex during the time that the DoD "insisted" that all new projects were to be done in Ada. (Never mind that Ada was, much like Rust is now, a language under development, and oh, what a mess Ada 3.0 became...but I digress.) Contractors would dutifully come back with bids that were some 3-5 times higher (and 2 to 3 times longer) than the original ones, and the DoD suddenly came up with a "waiver program" that would allow said contractors to develop the code as they originally would have.

Expect to see this lather, rinse, repeat cycle replayed in all its capitalist glory under CISA's latest fiat.

Just who do they think they are...tRump?

Under Trump V2.0

JUst make all your apps supplied to the US Gov do two things.

1) Play the Jan 6th anthem on startup

2) Start every message with 'Trump is God'

And you will be safe... for the time being, as long as you are a White Male, born in the lower 48.

... and do those wheels look just a wee bit wobbly?

No... Just Rusty

We need a "Ba Dum Tsssscchh" icon.

All the listed memory-safe language examples are itself implemented in C or C++. This is because historically C and C++ have been the only languages that had good enough performance to implement the runtime engine. Nowadays we have Rust and Zig and it's still too early to say if Zig is safe enough in practice. Rust is safe enough but it's harder language to use than C and C++. I personally feel that Rust was much easier language to understand than Haskell so it's definitely not impossible language to learn. And even vanilla Rust cannot handle out-of-memory situation gracefully – the default implementation simply kills the whole program. Sure, it avoids having remove code execution but still allows for DoS problems.

Go is written in Go.

The early ones were bootstrapped in C; just like C was boot strapped in machine code.

C was bootstrapped using its predecessor B, which itself was bootstraped via TMG (TransMoGrifiers - a compiler generator). C was not bootstrapped in machine code, or even assembler.

I personally feel that Rust was much easier language to understand than Haskell

Wow low bar

The programming language you use is the right one for the task at hand. That can be any language, be it, to name a few, C, C++, Rust, Java, Python, C# or Assembly. You need to know which tool to use for the project or task. Finding that out is part of being a programmer.

You need a real programmer, regardless of the language used. You need to learn any language and need to create to become experienced. All programmers need supervision and all programmers need to supervise. That is how you learn and improve to the expertise level of the language at hand.

If I had them, I would give you 10 thumbs up, as it is you get 2.

That can be any language, be it, to name a few, C, C++, Rust, Java, Python, C# or Assembly.

But specifically excludes APL.

And probably that thing called "sappeur", which likely is even less mature than Rust, and except for one particular commentard, has never been heard of, much less used, in any commercial project, ever, anywhere.

Can someone give me a summary of just what about Rust is causing the translation problems? Likely there are multiple reasons. I don't think I've seen a summary of what the issues are. Yes, Rust has a different syntax. But seriously, that can be overcome. Is it the semantics of borrowing?

I've written stuff in several different assemblers (thousands of lines in IBM-370), C, Lisp, Basic, Forth, AlgolW, Pascal, Fortran, a bunch of my own languages, and likely some I've forgotten. Many of those don't have pointer-like things so you can't do stuff you'd want. Is that the main issue? Is it how borrowing works?

(I've written a memory safe compiler with restricted pointers, structs, safe unions, allocated records, arrays, etc. etc. If I can get it to full maturity, would something like that work? See http://www.graysage.com/Zed/New . I'm close to finished doing all the hacks in Elf .o files to match gcc/ld's desires.)

Can someone give me a summary of just what about Rust is causing the translation problems?

Effort. Which in turn requires time and resources to train staff and to translate/replicate existing code and potentially maintain duplicate, etc. And that has a significant cost attached to it that is often not granted as generally customers demand fast & cheap.

I'm not saying memory-safe is a bad goal, it is clearly very good, but sometimes it is going to be easier to slap an AppArmour profile around some existing code than to re-write in a safer language and then have to debug the new bugs, etc.

Another problem is learning Rust in today's Rust community.

You ask noob questions because you're a noob, and you get told you're an idiot, instead of being pointed to a FAQ, documentation, or given helpful advice.

Or you ask "is this the right way to do it?" and the same thing happens.

I heard about Rust, went to the forums and saw that, and that's as far as it went.

The issue is that to convert a C program to a "proper" Rust program you have to approach a lot of things in a different way. Rust is not simply C with different key words.

If you want an analogy, then if you've done much Python programming you have probably seen Python programs that were either directly translated from C or Java, or written by people familiar with C or Java and are just writing their Python program the same way they write a C or Java program. This is a well known phenomenon in Python and is immediately recognizable by people with experience with the language. The end result is something very verbose and slow because the Python language is being used in ways it was never meant to be in order to make it work like a different language.

With C and Rust, there have been multiple machine translation projects, including AI based, but the results have been very disappointing. You simply end up with a C program that is written in Rust rather than a "proper" Rust program, and you probably haven't made much if any use of the memory safety features which you were converting to Rust for. So why bother?

The answer would seem to come down to either completely replacing all existing C and C++ programs with ones written in other language (like that's ever going to happen), or else address the problem in a different way, one that nobody has really come up with yet.

Thank you.

There have been attempts in the past to make a "safe C", but I haven't been tracking them. My guess is that they don't have answers for some of the "creative" things that C programmers know how to do, and will continue to do until stopped. :/)

In many ways, my Zed language is a followon to C. Most of the things you can do in C, a privileged Zed programmer can do. But you can also do safe things with slightly different techniques. For example my '@' values are much like C++ refs, but are explicit, not implicit, so programmers are less likely to mess things up (although many will complain about the extra character).

Similarly, I use the 'nonNil' concept to let many runtime checks for NULL be omitted. (Note: there was a previous language that used the word "nonNil" for something quite different.) This also clarifies the requirements on parameters, etc.

As for bounds checking, I've got some simple "constraints" that the semantic code can identify and thus inform code generators that some runtime bounds checks are not needed. Part of doing that is that the iterator variable of a 'for' loop is 'con', i.e. not writeable. If your C "for" loop is actually a "while" loop, then just rewrite it as a 'while' loop.

Also, Zed 'enum' values are guaranteed to be in-range, so their use in 'case' constructs, as array indexes, etc. does not require extra checking (checking is done when arithmetic is done on them). Zed has 'oneof' types that are like C "enum" types.

Switching to using this stuff, and more, does take effort - I've done some of it when I translated my initial C parser to Zed, but if management demands it, its not going to kill you, so long as time is budgeted. You can even do a bunch of prep work in C (like the "for' loop stuff), checking that your program keeps working. For 'nonNil', you could add asserts at the start of functions where you want one or more parameters to always be non-NULL.

> So why bother?

Because someone required you to write it in Rust, and doing so lets you tick that box?

Rust is both incomplete and unstable.

There exactly one implementation, and there is no standard, or even specification - so there cannot be another implementation.

That doesn't mean it's bad. It means it is not ready .

There are some design decisions that mean it cannot replace C or C++.

1) It cannot replace C because it only supports static linking. All external interfaces are C .

2) Rust cannot ever replace C++, and trying is horrifically unsafe, because it has no inheritance. Anyone claiming you can do that does not understand either language - this was never a goal.

Given another decade, Rust may fix the stability and dynamic linking issues.

Given another decade, C++ will be provably safer than Rust.

Well, until the RedoxOS project is mature enough to be viable as an OS, the US government is going to be stuck with C just like the rest of the industry.

Is the US government even helping to fund RedoxOS? Or are they just too busy writing statements telling other people to use an immature language platform.

All programmers need supervision and all programmers need to supervise.

Supervisors or rather managers are part of the problem that is all too often forgotten. Many were never programmers and so do not understand what makes a good environment to program; or of they do their own managers will not let them do the right thing.

A large part of the problem is budgets and timescales. Managers want programs produced in as short a time as possible and as cheaply as possible. The result is that proper design and documentation is not done, testing is skimped.

Some of that is understandable in a competitive environment: if Microsoft had ensured that its products were properly tested someone else would have beaten them to market and they would not be where they are today.

if Microsoft had ensured that its products were properly tested someone else would have beaten them to market and they would not be where they are today.

Oh if only!

@Alain_Williams

Quote: "....Managers want programs produced in as short a time as possible and as cheaply as possible....."

Ah yes:

(1) Keep the PRODUCER COST as low as possible.....

(2) ...and export the problems (and the COST of those problems)...to the customer!!

Fantastic plan!! Keep up the good work!!

As any engineer will tell any manager "Products can be had good, cheaply, safe, or soon. Now pick which two out of those four that you want because it is not possible to have all four."

You missed the point. Supervising programmers is not about managing them.

A supervising programmer is looking at the code. Just like programmers must accept that other programmers supervise them. It is also called peer review , except that there is an implicit educational purpose to the setup. A novice is not a real "peer", but will become one in due time when you all accept the learning curve.

Shame about the horrible horrible things some of these languages do to achieve their 'safety' or easy of use. Plus the inevitable bloat.

I use all sorts for all kinds of things but don't try to tell me some of these options are inherently better because they made a different compromise on one feature and should become the One True Path.

It's not like most of the advocates are actually going to churn out better code even after the swap, they'll just have a different flavor of problem while nanny guides them away from a particular type of careless error. GIT issue lists are stuffed full of the evidence that language choice != better code.

In my glorious place of employment it's not even possible to move from C to C++ified C (replacing buffers and linked lists with strings and vectors and printfs with formats). The first step of modifying the toolchain to compile using the C++ compiler instead of C compiler and the minimum amount of code which trips up the C++ compiler is still as far away as it ever was. If that can't be done then Rust is just not happening and I don't suppose my employer particularly special. If an end client isn't paying for it they just don't want to know.

Which is why the real way to improve safety is to continue improving the safety of existing languages.

That way, existing codebases can slowly transition to the "safe" subset, one function, one class, one subsystem at a time.

New languages are exciting and fun, but rewriting an entire something in a new language is almost always an incredibly bad idea. It's expensive, time consuming and absolutely certain to introduce errors.

Which also means writing a new application in a new language is very risky - if Rust gets replaced by Zig* next year, all your Rusty stuff needs rewriting...

*I have no idea how Zig compares to Rust

...Just stop paying they to produce crap. They can't have a bottom line if they can't find the bottom.

... going by my various video feeds and incoming article alerts, it's all Zig, all the time, now!

Don't these guys keep up with the cool kids(tm)?

This doesn't bother me. I code in HTML.

Oh hi Lottie Dexter, I always wondered what happened to you after the Year of Code.

(Search for the details if you can't remember them, in brief she was the figurehead for a government coding initiative who couldn't code and failed to appreciate what the term meant.)