HN user
I think the main issue is that Bun relies heavily on existing C++ libraries like JavascriptCore, and these require RAII and ref-counting semantics from C++ that are closer to Rust than Zig.
You could write a JS engine with Zig-like idioms (arena allocation, static initialization), but that would require re-writing the whole JS engine from the ground-up (though I would definitely be interested in it if someone actually tries to do it!)
If both parties are actively willing to do it anyway, then why do votes even matter?
The art of Unsafe Rust is marking the right demarcation with the right set of invariants that Safe code must adhere to inside the module that uses Unsafe. If you do this incorrectly, then even Safe code outside the unsafe block can cause undefined behavior.
Which is why having unsafe code without exactly specified invariants is practically useless: the Bun rewrite code has too many SAFETY comments that are incorrect and misleading, so most of the unsafe demarcations aren't helpful in achieving UB-free code.
We can gradually refactor it
Is quite a hell of a statement, when memory management issues are highly nonlocal and need some careful design upfront in order for you to nail it.
Unsafe isn't something that you can gradually clean up. Even one single flawed usage of unsafe (an ill-assumed invariant) can poison the whole program in scary ways, and might require a total refactor of your codebase to fix it.
You do have to inevitably use unsafe because of FFI (Bun uses existing C++ modules like JavascriptCore for most functionality). Optionally also for performance (at least if you want to win Deno on that front)
clear well-scoped unsafe boundaries
This is not done by blindly porting Zig code 1:1 and calling it a day. You do have to make conscious decisions about code architecture to manage Unsafe code, since you need choose the right invariants for your Safe Rust code to conform inside the module (Note that unsafe pollutes the whole module containing it, not just the code inside the unsafe block!)
... it's a joke. A perfect example of how Plan 9 humor works.
I think it can actually be a bit better in terms of artistic consistency to have a fixed set of materials you can work with in a given game. Very important if you want any sort of stylized rendering!
I really do not understand how people talk about "Being rich / being a billionaire will make you fundamentally unhappy". Damn if I had all the money I have so many good-willed projects I want to throw money at!
Or for a better alternative, just use plain old indices rather than shared pointers.
The scene is only going to be loaded / unloaded all at once, you can just load the data into contiguous arrays and index from them. No need to use shared_ptr since lifetimes aren't that complex.
I thought SDL3 covers everything on that front though? Don't think we need to reinvent the wheel too much for window management.
our American frontier AI companies are incredibly ethical
Ah... sweet summer child.
Intellectual property theft. How can we be sure that no output of our American frontier AI models was used while training these Chinese models?
The US AI models are already using pirated copyrighted material off the Internet. If Chinese models also do this, they're at least giving it back to the people by releasing their weights as open source.
The problem with metaprogramming-heavy C++ codebases is always compilation times and obtuse error messages...
Template metaprogramming is sometimes very useful to get around C++'s language restrictions, but I tend to use it sparingly.
LLVM uses a hand-rolled version of RTTI for the best performance (the parent constructor accepts its runtime type as an enum), and it seemed that the maintenance costs for it aren't that high. (See https://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html)
Or if you're even lazier, you can easily make a more automatic RTTI system with some templates / macros that works much faster than dynamic_cast! (See https://github.com/royvandam/rtti)
I feel that generative AI is the culmination of Baudrillard and Mark Fisher's thesis.
The world we live in is already dead, and we are wandering with its ghosts. After capitalism strips everything off its materiality and leaves only with its symbols, only the nostalgia for a non-existent past remains.
Yes but in a weird way (at least on vanilla 3DGS) - it duplicates the splats on the mirror side.
Vanilla 3DGS cannot do any specular lighting or reflections - the color is basically baked in the splats. There's some active research going on to create richer Gaussian splats so we can do shading (or even ray tracing on it) - but haven't seen anyone using in production yet.
Cannot find anything related to Monte Carlo methods in the source code. I thought Spark implemented a conventional 3DGS pipeline with LoD optimizations (And it seems they do the sorting on the CPU using Rust/WebAssembly because of WebGL limitations)
Note that the first published work of rendering Gaussian Volumes was in this 1991 paper (https://articles.tomasparks.name/publications/Westover1991.p...) - so 3DGS is really a rehash of an old method from the 90s!
The contributions of 3DGS lie in how fast you can make them in modern GPU hardware (tiling + sorting with threads), and how to make the pipeline differentiable so that you can fit the Gaussian splats with photogrammetry data. Similar to the history of deep learning, it became technically feasible once the GPU hardware was powerful enough.
Really nice idea for 3DGS rendering - though the main problem is the noise (an unfortunate issue for all Monte-Carlo based methods).
I think future papers would probably continue improving on this method and focus on how to sample the points more efficiently while being unbiased (similar to how ray-tracing solved their performance issues). Or maybe... we can just add a deep-learning based denoiser and call it a day!
You can launch much more logical threads than the available physical threads. The GPU scheduler will automatically dispatch the work to the SMs.
Unfortunately you need specialized hardware for triangle rasterization, and TPUs / Compute oriented GPUs cannot really do this efficiently.
Some gamedevs hoped Nanite would eliminate the need for rasterization hardware, but because it's only performant in certain scenarios (very high poly meshes) consumers are pushing back against this.
Does it mix well with text input? What I really want is a native WYSIWYG Markdown editor - in a similar fashion to Typora (Electron) or Milkdown (a JS library).
I just wish there was a native Markdown renderer / editor library in C that I can use cross-platform - in the style of something like IMGUI (where the library outputs a list of primitives for you to render yourself in any graphics API).
Or well... since we now have Claude I might have a jab at this someday in my free time.
I'm quite interested in how they dealt with Rust's memory model, which might not neatly map to CUDA's semantics. Curious what the differences are compared to CUDA C++, and if the Rust's type system can actually bring more safety to CUDA (I do think writing GPU kernels is inherently unsafe, it's just too hard to create a safe language because of how the hardware works, and because of the fact that you're hyper-optimizing all the time)
South Korea has CCTVs all over the place (especially in the cities), and even small-scale robbery is treated as a very serious crime that often it's not worth the risk.
The problem - robots do break, they need constant maintenance, repair, and replacement (especially the smaller ones like the humanoids), and can go wrong in all sorts of situations. The costs for robot maintenance largely depend on the reliability of hardware and that should be included in the ROI calculation (which almost no one is doing right now)
Yeah even the Chinese open models have a problem that inference costs for these aren't that cheap. The only way out for the AI bubble collapse is simply more efficient hardware at lower costs and infrastructure setup downtime.
What if the competitors are also expensive? If one of OpenAI and Anthropic raises prices, the other one will follow suit (since both have the same profitability problem).
Open source models currently look good on paper, but the flagship models are still quite huge and cannot be run efficiently on consumer hardware, thus having the same inference hosting cost issues (I'm assuming OpenAI and Anthropic has done a shit ton of optimizations already on their servers.) The main breakthrough needed is plainly cheaper and more efficient hardware (such as TPUs or Huawei Ascends), and how to scale infrastructure quickly without losing money.
Claude and Claude Code are still quite useful even when considering the recent degradations, so I don't think corporate users will leave easily especially considering that they're subsidized by their companies. I think the most likely scenario is that Anthropic will remove the Max ($100 / $200) subscriptions (which were the sweet spot for most users) and opt for token-based prices instead, which will make the average cost 2x ~ 3x higher which will keep them afloat in terms of ROI. Performance will plateau though since model research cannot sustain itself any longer, and then it's only a matter of how fast the open-source Chinese models will catch up in efficiency.