Why do people do that? I've been on HN a while and have never figured how changing "How x" to "x" helps anything or complies with any guidelines or anything like that. The guidelines have an example specifically leaving a how in there:
>we'd appreciate it if you'd crop it. E.g. translate "10 Ways To Do X" to "How To Do X,"
It's automatic. If you post and the title gets mangled you can go back and edit the title and it won't get re-mangled, but you kinda have to be paying attention and be aware of that.
How is it different to the first line of the article? "Canadian scientists have made a significant advance in understanding the mechanisms that enable embryos to properly form their limbs"
And there are basic things that shouldn’t be subjective at all but that the IRS refuses to give a clear answer to, like if/how the SALT cap affects deduction for NIIT. There are at least 3 possible interpretations and no consensus.
That's because it's law, and the IRS doesn't get to decide that, courts do.
There are parts of the tax code that mean different things in different parts of the US because of conflicting circuit court decisions that haven't made it to the Supreme Court.
The Mercurial project has been incrementally rewriting core operations in Rust for several years now. As Pierre-Yves says in the talk, you can do an hg status on a million-file repo in 100ms. I rewrote hg annotate (aka blame) in Rust last year.
It's kind of late, though, right? Git had core components ("plumbing") in C from 2005, with gradual rewriting of the "porcelain" layer from Perl to C in the late 2000s and early 2010s. People have been complaining about Mercurial performance for a long time. I'm sure the Python 2->3 headache did not help.
While I agree that Mercurial probably lost a ton of users for not clearly addressing performance issues for quite a while, I've found it's never too late to switch from using git, to be honest. I am personally using Fossil for all of my projects and it's been a great experience overall. I didn't have particularly challenging needs when it came to git so I wouldn't say that it's been a major headache overall for me, but I also think Fossil just is better as a default than git for everything that I do (and everything I've ever worked on):
- Assume we want to sync to main repo as a default when issuing operations, keeping us in sync more often and easily
- `commit` just commits all indexed files with changes, no need for staging
- Worktrees by default (admittedly this is more of a convention and you can certainly do the same with `git worktree`, but it's very prominent in how they show you how to use Fossil).
- `fossil ui` for having your own mini-GitHub is great, and having changes you make there sync with your remote is incredibly convenient.
- `fossil serve` on your remote is a great way to make your mini-GitHub an actual persistent service. I've used SSH remotes for `git` but as far as setup goes this actually is a close second in terms of convenience. Nevermind setting up a more involved forge; `fossil serve` is overperforming for what you get by a lot here.
All in all switching to Fossil after a ton of time using git has been a great experience overall.
Programming languages take a long time to build. Zig is a more ambitious project than most. I see lots of progress in these release notes and I'm happy to "give a pass" for the fact that it's not finished.
No one's been giving passes bewildering or otherwise for sweeping issues under the rug, because that didn't happen. The 0.16 release notes are linking to plenty of GitHub issues. If you have additional information to post on an issue then you can copy it to Codeberg: https://codeberg.org/ziglang/zig/issues/30027
I think Andrew should seriously think about decoupling the toolchain from the language to put focus on reaching stability there. As it is, we have the compiler with surrounding toolchain, the standard library and the language. The two former can keep evolving even language is fixed.
Just being ambitious isn’t necessarily good. Look at Perl6.
Glad I switched from their personal computer backup to using restic + B2 a while ago. Every night my laptop and homelab both back up to each other and to B2. It takes less than a minute and I have complete control over the exclusions and retention. And I can easily switch off B2 to something else if I want.
I was using Restic + B2 for a while, but recently switched to Restic + Hetzner Storage Box.
Storage Box is a little more effort to setup since it doesn't provide an S3 interface and I instead had to use WebDAV, but it's more affordable and has automated snapshots that adds a layer of easy immutability.
I recently tried disabling notification in LinkedIn. The designers and engineers working there who created the notifications settings are truly evil. You have to go through 14 categories. Some of them let you toggle the whole category at once, some don't. Some categories are split into 8 more subcategories.
The screenshots are from 2011 and the redesign took months of engineering, PostgreSQL + PostGIS with 13M features, Redis caching, MCP Server for AI agents. Happy to discuss technical details.
No, that’s a different thing. “noreturn” is like Rust’s “never” type (spelled as an exclamation mark, !). Also known as an “uninhabited type” in programming language theory.
Note that Rust's ! isn't stabilized, however you can (in stable Rust, today) make your own empty/ uninhabited types, yours just isn't "the" canonical empty type for the language, and so the type arithmetic won't necessarily see that it's the same thing in some cases if that matters.
Rust's core::convert::Infallible is such a type, representing in that case the error type for conversions which have no errors. For example, we can try to convert most numeric types into a 16-bit unsigned type, and obviously most of them can fail because your value was too big or negative or whatever. u16 however obviously never fails, the conversion is a no-op, nevertheless it would be stupid if we can't write generic code to convert it - so of course we can, and if we wrote generic error handling code, that code is dead for the u16 case, we can't fail, the use of empty types here justifies the compiler saying OK, that code is dead, don't emit it. Likewise converting u8 to u16 can't fail - although it's slightly more than a no-op in some sense - and so again the error handling is dead code.
I see. I can not give more insightful answer here then. From personal experience, I've noticed with 0.16 with the std.Io async stuff that you cannot do:
io.concurrent(foo, .{});
where foo's return type is `error{foobar}!noreturn`, because the compiler crashes when it tries to use that type as a std.Io.Future(T)'s struct field. Might be related or not.
reply