hardwaregeek

There's a massive gap between taught at CMU and taught at most universities. And even if it is taught, it's usually outdated or focused on very literal stuff like how to write web applications. I'd have killed for a class that actually focuses on implementation, on teamwork, on building complicated systems.

This is an extremely niche solution, but when I need a bunch of perfectly ripe avocados, I order them from the Avocado Guy[1]. It's not that much more expensive than a grocery store (especially considering the avocados are usually on the large side), and they come perfectly ripe each time.

[1]: https://davocadoguy.net

You can make it pretty darn robust! OCaml compiles very quickly and has a good type system. Rust is slow due to LLVM, macros, and the compilation unit being the entire crate. None of these are requirements for a good type system

The problem with that reasoning is that GPS/compasses in phones are often wrong, so it helps to have the spacial awareness to know that you're on the north west corner of Delancey facing north, so you need to turn left to start heading west on Broadway. This is especially true if you're in a dense area where GPS gets especially confused, or if you're trying to catch an Uber (since now there's two potentially faulty GPS's in play).

I often have to zoom in obnoxiously far to read the damn street names. It's quite frustrating and could easily be solved with some sort of tap to display name feature.

I could see this working really nicely for those clothes in the liminal space between clean and dirty that I inevitably toss on my chair right now.

I'm not convinced that these type signatures have to be that bad. You could probably make them pretty tenable, especially with a good code formatter.

Also, I'm confused. We're using type driven development and writing the type signatures as part of the documentation, we should be thinking in terms of types, why would they be difficult to write?

Well there's also the fact that the types flow downward from the interface. Like the source of truth comes from your function parameter types that are always explicitly written. One thing that tripped me up writing OCaml is that you could have a mistake in your function that'd show up as a bug in a completely different location due to the inference algorithm. Like dumb example but say I have `foo` instead of `foo()` that changes the function return type to be a () -> int instead of int. You'll get the error when you use the function result instead of inside the function.

Yeah my semi-hot take is that type annotations in functions is a feature not a bug. It forces legible interfaces (with the exception of nasty generics I suppose).

Man, this feels like something out of Severance. Creating an AI model of Dalio to properly rank employees according to tenants? What the hell?

I'm so tired of these rants. They're always very unoriginal and cover the same points of waaaah software is slow, software is bloated. And they never offer solutions or analysis beyond "(almost) everything sucks".

Y'know why software sucks? People. People are hard to manage, hard to incentivize, hard to compensate. Focusing on the slow loading web page is neglecting the economic incentives to bloat the bundle with trackers, to ignore perf work in favor of features, to not compensate open source developers.

The point about engineers in other domains doing it better, well I'm not exactly convinced about that (look at the bloated cost of building in America). But taken as true, they're doing better because there are economic, legal, and social incentives to do better. Not because they're just better at engineering.

You're not wrong! I don't want to see Rust cryptocurrency jobs, so I built this site. If you don't agree with that, then there are loads of great sites for finding Rust jobs in crypto. I'm not purporting to be the site for Rust jobs. It's simply a curated list selected by me.

Yeah part of the issue is that language designers by definition have not-invented-here syndrome. So it takes a lot to convince them to not write it themselves. LLVM has solved a sufficiently hard problem that it’s gotten over this barrier, but other meta-tools will likely struggle to achieve that

Why not? It’s fun and a cool exercise. It’s like writing songs. They may not be hits but they can still be fun to make.

Yeah I've written about what I call "Tooling for Tooling", stuff like the LSP or tree-sitter that make it easier for language authors to build out their tooling ecosystem. I wish people invested more into these sorts of projects so we could raise the standard of tooling for everyone.

I got to see this talk irl and it was definitely one of the highlights of the conference. It did make me feel a little bad for how many times I’ve ragged on programming languages for having poor UX/tooling, even though it’s pretty unrealistic to expect a community driven project to invest the thousands of developer hours. I do wonder if there are ways to lower that burden, although that still doesn’t help with the cost of support and developer relations.

Have you tried blending it with a hot flash oil? My suspicion is that the two would be better than the sum of their parts.

