With that said, I would not say few companies rely on GCP. Search for "GCP" in this month's HN hiring thread. There are 23 hits, more than Azure's 21. AWS has 90 hits, which I guess shows its sheer dominance in the startup space. But these figures more or less agree with my intuition of the major clouds being AWS/GCP/Azure.

Manually checking the dependencies used by this project, I was pleased to see they are all the latest version. That doesn't mean there are no issues lurking in transitive dependencies, of course.

As for getting an LLM to review the code, I think we can get all opinionated very fast. For instance, when I was eyeballing the code, some of the enum methods converting to/from strings made me think "this could've been a single #[derive] with strum." That would make the code in provider.rs a lot more concise, at the cost of importing one crate (with no dependencies!)

Lastly, for fun, I decided to get DeepSeek V4 Pro (with Max thinking) to "audit" the codebase. The output mentioned no obvious signs of hidden telemetry, but it did note that the project sets the panic handler to "abort", which I have strong opinions on... Presumably the OP wanted to avoid linking against libunwind to save a few kilobytes of binary size, but now you have a binary that immediately aborts and doesn't give the user a stacktrace of what just crashed. I would rather have a ~50 KiB larger binary if it means getting useful debug info during a panic. Additionally, if there are async tasks that panic, they can't be recovered to display a generic error message; instead the whole process just aborts.

For the longest time, I recall the opposition to async/await support being twofold:

1. adding support would require deep changes across the CLJS compiler (theller, creator of shadow-cljs, once tried and concluded this)

2. macros from libraries like Promesa provided similar convenience

There were some other arguments brought up at the time (e.g. just use core.async, expression-oriented languages aren't a good fit with async/await, etc.), but they were usually specific to one person rather than something you'd see repeated in forums.

In the Clojurians Slack, borkdude once stated he wasn't convinced it'd be impractical to add support. It seems that he eventually took the time and made it happen. Extremely thankful for that.

One can find MPEG-2 TS in surprising places (see: DOCSIS encapsulating Ethernet frames into TS packets).

If I had to guess why MPEG-2 TS, it'd probably be the for the fact it's a well-supported streaming format in both hardware and software. If you tried using QuickTime or MPEG-4 containers, you'd have to rely on hacks like ensuring the moov atom preceeds mdat.

Matroska may be worth considering (especially the subset used by WebM to make it stream-friendly and quicker to seek), but no idea how widespread hardware support is for (de)muxing that.

k3s has been running on my home server for about three years now (using the default SQLite backend), and there doesn't seem to be excessive CPU usage despite dozens of watches existing in the simulated etcd. Of course, this doesn't say much about Honker, but it's nonetheless worth pointing out that sometimes the choice of database forces one towards a certain design.

[1] https://github.com/k3s-io/kine/blob/648a2daa/pkg/logstructur...

Most of the rail has get around mountainous, uneven terrain subject to earthquakes, strong winds, and heavy rain. California should be able to build rail parallel to the I-5, a long, flat terrain without extreme weather or strong earthquakes. The problem seems to be a political one, not an engineering one. In fact, if the Interstate Highway System did not already exist, I doubt the U.S. today would be able to accept and complete it.

> one long line with a few branches

I currently live in Japan, and that does not really match what I've observed. There are three distinct railway companies in my area (JR, Tokyu, Yokohama Municipal Subway), each with their own dedicated rail, trains, power supply, etc.

The situation is more like "a disjoint union of graphs, where some of the graphs are connected".

Also, I believe GitHub Actions cache cannot be bulk deleted outside of the CLI. The first time I [hesitantly] used the gh CLI was to empty GitHub Actions cache. At the time it wasn't possible with the REST API or web interface.

Besides text reading like a machine translation, the tell-tale signs often involve things like:

- itemized lists (I know, it's ironic that I'm using them here)

- frequent use of conjunctions

- use of demonstratives that feels redundant

- full-width colons, especially in titles

- subheadings that always end in abstract nouns

- bold text, especially at the beginning of a line

The demonstrative bit may be hard to express, but to give you an idea: when communicating in Japanese, words that can be understood from context may be omitted. Explicitly writing out words understood from context can sometimes make a sentence sound redundant.

Before LLMs were widespread, SEO spam in the Japanese net tended to be affiliate sites with predictable, template paragraphs. I get reminded of those sites whenever GPT starts a response with 「結論から言うと、〇〇」, since that's exactly how those affiliate sites wrote back in the day.

Inputting Japanese sentences of any length flags the whole sentence as "Dramatic Fragment: A standalone paragraph with ≤4 words".

When I see a title transitioning from "Lean said this proof is okay" to "I found a bug in Lean", I'm intuitively going to think the author just found a soundness (or consistency) issue in Lean.

  Hi there,
  
  We're sunsetting Text Threads in next week's Stable release and wanted to give you a heads up as someone who's used the feature.
  
  Text Threads were Zed's original AI interface, built before the Agent Panel existed. As the Agent Panel matured with tool use and other agentic capabilities, development on Text Threads stopped. Rather than maintain a surface area we're not actively improving, we're removing them so we can focus on building a better interface for working with agents.
  
  We’re actively working on making the Agent Panel feel more like an editor, so the ideas behind Text Threads will carry forward in a more capable form.
  
  Thank you for using Zed. 
  – The Zed team

Comments URL: https://news.ycombinator.com/item?id=47596567

Points: 7

# Comments: 0

The fact they don't really need it in their life (or job). English is definitely necessary if you work service jobs in Tokyo (to deal with tourists), but not much anywhere else.

Japanese is one of a handful of languages where one can complete a postdoc entirely within the language. Many languages are not like this. e.g. in the Phillipines, STEM subjects are almost entirely taught in English, since Tagalog simply doesn't have words to describe most of the concepts. The result is something like 90% of the coursework being in English, with random Tagalog words mixed in. The concept is called "Taglish" if I recall correctly.

This is unnecessary in countries like Japan, China, South Korea, etc. If you're applying to a graduate school in Japan (or China, or Korea), expecting to receive education in English is actually the edge-case, not the expectation.

Also, at least in my company, there is an interesting trend where people are deciding learning English isn't really necessary since AI translation has gotten "good enough" for most use cases.

For what its worth, I ended up getting a tech job in Japan instead. Ironically, the requirements at U.S. startups are much higher, and U.S. startups fit the stereotype of Japanese work culture more than Japanese companies nowadays.

- cherry blossoms have been consistently blooming earlier each year

- some areas have been breaking historic high temperatures over the past 3 years (e.g. 伊勢崎市)

- even this year, there were several 20C days in Tokyo where the climate felt more like spring than winter

- 気象庁 is surveying for a new word to describe days with temperature exceeding 40C, since they are now becoming common in some areas.

Lastly, one joke my friends say is "In Japan there are four seasons: rainy season, summer, midsummer, and winter."

It's one thing to offer anonymous e-mail addresses, but it's also awesome that GitHub can help prevent mistakes that would otherwise leak a user's e-mail address. I am not sure how many people try to be privacy conscious on GitHub, but I assume most users don't, so it's nice seeing this little feature exist.