> Haskell

I think writing timing-attack resistant code in Haskell would be very hard to impossible, at least without writing very unidiomatic code (basically "C in Haskell"). I'm happy to be proven wrong, though.

Writing unidiomatic code would still be compliant with the Haskell Language Report, compiled by an Haskell compiler and safer than plain C code.

One approach would be do design an embedded DSL for implementing cryto algorithms. And then a compiler for this DSL into C or LLVM.

In fact, I believe something along the lines of this has already been done: https://cryptol.net

Honest question: What makes you think you can't mitigate? A̶ ̶t̶y̶p̶e̶s̶a̶f̶e̶ ̶c̶r̶y̶p̶t̶o̶ ̶t̶h̶a̶t̶ ̶m̶e̶a̶s̶u̶r̶e̶s̶ ̶i̶t̶s̶ ̶e̶x̶e̶c̶u̶t̶i̶o̶n̶ ̶t̶i̶m̶e̶ ̶a̶p̶p̶e̶n̶d̶e̶d̶ ̶w̶i̶t̶h̶ ̶a̶ ̶f̶i̶n̶a̶l̶ ̶d̶e̶l̶a̶y̶ ̶t̶i̶m̶e̶ ̶r̶e̶a̶d̶ ̶f̶r̶o̶m̶ ̶/̶d̶e̶v̶/̶u̶r̶a̶n̶d̶o̶m̶ ̶c̶a̶n̶ ̶s̶t̶i̶l̶l̶ ̶b̶e̶ ̶i̶d̶i̶o̶m̶a̶t̶i̶c̶.̶ It has to be monadic, that is for sure but abstracting a crypto algorithm as IO is actually treating it as a device which sounds like a safe metaphor.

Edit: Whoah, why the hate? :(

I believe padding the timing always has been considered a bad idea. If you want to guarantee you won't exceed the timing, you probably have to take so much margin that your primitive becomes prohibitively slow. And I'm not even sure it would protect you against cache timing attacks.

Simply put, there are easier and cheaper ways to guarantee timings. Perhaps Haskell is even capable of harnessing them. (I'm thinking of the usual "no secret dependent branches", and "no secret dependent indices".)

Random delays do not protect against timing attacks. Best thing it can do, is to force the attacker to collect a few more timing samples. (To the point where the the random noise averages itself out.)

Rust doesn't even exist on a plethora of platforms which C targets. I have high hopes with D and give or take ~2 years, it'll be able to progress forward in lots of domains. Not sure about other languages.

One big long term advantage of Rust is that it leverages LLVM. Basically anywhere LLVM gets ported Rust follows.

I could run Rust code on a PlayStation and PocketStation (although I had to cheat a bit on the former because LLVM doesn't support MIPS I).

LLVM is not as widely ported as GCC (especially on older, deprecated hardware) but it's getting there.

https://svkt.org/~simias/rustation/pockestation-rust.jpg

That is a matter of tooling, though.

Until the early 90's C had hardly any meaning outside big expensive UNIX boxes.

And it was already on its way out on Windows and OS/2, if it wasn't for the rise of FOSS software and its dependency on C.

I think it might be a bit more than that. As far as I can see, all the primitive data types in Rust have sizes which are multiples of eight. However, there are still architectures out there with 9 bit bytes, or 36-bit words. Maybe it's good that all the primitive data types have an explicit size (encoded in their name), but this comes at a cost (in case a byte is 9 bits long, one of the bits will effectively not be used). On the other hand, C and C++ are less explicit about the sizes of their data types so they can accommodate these more weird architectures more easily (and, if you need an explicit size, you can explicitly ask for it).

You have a point but in general you wouldn't write "generic" C code on these exotic (by modern standards) architectures. So I guess if you wanted to port Rust to these systems you could introduce an i9 and an i36 and use that instead. I doubt you could get firefox and its dependencies to work on a CHAR_BIT == 9 system without some heavy modifications. I could be wrong though, it's not like I tried.

In my experience most modern codebases tend to target POSIX systems (explicitly or implicitly). That gives you a subset of C to work with and makes your life easier. The exceptions are things like DSPs which can have rather non-standard layouts but you generally write very specific and unportable code for these anyway.

Of course if you want to be completely portable you can't assume that CHAR_BIT == 8 or that you can convert back and forth between function and data pointers but in practice a lot of software relies on this.

Even before stdint became part of the standard it was very common for programs and libraries to typedef their own "sized" integer types. It's the only reasonable way to deal with ints in C IMO, otherwise you can't assume that your ints are greater than 16bits (which is probably too tiny for many uses) so you're tempted to put "longs" everywhere. But then longs will be 64bits on modern architectures which could be overkill and reduce performance.

So in theory those variable-size integer types are interesting but in practice they're basically useless because you end up making assumptions, one way or an other. I think it was a good idea for Rust to get rid of them.

Any language that needs evangelists is clearly not able to progress on its own merits and archievments.

What? You think other languages don't have "fan-people"? People who like Rust tend to like it very much, and it does provide a real solution to problems that C and C++ create, while providing a no-compromise performance story. So why wouldn't people talk about it?

Perl had evangelists, Ruby (on Rails) had evangelists, C++ had evangelists, Java had evangelists (some would say Java even had apostles and Messiahs...), almost every language has evangelists.