Conveniently forgetting how they removed the jpeg-xl support from the chrome codebase despite overwhelming developer backlash that they then proceeded to ignore for over a year.
They literally tried to kill it - stating (nonsensical) reasons why it was obsolete and unneeded.
And since now the rest of the world have adopted it despite Google, they have crawled out of their slime pits praising themselves for its development with only a passing mention of cloudinary?
People bragging that they "dont touch code" and only "argue" with agents are reinventing the slowest possible IDE.
Obviously the agents are great at producing large chunks of code, but they often make minor and sometimes trivial mistakes which need amending.
Typing something like "in src/auth/session/token_manager.ts the refreshTokenExpiry variable should be refresh_token_expiry. update every reference and make sure nothing else changes" and waiting for the LLM to do its thing takes longer than opening the file and doing the rename yourself.
If you are describing microscopic edits in natural language you are not avoiding coding. You are coding through an extremely verbose, lossy interface with higher latency and lower precision.
Codex and CC are actually getting better at reviewing code and flagging issues. False positive rate dropped fairly significantly. Also obviously might be very personal preferency but creating clear specs and iterating on specs really helps to crystalize the approach I want to take to solving a given problem.
In the latest commit, refreshTokenExpiry should be snake case. Fix and make a note to do that in $LANG.
Or otherwise scope the rule. The point is you don't need to be super verbose about it and you get to fix forward too, preventing the same issue reoccurring. You build knowledge and context that let you move faster.
> Figma invented its own primitives to make that work: components, styles, variables, props, and so on
Fireworks, Sketch, XD, Axure, etc all had these (or most of them) in some form before Figma even existed. Even illustrator, photoshop, etc have had the applicable ones for decades.
Given your confidence and the seemingly small amount of time you think it will take, this seems like something you should be proving rather than expecting others to do so.
> "shall not suffer interference from other states when in international waters"
The strait of hormuz is NOT international waters.
UNCLOS states that "straits used for international navigation" shall allow transit with impedance, which would include the strait of Hormuz, but Iran has never ratified the treaty (and neither has the USA).
While the US never ratified UNCLOS III (with things like economic exclusion zones), they did ratify the preceding UNCLOS I's Convention of the High Seas and it's freedom of navigation.
How are they leading? If I parse this correctly, "actually" open would mean fully open data training and weights? Then, by this definition, I'm only aware of Olmo (AllenAI - Seattle), Apertus (Swiss) and to some degree (unclear what data was actually published) Nemotron (Nvda, US). What are some examples of chinese similar models? (I'm not aware of any).
It might not be slow forever, but it’s slow now. I’d love to see an open ISA that is fast. But I don’t understand why the industry decided to start over with RISC-V when the compilers and toolchains and chips already existed in power land.
Shrug. The first RVA23-compliant chips are coming soon.
spacemiT K3 imminent (likely shipping boards this month) and Tenstorrent Ascalon (via Atlantis SoC devboard) this summer. These won't be the fastest CPUs available, but they'll meet the "fast enough" criteria for many uses and users.
Multiple parties including Tenstorrent expect performance parity with the ARM and x86 offerings available at the same time by 2028. Note performance is mainly gated by access to latest fab nodes, which comes with costs that necessitate serious volume. They expect to be there by then.
>But I don’t understand why the industry decided to start over with RISC-V when the compilers and toolchains and chips already existed in power land.
The rationale was documented in the "Instruction Sets Should Be Free: The Case For RISC-V" paper[0].
Note OpenPOWER is mentioned but is not in the comparison. The reason for that is simple: RISC-V predates OpenPOWER. It was an obvious reaction to RISC-V, and they were too late, as RISC-V already had the industry's attention. Furthermore, Open is a lie; payment to IBM is required in practice.
reply