Mond_

...C++ teaches good programming practices? I thought it mainly teaches you how to be paranoid, and how to keep track of the bizarre interactions of 20 bespoke historical features.

It doesn't exactly, no. There are linters and a compiler-enforced check preventing unused variables. Overall it's pretty easy to accidentally drop errors or overwrite them before checking.

So no, it doesn't.

I mean, I don't want to be a "Keeps bringing up Rust in the comments" sort of guy, but null pointer dereferences are in fact a problem that can be solved essentially completely using strict enough typing and static analysis.

Most existing software stacks (including Google's C++, Go, Java) are by no means in a position to solve this problem, but that doesn't change that it is, in fact, a problem that fundamentally can be solved using types.

Of course, that'd require a full rewrite of the service.

I really don't like how this article claims that the primary issue with Go's error handling is that the syntax is too verbose. I don't really care about that.

How about:

- Errors can be dropped silently or accidentally ignored

- function call results cannot be stored or passed around easily due to not being values

- errors.Is being necessary and the whole thing with 'nested' errors being a strange runtime thing that interacts poorly with the type system

- switching on errors being hard

- usage of sentinel values in the standard library

- poor interactions with generics making packages such as errgroup necessary

Did I miss anything?

HoTT is a highly technical, highly niche topic and it doesn't make sense to tackle two ambitious projects at the same time like this. HoTT isn't even remotely close to being accepted as a reasonable standard, and it's kind of a non-starter for most people.

This is a bit like asking the developers of a Javascript framework why they they didn't write a framework for Elm or Haskell.

This isn't much of a tutorial or learning guide, it's a lookup table that roughly pattern matches C++ to Rust.

Probably not the best place to start learning.

How would you deal with fallible construction of objects while avoiding exceptions in idiomatic C++?

You cannot possibly know which innovations and standardizations happened past 1982 in the world in which Bell was not dismantled.

Could it be? Is it time?

Is it finally the year of the Linux desktop?

Cool as fuc + very nice blog design.

Guilty as charged, I did not know about the `import_trait_associated_functions` feature at the time. I might add a note to the article to clarify this.

There's like 5 terms for this in different programming languages. I think 'pipelining' is the best universal word. 'Method chaining' just isn't correct, nor is 'builder pattern', and 'transducer' or 'thrush combinator' is obviously a nonstarter for most people.

Yeah, I really wanted to avoid a discussion over functional vs. imperative programming, so I just... didn't talk about the imperative style at all, and just said so in the first section.

I think the imperative style isn't as readable (of course I would), but that's absolutely a discussion for another day, and I get why people prefer it.

Point free was technically mentioned once, but more as a "I'd rather not get into this in great detail right now." thing. It's really cool, though.

Have you read the article? This isn't about functional vs. imperative programming, it's (if anything) about two different ways to write functional code.

Oh, interesting! Thank you, I did not know about that, actually.

That'd be problematic, but also sounds like a (solvable) tooling problem to me.

I feel like a sufficiently good debugger should allow you to place a breakpoint at any of the lines here, and it should break exactly at that specific line.

  fn get_ids(data: Vec<Widget>) -> Vec<Id> {
      data.iter()
          .filter(|w| w.alive)
          .map(|w| w.id)
          .collect()
  }

It sounds to me like you're asking for linebreaks. Chaining doesn't seem to be the issue here.

"These are the same picture." (Sort of.)

Does it actually make more sense, or is it just more familiar?

> The second approach is open for extension - it allows you to write new functions on old datatypes.

I prefer to just generalize the function (make it generic, leverage traits/typeclasses) tbh.

> Probably for lack of > weird operators like <$>, <*>, $, or >>=

Nope btw. I mean, maybe? I don't know Haskell well enough to say. The answer that I was looking for here is a specific Rust idiosyncrasy. It doesn't allow you to import `std::iter::Iterator::collect` on its own. It's an associated function, and needs to be qualified. (So you need to write `Iterator::collect` at the very least.)

> if your language allows you to implement proper pipelining with implicit argument passing by yourself > You can decide for yourself what symbols are used and what you find intuitive

i mean this sounds fun

but tbh it also sounds like it'd result in my colleague Carl defining an utterly bespoke DSL in the language, and using it to write the worst spaghetti code the world has ever seen, leaving the code base an unreadable mess full of sharp edges and implicit behavior

> Pipelining can become hard to debug when chains get very long. The author doesn't address how hard it can be to identify which step in a long chain caused an error.

Yeah, I agree that this can be problem when you lean heavily into monadic handling (i.e. you have fallible operations and then pipe the error or null all the way through, losing the information of where it came from).

But that doesn't have much to do with the article: You have the same problem with non-pipelined functional code. (And in either case, I think that it's not that big of a problem in practice.)

> The author uses examples that function very differently.

Yeah, this is addressed in one of the later sections. Imo, having a unified word for such a convenience feature (no matter how it's implemented) is better than thinking of these features as completely separate.

No need to kick someone while they are down.

The Llama 4 launch looks like a real debacle for Meta. The model doesn't look great. All the coverage I've seen has been negative.

This is about what I expected, but it makes you wonder what they're going to do next. At this point it looks like they are falling behind the other open models, and made an ambitious bet on MoEs, without this paying off.

Did Zuck push for the release? I'm sure they knew it wasn't ready yet.

Do you have a source for this? That's interesting (if true).

> The coolest one I've heard is that Fuchsia's network stack managed to eliminate deadlocks.

Is there a write up on this? That's very cool

No smallcaps variant? Disappointing honestly.

Google is worse at marketing and hyping people up.

Pretty sure the modern Gemini image models can already do token based image generation/editing and are significantly better and faster.