SoylentNews is people
SoylentNews
It's memory-safe, with a few caveats:
Developers looking to continue working in the C and C++ programming languages amid the global push to promote memory-safe programming now have another option that doesn't involve learning Rust.
Filip Pizlo, senior director of language engineering at Epic Games, has created his own memory-safe flavor of C and – because why not? – named it after himself.
Pizlo got in touch after seeing our report on TrapC – a memory-safe C-fork due for release next year.
"I wanted to alert you to the existence of Fil-C, a personal project of mine, which exists today, does just about everything TrapC claims to do (including being totally memory-safe), and is freely available," Pizlo explained. "It aims for 100 percent compatibility with C and C++ – just compile your stuff with my compiler and you get memory safety."
The US government and other interested parties are rather keen to encourage memory safety – something not available out of the box for C and C++ code. C and C++ require manual memory management, which has been shown to be inadequate for preventing memory safety bugs like out of bounds reads and writes.
Since the majority of serious vulnerabilities in large codebases can be attributed to memory safety failings, the common refrain over the past few years has been to develop in a programming language like Rust that (optionally) produces memory-safe code. And more recently there have been efforts to rewrite legacy code in critical libraries and applications using Rust.
There are many other memory-safe languages – such as C#, Java, Python, Swift, Go, and JavaScript. But Rust, for better or worse, has become the most commonly cited option in memory safety evangelism because it's fast, suited for low-level code, and does a lot of things well (safe concurrency and a well-conceived package management system). What's more, the non-profit Rust Foundation has been run well enough to attract funding and support from the tech firms likely to be interested in Rust's qualities.
Also, Rust came out of Mozilla, which isn't seen by the major tech platforms – several of which have their own home-grown programming languages – as a competitor. Consider that Rust debuted in late 2013 and Apple's Swift arrived a year later – during that period, Rust has attracted a broad constituency, while Swift is mainly used by Apple-aligned developers.
But the thing about Rust is that it's not all that easy to learn. So calls to rewrite everything in Rust have elicited pushback from those with significant C or C++ experience – like Linux kernel maintainers, who would prefer to continue working in languages they've mastered.
Like the forthcoming TrapC fork and the Safe C++ project, Fil-C aims to support memory safety without requiring reeducation in another programming language.
[...] Fil-C has some limitations. Presently, it only works on Linux/x86_64. Also, it's slow – about 1.5x-5x slower than legacy C. That's in part because of its implementation of a pointer encoding method for tracking bounds and types called MonoCaps, and also overhead from calling conventions and dynamic linking that differ from standard C.
"The plan to make Fil-C fast is to fix these issues," explains Pizlo. "I believe that fixing these issues can get Fil-C to be only 1.5x slower than C in the worst cases, with lots of programs being only 1.2x slower. But it'll take some focused compiler/runtime/GC hacking to get there."
[...] Pizlo observes in his presentation that while there have been substantially successful attempts to make C code memory-safe – such as CheckedC and -fbounds-safety – many of these fall short in one way or another, particularly for certain edge cases.
His goal, he says, is to support garbage in, and memory safety out.
"Part of the reason why I'm doing this is I want to obviate the need for Rust," declares Pizlo. "I'm not there yet performance-wise, but I will get there."
(Score: 1, Interesting) by DadaDoofy on Tuesday November 19, @08:18PM (16 children)
If you can't do it with C#, Swift or Java, it probably doesn't need doing. The rest are just needless distractions that fragment the pool of developers and make code more expensive to maintain.
(Score: 5, Insightful) by JoeMerchant on Tuesday November 19, @08:29PM
All depends on your scope...
We've got battery powered devices running ESP32 micros, they're not a great C#/Swift/Java target - I mean, I bet you _can_ run those languages there, but if you value performance, not just speed but also battery life, you'll probably get a significant bump in any project by switching to the existing C libraries.
I looked into migrating out of Qt/C++ to Qt/Python - it went pretty well, only lost about 2% speed throughout the UX development, but then I got to a tight loop computation that is nothing in C or C++, but runs 1000x slower in Python. Yeah, so that part needs to be written in C++ and imported as a dependency-hell library object. So, I'm still writing C++, in addition to Python, adding a whole extra layer of complexity to the overall build and project management, and I have gained what? Maybe I can turn over the Python part of the code base to somebody who is afraid of C++?
When the toolset around Rust matures to the level that C/C++ toolsets have (like when hell freezes over x6), then it should be an easy switch.
🌻🌻🌻 [google.com]
(Score: 3, Funny) by gawdonblue on Tuesday November 19, @08:35PM (4 children)
If you can't do it with Fortran or COBOL, it's not worth doing.
Kids these days.
(Score: 2) by turgid on Tuesday November 19, @09:37PM (3 children)
Real men program in FORTRAN and assembler (IBM360).
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Interesting) by JoeMerchant on Tuesday November 19, @11:37PM (2 children)
I had several jobs translating Fortran and Matlab code into "modern user facing" Qt/C++. Probably drew $500k in salary over the years on those kinds of jobs.
🌻🌻🌻 [google.com]
(Score: 0) by Anonymous Coward on Tuesday November 19, @11:49PM (1 child)
> Probably drew $500k in salary over the years on those kinds of jobs.
Just curious, was it closer to $100K/year for 5 years? or closer to $500K in one year??
(Score: 0) by Anonymous Coward on Wednesday November 20, @09:04PM
I knew a COBOL programmer who was getting $300 an hour back in 1998-9, and had more customers than he could handle.
I think that period pretty much set him up to retire whenever he felt like it.
(Score: 3, Touché) by Snotnose on Tuesday November 19, @11:03PM (5 children)
I have a register at 0xf0001342 and I need to set bit 4. Show me how to do that in Java.
Of course I'm against DEI. Donald, Eric, and Ivanka.
(Score: 3, Funny) by Anonymous Coward on Tuesday November 19, @11:52PM
> Show me how to do that in Java.
Lots of AI answers out there, they are, of course, looking forward to serving you!
(Score: 1, Redundant) by DannyB on Wednesday November 20, @06:02PM
If your problem domain involves thinking about bits in registers, then Java, C# and many other languages do not fit your problem domain.
If your problem domain is, say, designing a payroll system that must comply with Federal and man State regulations, forms, requirements, submission formats, and handle all sorts of payroll problems for different types of people and how they are paid, then a low level bit-manipulation language is not a good fit for that problem domain. In this case, a language which makes it IMPOSSIBLE to make a memory management or pointer error is a much better fit.
If there were one perfect programming language for all porpoises, we would all already be using it.
If a language is popular and widely used (like C, or like Java), then it MUST BE DOING SOMETHING RIGHT or so many people wouldn't be using it. It must be solving someone's real world problems in a beneficial way. Does that even make sense?
Some people need assistants to hire some assistance.
Other people need assistance to hire some assistants.
(Score: 0) by Anonymous Coward on Wednesday November 20, @09:10PM (2 children)
10 A=PEEK(0xf0001342)
20 A=A+8
30 POKE (0xf0001342,A)
(Score: 2) by Snotnose on Wednesday November 20, @10:28PM (1 child)
Nice try but no cigar. If the bit was already set then adding 8 not only clears the bit, but sets the next higher bit.
My question was rhetorical If you're bit banging you're probably in the embedded space. If you're in the embedded space Java's garbage collection is going to be a much bigger headache.
Of course I'm against DEI. Donald, Eric, and Ivanka.
(Score: 0) by Anonymous Coward on Thursday November 21, @08:57PM
:( I was trying for funny.
(Score: 0) by Anonymous Coward on Tuesday November 19, @11:56PM (2 children)
WTF? I can write real-time anything in those shit languages.
(Score: 0) by Anonymous Coward on Tuesday November 19, @11:59PM (1 child)
GD non-editable comments. I mean, "can't."
(Score: 2) by DadaDoofy on Wednesday November 20, @01:43AM
You seem to be implying real time solutions can't be written in languages that are memory safe. If that is the case, it's only a matter of time until new hardware makes that not the case.
For instance, United Audio had a whole line of hardware products that ran their audio plugins in order to surpass the internal processing capabilities of PCs at that time. Later, Apple's M processors obsoleted all that by matching, and then with later generations of their M processors, vastly exceeding that performance making that purpose-built hardware completely obsolete.
(Score: 2) by Freeman on Wednesday November 20, @02:55PM
Swift is below a heap of other languages. https://spectrum.ieee.org/top-programming-languages-2024 [ieee.org]
Ah, found the reason I'd barely even heard of it: https://en.wikipedia.org/wiki/Swift_(programming_language) [wikipedia.org]
I've yet to be suckered into that particular walled garden, besides having been given an iphone or two. Free is free.
Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"