Mesopropithecus

True. I just happen to prefer the US to set the rules over an illegitimate, theocratic, and terrorist regime.

Funny how Windows copies KDE (features and trajectories), almost 18 years after KDE 4.0/4.1. Also makes me feel old.

Was gonna write that it pays dividends only from a certain project size onwards, but in fact it could be true from a certain org size instead. So yes, it has some component of bureaucracy-as-code, and I agree with the author that that can be a good thing.

I'm seeing this way too often in production code, despite linters and reviews. So we have to keep plastering over.

"They know what’s intuitive and what isn’t"

... and then they ignore it? It triggers me when someone calls hidden swipe gestures intuitive. It's the opposite of affordance, which these designers should be familiar with if they are worth their salaries.

Like this? https://protobuf.dev/reference/protobuf/textformat-spec/

Funnily, 1.5 decades after Golang popularized formatters, in 2024 it is the only language that I work in that requires me to think about formatting. Mostly line length, but super annoying.

They have tons of commuters and business travelers. Didn't look into the methodology, but my first guess would be that those are included in the numerator, but not in the denominator.

That's what options are for. But I find it more cost effective to just diversify my investments.

Ok satire and i fell for it. Nice.

Not familiar with the details, but page fault != segfault.

Do it. I recently built a beefy machine, the first time in years that I have something I can play on, it's Linux only and it's great. Deepening on the games you play, check protondb first.

I agree with that, but null safety would be a big deal for correctness.

In the intern's place, I probably would not have bragged about copying that company's idea.

Then again, as the company, if I felt a former intern could threaten my business like that, I'd ask serious questions about my value proposition and moat (which could be premium features, sales, or an attractive/viral free tier - not too familiar with what they do). On a personal level, I can see how it could feel unfair, but the idea does not seem that original.

In the second example, buffer is still a pointer? If so, when does free run, and who decides that? When buffer goes out of scope, could do_stuff store the pointer some place else?

I find this an interesting thought experiment, basically types that you'd opt in to RAII. Just have a feeling that you'll need to define some notion of ownership to make it work.

Try-blocks with ~one line are best practice on code based I have worked with. The upside is that you can bubble errors up to the place where you handle them, AND get stack traces for free. As a huge fan of Result<T, E>, I have to admit that that's a possible advantage. But maybe that fits your definition of lazy :).

RIP. When I wasn't sure what to make of Goedel, Escher, Bach, his writings tipped the scale. Thanks!

Some of the in-house stuff was built before alternatives were available or scalable, and now there'd be a high cost and friction to trying to change it. Happens in many big companies that have been around for a few decades, it's not because of bad intentions.

As someone who hasn't thought about it that way yet: that's interesting!

Interesting. Though "ein Paar" is singular, "ein paar" is plural, making it clear from the context in many cases. Curiously, it's not clear in the case where it matters most: "please bring [ein [pP]aar Socken]". As an engineer, I'd say "please bring ein Sockenpaar" when I mean ein Paar, for clarity, for the low price of people thinking I'm weird.

Title should read "Extend a C project with Zig".

Exactly. So when people take"essential oils" or whatever to "detox" - yeah sure, you may feel a difference.

But that's probably because that substance you ingested wasn't healthy in the first place and what you're witnessing is your body trying to get rid of it fast.

The thing I love about HN is that enthusiast stuff like this makes it to the front page. <3

Depending on your background, learning either will be beneficial in that you'll learn about a C-like memory model. My experience is that Go is way easier to get started with (both in terms of the language and the libraries). It has a certain concurrency model baked into the language (which in Rust is available in the standard library). It's kind of a lower-level Python. Also I'd say that if you're not familiiar with either language, Go programs are probably easier to read, which can make a difference if you're not working alone on a project.

Rust takes a bit more effort to initially get results, but once you get there, you work in a language that gives you expressive ways to create abstraction (this is a matter of taste maybe), generates generally faster code, and does not incur overhead by garbage collection. Also, there are ways to write asynchronous code in an elegant way. The price is that you spend more time learning about structuring programs in a way that the compiler accepts. Once you are past that point, you'll be at least as productive as in Go.

I used to dabble with Go and like it, but once I had to write more code, I found it more tedious compared to Rust. But as I said, more readable to the uninitiated, that was one of the Go design goals.

I have to apologize, I misread the context of "people whining..", which was in fact about those that don't even use the language. If this was not intended to be aggressive, sorry.

Funny though that I did get triggered by it. Out of the Go community I've heard way too often "you don't really need xyz", when they mean "we're not going to support xyz, here's why, and if you disagree, we respectfully ask you to look elsewhere".

Comments like this are why I like to joke that the G in Golang stands for gaslighting.

I assume the previous poster meant that you can't tie specific taxes to specific spending buckets in Germany.

Meaningless statement unless you correct at the very least also for demographics and infection rates.

To some extent yes, it's certainly influenced by Smalltalk. I just wish the author hadn't focused that much on control flow in that paragraph. Ruby afaik also supports live programming up to a point (REPL), but it's still not the same live-ness as in Self or Smalltalk.

Not a fan of snarky comments generally, but this one made me laugh. And cry.