Interesting! I've mostly added umami from mushroom powder and MSG. Anchovies or fish sauce could be an interesting addition, although that does make it more of a sauce than an oil.

I've learned from cooking more Indian food recently that it's okay to burn spices a little. In most cuisines you're told to only bloom spices briefly but Indian food isn't afraid to really cook spices to their limit.

Ooh I’d never heard that! I will say there is something magical about caiziyou. It’s so nutty and roasted and beautifully dark.

That’s not necessarily true. A clever dripper does open air infusion and works great. Ditto with pour overs. But perhaps with oil more volatile aroma compounds are released? Either way the only solution is to try it!

Yeah I might give it a shot (although I gave away my sous vide machine). But low and slow isn't always better for extraction. Coffee for instance extracts more with a fast infusion versus cold brew.

It's not really a solved problem in general. Most editors appear to use TextMate grammars which nobody likes. Otherwise you have to implement it using whatever custom setup your specific editor uses. It just happens that most languages have some poor soul who set this up already. Emacs is actually on the better side because tree-sitter is a much better setup for writing grammars.

At least for me, whenever I have to set up CI or touch CI, it's incredibly painful. I usually end up having to push a bunch of commits to debug stuff, and there's a lot of configuration hell. I don't know if Earthly solves this, perhaps it does. But if I were considering moving onto a new CI, I'd immediately think about having to redo this painful process. And that's at the team level. At the org level, switching CI would be even worse.

That does make me wonder, how much of CI adoption is actually moving from one provider to another versus new projects adopting CI for the first time? I'd guess that barring a really extreme reason, most projects pick a CI provider and stick with it.

Having someone look directly at the camera can sometimes feel unnerving in video. Also it's a good way to hide a teleprompter and the side-to-side eye movement

Yeah that's what I meant by impact metrics. In the 2015-2017 playoff runs Green's impact is almost on-par with Curry. But for most people who watch basketball, they just look at the box score and don't look at advanced stats.

It’s like Draymond Green. Individually his statistics suck. He’s jokingly called Mr Triple Single (a triple double is a major achievement, a triple single not so much). But he’s such a fantastic defensive coordinator and playmaker that his impact metrics on the team are massive. Like practically comparable to Steph, his more lauded teammate, in some stretches.

A common refrain in basketball is that people forget it’s a team sport. Doesn’t matter how good you are individually if your team sucks (see Michael Jordan in 1988 or Lebron most of his career). Similarly programming is a team sport. Individual stats are not the same as team success.

Builder patterns are also super helpful for libraries. Allows you to create APIs with lots of optional fields without having call sites that pass in a dozen None values.

There's also the type state pattern where you have a struct take a generic so you can allow certain methods depending on the generic type. Like say you have a struct with a field that you want to be optional, but you know statically that at a certain point in the code it'll be set.

You can do:

    struct User<IdType> {
       id: IdType
    }

    impl User<()> {
       fn create() -> User<u64> {
         ...
       }
    }

    impl User<u64> {
       fn id() -> u64 {
         user.id
       }
    }

That way you can have some methods where you can be certain that the ID is set and some methods where it's not set.

Aw, that's nice of pg to want something better for his friend. As cynical as we are about technology, new developments can be so fantastic for accessibility and better quality of life.

I'd love this to be the case, but ring, which the author of the post created, is unfortunately not really maintained. It doesn't build on Windows ARM, which in turn inhibits rustls. It's a shame because I'd prefer to not depend on OpenSSL. Not that it's the author's fault. We shouldn't be reliant on a single person's contributions to have a working Rust cryptography toolchain.

Okay…so it accepts more grammars than other parser generators. That doesn’t seem massive if I’m being honest. If you had said mehnir works with your IDE (navigating C code inside bison drove me nuts), and had good support for error recovery and idk, gave you syntax highlighting for free, I’d agree. But a minor upgrade in grammars? Not exactly Christmas here.

I have a question for you then: why is it that so many projects that are not performance bound, that are not low level systems projects, why do they use Rust and not OCaml? OCaml had a 22 year head start after all.