robinm
I totally get the = async { body } (and I think I would prefer it for everything since it makes one liner like fn add(a: i32, b: i32) -> i32 = a+b much nicer and compact). I can also get the "ignore associated type” part. But I fail to see why removing the impl in -> impl Future is useful.
I didn’t know about CACHEDIR.TAG, that’s good to know. And yes, Rust tooling is stellar.
I do understant why old unicode versions re-used “i” and “I” for turkish lowercase dotted i and turkish uppercase dotless I, but I don’t understand why more recent version have not introduce two new characters that looks exactly the same but who don’t require locale-dependant knowlege to do something as basic as “to lowercase”.
As far as I know, adding the support for restrict didn’t trigger any bugs in GCC
That’s very impressive for gcc. IIRC adding restrict to LLVM triiggered major bugs and miscompilations at least for the first two attempts. As they said they need to do a crater run to be sure, but even passing the initial smoke test is an achievement for gcc.
However, I’m surprised the code is “only” 3% faster using restric annotation. IIRC the speed-ups were about 5% for LLVM so maybe there is still some performance to gain on the gcc side?
Usually when people say “I suck at maths”, it means that they are bad at doing manual calculus. Maths is extremely useful in programming, but it’s absolutely not the same kind of math. I don’t think that the grade you had in math at school will influence in any if you will be good or bad in programming.
That was a fantastic read. I’m both impressed by the stellar performance of C, and the stellar safety of Rust while keeping nealy best in class performances.
That’s a very, very good read on how to make a very complex C project safer in practice. To sum-up: make it possible to introduce new module in a memory safe language (Rust in this case), make it harder to write bugs in C since the C part is not going to disappear overnight, and use as much tooling as you can to find any existing or newly introduced bugs (both memory bugs a logique error).
That’s well written. I think that requiered 2+ code review could also help because with time more people will gain knowledge of the dark parts of the codebase, just by reviewing the PR of “Martin” when he work on them.
As a rough estimation, if you include everything (apperance, discussion, functionality, interaction with other controls, …) I would say that every single input field or button is about a day of work. And then you start to realise how many buttons there is in any GUI and how much it will cost.
