A state (not federal) house representative and her husband were murdered.
A state (not federal) senator and his wife were attempted murdered, but both survived and are expected to recover.
Your comment frames it as if 2 members of federal congress were assassinated which would have been a much bigger deal. State politicians being killed is still shocking and tragic, but try to be precise in your language as to not mislead.
This is surprising to me. Are you implying/saying it's no big deal that 2 elected officials were shot (one killed) because they are "only" state-level politicians?
This is not a good sign for democracy in the US. I think a healthy response would be protests, investigations, state and federal "comissions" looking into domestic political terrorism, etc. A whole lot of consequences. Instead there is nothing.
In contrast, in Brazil (not even a best example of a healthiest democracy) the assassination of a city councilwoman (city! not even state!) has been a dominant story in politics for many years and has never completely fallen out of public attention. It's been close to a decade!
I'm not one to quickly say "fascism" or to spell out doom but even to me this is a crystal clear sign of a system starting to fail...
It's a big deal, just not as big a deal as misleadingly implied. "The capitol building was bombed!" (implying Washington DC) vs "The capitol building [of Alaska] was bombed!" would both be big deals, but one is a much bigger deal than the other.
It might not be 100% lies, it might be "based on a true story". The temptation to embellish/frame yourself as the faultless protagonist is instinctive and there are hundreds of examples of people doing it. Narrative shifts are super common in cases where facts are initially sparse and then more come to light... we don't have the whole context.
Surprised this story has not been flagged as it's essentially political flamebait - an uncorroborated, unverifiable account from a single person trashing the current US administration and causing everyone to pile on their hot takes and equally unverifiable and possibly embellished anecdotes.
...unless you run afoul of any of their many obscure laws, even unintentionally. I had a relative travel to Japan with his family. He's into locksport (watches Lock Picking Lawyer, etc). He had some lock picking paraphernalia on his person that he forgot about since he just carries it around 24/7 without thinking about it. Long story short, they were discovered in a metal detector at some point and Japanese security whisked him away to an interrogation room. He tried to explain locksport and youtube but the Japanese police were incredulous. He spent a full day in Japanese detention (leaving his wife and kids stranded in Tokyo without him) and at one point it was looking like he might be facing more serious charges, but then luckily someone from an American military base was able to bail him out somehow.
This doesn't seem like an "obscure" law to me. In fact if this is a hobby of yours I would expect you to understand that it's not legal in a number of places.
It was an honest mistake, especially for someone who rarely travels.
It could happen to anyone in a country where possessing lock picks is not a criminal act. For example, your sibling might get you some picks in credit card form factor one year for Christmas. You put them in your wallet and forget about them. You travel a bit within the USA and nobody cares. Then years later you travel to Japan and are whisked away to jail because of a thing you forgot about in your wallet. The Japanese don't understand why an innocent civilian would ever have such a thing; therefore you must be a nefarious criminal.
Yeah but we currently have a $2T deficit. We could do all sorts of good for "less than 10% of the DoD's annual budget", but we are already spending far more money than we bring in. The DoD's budget needs to be reduced by like 50% (along with a lot of other departments/programs) to have even a hope of getting debt under control, let alone introducing new "think of the children" expenses
Well, years later the website is still operational and the company still seems functional after Musk cut 80+% of the staff, which to me is pretty mind blowing. I'd call that pretty successful. If I, as the end user, can't tell the difference between pre-80% and post-80% cut twitter then what value was that 80% bringing to the organization, exactly?
Well, it's an incredibly unpleasant place to be, the curation is terrible, ads are dregs of the internet, and they no longer allow public access to the site or API in any meaningful way. Yay.
Lost massive amount of revenue so other financial partners on the deal had to write it down substantially- is losing money a successful investment in your book?
Then why is everyone fleeing to escape the high taxes and crime? California is losing house seats at the present.
Also, I don't know if you can really credit the left's supermajority for the success of SV... CA's politics have pivoted over the years. Look at an election map of CA in 1980 and you'll see: https://en.wikipedia.org/wiki/1980_United_States_presidentia...
If your backend is JS and it's too slow for you, then obviously porting it to a machine code binary will speed it up significantly. If you are happy with your backend performance, then does it matter?
In my experience it is pretty difficult to make WASM faster than JS unless your JS is really crappy and inefficient to begin with. LLVM-generated WASM is your best bet to surpass vanilla JS, but even then it's not a guarantee, especially when you add js interop overhead in. It sort of depends on the specific thing you are doing.
I've found that as of 2025, Go's WASM generator isn't as good as LLVM and it has been very difficult for me to even get parity with vanilla JS performance. There is supposedly a way to use a subset of go with llvm for faster wasm, but I haven't tried it (https://tinygo.org/).
I'm hoping that Microsoft might eventually use some of their wasm chops to improve GO's native wasm compiler. Their .NET wasm compiler is pretty darn good, especially if you enable AOT.
I think the Wasm backends for both Golang and LLVM have yet to support the Wasm GC extension, which would likely be needed for anything like real parity with JS. The present approach is effectively including a full GC implementation alongside your actual Golang code and running that within the Wasm linear memory array, which is not a very sensible approach.
The major roadblocks for WasmGC in Golang at the moment are (A) Go expects a non-moving GC which WasmGC is not obligated to provide; and (B) WasmGC does not support interior pointers, which Go requires.
These are no different than the issues you'd have in any language that compiles to WasmGC, because the new GC'd types are (AIUI) completely unrelated to the linear "heap" of ordinary WASM - they are pointed to via separate "reference" types that are not 'pointers' as normally understood. That whole part of the backend has to be reworked anyway, no matter what your source language is.
Go exposes raw pointers to the programmer, so from your description i think those semantics are too rudimentary to implement Go's semantics, there would need to be a WasmGC 2.0 to make this work.
It sounds like it would be a great fit for e.g. Lua though.
That's not the base language, it's an unsafe superset. There's no reason why a Wasm-GC backend for Golang should be expected to support that by default.
If it is part of the language reference it is part of the language.
Usually when language reference books used to be printed, or we used ISO languages, what is there on paper, is the language.
We are only discussing semantics, if it is hardcoded primitives, or made available via the standard library, specially in case of blessed packages like unsafe which aren't fully implemented, rather magical types for the compiler.
Which is nothing new since the 1960's that there are systems languages with some way to mark code unsafe, the C linage of languages are the ones that decided to ignore this approach.
The standard library uses unsafe for syscalls, for higher-performance primitives like strings.Builder, etc, so it's support is mandatory to run any non-trivial Go program
For a while the GOOS=nacl port and the Google App Engine ports of Go disallowed unsafe pointer manipulation too, so there is some precedent. Throughout some of the ecosystem you can see pieces of "nounsafe" build tag support (e.g. in easyjson).
Most programming languages that offer unsafe, either as language keyword, or meta package (unsafe/SYSTEM/UNSAFE whatever the name), have similar option, that doesn't make it less of a feature.
Somehow I don't think Wasm-GC is going to support bare metal syscalls anytime soon. That stuff all has to be rewritten anyway if you want to target WASM.
It's not just system calls. E.g. reflection package uses unsafe too: https://github.com/golang/go/blob/master/src/reflect/value.g... .
Many packages from Go standard library use unsafe one way or the other, so it's not fair to say that unsafe package is separate from the rest of the language
The GC extension is supported within browsers and other WASM runtimes these days - it's effectively part of the standard. Compiler developers are dropping the ball.
I did some perf benchmarks a few years ago on some JS code vs C code compiled to WASM using clang and running on V8 vs the same C code compiled to x64 using clang.
The few cases that performed significantly better than the JS version (like >2x speed) were integer-heavy math and tail-call optimized recursive code, some cases were slower than the JS version.
What I was surprised was that the JS version had similar performance to the x64 version with -O3 in some of my benchmakrs (like float64 performance).
This was a while ago though when WASM support had just landed in browsers, so probably things got better now.
I'm assuming you are talking about https://github.com/onnx/onnx-mlir?
In your experience, how much faster is a "compiled" onnx model vs. using an onnx runtime?