Hacker News Reader

Comment by kqr | Hacker News Reader

I started programming with C a long time ago, and even now, every few months, I dream of going back to those roots. It was so simple. You wrote code, you knew roughly which instructions it translated to, and there you went!

Then I try actually going through the motions of writing a production-grade application in C and I realise why I left it behind all those years ago. There's just so much stuff one has to do on one's own, with no support from the computer. So many things that one has to get just right for it to work across edge cases and in the face of adversarial users.

If I had to pick up a low-level language today, it'd likely be Ada. Similar to C, but with much more help from the compiler with all sorts of things.

View on HN

When Ada was first announced, I rushed to read about it -- sounded good. But so far, never had access to it.

So, now, after a long time, Ada is starting to catch on???

When Ada was first announced, back then, my favorite language was PL/I, mostly on CP67/CMS, i.e., IBM's first effort at interactive computing with a virtual machine on an IBM 360 instruction set. Wrote a little code to illustrate digital Fourier calculations, digital filtering, and power spectral estimation (statistics from the book by Blackman and Tukey). Showed the work to a Navy guy at the JHU/APL and, thus, got "sole source" on a bid for some such software. Later wrote some more PL/I to have 'compatible' replacements for three of the routines in the IBM SSP (scientific subroutine package) -- converted 2 from O(n^2) to O(n log(n)) and the third got better numerical accuracy from some Ford and Fulkerson work. Then wrote some code for the first fleet scheduling at FedEx -- the BOD had been worried that the scheduling would be too difficult, some equity funding was at stake, and my code satisfied the BOD, opened the funding, and saved FedEx. Later wrote some code that saved a big part of IBM's AI software YES/L1. Gee, liked PL/I!

When I started on the FedEx code, was still at Georgetown (teaching computing in the business school and working in the computer center) and in my appartment. So, called the local IBM office and ordered the PL/I Reference, Program Guide, and Execution Logic manuals. Soon they arrived, for free, via a local IBM sales rep highly curious why someone would want those manuals -- sign of something big?

Now? Microsoft's .NET. On Windows, why not??

> So, now, after a long time, Ada is starting to catch on???

Money and hardware requirements.

Finally there is a mature open source compiler, and our machines are light years beyond those beefy workstations required for Ada compilers in the 1980's.

I recently started re-reading "Programming in Ada" by J.G.P. Barnes about the original Ada. In my opinion, it was not that good of a language. Plenty of ways to trigger undefined behavior.

Where C was clearly designed to be a practical language with feedback from implementing an operating system in C. Ada lacked that kind of practical experience. And it shows.

I don't know anything about modern day Ada, but I can see why it didn't catch on in the Unix world.

> Plenty of ways to trigger undefined behavior

I'm curious about this list, because it definitely doesn't seem that way these days. It'd be interesting to see how many of these are still possible now.

Search engines seem to no longer produce an estimate of the hit count, but here are some of the ways: https://duckduckgo.com/?t=h_&q=site%3Aada-auth.org+%22errone...

I didn't make a list, but let me give an example. Page 22 where variable declarations are introduced:

If a variable is declared and not given an initial value then great care must be taken not to use the undefined value of the variable until one has been properly given to it. If a program does use the undefined value in an uninitialised variable, its behaviour will be unpredictable; the program is said to be erronous.

I recall watching a presentation about C++20. During the presentation, the presenter said there were about 163 undefined behaviors in the C language (note: I think it was C99) which implied there were many more in C++ since it’s a much more complex language. Unfortunately, I don’t have a link to that presentation.

You might have heard about the SPARK variant of Ada. I recall reading in an article many years ago that the original version of SPARK was based on Ada83 because it is a very safe language with a lot less undefined behaviors, which is key to trying to statically prove the correctness of a program.

> I started programming with C a long time ago, and even now, every few months, I dream of going back to those roots. It was so simple. You wrote code, you knew roughly which instructions it translated to, and there you went!

Related-- I'm curious what percentage of Rust newbies "fighting the borrow checker" is due to the compiler being insufficiently sophisticated vs. the newbie not realizing they're trying to get Rust to compile a memory error.

If you come from C to Rust to basically have to rewire your brain. There are some corner cases that are wrong in Rust, but mostly you have to get used to a completely new way of thinking about object lifetimes and references to objects.

...and then you come back to your C code and think 'how could I not think of these things'.

Though one thing that makes Rust quite different from C is move semantics.

I certainly spent most (95%+?) of my "fighting the borrow checker" time writing code I would never try to write in C++. A simple example is strings: I'd spend a lot of time trying to get a &str to work instead of a String::clone, where in equivalent C++ code I'd never use std::string_view over std::string - not because it would be a memory error to do so in my code as it stood, but because it'd be nearly impossible to keep it memory safe with code reviews and C++'s limited static analysis tooling.

