I miss the days when tech people were copyright skeptics. Remember when everyone was upset with Disney for our perpetual copyright regime and the destruction of public domain?
Now many tech people are copyright maximalists and 100% converted to the church of Disney. It’s depressing.
I don't think that's right. The problem is that Anthropic is hoarding it and that's hypocritical. If copyright doesn't count for Anthropic, they should publish Claude. If they wanna hide Claude behind copyrights and/or TOS, they don't get to screw with other people's copyrights and TOS and then profit from it.
To call that opinion "copyright maximalist 100% converted to the church of Disney" is, at the very least, hyperbole.
I have a feeling that comparing a safe, sustainable energy source to large language models is disingenuous. If you support LLMs and the field, you can just state it outright, without insincere comparisons.
If you oppose LLMs and the field because of pure irrational instinct, like those people in the past, you can just state it outright, no need for complicated arguments.
Yeah, that's also fine. However I am personally willing to side with the group which's arguments for the cause are environmental and societal impact over the one which's rebuttal to that is the fact we were wrong once 40 years ago. That's just me though.
This train of thought is hilariously rife with selection bias.
There is an infinitely long list of technologies that "Luddites and doomers" tried to block and were thankfully successful in doing so.
CFCs and ozone.
Leaded gasoline.
Thalidomide.
Offensive bioweapons.
I'm not claiming Luddites and doomers are always or usually right (they're often wrong), but your claim they were wrong every time is just total epistemological failure on your part.
The point the post you replied to is making is that while you get value out of it, and in your case it's not that expensive, it's just simply not the case worldwide
There's not much Letterboxd does that cannot be federated. For one, their metadata database is a near full replica of TMDB, with very minor exceptions such as retaining deleted TMDB media. I'm not opposed to Letterboxd dying if it means people consider an alternative that is less fragile.
The value of many platforms is not the database or the stack, but the community on it. People use Letterboxd because their friends are there and because actors and directors have their lists and ratings there.
It's slower. Wasm32 can just reserve 8 GiB (32-bit pointer + 32-bit offset) of the virtual address space from the OS for each memory, so checking for out-of-bounds memory accesses imposes no performance penalty. Wasm64 can't do that, so each memory access is a bit slower.
Oh that's interesting, never noticed it in my experience but I have never written anything in wasm where it would matter. Makes perfect sense now that I think about it though. Thanks!
Sometimes I wonder whether it's possible to run the wasm code in a separate sandboxed process to eliminate a lot of checks. I mean optionally, because normally JS calls wasm code synchronously in the same address space. The bridge will add more latency when there is a transition between JS and wasm. It's obviously complicated because some data structures can also be shared, such as SharedArrayBuffer.
> The bridge will add more latency when there is a transition between JS and wasm.
This would be similar to how NaCl/PNaCl communicated with the JS side (via message passing), and that really sucked and would also be prohibitively slow for talking to 'high frequency APIs' like WebGL2 or WebGPU (or the DOM heh).
You don't need 4GB and it wastes memory to make pointers twice as big? Even Linux supports running 64-bit code in a 32-bit address space ("x32 ABI") for this reason.
TL;DR: wasm64 has slower memory load/store operation because it requires 'software bounds checking', so unless you absolutely need more than 4 GB RAM, wasm32 is the better choice.
There is no ETA on 1.0, but breakage has followed the pattern of it not really being hard to upgrade to a newer version, as it is very well documented on the version release notes.
writergate was not smooth, a lot of things that moved over to writer (Writer.Allocating for instance) had no documentation and I had to go read the zig source code to figure it out. the docs were just "instead of That use This"
People from ZSF and other maintainers have had a pretty clear stance that, while they don't necessarily like LLMs conceptually, they don't really care about if you will use them for tooling or development of your own projects. The anti-LLM stance has been on things that directly affect development of Zig (communication around issues, feature/pull requests, etc) and now, an event which is meant to be a connection place for Zig developers around the world to show off their projects and talk about other projects, and I'm sure you understand why this is a nice place to have human on human communication be the primarily encouraged method.
None of these really affect the end user of the compiler of making functioning, good tools with the language, with a LLM, if they wish to. Ghostty uses LLMs extensively, Bun was essentially vibe coded even before the Rust port. You might not wish to, ideologically speaking, develop in a language built by people who don't like your method of building things, but it's not a blocker that will turn the language into a "hobby language" (if we are judging hobbyism by lack of AI usage)
