Lisp, Algol 68, Pascal, Smalltalk, ML, all had both memory safety and type safety. Nobody uses it today. Why? Because software isn't developed by rational beings choosing the best tool for the job. It's developed by humans who are influenced by their cultural norms and environment. You can give someone a perfect programming language that produces bug-free programs, and they'll reject it because it uses curly-braces or some shit. Write all the papers you want; as long as the inmates are running the asylum, there is no safety.
pron 16 hours ago [-]
Algol 68 and Pascal weren't memory-safe, and as for Lisp, Smalltalk, and ML, their style of memory safety - based on GC - took over the world pretty much the second it became practical enough for widespread use.
It is true that some decisions people make aren't rational, and it may even be true that most decisions most people make aren't entirely rational, but the claim that the whole software market, which is under selective pressures, manages to make irrationally wrong decisions in a consistently biased way is quite extraordinary and highly unlikely. What is more likely is that the decisions are largely rational, just don't correspond to your preferences. It's like the VHS vs. Betamax story. Fans of the latter thought that the preference for the former was irrational because of the inferior picture quality, but VHS was superior in another respect - recording time - that mattered more to more people.
I was programming military applications in Ada in the nineties (also not memory-safe, BTW) and I can tell you we had very good reasons to switch to C++ at the time, even from a software correctness perspective (I'm not saying C++ still retains those particular advantages today).
If you think so many people who compete with each other make a decision you think is obviously irrational, it's likely that you're missing some information.
heresie-dabord 1 hours ago [-]
> What is more likely is that the decisions are largely rational, just don't correspond to your preferences.
Cyber Security itself is an example of this. It may seem rational to want guarantees of security for the entire supply chain. But that simply isn't possible in reality.
A professional effort is the judicious application of resources to the highest priorities. That includes care in design and testing. Applications built with C and C++ are running everywhere around the world, every minute of every day.
daymanstep 16 hours ago [-]
What were the reasons for switching from ADA to C++ if I may ask?
pron 16 hours ago [-]
The compiler was much faster, the tooling better, and it was easier to find knowledgeable programmers (we were spending quite a bit of time sifting through thick Ada reference manuals). Whatever correctness benefits Ada provided at the language level were more than made up for by C++'s productivity boosts (at the time) that allowed writing and running more tests and fixing bugs more quickly, resulting in code that was no less correct and easier to maintain and evolve to boot.
sramsay64 11 hours ago [-]
This was my experience of Ada as well. Beautiful language, that somehow seemed to combine the best parts of Haskell and C. But so difficult to find documentation online. C++ has it's footguns, but it's hard not to learn them all just from the background noise alone. The tooling and stackoverflow-ability makes C++ feel as fast to develop as a scripting language in comparison to Ada.
kelseyfrog 11 hours ago [-]
An enormous factor here is the cult of speed. This mantra — performance above all — has touched every generation of programmers. The zero-overhead zealots, the minimal-runtime purists, these camps are not only present, they are crowd out every other perspective. It's not that their arguments are entirely unfounded. Language choice does have a causal effect on application performance. The issue is that these voices drown out all others.
The root of the problem is measurement. Speed is one of the few dimensions of software that is trivially quantifiable, so it becomes the yardstick for everything. This is textbook McNamara Fallacy[1]: what is easy to measure becomes what is measured, and what is not easily measured is erased from the calculus. See developer velocity, cognitive overhead, maintainability, and joy. It's the same fallacy that McNamara made in Vietnam and Rumsfield made in the War on Terror so at least they're in good company.
This singular focus distorts decisions around language choice, especially among the inexperienced, who haven't yet learned to recognize trade-offs or to value the intangibles software process. Like you said, humans are irrational, but this is one particularly spectacular dimension of that irrationality.
> performance above all — has touched every generation of programmers
I find it hard to reconcile this with the actual observed trend of all software getting slower and more memory intensive over time
sevensor 4 hours ago [-]
My observation from internal C projects I’ve worked with is that they often end up doing the wrong thing very fast, because the right thing is so hard to express in C. If you do the wrong thing ten million times, it can start to approximate the right thing. The best of all worlds is using a low level language for speed and a high level language for dealing with complexity. I very much doubt there’s one right language for everything.
kelseyfrog 10 hours ago [-]
You can simply scroll down in this very comments section to find folks arguing about the performance characteristics of various languages in the context of making claims about their benefits. Res ipsa loquitur
eviks 10 hours ago [-]
That's simple indeed, but also simply wrong. Reality of actually written apps is a way more important factor than such comments, and in that reality the cult of performance is tiny, not crowding out everything else
mittensc 9 hours ago [-]
> An enormous factor here is the cult of speed.
Application performance is a very important factor. To ignore it is foolish.
kelseyfrog 15 minutes ago [-]
Help me understand how this went from "There are factors other than speed that are important too" to "ignore speed." Would different phrasing conveyed the idea more effectively?
burnt-resistor 15 hours ago [-]
Pascal has subrange integer types. I'm wondering if any other language besides family relatives Ada or Delphi has this, apart from dependent type systems like Idris[0] or an explicit Haskell type like Data.Range.[1]
rust has this to some extent (also enums can be seen as an evolution of this for some use cases)
1vuio0pswjnm7 12 hours ago [-]
"You can give someone a perfect programming language that produces bug-free programs, and they'll reject it because it uses curly-braces or some shit."
Ada does not have curly braces.
Stephen Bourne, author of the Bourne shell, used macros to make C memory unsafe language look like Algo 68 memory safe language.
ksec 16 hours ago [-]
I am the only one on HN that brings up Ada because I think it deserve some credit. But then it seems there are a lot of hate towards Pascal style syntax.
johnisgood 2 hours ago [-]
I bring it up all the time. :P
steveklabnik 13 hours ago [-]
"table stakes" does not mean "guaranteed to succeed," so it's no surprise that some memory safe languages have died.
nick_ 19 hours ago [-]
If Rust is the language that finally overwhelms the resistance to memory safe languages, that's good.
I think it's also important not to centre Rust alone. In the larger picture, Rust has a combo of A) good timing, and B) the best evangelism. It stands on decades of memory safe language & runtime development, as well as the efforts of their many advocates.
jandrewrogers 18 hours ago [-]
This statement seems imprecise. We've had memory-safe languages for decades and they are the primary programming languages used today e.g. Java and Python. There is no meaningful resistance to them.
If you look at what unsafe languages are used for, it mostly falls into two camps (ignoring embedded). You have legacy code e.g. browsers, UNIX utilities, etc which are too expensive to rewrite except on an opportunistic basis even though they could be in principle. You have new high-performance data infrastructure e.g. database kernels, performance-engineered algorithms, etc where there are still significant performance and architectural advantages to using languages like C++ that are not negotiable, again for economic reasons.
Most of the "resistance" is economic reality impinging on wishful thinking. We still don't have a practical off-ramp for a lot of memory-unsafe code. To the extent a lot of evangelism targets these cases it isn't helpful. It is like telling people living in the American suburbs that they should sell their cars and take the bus instead.
HideousKojima 18 hours ago [-]
[flagged]
odyssey7 16 hours ago [-]
I don’t buy the economic argument favoring memory-unsafe languages. There are fast memory-safe options. Legacy codebases can eventually become more expensive to maintain than to rewrite. What is the economic cost of an Achilles’ heel when critical systems are destroyed?
There are critical systems today that are essentially Prince Rupert’s drops. Mightily impressive, but with catastrophic weaknesses in the details.
tptacek 19 hours ago [-]
I think it's important to keep the scope of the debate well-defined, because memory-safe languages completely stomped out memory-unsafe languages more than 20 years ago; almost all new code is written in languages that are unshowily memory safe (like Java and Python).
We're really talking about resistance to memory safety in the last redoubts of unsafety: browsers and operating systems.
olarm 18 hours ago [-]
> We're really talking about resistance to memory safety in the last redoubts of unsafety: browsers and operating systems.
And control systems, c++ (along with PLCs ofcourse) dominates in my experience from developing maritime software and there doesnt appear to be much inclination towards change.
tuveson 18 hours ago [-]
> browsers and operating systems
And the VMs for the two languages that you mentioned above (edit: though to be fair to your comment, I suppose those were initially written 20+ years ago).
zahlman 18 hours ago [-]
To be fair, there's a pretty clear difference between achieving memory safety with a garbage collector and run-time type information, versus achieving it through static analysis.
fiddlerwoaroof 15 hours ago [-]
Static analysis is worse and limits the programs you can write in annoying ways?
zahlman 9 hours ago [-]
I like dynamic typing, but the point wasn't about holy warring. The point is simply that it's different.
chubot 17 hours ago [-]
There’s also google, yandex, baidu, and bing, which are incredible amounts of c++ code
And probably lots of robotics, defense, and other industries
Granted, those aren’t consumer problems, but I would push back on the “last redoubts”.
We should absolutely move toward memory safe languages, but I also think there are still things to be tried and learned
npalli 16 hours ago [-]
> We're really talking about resistance to memory safety in the last redoubts of unsafety: browsers and operating systems.
.. and other performance critical areas like Financial applications (HFT), High Performance Computing (incl. AI/ML), embedded, IoT, Gaming/Engines, Databases, Compilers etc.. Browsers and OS are highly visible, but there is a gigantic ton of new C++ code written everyday in spite of the availability of memory safe languages.
tptacek 15 hours ago [-]
People keep coming up with all these examples of things still written in C/C++. Sure. So are most AAA games. But so far nothing that's been identified --- maybe excepting databases, but vulnerabilities there are still rare --- that is a meaningful component of insecurity, which is what "memory safety" addresses.
spacechild1 13 hours ago [-]
> that is a meaningful component of insecurity, which is what "memory safety" addresses.
There are plenty of people, though, who argue that everything must be memory safe (and therefore rewritten in Rust :) I personally don't agree with that sentiment and it seems like you don't agree either.
tptacek 11 hours ago [-]
It would be better for everyone if everything on a forwardgoing basis was written in a memory-safe language.
spacechild1 10 hours ago [-]
What difference does it make for a video editor or DAW?
adgjlsfhk1 9 hours ago [-]
iphones have already CVEs from memory safety issued in image formats. is entirely plausible that a similar issue could exist in video or audio codecs
Was a fascinating detective story to illustrate it.
noelwelsh 19 hours ago [-]
Rust also didn't give up, whereas earlier languages like Cyclone did. This is a problem with the different incentives in research; once you've shown it works there is no funding for further development.
jekwoooooe 17 hours ago [-]
Go is fast and memory safe. It has some data race protections built in but doesn’t go as far as rust. This has its benefits like not having to deal with borrow checker insanity (or rust syntax for that matter)
Unlike python or java, it’s both compiled and fast
haimez 17 hours ago [-]
Java is both compiled (first to bytecode, then to machine code by the JIT) and fast (once JIT compiled).
jandrewrogers 13 hours ago [-]
It depends on what you are using it for, “fast” is relative. Java can be fast for applications where performance and scalability are not a primary features. If performance and scalability are core objectives, even performance-engineered Java isn’t really competitive with a systems language. You can bend Java to make it perform better than most people believe, especially today, but the gap is still pretty large in practice.
I wrote performance-engineered Java for years. Even getting it to within 2x worse than performance-engineered C++ took heroic efforts and ugly Java code.
Raidion 16 hours ago [-]
Java is "fast" but not fast. Most of the time if performance is a true concern, you are not writing code in Java.
frollogaston 16 hours ago [-]
I have yet to run a Java program that I haven't had to later kill due to RAM exhaustion. I don't know why. Yeah an Integer takes 160 bits and that's without the JVM overhead, but still. Somehow it feels like Java uses even more memory than Python. Logically you'd point the finger at whoever wrote the software rather than the language/runtime itself, but somehow it's always Java. It's like the Prius of languages.
Ok, just glanced at my corp workstation and some Java build analysis server is using 25GB RES, 50GB VIRT when I have no builds going. The hell is it doing.
cherrycherry98 11 hours ago [-]
GC usually only runs when the process wants to allocate an object but there's no space left on the heap. It's entirely possible that it did a bunch of work previously which created a bunch of garbage now waiting to be cleaned up. See the G1PeriodicGCInterval flag to enable idle collections (assuming G1).
Java is also fairly greedy with memory by default. It likes to grow the heap and then hold onto that memory unless 70% of the heap is free after a collection. The ratios used to grow and shrink the heap can be tuned with MinHeapFreeRatio and MaxHeapFreeRatio.
andreasmetsala 4 hours ago [-]
Why do Java developers still have to tune stuff like that?
lmm 13 hours ago [-]
> Ok, just glanced at my corp workstation and some Java build analysis server is using 25GB RES, 50GB VIRT when I have no builds going. The hell is it doing.
Allocating a heap of the size it was configured to use, probably.
frollogaston 12 hours ago [-]
That's a max size, not a preset allocation. The process normally starts out using 1GB.
lmm 11 hours ago [-]
Sure, but if it's had to use a lot at some point in the past it usually holds onto it.
frollogaston 10 hours ago [-]
That would explain it, but also, that's super broken
noelwelsh 9 hours ago [-]
Nothing broken about it. It's optimized for a particular situation, that situation being a long running process on a server. This is where the JVM typically runs. If you don't want that behaviour there are a myriad of GC options, which could be better documented but are not that hard to find.
lmm 10 hours ago [-]
It's not a big issue for a server deployment where if you got that memory from the OS and didn't get killed, there's probably nothing else running on the box and you might as well keep it for the next traffic spike. But yeah not ideal on the desktop/workstation.
adgjlsfhk1 9 hours ago [-]
don't slander the Prius! it's an incredibly efficient and robust machine. Java is a Chevy Colerado. surprisingly common for how unreliable it is
AlotOfReading 15 hours ago [-]
More of a historical footnote than a serious example, but you've never had to kill the Java applications running on your SIM card (or eSIM).
frollogaston 15 hours ago [-]
I don't know about that, my flip phone used to crash quite often. And it displayed a lot of Java logos.
AlotOfReading 15 hours ago [-]
Different processor and JVM. My understanding is that early versions of the Java card runtime didn't even support garbage collection. It was a very different environment to program, even if the language was "Java".
lmm 13 hours ago [-]
Java is fast for long-running server processes. Even HFT shops competing for milliseconds use it. But yeah every user-facing interactive Java application manages to feel clunky.
symbolicAGI 12 hours ago [-]
Learned from an NYC exchange 10 years ago that Java can be written so as to not use garbage collection. Fast and no pause for GC.
1. Resource and reuse objects that otherwise are garbage collected. Use `new` sparingly.
2. Avoid Java idioms that create garbage, e.g. for (String s : strings) {...},
substitute with (int i = 0, strings_len = strings.length(), i < strings_len) {
String s = strings[i]; ...}
b0a04gl 19 hours ago [-]
c/c++ you're in unsafe mode by default, unless you build guardrails yourself. rust built different: unsafe is loud, compiler flags it, tooling keeps count, you can gate it in ci. bugs don’t slip in quiet.. burden of proof shifts
Animats 12 hours ago [-]
"Omniglot" is a rather dramatic title for something that's basically a way to call C from Rust with additional checking on the C side for type compatibility.
That said, it might be useful. The demo case is contrived, though.
Passing Rust async semantics into C code is inherently iffy.
I'd like to see something like OpenJPEG (a JPEG 2000 encoder written in C) safely encapsulated in this way.
Oddly I see a lot of marketing for Rust. Not gonna make it a success, sorry. No one cares about Rust lol. It's specialized. It has a value and a place, but it isn't a mainstream thing unfortunately.
spoiler 2 hours ago [-]
What gives you the impression it won't be mainstream at some point? Its adoption seems to be on steady but slow rise.
Also I think there's other great things about Rust other than _just_ memory safety
taping-memory 17 hours ago [-]
I'm reading the article and so far it's great.
I'm just wondering in the explanation of listing 2 you say:
> a discriminant value indicating the enum’s active variant (4 bytes)
It doesn't change any of the conclusions, I'm just curious
OptionOfT 16 hours ago [-]
Using repr(C) makes it 4 bytes.
But then again, modeling a C enum to a Rust enum is bad design. You want to use const in Rust and match against those.
But it is a bad example in general, because the author passes on a pointer of a string slice to FFI without first converting it to a CString, so it isn't null terminated.
taping-memory 15 hours ago [-]
> Using repr(C) makes it 4 bytes.
That makes sense, they just don't use repr(C) for the PrintResult so I didn't consider that.
> But then again, modeling a C enum to a Rust enum is bad design. You want to use const in Rust and match against those.
That makes sense but if there could be a way to safely generate code that converts to an enum safely as proposed in the article that would be good as the enum is more idiomatic.
> But it is a bad example in general, because the author passes on a pointer of a string slice to FFI without first converting it to a CString, so it isn't null terminated.
The signature for async_print in C is `async_res_t async_print(const *uint8_t, size_t)` and they are passing a pointer to a &[u8] created from a byte string literal, so I think it's correct.
halis 7 hours ago [-]
Rust is starting to feel like those people calling about your car’s extended warranty.
djha-skin 16 hours ago [-]
Nope: ease of use is table stakes. Rust is not easy to use. It will never become mainstream because of this. For all its faults, C is comparatively simple.
another_twist 14 hours ago [-]
I actually think rust is very very easy to use to the point where I'd consider using it for scripting. They need to write out more detailed guides on how to do X with Rust though. e.g there's no runtime polymorphism in Rust since every trait + struct binding is unique. However, it similar behaviour can be accomplished by generics hence so many angular brackets in normal Rust code.
TylerE 13 hours ago [-]
I find attitudes like this simply bizzare. nothing about rust is 'easy' no matter how much it's fans insist it so.
Just the syntax is miserable punctuation soup to start with.
0x1ceb00da 11 hours ago [-]
Not saying rust is easy, but syntax wouldn't even be in the top 5 if I had to list things that make rust difficult.
justinrubek 5 hours ago [-]
It always amazes me what things people will latch on to. There are many valid criticisms to be had, but those aren't the focus points of the debates.
Measter 3 hours ago [-]
But many of those valid criticisms require some familiarity with the language. With syntax they can just point at it and claim it's bad without having to learn anything first.
another_twist 7 hours ago [-]
I mean I have worked with c++, Python, JS/TS, Java and Scala. The syntax of Rust is a mix of these. Apart from that, borrowing, some pointer work and you're set. Honestly Copilot is pretty good at generating code that you can pick up the patterns from. I would highly recommend you give it a try. Not a fan though, for any large project Rust wont be my first choice because of lack of proper libraries and Java is performant enough almost all the time.
They are in particular careful to never state that bindgen emits the wrong code. Maybe they could have said that bindgen in fact does handle this case correctly. But Omniglot seems to be doing a lot more than bindgen, and
IshKebab 18 hours ago [-]
Well... he does have a point. Don't demonstrate your great tool with an issue that the existing solution doesn't actually have.
ARob109 16 hours ago [-]
Learning Rust ATM and using bindgen on a C header. Just looked and it generates Rust enums from C enums. I'm not sure what the default behavior of bindgen is, but it seems there is option for constifying enums
--constified-enum <REGEX>
Mark any enum whose name matches REGEX as a series of constants
--constified-enum-module <REGEX>
Mark any enum whose name matches REGEX as a module of constants
IMO, saying bindgen avoids the issue presented in the article is not accurate.
I used to work on an old C project where everyone knew there were memory issues, but no one wanted to touch it. Rewriting was too expensive, so we just used tools to keep it running.
Now most new projects go with Rust. Memory safety feels like the default, but it's going to take time for the old stuff to catch up.
marsven_422 20 hours ago [-]
[dead]
userbinator 14 hours ago [-]
[flagged]
timewizard 20 hours ago [-]
> if it compiles, then it’s correct … or at least, will not contain use-after-free or other memory safety errors
In a language with the `unsafe` construct and effectively no automated tooling to audit the uses of it. You have no guarantee of any significance. You've just slightly changed where the security boundary _might_ lie.
> There is a great amount of software already written in other languages.
Yea. And development of those languages is on going. C++ has improved the memory safety picture quite a bit of the past decade and shows no signs of slowing down. There is no "one size fits all" solution here.
Finally, if memory safety were truly "table stakes" then we would have been using the dozens of memory safe languages that already existed. It should be blindingly obvious that /performance/ is table stakes.
AlotOfReading 19 hours ago [-]
In a language with the `unsafe` construct and effectively no automated tooling to audit the uses of it.
Cargo allows you to apply rustc lints to the entire project, albeit not dependencies (currently). If you want dependencies you need something like cargo-geiger instead. If you find unsafe that way, you can report it to the rust safety dance people, who work with the community to eliminate unsafe in crates.
All of this is worlds ahead of the situation in C++.
vlovich123 19 hours ago [-]
OP is wrong that there's no tooling. All the C++ tooling that I'm aware of (e.g. ASAN/UBSAN/MSAN/TSAN) is still available on Rust. Additionally, it has MIRI which can check certain code constructs for defined behavior at the MIR level which, unlike sanitizers, validates that all code is sound according to language rules regardless of what would be run by generated assembly; this validation includes unsafe code which still has to follow the language rules. C/C++ doesn't have anything like that for undefined behavior by the way.
However, if I can apply a nitpicking attitude here that you're applying to their argument about the ease with which unsafe can be kept out of a complex codebase. unsafe is pretty baked into the language because there's either simply convenient constructs that the Rust compiler can't ever prove safely (e.g. doubly-linked list), can't prove safely today (e.g. various accessors like split), or is required for basic operations (e.g. allocating memory). Pretending like you can really forbid unsafe code wholesale in your dependency chain is not practical & this is ignoring soundness bugs within the compiler itself. That doesn't detract from the inherent advantage of safe by default.
AlotOfReading 18 hours ago [-]
I do safety critical code. I would consider banning allocation (e.g. just using Core) or avoiding certain data structures a completely feasible strategy to avoid unsafe if I wanted to exclude it from my safety model. It's what I'm already doing in C++. The difference is that in C++, I can never prove the absence of undefined behavior from any part of the codebase, even if I review every single line. Even if I could, that proof might be invalidated by a single change anywhere.
It's not easy in Rust, but it's possible.
zaphar 19 hours ago [-]
Languages with unsafe don't just change where the security boundary lies. It shrinks the size of the area that the boundary surrounds.
C++ has artificially limited how much it can improve the memory safety picture because of their quite valid dedication to backwards compatibility. This is a totally valid choice on their part but it does mean that C++ is largely out of the running for the kinds of table stakes memory safety stuff the article talks about.
There are dozens of memory safe languages that already exist: Java, Go, Python, C#, Rust, ... And a whole host of other ones I'm not going to bother listing here.
torstenvl 19 hours ago [-]
[flagged]
zahlman 17 hours ago [-]
> Most of them have a single implementation.
None of them have a single implementation. It only took a few minutes to find all the following:
* C# has Mono, which actually implements the entire .NET framework
* Rust has Rust-GCC and gccrs
johnfernow 18 hours ago [-]
The Java language specification is open and there are multiple implementations. OpenJDK is the official open-source reference implementation, and many of the alternative implementations pull from upstream, but OpenJ9 is a different JVM implementation (though does currently use OpenJDK's class libraries to form a complete JDK.)
Before Microsoft opened-up C#, Mono was a completely independent alternative implementation.
Python has CPython (reference open source implementation), but also PyPy, MicroPython and several others.
torstenvl 18 hours ago [-]
I'm not sure what you mean when you say the Java spec is open, but Oracle certainly took the position—and the Supreme Court confirmed—that they own copyright in the APIs.
Has Oracle dedicated those to the public domain in the meantime? Or at least licensed them extremely permissively?
More importantly, is there a public body that owns the spec?
Kranar 17 hours ago [-]
>the Supreme Court confirmed—that they own copyright in the APIs.
To use your own terminology, this is clearly and objectively false. The US Supreme Court made no such finding.
What the court concluded was that even if Oracle had a copyright on the API, Google's use of it fell under fair use so that making a ruling on the question of whether the API was protected by copyright was moot.
torstenvl 15 hours ago [-]
Your point of order is partially accurate. It was the Federal Circuit that held APIs copyrightable. SCOTUS did not disturb that holding, but did not explicitly affirm it either. However, your contention that this makes copyrightability moot is a stretch.
jcranmer 15 hours ago [-]
The majority opinion in Google v Oracle did an involved fair use analysis for the reimplementation of the API that really makes it clear that it's hard for anybody to violate the copyright of an API by doing a clean-room implementation and not have it be covered by fair use.
But who cares if there's a public body who owns the specification? The Supreme Court ruled Google's use of the copyrighted APIs fell within fair use. That gives, within the US (other countries will have other legal circumstances) a basis for anyone to copy pretty much any language so long as they steer clear of the actual copyrighted source code (don't copy MS's C# source code, for instance) and trademark violations.
torstenvl 15 hours ago [-]
[flagged]
Jtsummers 15 hours ago [-]
> I don't understand your thought process.
You claim to be a lawyer, I doubt your reading comprehension is really this bad but just in case I'll spell it out for you. You asked:
> More importantly, is there a public body that owns the spec?
Anyone can implement a compiler or interpreter for C# if they want, and there is a link to the standard for it. Is this clear enough for you?
Also, from an earlier comment you made a false claim and a strange reference.
You claimed that "most of" Java, Rust, C#, Python, and Go have only a single implementation. This is false. There are multiple implementations of each.
Second, you make a bizarre reference to "fad[ing] away like Pascal." Why do you think Pascal faded? I'll give a hint: It had nothing to do with being proprietary. At best that reference is a non sequitur, at worst it demonstrates more confusion on your part.
torstenvl 11 hours ago [-]
It isn't my reading comprehension that is deficient. You are talking in circles and demonstrating a remarkable inability to think clearly. I was just being polite.
Something being proprietary means that it is owned. It means "relating to an owner or ownership"; "of, relating to, or characteristic of an owner or title holder"; "used, made, or marketed by one having the exclusive legal right"; "privately owned and managed and run as a profit-making organization."
15 hours ago [-]
umanwizard 18 hours ago [-]
What does “proprietary” mean to you?
torstenvl 18 hours ago [-]
It doesn't mean anything "to me." Its meaning is clear and objective and applies to every language listed above.
umanwizard 18 hours ago [-]
Okay, please explain in what sense Python or Rust is proprietary.
torstenvl 18 hours ago [-]
In all senses. They are both 100% proprietary. There is no sense in which either language is anything other than proprietary.
It is literally illegal for me to start marketing The TorstenVL Rust Compiler. Because the language is proprietary.
ben0x539 18 hours ago [-]
All of these have implementations available under free software licenses so they are clearly and objectively not proprietary.
Trademarks are annoying but I can hardly imagine they're what anyone is worried about when picking a language in this context, they're not what's going to cause a language to disappear.
torstenvl 18 hours ago [-]
That's completely nonsensical.
zahlman 17 hours ago [-]
No; that's what the word "proprietary" means as applied to software.
anonymars 17 hours ago [-]
Care to elaborate?
SpaceNugget 18 hours ago [-]
A trademark on the word "Rust" has nothing to do with whether the language itself is proprietary. Clearly and Objectively.
What you can call something and whether you can legally make the thing or have a permissive license to an existing implementation are two completely unrelated things.
For example, you also can't make a C compiler and name it the "microsoft C compiler" due to your lack of trademark right. Does that mean C is also proprietary?
If you still aren't convinced, you are definitely using a different definition of the word proprietary than everyone else.
zahlman 17 hours ago [-]
Wikipedia tells me:
> Proprietary software is software that grants its creator, publisher, or other rightsholder or rightsholder partner a legal monopoly by modern copyright and intellectual property law to exclude the recipient from freely sharing the software or modifying it, and—in some cases, as is the case with some patent-encumbered and EULA-bound software—from making use of the software on their own, thereby restricting their freedoms.[1]
> Proprietary software is a subset of non-free software, a term defined in contrast to free and open-source software; non-commercial licenses such as CC BY-NC are not deemed proprietary, but are non-free. Proprietary software may either be closed-source software or source-available software.[1][2]
The Python development team, via the LICENSE file in the GitHub repository, tells me
> All Python releases are Open Source (see https://opensource.org for
the Open Source Definition). Historically, most, but not all, Python
releases have also been GPL-compatible; the table below summarizes
the various releases.
In what sense is FOSS software a kind of non-FOSS software?
18 hours ago [-]
eimrine 11 hours ago [-]
Rust implementations are owned by some megacorps, exactly as Java. Compare with C which is not owned by anyone.
umanwizard 10 hours ago [-]
That’s not true. The only rust implementation with a significant number of users is rustc which is Apache licensed and owned by the Rust foundation.
11 hours ago [-]
SpaceNugget 18 hours ago [-]
[flagged]
jazzyjackson 17 hours ago [-]
I just checked merriam webster, "something that is used, produced, or marketed under exclusive legal right of the inventor or maker"
exclusive legal right = not permissively licensed. it's really not a matter of jargon.
EDIT: nvm parent is confused and thinks trademarks are the same as nonfree.
xvedejas 19 hours ago [-]
Safe rust is a safe language. Yes, it is built upon unsafe rust. But I still consider Python to be a memory safe language despite it being built on C. I can still trust that my Python code doesn't contain such memory errors. Safe Rust is the same in terms of guarantees. That's all that anyone is claiming.
burnt-resistor 15 hours ago [-]
The main problem now is that there isn't a platform that has the tooling or infrastructure to prove, including through formal methods, that they are correct and free from bugs in the spirit of the seL4 project.
UltraSane 17 hours ago [-]
It is a lot like how you have to trust the core proving kernel in a theorem prover but if you do then you can trust every proof created using it.
> It should be blindingly obvious that /performance/ is table stakes.
Nah, there's a famous WG21 (the C++ committee) paper named "ABI: Now or Never" which lays out just some of the ever growing performance cost of choices the committee has made to preserve ABI and explains that if this cost is to be considered a price paid for something the committee needs to pick "Never" and if they instead want to stop paying the price they need to pick "Now" and, if as the author suspects, they don't actually care, they should pick neither and C++ should be considered obsolete.
The committee, of course, picked neither, and lots of people who were there have since defended this claiming that this was a false dilemma - they were actually cleverly picking "Later" which that author didn't offer. Each time they've repeated this more time has passed yet they're still no closer to this "Later" ...
imglorp 19 hours ago [-]
That's an extreme take now and maybe uncharitable. The safe parts of rust are simply no comparison to the whole c/c++ world: the tooling is eliminating vast swaths of "easy" errors. Unsafe parts might be comparable if they're calling the same libraries.
It is true that some decisions people make aren't rational, and it may even be true that most decisions most people make aren't entirely rational, but the claim that the whole software market, which is under selective pressures, manages to make irrationally wrong decisions in a consistently biased way is quite extraordinary and highly unlikely. What is more likely is that the decisions are largely rational, just don't correspond to your preferences. It's like the VHS vs. Betamax story. Fans of the latter thought that the preference for the former was irrational because of the inferior picture quality, but VHS was superior in another respect - recording time - that mattered more to more people.
I was programming military applications in Ada in the nineties (also not memory-safe, BTW) and I can tell you we had very good reasons to switch to C++ at the time, even from a software correctness perspective (I'm not saying C++ still retains those particular advantages today).
If you think so many people who compete with each other make a decision you think is obviously irrational, it's likely that you're missing some information.
Cyber Security itself is an example of this. It may seem rational to want guarantees of security for the entire supply chain. But that simply isn't possible in reality.
A professional effort is the judicious application of resources to the highest priorities. That includes care in design and testing. Applications built with C and C++ are running everywhere around the world, every minute of every day.
The root of the problem is measurement. Speed is one of the few dimensions of software that is trivially quantifiable, so it becomes the yardstick for everything. This is textbook McNamara Fallacy[1]: what is easy to measure becomes what is measured, and what is not easily measured is erased from the calculus. See developer velocity, cognitive overhead, maintainability, and joy. It's the same fallacy that McNamara made in Vietnam and Rumsfield made in the War on Terror so at least they're in good company.
This singular focus distorts decisions around language choice, especially among the inexperienced, who haven't yet learned to recognize trade-offs or to value the intangibles software process. Like you said, humans are irrational, but this is one particularly spectacular dimension of that irrationality.
1. https://en.wikipedia.org/wiki/McNamara_fallacy
I find it hard to reconcile this with the actual observed trend of all software getting slower and more memory intensive over time
Application performance is a very important factor. To ignore it is foolish.
0. https://stackoverflow.com/questions/28426191/how-to-specify-...
1. https://hackage.haskell.org/package/range-0.3.0.2/docs/Data-...
Ada does not have curly braces.
Stephen Bourne, author of the Bourne shell, used macros to make C memory unsafe language look like Algo 68 memory safe language.
I think it's also important not to centre Rust alone. In the larger picture, Rust has a combo of A) good timing, and B) the best evangelism. It stands on decades of memory safe language & runtime development, as well as the efforts of their many advocates.
If you look at what unsafe languages are used for, it mostly falls into two camps (ignoring embedded). You have legacy code e.g. browsers, UNIX utilities, etc which are too expensive to rewrite except on an opportunistic basis even though they could be in principle. You have new high-performance data infrastructure e.g. database kernels, performance-engineered algorithms, etc where there are still significant performance and architectural advantages to using languages like C++ that are not negotiable, again for economic reasons.
Most of the "resistance" is economic reality impinging on wishful thinking. We still don't have a practical off-ramp for a lot of memory-unsafe code. To the extent a lot of evangelism targets these cases it isn't helpful. It is like telling people living in the American suburbs that they should sell their cars and take the bus instead.
There are critical systems today that are essentially Prince Rupert’s drops. Mightily impressive, but with catastrophic weaknesses in the details.
We're really talking about resistance to memory safety in the last redoubts of unsafety: browsers and operating systems.
And control systems, c++ (along with PLCs ofcourse) dominates in my experience from developing maritime software and there doesnt appear to be much inclination towards change.
And the VMs for the two languages that you mentioned above (edit: though to be fair to your comment, I suppose those were initially written 20+ years ago).
And probably lots of robotics, defense, and other industries
Granted, those aren’t consumer problems, but I would push back on the “last redoubts”.
We should absolutely move toward memory safe languages, but I also think there are still things to be tried and learned
.. and other performance critical areas like Financial applications (HFT), High Performance Computing (incl. AI/ML), embedded, IoT, Gaming/Engines, Databases, Compilers etc.. Browsers and OS are highly visible, but there is a gigantic ton of new C++ code written everyday in spite of the availability of memory safe languages.
There are plenty of people, though, who argue that everything must be memory safe (and therefore rewritten in Rust :) I personally don't agree with that sentiment and it seems like you don't agree either.
Was a fascinating detective story to illustrate it.
Unlike python or java, it’s both compiled and fast
I wrote performance-engineered Java for years. Even getting it to within 2x worse than performance-engineered C++ took heroic efforts and ugly Java code.
Ok, just glanced at my corp workstation and some Java build analysis server is using 25GB RES, 50GB VIRT when I have no builds going. The hell is it doing.
Java is also fairly greedy with memory by default. It likes to grow the heap and then hold onto that memory unless 70% of the heap is free after a collection. The ratios used to grow and shrink the heap can be tuned with MinHeapFreeRatio and MaxHeapFreeRatio.
Allocating a heap of the size it was configured to use, probably.
1. Resource and reuse objects that otherwise are garbage collected. Use `new` sparingly.
2. Avoid Java idioms that create garbage, e.g. for (String s : strings) {...}, substitute with (int i = 0, strings_len = strings.length(), i < strings_len) { String s = strings[i]; ...}
That said, it might be useful. The demo case is contrived, though. Passing Rust async semantics into C code is inherently iffy. I'd like to see something like OpenJPEG (a JPEG 2000 encoder written in C) safely encapsulated in this way.
Also I think there's other great things about Rust other than _just_ memory safety
I'm just wondering in the explanation of listing 2 you say:
> a discriminant value indicating the enum’s active variant (4 bytes)
As far as I can find, there's no guarantee for that, the only thing I can find is that it might be interpreted as an `isize` value but the compiler is permitted to use smaller values: https://doc.rust-lang.org/reference/items/enumerations.html#...
Is there any reason to say it should be 4 bytes?
It doesn't change any of the conclusions, I'm just curious
But then again, modeling a C enum to a Rust enum is bad design. You want to use const in Rust and match against those.
But it is a bad example in general, because the author passes on a pointer of a string slice to FFI without first converting it to a CString, so it isn't null terminated.
That makes sense, they just don't use repr(C) for the PrintResult so I didn't consider that.
> But then again, modeling a C enum to a Rust enum is bad design. You want to use const in Rust and match against those.
That makes sense but if there could be a way to safely generate code that converts to an enum safely as proposed in the article that would be good as the enum is more idiomatic.
> But it is a bad example in general, because the author passes on a pointer of a string slice to FFI without first converting it to a CString, so it isn't null terminated.
The signature for async_print in C is `async_res_t async_print(const *uint8_t, size_t)` and they are passing a pointer to a &[u8] created from a byte string literal, so I think it's correct.
Just the syntax is miserable punctuation soup to start with.
Please don't do this, thanks!
They are in particular careful to never state that bindgen emits the wrong code. Maybe they could have said that bindgen in fact does handle this case correctly. But Omniglot seems to be doing a lot more than bindgen, and
--constified-enum <REGEX> Mark any enum whose name matches REGEX as a series of constants
--constified-enum-module <REGEX> Mark any enum whose name matches REGEX as a module of constants
IMO, saying bindgen avoids the issue presented in the article is not accurate.
edit: formatting
You can force it to generate Rust enums, but it doesn't by default.
The referenced footnote, [9], leads to: https://www.usenix.org/conference/osdi25/presentation/schuer...
In a language with the `unsafe` construct and effectively no automated tooling to audit the uses of it. You have no guarantee of any significance. You've just slightly changed where the security boundary _might_ lie.
> There is a great amount of software already written in other languages.
Yea. And development of those languages is on going. C++ has improved the memory safety picture quite a bit of the past decade and shows no signs of slowing down. There is no "one size fits all" solution here.
Finally, if memory safety were truly "table stakes" then we would have been using the dozens of memory safe languages that already existed. It should be blindingly obvious that /performance/ is table stakes.
Cargo allows you to apply rustc lints to the entire project, albeit not dependencies (currently). If you want dependencies you need something like cargo-geiger instead. If you find unsafe that way, you can report it to the rust safety dance people, who work with the community to eliminate unsafe in crates.
All of this is worlds ahead of the situation in C++.
However, if I can apply a nitpicking attitude here that you're applying to their argument about the ease with which unsafe can be kept out of a complex codebase. unsafe is pretty baked into the language because there's either simply convenient constructs that the Rust compiler can't ever prove safely (e.g. doubly-linked list), can't prove safely today (e.g. various accessors like split), or is required for basic operations (e.g. allocating memory). Pretending like you can really forbid unsafe code wholesale in your dependency chain is not practical & this is ignoring soundness bugs within the compiler itself. That doesn't detract from the inherent advantage of safe by default.
It's not easy in Rust, but it's possible.
C++ has artificially limited how much it can improve the memory safety picture because of their quite valid dedication to backwards compatibility. This is a totally valid choice on their part but it does mean that C++ is largely out of the running for the kinds of table stakes memory safety stuff the article talks about.
There are dozens of memory safe languages that already exist: Java, Go, Python, C#, Rust, ... And a whole host of other ones I'm not going to bother listing here.
None of them have a single implementation. It only took a few minutes to find all the following:
* https://en.wikipedia.org/wiki/Free_Java_implementations
* Go has gofrontend and GopherJS aside from the reference implementation
* Python has a whole slew of alternate implementations listed on the main Python web site: https://www.python.org/download/alternatives/
* C# has Mono, which actually implements the entire .NET framework
* Rust has Rust-GCC and gccrs
Before Microsoft opened-up C#, Mono was a completely independent alternative implementation.
Python has CPython (reference open source implementation), but also PyPy, MicroPython and several others.
Has Oracle dedicated those to the public domain in the meantime? Or at least licensed them extremely permissively?
More importantly, is there a public body that owns the spec?
To use your own terminology, this is clearly and objectively false. The US Supreme Court made no such finding.
What the court concluded was that even if Oracle had a copyright on the API, Google's use of it fell under fair use so that making a ruling on the question of whether the API was protected by copyright was moot.
But who cares if there's a public body who owns the specification? The Supreme Court ruled Google's use of the copyrighted APIs fell within fair use. That gives, within the US (other countries will have other legal circumstances) a basis for anyone to copy pretty much any language so long as they steer clear of the actual copyrighted source code (don't copy MS's C# source code, for instance) and trademark violations.
You claim to be a lawyer, I doubt your reading comprehension is really this bad but just in case I'll spell it out for you. You asked:
> More importantly, is there a public body that owns the spec?
And I answered:
> For C# there is the ECMA specification for it https://ecma-international.org/publications-and-standards/st...
Anyone can implement a compiler or interpreter for C# if they want, and there is a link to the standard for it. Is this clear enough for you?
Also, from an earlier comment you made a false claim and a strange reference.
You claimed that "most of" Java, Rust, C#, Python, and Go have only a single implementation. This is false. There are multiple implementations of each.
Second, you make a bizarre reference to "fad[ing] away like Pascal." Why do you think Pascal faded? I'll give a hint: It had nothing to do with being proprietary. At best that reference is a non sequitur, at worst it demonstrates more confusion on your part.
Something being proprietary means that it is owned. It means "relating to an owner or ownership"; "of, relating to, or characteristic of an owner or title holder"; "used, made, or marketed by one having the exclusive legal right"; "privately owned and managed and run as a profit-making organization."
It is literally illegal for me to start marketing The TorstenVL Rust Compiler. Because the language is proprietary.
Trademarks are annoying but I can hardly imagine they're what anyone is worried about when picking a language in this context, they're not what's going to cause a language to disappear.
What you can call something and whether you can legally make the thing or have a permissive license to an existing implementation are two completely unrelated things.
For example, you also can't make a C compiler and name it the "microsoft C compiler" due to your lack of trademark right. Does that mean C is also proprietary?
See also: The most famous open source project is trademarked https://www.linuxfoundation.org/legal/trademark-usage
If you still aren't convinced, you are definitely using a different definition of the word proprietary than everyone else.
> Proprietary software is software that grants its creator, publisher, or other rightsholder or rightsholder partner a legal monopoly by modern copyright and intellectual property law to exclude the recipient from freely sharing the software or modifying it, and—in some cases, as is the case with some patent-encumbered and EULA-bound software—from making use of the software on their own, thereby restricting their freedoms.[1]
> Proprietary software is a subset of non-free software, a term defined in contrast to free and open-source software; non-commercial licenses such as CC BY-NC are not deemed proprietary, but are non-free. Proprietary software may either be closed-source software or source-available software.[1][2]
The Python development team, via the LICENSE file in the GitHub repository, tells me
> All Python releases are Open Source (see https://opensource.org for the Open Source Definition). Historically, most, but not all, Python releases have also been GPL-compatible; the table below summarizes the various releases.
This license is also described on Wikipedia at https://en.wikipedia.org/wiki/Python_License .
Similarly, the reference Rust implementation (https://github.com/rust-lang/rust) is licensed under Apache 2.0 and MIT licenses.
In what sense is FOSS software a kind of non-FOSS software?
exclusive legal right = not permissively licensed. it's really not a matter of jargon.
EDIT: nvm parent is confused and thinks trademarks are the same as nonfree.
Nah, there's a famous WG21 (the C++ committee) paper named "ABI: Now or Never" which lays out just some of the ever growing performance cost of choices the committee has made to preserve ABI and explains that if this cost is to be considered a price paid for something the committee needs to pick "Never" and if they instead want to stop paying the price they need to pick "Now" and, if as the author suspects, they don't actually care, they should pick neither and C++ should be considered obsolete.
The committee, of course, picked neither, and lots of people who were there have since defended this claiming that this was a false dilemma - they were actually cleverly picking "Later" which that author didn't offer. Each time they've repeated this more time has passed yet they're still no closer to this "Later" ...
Industry is seeing quantifiable improvements, eg: https://thehackernews.com/2024/09/googles-shift-to-rust-prog...
I think a big part of it is just inertia.