This was made all the worse by the fact that I frequently, eventually, succeeded in "winning". I would write unnecessary and unprofiled "micro-optimizations" that I was confident were safe and would remain safe in Rust, that I'd never dare try to maintain in C++.

Eventually I mellowed out and started .clone()ing when I would deep copy in C++. Thus ended my fight with the borrow checker.

Not everything can be proved at compile-time, so necessarily Rust is going to complain about things that you know can be done safely in that specific context.

For example some tree structures are famously PITA in Rust. Yes, possible, but PITA nonetheless.

> You wrote code, you knew roughly which instructions it translated to, and there you went!

This must have been a very very long time ago, with optimizing compilers you don't really know even if they will emit any instructions.

On x86-type machines, you still have a decent chance, because the instructions themselves are so complicated and high-level. It's not that C is close to the metal, it's that the metal has come up to nearly the level of C!

I wouldn't dare guess what a compiler does to a RISC target.

(But yes, this was back in the early-to-mid 2000s I think. Whether that is a long time ago I don't know.)

I'd call it a while ago, but not a long time. Long time to me is more like 70s or 80s. I was born in 1996 so likely I'm biased: "before me=long time". It would be interesting to do a study on that. Give the words, request the years, correlate with birthyear, voila

Given how fast our field grows, you might want to consider anything beyond 13 years "a long time ago", since only a tenth of us were around back then[1].

[1]: https://entropicthoughts.com/python-programmers-experience

I don't think that's a good benchmark for a C discussion, though it probably is for JS.

> I wouldn't dare guess what a compiler does to a RISC target.

Just let your C(++) compiler generate assembly on an ARM-64 platform, like Apple Silicon or iOS. Fasten your seat belt.

Another way of looking at it (although, I’m not sure if I believe this, haha)—it might be easy to guess what the the C compiler will spit out, for the proprietary bytecode known as “x86.” It is hard to guess what actual machine code (uops) it will be jitted to, when it is actually compiled by the x86 virtual machine.

Yeah, back in the MS-DOS and Amiga glory days when C compilers were dumb, and anyone writing Assembly by hand could easily outperform them.

C source files for demoscene and games were glorified macro assemblers full of inline assembly.

Thanks for the reference to Amiga. Every random reference to my beloved computer fills me with joy.

On my circle of friends I was the PC guy, however got to enjoy quite a bit of the Amiga ecosystem, thanks to us being always being around each others, and some incursions into our demoscene attempts.

C compilers got a lot better though and sanitizers and analyzers can also easily catch a lot of mistakes.

Don't forget Pascal is still alive.

From what I remember about Ada, it is basically Pascal for rockets.

And some call it Boomer Rust, if I recall.

Hahaha! I'll start calling Rust "Zoomer Ada"

With operator precedence fixed to not be an annoyance.

Only in terms of syntax. Feature-wise it's more like C++ but everything is explicit.

Also, COBOL and FORTRAN. FORTRAN is still being developed and one of the languages supported as first class citizen by MPI.

There's a big cloud of hype at the bleeding edge, but if you dare to look beyond that cloud, there are many boring and well matured technologies doing fine.

> no support from the computer

There are a lot of things that are so USEFUL, but maddening.

C is one. make is another.

They serve a really valid purpose, but because they are stable, they have also not evolved at all.

from your ada example, I love package and package body. C has function prototypes but it is almost meaningless.

everyone seems to think C++ is C grown=up, but I don't really like it. It is more like systemd. People accept it but don't love it.

> Similar to C, but with much more help from the compiler with all sorts of things.

Is that not the problem rust was created to solve?

Rust is more like C++ (though still not really) than like C. Rust is a complete re-imagination of what a systems language could be.

My conclusion is that C is not a good basis for what Rust is trying to do. The kind of reliability Rust is trying to provide with almost no runtime overhead requires a much more complex language than C.

... and C++ is a much more complex language than C.

True. Though there are plenty of people advocating for some small extensions to C to make it safe.

Indeed. I'm still not entirely sure why Rust was created when we have Ada, but if I had to guess it's mainly because Rust has slightly more advanced tricks for safe memory management, and to some degree because Rust has curly braces.

Ada use was strongly tied to the US DoD, which put some people off it, for one.

Ada doesn't attempt to statically exclude data races or aliasing bugs. Rust does. I guess you're calling that "slightly more advanced tricks for safe memory management", which sounds wildly inaccurate to me; those problems aren't usually considered "memory management" at all. Rust also has better error handling, a stronger static type system, a Turing-complete compile-time macro system, and much less verbose code.

Writing user-facing applications in Swift and dropping to C and C++ when required seems to give the best of both worlds.

For me the main benefit of C and C++ is the availability of excellent and often irreplaceable libraries. With a little bridging work, these tend to just work with Swift.

Swift seems like an excellent language, but I can't shake the feeling that it's just not worth learning unless you're writing code on and for Apple's ecosystem.

Reply on news.ycombinator.com