Hacker Newsnew | past | comments | ask | show | jobs | submit | zamalek's commentslogin

> Anybody who thought the simple action of rewriting things in Rust would eliminate all bugs was hopelessly naive

All bugs is typically a strawman typically only used by detractors. The correct claim is: safe Rust eliminates certain classes of bugs. I'd wager the design of std eliminates more (e.g. the different string types), but that doesn't really apply to the kernel.


> All bugs is typically a strawman typically only used by detractors. The correct claim is: safe Rust eliminates certain classes of bugs. I'd wager the design of std eliminates more (e.g. the different string types), but that doesn't really apply to the kernel.

Which is either 1) not true as evidenced by this bug or 2) a tautology whereby Rust eliminates all bugs that it eliminates.


I think the answer is #2, the tautology. But just because it’s a tautology doesn’t mean it’s a worthless thing to say. I think it’s also true, for instance (a corollary), that Rust eliminates more types of bugs than C does. And that may be valuable even if it does not mean that Rust eliminates all bugs.

>> safe Rust

> 1) not true as evidenced by this bug

Code used unsafe, putting us out of "safe" rust.


Github runners are slow. We're using WarpBuild and they are still cheaper per-minute, even with all the changes Github has made. Then there's the fact that the machines are faster, so we are using fewer minutes.

There are multiple competitors in this space. If you are (or were) paying for Github runners for any reason, you really shouldn't be.


Thanks for the WarpBuild love!

Performance is the primary lever to pay less $0.002/min self hosting tax and we strive to provide the best performance runners.


We also use WarpBuild and very happy with the performance gain. This changes nothing except maybe it should signal to WarpBuild to start supporting other providers than Github. We are clearly entering the enshitiffication phase of Github.

thanks for the love! we are actively considering supporting other providers.

C# is already memory safe. This isn't the reason why some people chose Rust over C#.

Would any of these soft forks survive without Mozilla working on Firefox?

Depends, will I win the jackpot?

The forks do not currently have the manpower to take up the full maintenance of a browser but that does not mean it's impossible that they'll be able to rally enough developers in case Mozilla implodes. A lot of people want a truly free browser to exist. Currently Firefox (barely) manages to fulfill that role and keeps many of those people from spending their time/money on alternatives.



I love the bare-bones landing page, many products have landed me as a customer due to that.

Do you have IMAP import? And CardDAV/CalDAV? Edit: also wildcards?


Thanks for your interest. IMAPsync migrations are supported. No CardDAV/CalDAV. For wildcards, do you mean catch all? If so, that is supported as well.

Firefox Mobile, Android: can't access property "enable", c is null

> But I found that the 20-30 minute stops every 2h really improve how I feel after a day or two of driving.

I honestly started considering this a feature. I am a huge believer in "productive friction" - where some things are intentionally made annoying or hard so that humans avoid them - and this is a really good example.


> Like what does your polytree look like if you add a messaging pub/sub type system into it.

A message bus is often considered a clean way to deal with a cycle, and would exist outside the tree. I hear your point about the graph disappearing entirely if you use a message bus for everything, but this would probably either be for an exceptionally rare problem-space, or because of accidental complexity.

Message busses (implemented correctly) work because:

* If the recipient of the message is down the message will still get delivered when it comes back up. If we use REST calls for completion callbacks then the sender might have to do retries and whatnot over protracted periods.

* We can deal with poison messages. If a message is causing a crash or generally exceptional behavior (because of unintentional incompatible changes), we can mark it as poisoned and have a human look at it - instead of the whole system grinding to a halt as one service keeps trashing another.

REST/RPC should be for something that can provide an answer very quickly, or for starting work that will be signaled as complete in another way. Using a message bus for RPC is just as much of a smell as using RPC for eventing.

And, as always, it depends. The line may be somewhere completely different for you. But, and I have seen this multiple times, a directed cycle in a distributed system's architecture turns it into a distributed monolith: eventually you will reach a situation where everything needs to deploy at the same time. Many, many, engineers can talk about their lessons in this - and you are, as always, free to ignore people talking about the consequences of their mistakes.


I think that icons hold value so long as they have mostly distinct colors (which none of his examples do, so his point stands). At least for me, colors make vastly superior landmark than words do (once i know the interface).

I'm not sure what a typical ketamine dosage looks like, but I have discussed it with my psychiatrist as a fallback if TMS doesn't work out, and she said that ego death is one of the primary mechanisms (alongside reintegration therapy, spending a weekend tripping balls won't fix a thing - at least perpetually).

For humans the antidepressant dose is very low - I think less than 50mg. You might feel some minor dissociative effects at that dose, but only minor, yet in some patients it can apparently produce a pronounced antidepressant effect which is interesting and suggests a non NMDA mechanism

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: