An extreme example of unportable C is the book Mastering C Pointers: Tools for Programming Power, which was castigated recently. To be fair, that book has other flaws rather than being in a different camp, but I think that fuels some of the intensity of passion against it.

This… rather grossly undersells how much is wrong with that book. The author didn’t understand scope, for crying out loud, and never had a grasp of how C organized memory, even in the high-level handwavy “C Abstract Machine” sense the standard is written to.

There are better examples of unportable C, such as pretty much any non-trivial C program written for MS-DOS, especially the ones which did things like manually writing to video memory to get the best graphics performance. Of course, pretty much all embedded C would fit here as well, but you’ll actually be able to get and read the source of some of those MS-DOS programs.

In so doing, the committee had to converge on a computational model that would somehow encompass all targets. This turned out to be quite difficult, because there were a lot of targets out there that would be considered strange and exotic; arithmetic is not even guaranteed to be twos complement (the alternative is ones complement), word sizes might not be a power of 2, and other things.

Another example would be saturation semantics for overflow, as opposed to wraparound. DSPs use saturation semantics, so going off the top end of the scale plateaus, instead of causing a weird jagged waveform.

As for the rest, it’s a hard problem. Selectively turning off optimization for specific functions would be useful for some codebases, but aggressive optimization isn’t the only problem here: Optimization doesn’t cause your long type to suddenly be the wrong size to hold a pointer on some machines but not others. Annotating the code with machine-checked assumptions about type size, overflow behavior, and maybe other things would allow intelligent warnings about stupid code, but… well… try to get anyone to do it.

hackernews and reddit, mostly.

Possibly unpopular opinions (and a large block of text) incoming:

C++, Go, Swift, D and Rust all fail to adequately replace C for me. When given the choice, I would likely choose to just stick with C (for the moment; I’ll talk about what I’m considering at the end).

C++ has so much historical baggage and issues, it’s already an immediate turn-off. More than that, it’s explicitly understood that you should carve out a subset of C++ to use as your language because trying to use the whole thing is a mess of sadness (given that it’s massive at this point). I appreciate the goal of zero-cost abstraction and having pleasant defaults in the standard library, but there are just too many problems for me to take it as a serious choice. Plus, I still have to deal with much of the unfortunate UB from C (not all of it, and honestly, I don’t mind UB in some cases; but a lot of the cases of UB in C that just make no reasonable sense come across to C++). It should be noted that I do still consider C++ occasionally in a C-with-templates style, but it’s still definitely not my preference.

Despite how often people place it here, I do not believe Go belongs in this group of candidates The garbage collection alone makes it unfit for systems programming. I see Go as a very reasonable choice to replace Java (but I don’t use Java whenever I have the choice, so I might not be the best person to ask). There are many other parts of this language that rub me the wrong way, but mostly, I just think it’s not a good systems language (but is instead a great intro language for higher-level stuff).

Swift is really easy to rule out: It’s not cross-platform. Even if it were, it has all sorts of terrible issues (have they fixed the massive compile times yet?) that make it a no-go.

D, as far as I can tell, manages to be C++ without the warts in a really lovely way. Having said that, it seems like we’re talking about good replacements for C, not C++, and D just doesn’t cut it for me. GC by-default (being able to turn that off is good, but I’ll still have to do it every time), keeping name mangling by-default, etc. -betterC helps with some of this, but at that point, there’s just not enough reason for me to switch (especially with all the weirdness of there being two de facto standard libraries from different organizations, one of which I think is still closed-source? sounds like I might need to take another look at D; though, again, its emulation of C++ still suggests to me that it won’t quite cut it).

Rust is the only language in this list that I think is actually a reasonable contender. Sadly, it still bites a lot of these issues: names are still mangled by-default, the generated binaries are huge (I’m still a little bugged that C’s hello-world with glibc dynamically links to 6KB), et al.

But more than all of these things I’ve listed, the problems I have with these languages is that they all have a pretty big agenda (to borrow a term from Jon Blow). They all (aside from C++ which has wandered in the desert for many years) have pretty specific goals with how they are designed to try and carve out their ideal of what programming should be instead of providing tools that allow for people to build what they need.

So, as for languages that I think might (someday, not soon really) actually replace C (for me):

• zig
• myr
• jai (currently, vaporware)

Zig strikes a balance between C (plus compile-time execution to replace the preprocessor) and LLVM IR internals which allow for incredibly fine-grained control (Hello arbitrarily-sized, fixed-width integers, how are you doing?). It also manages to have the best C interop story I have ever seen in a language so far (you can import from C header files no problem, and zig libraries can have their code called from C also no problem; astounding).

Myr is still really new (so is Zig really), and has a lot left to figure out (e.g., its C interop story is not quite so nice yet). However, it manages to be incredibly simple and terse for a braced language. My guess is that, in the long run, myr will actually replace shell languages for me, but not C.

Jai looks incredibly cool and embraces a lot of what I’ve mentioned above in that it is not a big agenda language, but provides a lot of really useful tools so that you can use what you make of it. However, it’s been in development for four years and there is no publicly available implementation (and I am worried that it may end up being closed-source when it is released, if ever). I’m hoping for the best here, but am expecting dark storms ahead.

