atheken

Unicode is thoroughly underrated.

UTF-8, doubly so. One of the amazing/clever things they did was to build off of ASCII as a subset by taking advantage of the extra bit to stay backwards compatible, which is a lesson we should all learn when evolving systems with users (your chances of success are much better if you extend than to rewrite).

On the other hand, having dealt with UTF-7 (a very “special” email encoding), it takes a certain kind of nerd to really appreciate the nuances of encodings.

I'm a go n00b, but since the source code is available, I figured I'd look. TL;DR: it probably uses the shell's default globbing resolution to produce the file list.

The generate command iterates over the internal files, but I can't find exactly how GoFiles is populated.

You can probably learn what it's doing by running go generate -n or go generate -x, and I think you can also explicitly call go generate with a file pattern list, which would give you this control.

Otherwise, I think you can include more than one magic comment in a single file, so if you have some dependant generators, these could be placed in the same file, sequentially, and you'd get the expected result.

Another alternative would be to try renaming the relevant files so that they sort the way you want them to run, lexicographically.

Sure you could say it about “any language,” but I think you’re skipping a lot of nuance with your examples: python has notoriously had a long transition from 2 -> 3. C is 40+ years old, and the semantics and idioms of the language aren’t changing from month to month.

I think the parent comment is making the point that the pace of change and evolving idioms/features of Rust means that code you write today may need to be updated in a far shorter timespan than the typical timeline for working code (a few months, rather than several years). The bitrot is just a lot faster right now than other languages.

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 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.