Kolja

I have no personal experience with Wasmer or the people behind it. But with the things I read about them (e. g. https://mnt.io/2021/10/04/i-leave-wasmer/ crossed my path again a few days ago) would make me, to put it lightly, hesitate before building on it.

I remember having those concerns. And Steam performance did take a few months to solidify if I remember correctly, so not everything was unfounded. Before it, only MMOs had login screens separating gamers from gaming ;-)

Nowadays, the only problems I have with Steam stem from my credit card's security mechanisms.

You are right, Valve being private removes a lot of the incentives to mess with Steam in ways I would consider negative.

I think it's pretty amazing that Valve managed to create something of this type (a store/launcher/software platform), targeted at an easily annoyed[citation needed] group of people (gamers), running for this long, that is mostly used by choice and not universally hated.

That's what happens if the buyer is also the user, I guess.

Also, I can't find any mention of the French having problems cooling down their reactors last year due to drying out rivers.

Nuclear might have been an option fifty years ago, but now it's too late to start, and we should focus on storage and renewables instead, if you ask me.

[edit]: fixed a typo

I think you are off by at least a decade, MacOS X licenses cost low triple digits (cheaper if upgrading) well into the oughts.

The style, and especially the splotchy background coloring, made Paper[1] (By WeTransfer it seems? When it was released they were called fiftythree.) my first guess.

[1]: https://apps.apple.com/us/app/paper-by-wetransfer/id50600381...

I've repeatedly heard the sentiment from interviewers that it's not worth the time asking questions you know you won't get an answer to. As a sibling noted, both of your questions can reasonably fall into that category.

Not disagreeing, just lamenting the sad state of journalism nowadays, at least as I perceive it.

This seems to be a weird micro-optimisation. While I agree with some of the goals (classless files, parameterless main exist in Kotlin and are nice to have), they should, in my opinion, not be implemented for the sole purpose of making `main` as minimal as possible.

I don't think you need to understand every single character of your very first program right from the beginning. A few of the concepts can be hand waved away to be explained in a later chapter without impeding the overall understanding of programs once you left the sub-twenty-lines beginner programs.

While I personally am mostly happy with using Exchange via IMAP (through Postbox), and therefore cannot speak to or against it, there is Owl[1]. Have you ever tried that, and if so, what's your experience been like?

[1]: https://www.beonex.com/owl/

Not sure if I understand correctly, but wouldn't one of the two "operands" need to be a file in any case (the linked tools would require you to paste two times as well)?

In that case, assuming that one file is OK and only the other text needs to be pasted, you can diff against stdin. On macOS there is `pbpaste`, which prints the contents of the pasteboard to stdout. This allows you to do `pbpaste | diff the-file -`, with `-` being the commonly used "filename" for stdin.

Also, the latest version (>= 2.3.0, released June '19) has a new flag specific to managing dotfiles. When passing `--dotfiles`, stow replaces `dot-` at the beginning of filenames with `.` in the symlinks. The online help does not mention it, but the release notes and man pages do.

I'm sure that Docusaurus can do a lot, and more in the future. I think the resulting pages feel a little heavy to use (how they load and react in a browser), but that's just my personal opinion.

I had tried to find a tool that would be simple, quick to use, and as close to a static HTML page as possible while still retaining a "book" character. Even a Vimwiki HTML export would have been an option, were Vimwiki's Markdown support better. Mdbooks fit the bill, and does not seem to stray too much from that initial direction, as far as I can tell.

No idea, actually (not a Rust developer myself). What I have noticed is that Rust seems to provide good tooling for building monolithic executables that contain a complete application, including assets. That's quite nice for trying stuff out or managing a few of those without a package manager, but has nothing to do with documentation generation per se.

I thought so, too. I've switched to mdbook[1], which is more lightweight, and (at least at the time) was one of the few solutions that compiled down to a directory that can be used without limitations while offline.

[1]: https://rust-lang.github.io/mdBook/ – the website itself is a demo of the sites produced by mdbook.

There is no blaming in GP's post. Just the notion that Germans themselves, of their own volition, are striving to not let history repeat itself.

Not everything that would be a net benefit to society has enough people interested in it that they can control markets through their wallets.

It's not just you. And I know of at least a couple of people that think the same way...[1]

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

Not only not any more, Zig has never been closed source.

> I am curious to know the reasons behind the @as() syntax. What's wrong with "i32 y = (i32) x;"?

Built-ins in Zig are functions beginning with `@`. Your cast operator would be a new syntax construct, something Zig tries to limit as much as possible (keeping the parser simple).

> What type is "b"? i32?

That's easy, i32. Integer literals are of type comptime_int, which may coerce into other integer types if possible without loss of information, and since the only typed expression is the @as, every other integer in the line will coerce to its type.

OK, I misspoke. I heard the sentiment from the Apple-focused voices in my information bubble, doesn't mean that nobody else said it. It's just that "nobody believed those Geekbench benchmarks" is not completely true.

> Just nobody believed those Geekbench benchmarks showing that in short benchmarks your phone could be faster than your laptop.

Except for a lot of the Apple-centric journalists and podcasters, who have been imagining for years how fast a desktop built on these already-very-fast-when-passively-cooled chips could be.

Not that that matters very much when experienced and real-world workload performance suffers, but as far as I can tell, the M1 is no slouch in that respect either.

I think Zig's error handling is even better: https://ziglang.org/#toc-A-fresh-take-on-error-handling

Return values are a pair of an error value (internally basically an enum) and a result value. Error handling is mandatory, but passing errors to the caller from a nested function can be done by prefixing with `try`.

IIRC, Swift is similar.