Okay, sorry for the massive post; let me just wrap up a few things. I do not mean to imply with this post that any of the languages above are inherently bad or wrong, only that they do not meet my expectations and needs in replacing C. For a brief sampling of languages that I love which suffer from all the problems I mentioned above and more, see here:

• Haskell and Idris, but really Agda
• Ada
• Lua
• APL (specifically, the unicode variants)
• Pony

They are all great and have brilliant ideas; they’re just not good for replacing C. :)

Now then, I’ll leave you all to it. :)

Nice. If you distribute pre-compiled binaries, please gpg-sign them and perhaps provide sha512 checksums of them as well.

Something interested I learned while working on a shell: GNU readline was extracted from bash, while curses was at least partly extracted from vi!

In other words, the libraries were extracted from applications, rather than written from the ground-up as libraries. That seems to be a more fool-proof way to design a complete and usable (if not optimal) interface.

https://en.wikipedia.org/wiki/Curses_(programming_library)

Something I hope to be covered is text reflowing, where you can resize your terminal and have the text flow to the new size. I’ve found it difficult to find a minimal terminal like Terminator which also supports this feature.

Something I can’t ever shake the feeling of, is that iTerm2 for macOS is the best terminal emulator, and consistently innovates and pushes the boundaries on what a terminal emulator can do … but without feeling bloated.

Given how much confusion is created by systems which do allow “foo.bar” and “foobar” to be different email addresses in the same domain, for different users, Gmail saying “we won’t allow that” is wonderful. Given how often people don’t correctly write down dots or whatever when copying email addresses, Gmail’s behavior is also good for getting the mail to just flow.

Saying Netflix shouldn’t have to have insider knowledge misses that (1) they made assumptions which required that insider knowledge, and (2) most sites make insider assumptions. Continuing with 2 for now: every site is allowed to have whatever rules they want for the left-hand-side (LHS), and per the standards the left-hand-side is case-sensitive. If I want “bar@” and “bAr@” to be different email addresses, that’s my business. Any email handling system which generally loses case of the LHS is, technically, broken. The federation used by email allows whatever systems are responsible for a given domain to have complete control over the semantics of the LHS.

In practice, the most widely deployed LHS canonicalization is almost certainly “be case-insensitive”, followed by “have sub-addresses with + or perhaps -”. IMO, the Gmail dot handling is incredibly sane and everyone running mail-systems should seriously consider it.

If I went out filing bugs against systems which made the case-insensitive assumption, then I’d be dismissed as a crazy person. In practice we (almost) all accept that some assumptions will be made. If you want to be safe, or not have to make assumptions, then validate the email addresses used at signup.

A friend had some issues with his wife because four different people had signed up for Ashley Madison using his email address (first-name @ gmail.com) and A-M never validated. Perhaps the potential consequences here highlight why not validating email addresses at sign-up or email address change should be interpreted (legally) as reckless negligence. If you’re going to decide that you don’t need to validate, then you assume responsibility for knowing about the canonicalization performed by every recipient domain. So the author of this piece is flat wrong: the moment Netflix decided to not bother validating email addresses, while also using email addresses as authentication identifiers, they assumed complete responsibility for the security consequences of having correct information about canonicalization used in every domain, to keep their authentication identifiers distinct.

(disclosure: as well as the hat, I’m also a former Gmail SRE, but had nothing to do with this feature)

would love to know what extensions he’s using in sublime for compile checking

I am planning to run freebsd on my laptop, but can’t yet because it doesn’t support my integrated graphics card yet.

It’s an intriguing proposal, and I think we will see some experiments in this direction in the near future.

To be skeptical on one point, though, I’m not ready to say this particular claim is wrong, but it does make me raise an eyebrow:

Rust only imposes one opinion on your program: that it should be safe. I would argue that the only real difference at the runtime level between programs you can write in LLVM and programs you can write in Rust is that Rust requires all of your programs to be safe, i.e. not have memory errors/data races.

Is that really the only opinion it imposes on your program? I mean if it were, that would be no real restriction, because you can always drop into unsafe. But consider C as a target language. It doesn’t even attempt to require your program to be memory-safe, and yet a number of compiler implementers have found C as a target language limiting. Is Rust less limiting than C as a target language? It might be, but this post doesn’t lay out an argument in that direction.

For example, the Haskell compiler GHC deprecated its C backend and now targets LLVM primarily. As I understand it, one of the primary issues was over garbage collection. The post does mention that Rust “needs a battle-hardened GC”, but it’s not necessarily that the target language needs one GC. That would be useful as a way of getting going and might suffice in many cases, but to avoid limiting the kinds of languages and performance profiles you can support, a compiler IR needs to provide low-level enough access for the source language to plug in its own GC strategies, and ideally own memory representations too. It’s possible the Rust internals that are alluded to provide this better than C does; admittedly I know nothing about what kinds of useful-for-compilers internals the Rust toolchain exposes.