atheken @ atheken @programming.dev

Posts

0

Comments

103

Joined

2 yr. ago

That’s interesting. Usually when I see people talking about Rust, they really like it. Are there specific parts that make it less enjoyable than go for you?

I’ve tumbled down this rabbit hole on more than one occasion.

This line of thinking can lead you to the conclusion that the only ecologically just thing to do is for humans to cease to exist.

It’s a trap that can lead to despair.

Do your part to be mindful, respectful, and conservative with resources, but don’t give in to nihilism.

Cool. I should check it out. I tend to assume that when Apple (or Google) rolled this out that it’s not broken in any obvious way that I would recognize right away.

But like contactless payments, which I’ve advocated my friends and family switch to, I should read up on why it’s more secure.

You can still keep password + 2FA on GitHub and Google Suite (probably anything else that's currently implementing them), it's just a convenience/anti-phishing feature right now.

The passkey is synced between devices if it's kept in a password manager, I haven't looked at the mechanism that Apple uses to sync it/use it if you store it in the system keychain. I guess you could also have multiple passkeys configured for a few devices.

And, they are actually more convenient because then entire login process is one step with minimal keyboard input, rather than two.

I take what they're saying as "don't just give up/refuse to answer" - it's fine to say "I don't know, but I have a guess on how I'd start/find out" and try to work through that. In a real working environment, this is more how it'd work, and if someone truly didn't know where to start, usually the co-worker would try to help, which is not always how interviews go.

Which is what putting most of this stuff on the background accomplishes. It necessitates designing the UX with appropriate feedback. Sometimes you can’t make things go faster than they go. For example, a web request, or pulling data from an ancient disk that a user is using - you as an author don’t have control over these, the OS doesn’t even have control over them.

Should software that depends on external resources refuse to run?

The author is talking about switching to some RTOS due to this, which is extreme. OS vendors have spent decades trying to sort out the “Beachball of Death” issue, that is exceedingly rare on modern systems, due to better multi-tasking support, and dramatically faster hardware.

Most GUI apps are not hard RT and trying to make them so would be incredibly costly and severely limit other aspects of systems that users regularly prefer (like keeping 100 apps and browser tabs open).

I’d rather they ask me a question on something for which I’m an expert (myself) and that I can prepare for, than to fire off leetcode question.

Yeah, it’s a little bit redundant, but it can break the initial tension and get the conversation going. You can also use the time to emphasize some specific aspect of your work history that you think matches up with the job req, or shows why you actually want to work there.

If they don’t ask this question/prompt, what question would you want them to ask?

You might have a look at “CONTRIBUTING.md” files in repos.

• Set quality standards (no giant PRs, follow documented coding style, include tests for changed functionality, etc).
• Establish a way to discuss contributing work before they do it. Generally, have them open an issue discussing the proposed change and get buy-in from the maintainer (you) before starting work.
• document any high-level goals and non-goals in the README.md for the repo, and refer to that when discussing changes. You can always amend it as you discover more about what should be built.

Initially, contributors can fork and send a pull request for you to review and merge. You do not need to give them any write access to the main repository. Be respectful of their time and review PRs promptly.

If multiple people want to collaborate on a branch, they can do that in their fork. In my experience, this is pretty rare, usually you don’t want multiple people committing to the same branch (except for merges to master/main/stable, etc).

If you have a few dedicated contributors that have a history of submitting good quality patches, and alignment with you on your project’s goals, you can invite them to have more control in the main repository, at which point there should be minimal concern about granular controls.

The problem with the article is that it’s confusing hard realtime and low latency requirements. Most UIs do not require hard realtime, even soft realtime is a nice to have and users will tolerate some latency.

I also think the author handwaves “too many blocking calls end up on the main thread.”

Hardly. This is like rule zero for building gui apps. Put any non-trivial or blocking work on a background thread. It was harder to do before mainstream languages got good green thread/async support, but it’s almost trivial now.

I agree that there are still calls that could have variable response times (such as virtual memory being paged in or out), but even low-end machines are RAM-rich and SSDs are damn fast. The kernel is likely also doing some optimization to page stuff in from disk for the foreground app.

It’s nice to think through the issue, but I don’t think it’s quite as dire as the author claims.

The thread you are in and my response made it clear that the headline is clickbait by including that irrelevant detail.

If they didn’t include that word in the post title, it would have no traction at all.

It literally doesn’t matter. You can remove the word and the nature of the problem being discussed is still the same. What platform is being targeted has nothing to do with the example problem. Roblox is only mentioned to sensationalize it and get clicks.

It’s misleading because it’s irrelevant and makes it sound like a platform breach.

Try replacing Roblox with “Foozsplatz” and the implication of severity is completely different, even though the nature of what is being reported is unchanged.

Also, as far as I can tell, they’re talking about devs that are building on the Roblox platform, not devs that are building the platform.

In other words, random devs of varying skill levels getting name-squatted.

It’s not good, but including Roblox in the title is definitely misleading/clickbait.

Probably the more important question is whether DHH is your boss.

It’s fine to look for people with real experience/opinions on the internet, but at the end of the day, you have to build your own product.

I also am going to just say that I’m betting the kinds of stuff rails does in JS doesn’t really need a lot of complex JS. My guess is a lot of it paints on behavior similarly to what htmx does now, which doesn’t really require a ton of js code anymore. I don’t much see the point removing TS for the vast majority of projects.

I think it’s a double negative: “against not using”

As in, use a bundler.

Sure, you can make it 10x faster by optimizing the complexity, but I can improve throughput by 1000x by putting it on 1000 machines.

In practice, it’s a bit of both. Paying attention to Big-O and understanding the gross relative cost of various operations goes a long way, but being able to run an arbitrarily large number of them can get you out of a lot of jams.