spankalee

Wow, that's a huge problem with that red light camera program then. The drives that run red lights around me clearly don't care much for minor consequences. The point needs to be to identify the sociopathic drivers and get them off the road.

Subjectivity in applying the law is a huge problem, especially given how corrupt and violent police are. Red light cameras remove police from the equation for that infraction and apply the law evenly. They also scale in a way that police just can't, and that's extremely important for safety.

I live in a city where red light running is an epidemic. Drivers flagrantly just don't stop, and it kills people all the time. Red light cameras - plus actually revoking drivers licenses, and then actually throwing people in jail for driving on suspended licenses - are the only way to fix this.

It's far past time that drivers are no longer immune to consequences for violent, sociopathic behavior.

Of course, but at least there's a realistic, actually used, mechanism for replacing an administration. Impeachment in the US is a complete non-factor, so you can only wait for four years, no matter how bad things get.

The US needs a parliamentary system. Trump would have been dumped already. Instead we have to wait 3 more years to end this insanity.

I considered that, but it requires more pointer indirection and I'm supporting WASI as a first class target, so won't always have access to JS finalizers. I'm going with copying as simpler for now, praying that multi-byte access lands by the time my language is viable.

I'm writing a new Wasm GC language because I'm so unsatisfied with the current options. I'm three months in, and so for it's mostly good.

WASM takes care of all the GC bits, but in turn you have to use its ref, struct, and array types for everything. Making vtables is straight forward. Fat pointers for interfaces require an object though, since you can't do your own pointer layout.

In web contexts GC should be great because browser GCs can work across DOM, JS, and WASM, so you can hold a reference to a node that you get via JS, and if you remove the node from the DOM and discard the reference, it'll be collected just like in JS.

The big downside is data transfer over the Wasm boundary requires a lot more copying with GC. Byte arrays like (array i8) are completely opaque to the outside, so you need to vend individual byte access functions to read data. On the WASI side, it only lowers to linear memory, so you need to allocate some from scratch space, then copy into GC structs and arrays. Strings are doubly awful because of this because you also have to deal with encoding.

GC also doesn't support multi-threading yet.

Some of this is supposed to be fixed by things like https://github.com/WebAssembly/design/issues/1569 and WASI lowering to GC types. stringref would have been great, but that appears to be dead for now.

So I'm on board and optimistic these things will get fixed, but GC is still a bit of a second-class citizen for now.

Semantic versions would at least be playing nice with how npm manages version ranges. If every release of TypeScript is breaking, then you should use major versions so that `npm update` doesn't break your project.

Yes, typescript would be at version 60 now. No, that's not a problem at all. Numbers are free.

As a developer that integrates typescript into client-side web pages and writes lots of custom plugins, I'm extremely nervous about the port to Go.

I think the last estimate I saw was the the Go port compiled to WASM was going to be about triple the size of the minified JS bundle.

You're talking about adding a runtime feature. TypeScript doesn't do that anymore. It can't control what properties are on objects or add new ones - you do that yourself in the standard JavaScript portion of the language. TypeScript only lets you describe what's there.

As a sibling said, discriminated unions are they way to go here. You can also add custom type guard functions if you can't control the objects but you want to centralize the detection of the types, but it's better to let TypeScript do it itself so that you don't mess something up with a cast.

The OP was pointing out the rather opinionated use of the word "Unexpectedly".

There are lots of people who have expected these tariff and immigration policies to have a negative impact on the economy. Who wasn't expecting this? Right wing supporters of Trump. Thus the pretty reasonable claim that this is a right-wing slant.

How has today's AI meaningfully impacted construction and manufacturing jobs in the US?

This is made by Google Devrel. It's not going to break the TOS, but it could be abandoned. That happens frequently with devrel projects, since they're not actually tasked with or graded on engineering projects.

This is it exactly. Russia and Canada are in the best position to possibly "benefit" from global warming.

The US has Alaska, but if it wants more newly arable land in the future, the only options seem to be Greenland and Canada, the two places which Trump just so happens to be obsessed with annexing.

It's so uncomfortable to read.

Why do people do this? They capitalize names, so clearly their shift key works. Do they do it feel special or like some sort of rebel?

I'm not so sure about publishing these publicly if they are actually vulnerable. Yikes.

But TIL that OpenClaw's UI is built with Lit and web components. Cool side note at least.

That thing is removing the restrictions from the contract.

The government wants to use AI to decide who to kill. Fuck that.

That's an amazing thread, thanks for posting it! I've wanted `for await?()` for exactly these situations.

I feel like my deep dives into iterator performance are somewhat wasted because I might have made my project faster, but it's borderline dark magic and doesn't scale to the rest of the ecosystem because the language is broken.

Async iterables aren't necessarily a great solution either because of the exact same promise and stack switching overhead - it can be huge compared to sync iterables.

If you're dealing with small objects at the production side, like individual tag names, attributes, bindings, etc. during SSR., the natural thing to do is to just write() each string. But then you see that performance is terrible compared to sync iterables, and you face a choice:

  1. Buffer to produce larger chunks and less stack switching. This is the exact same thing you need to do with Streams. or

  2. Use sync iterables and forgo being able to support async components.

