HN Theater @HNTheaterMonth

Twitter's Ruby on Rails problem that the parent mentions - @26:30 https://youtu.be/LjFM8vw3pbU?t=1591

⬐ josephg

Thats the one - thankyou! Its interesting that google doesn't index the transcript of youtube talks.

Great detail I'd forgotten: At the time twitter took 460ms of compute to process each request. Almost all the CPU time was in bcopy, constructing the big string backtraces for exceptions (that were then being immediately discarded).

Cantrill did a talk on which he touches on C, C++ and Rust for systems programming [1].

His tl;dr being that Rust feels very much like a proper systems programming language, and more of a « better C » than C++. I don't entirely know what to make of it, but my instinct is that something like C++ with such an opportunity space for baroque concoctions (leading to an obsession with design patterns) is just playing with fire.

[1] https://www.youtube.com/watch?v=LjFM8vw3pbU

False.

Bryan Cantrill (OS developer who used to work at sun microsystems) talks about how the C macros are great [1].

John Carmack talks about how long functions can be better than short ones [2].

Every piece of advice that I've heard has had a contradiction coming from a preeminent developer.

To be fair, yes, people do agree on bad practices. They are just often wrong. People agreeing that something is true doesn't make it that way.

[1] - I believe that he mentions that here however, I'm not sure. I have heard him mention it in more than one video. https://www.youtube.com/watch?v=LjFM8vw3pbU

[2] - http://number-none.com/blow/john_carmack_on_inlined_code.htm...

⬐ Gupie

Not false.

Sure there are exceptions to most rules, but break them only if you know what you are doing and are able to justify doing so.

⬐ gmfawcett

> there are exceptions to most rules, but break them only if you know what you are doing and are able to justify doing so.

Isn't this exactly the kind of vague advice that GP was talking about?

⬐ Gupie

Perhaps, or perhaps it is a meta-rule, i.e. a rule about rules. Either way it is just obvious common sense IMO.

⬐ cheradenine_uk

I often think there's an equal and opposite other side to that: Don't /make/ any rules unless you know what you are doing and able to justify them (and their scope of effectiveness).

I've recently had to work on a project controlled by someone who's swallowed "clean code" and a couple of C# style guides and now just unthinkingly applies what he thinks he's read. E.g: you are not allowed any comments in this codebase. No variable may be typed. Period.

Both extremes are.. not good.

⬐ 100011_100001

I remember reading John Carmack's comments a few years back and it kind of broke my coding style because it seemed like I did everything opposite of his suggestions.

I haven't recovered since. For anyone interested, here is my notes summary from various articles and videos from John.

### John Carmack

* Do-always, then inhibit or ignore strategy

* Common pattern for me: get first results with hacky code, then write a brand new and clean implementation with the lessons learned, so they both exist and can be cross checked.

* If a function is only called from a single place, consider inlining it.

* If a function is called from multiple places, see if it is possible to arrange for the work to be done in a single place, perhaps with flags, and inline that.

* If there are multiple versions of a function, consider making a single function with more, possibly defaulted, parameters.

* If the work is close to purely functional, with few references to global state, try to make it completely functional.

* Try to use const on both parameters and functions when the function really must be used in multiple places.

* Minimize control flow complexity and "area under ifs", favoring consistent execution paths and times over "optimally" avoiding unnecessary work.

Yep.

I think Bryan Cantrill's talk from 2018 encapsulates things pretty well:

https://www.youtube.com/watch?v=LjFM8vw3pbU

Bryan is a hardcore C guy, and can write safe and reliable C code. But he has reached the limits of what C can offer in terms of composability and abstraction.

Like Linus, he wants and needs the kind of high performance and dependable behavior for systems programming that isn't possible with a garbage-collected language.

⬐ ssokolow

He also wrote a couple of blog posts called "Falling in love with Rust" and "Rust after the honeymoon":

http://dtrace.org/blogs/bmc/2018/09/18/falling-in-love-with-...

http://dtrace.org/blogs/bmc/2020/10/11/rust-after-the-honeym...

Bryan Cantrill's talk about Rust addresses when they removed green threads, and how much of a bold, disruptive change that was. He remarks on how that impressed him with the Rust community and made him follow the language more closely - had they been too scared to change the language in drastic ways, we would still be stuck with green threads.

Sorry, I can't remember the timestamp right now but the entire thing is worth a listen:

https://www.youtube.com/watch?v=LjFM8vw3pbU

⬐ steveklabnik

And to be clear, this was before 1.0; we cannot do this kind of thing these days.

Just yesterday I came across one of his other videos, and I guess Bryan Cantrill still as a bit of grudge against Oracle:

Light ranting: http://www.youtube.com/watch?v=Pm8P4oCIY3g&t=10m10s

A bit heavier ranting (with the fallout after his usenix ranting): http://www.youtube.com/watch?v=Pm8P4oCIY3g&t=14m21s

Selected quote: "Any explanation of Oracle that doesn't end with a nazi allegory does not fully explain Oracle"

Bryan Cantrill is really fun to listen to, is a tech veteran now, and is still as passionate and energetic as he was the first day (Another interesting video about programming languages he experienced during his (long by tech standards) career: https://www.youtube.com/watch?v=LjFM8vw3pbU)

I'm an embedded engineer, who's been tinkering a bit with learning Rust; so far only for an application-level project, but am keen to try it out in embedded. So far, it's been fun and exciting, along similar lines as Bryan wrote about in the OP. In fact, a video of a talk he did (https://www.youtube.com/watch?v=LjFM8vw3pbU) is what pushed me to getting started.

I think you're spot on with regards to tooling being a major concern, and to me, this is one of the promising aspects of Rust, with cargo at the high level and the LLVM tools lower down. It seems like a system that's primed for open source libraries targeting specific families of chips, cleaning up the mess we've got now with each vendor having their own framework, IDE, configuration tool, etc.

Speed and size concerns though, seem to depend a lot on the specific project. In the last couple years, I've worked on systems that had neither/either/both of those as the primary challenge. Of course in embedded, where you try to save money on parts early in a project can determine the technical (and so, schedule) challenges later on.

And, I'd add safety to the list, having spent loads of time finding bugs in legacy C caused by stuff like walking off the ends of arrays, jumping to uninitialised function pointers, fun with enums and unions, etc.

⬐ elcritch

The promise of cargo libraries supporting various chips and hardware would be a fantastic boon. Likely it’d significantly reduce security bugs and speed up dev time. Currently I’ve started using forth as a wrapper over embedded C libs so, well, I don’t have to write C daily.

⬐ tedmielczarek

There's an Embedded Rust working group currently, and they're doing some amazing things: https://github.com/rust-embedded/awesome-embedded-rust

James Munn gave a super interesting talk at this year's RustConf about some of the abstractions they're building for embedded systems: https://www.youtube.com/watch?v=t99L3JHhLc0

I think Rust is in a great position to become incredibly useful in the embedded space.

Honestly watching Brian talk about Rust https://www.youtube.com/watch?v=LjFM8vw3pbU is what finally inspired me to get the books and give it a go.

⬐ e12e

Thanks for posting that. Great rant/talk.

⬐ AceJohnny2

Hah, I think a lot of bcantrill's talks could be classified as rant/talk hybrids ;)

Here's his 2011 diatribe against Oracle (after they bought Sun, which he worked for at the time):

https://youtu.be/-zRN7XLCRhc?t=34m00s

⬐ qaq

Yep that one is pure gold

⬐ yash1th

Can you tell what books/resources you have used to pick rust?

⬐ qaq

Honestly so far "The Rust Programming Language" book proved to be the most useful resource.