The article proposes sync streams to get around this some, but the problem is that in any traversal of data where some of the data might trigger an async operation, you don't necessarily know ahead of time if you need a sync or async stream or not. It's when you hit an async component that you need it. What you really want is a way for only the data that needs it to be async.

We faced this problem in Lit-SSR and our solution was to move to sync iterables that can contain thunks. If the producer needs to do something async it sends a thunk, and if the consumer receives a thunk it must call and await the thunk before getting the next value. If the consumer doesn't even support async values (like in a sync renderToString() context) then it can throw if it receives one.

This produced a 12-18x speedup in SSR benchmarks over components extracted from a real-world website.

I don't think a Streams API could adopt such a fragile contract (ie, you call next() too soon it will break), but having some kind of way where a consumer can pull as many values as possible in one microtask and then await only if an async value is encountered would be really valuable, IMO. Something like `write()` and `writeAsync()`.

The sad thing here is that generators are really the right shape for a lot of these streaming APIs that work over tree-like data, but generators are far too slow.

Why do you presume it needs a JavaScript VM to parse JSON?

So you're saying that the web components community ignores the issues with web components by... writing a report on the issues with web components?

I still don't know what "mechanics and assumptions" are baked according to the OP.

> than the raw APIs, than Polymer, than Stencil, than...

Yes, and? Those are all different opinions and options on how to author web components.

> No. That is literally not the point. Which is extremely obvious from what I wrote in my original comment: "lit is both newer than React, and started as a fully backwards incompatible alternative to Polymer"

It's extremely hard to tell what your point is. Lit's newer than React? Yes. Lit started as an alternative to Polymer? Yes. Lit is "fully backwards incompatible [with] Polymer"? No, Lit and Polymer work just fine together because they both make web components. We have customers do this all the time.

I don't avoid authoring, authoring is the main point of these libraries. And what you build is just web components. That's like... the whole idea.

Can you even communicate what this complaint actually is?

I still don't know what you're arguing.

Is it that Lit gives you a different way of authoring web components than the raw APIs? Yes, that's entirely the point. It's a library that gives you better ergonomics.

Is it that from the outside the components aren't "Lit", but consumed as standard web components? Again, yes, that's entirely the point.

I can't even tell what you're arguing.

Lit helps you write web components.

Those web components are interoperable with other web components made with Polymer, Stencil, FAST, etc...

Redux really should have just been events up and new data down.

Web components are just a way for developers to build their own HTML elements. They're only a "framework" in as much as the browser is already a framework that wires together the built-in HTML elements.

I don't see any reason to lock away the ability to make nodes that participate in the DOM tree to built-in components only. Every other GUI framework in the world allows developers to make their own nodes, why shouldn't the web?

> too many mechanics and assumptions backed in, rendering them unusable for anything slightly complex.

Do you have any concrete examples there? What "mechanics" are you referring to. Given that very complex apps like Photoshop, Reddit, The Internet Archive, YouTube, The Microsoft App Store, Home Assistant, etc., are built with web components, that would make the claim that they're unusable seem silly.

With your other specific complaints about the community, I think I can guess you are. That person come into our discord server, was so mean and rude to everyone that they had to be told by multiple people to chill out. Had one very specific proposal that when multiple people thought it was a bad idea, threw a fit and said we never listen. You can't just come into a place and behave badly and then blame the community for rejecting you.

Lit is fully compatible with Polymer (and any other web components).

> Claude is definitively trained on the process of coding not just the code

This definitely feels like it.

It's hard to really judge, but Gemini feels like it might actually write better code, but the _process_ is so bad that it doesn't matter. At first I thought it was bad integration by the GitHub Copilot, but I see it elsewhere now.

I hope this works better than 3.0 Pro

I'm a former Googler and know some people near the team, so I mildly root for them to at least do well, but Gemini is consistently the most frustrating model I've used for development.

It's stunningly good at reasoning, design, and generating the raw code, but it just falls over a lot when actually trying to get things done, especially compared to Claude Opus.

Within VS Code Copilot Claude will have a good mix of thinking streams and responses to the user. Gemini will almost completely use thinking tokens, and then just do something but not tell you what it did. If you don't look at the thinking tokens you can't tell what happened, but the thinking token stream is crap. It's all "I'm now completely immersed in the problem...". Gemini also frequently gets twisted around, stuck in loops, and unable to make forward progress. It's bad at using tools and tries to edit files in weird ways instead of using the provided text editing tools. In Copilot it, won't stop and ask clarifying questions, though in Gemini CLI it will.

So I've tried to adopt a plan-in-Gemini, execute-in-Claude approach, but while I'm doing that I might as well just stay in Claude. The experience is just so much better.

For as much as I hear Google's pulling ahead, Anthropic seems to be to me, from a practical POV. I hope Googlers on Gemini are actually trying these things out in real projects, not just one-shotting a game and calling it a win.

I think the idea that if you don't support white supremacy you should get off the site owned and run by a clear white supremacist applies regardless of how elections go.