I'm one of those people who's adopting Zig :) But I don't think it's best for every project. For context, I've used Rust before for probably two years writing a realtime audio synthesis engine, so I'm fairly familiar with Rust vs Zig for handling low level details.
The biggest reason I use Zig is it's a very explicit language. The creators made a very intentional decision to avoid too many "high level" designs. This doesn't mean there's no capabilities for abstraction (comptime is great for that), but when you see array indexing, you can think "ptr + index * size with bounds check". There's lots of other things like that where the language does exactly one thing, and that thing is a low level operation.
This is terrible when you want to create high level abstractions that hide details from the programmer, but it's what I need when doing realtime audio synthesis or what I'm doing now which is writing an interpreter. I know exactly what allocates, I know what calls IO and can block (both operations explicitly take in an allocator or IO parameter), no data structures have private fields so I can always poke around at the insides. I know what types of errors a function returns, and creating errors is cheap with Zig's error union design.
So I don't use Zig because I think it's the safer language, I know it has sharp edges because of the number of times I've caused a panic on a poisoned pointer or use-after-free. But because it gives me such a transparent view into what is happening I find it liberating.
I think this is fair the majority of time, but I'd like to mention Zig, since Zig has a convention of all allocations being fallible and handled. It's a pain at first to handle error.OutOfMemory at each allocating site, but I feel like I'm much more conscious of where allocation can fail and how to gracefully handle it. I've also gotten a lot better at transactions since pretty much every operation has failure points now.
In fact I've written a whole interpreter that can recover from OOM by raising a recoverable exception to the user. It's really only because Zig made recovering idiomatic, and I'm not sure I could've done it in another language (maybe Rust but I'd have to rewrite large parts of stdlib to both return an error and take a custom allocator).
The Rust stdlib has added those functions that return errors, and the types are parameterized by the allocator trait. The trait is coming to stable in the next release!
Oh that's exciting! I knew about the allocator work, but I hadn't heard about error reporting for failed allocations, or that it was about to be stabilized.
In userspace/application code this isn't giving you all the value you hope for - because of overcommit and fork/exec, you can OOM on simply modifying a variable (in a non-file-backed page).
What Zig does is great, but it is not actually comprehensively checking that all allocations are fallible and handled. That's not possible on Linux.
> Despite the uncertainty, there are some clear messages we can send to the next generation of mathematicians. The first is that we stand with you. ...Second, mathematics is as important today as it ever was, and we need you. AI must not replace our collective ability to reason and deliberate, and mathematics remains a core capacity for doing so. We cannot imagine a world in which mathematics does not play an important part in our lives.
This is a really uplifting message. I'm currently in school pursuing a degree in applied math, and I've definitely felt unsettled with the recent advancements with automated proving. So it's nice to know that there's still a place for learning mathematics, and that we can find a new way forward.
It’s easy to get caught up in the worldview of academia, where the value of mathematics can seem tied to producing new interesting proofs... I’m a mathematics teacher, and I’d remind you that wider society really values people who are good at mathematics, even if they never prove anything groundbreaking. The ability to reason mathematically is useful far beyond the bubble of mathematical research. There will always be a place for mathematics grads so don't be discouraged by the AI news.
It really depends why wider society values people who are good at maths though. Unlike the arts, society (in my view) values people who are good at maths for purely utilitarian reasons; up until now strong mathematicians have been neccessary to meet various end goals. There's a very real risk that LLMs (or AI in general) will in the near term future surpass humans in all of those pursuits.
I remember reading about their setup and it blew my mind. They have MEMS mirrors that can rotate to redirect one of thousands of fiber lines into any other fiber line by using other optics. That way you can take in like 1000 lines and optically connect it to any of the other 1000 lines.
Basically they use lens array (one lens per input fiber) to focus each specific beam on its assigned mirror and mirror directs the light to the chosen output that also each has a lens in front of the fiber going out.
Honestly burning natural gas is much better than producing electricity with coal, and we can retrofit existing coal generation plants with natural gas and be like 85% cleaner. I'm kind of fed up with the absolutist takes of "don't use any fossil fuels," since that's just completely unreasonable in the next 10-20 years. Setting up power plants takes massive investment, and excluding AI-driven demand, there's not much money in power generation.
Solar has been making incredible progress, and works in sunny locations, but it's not a general purpose solution. Nuclear is getting there, but it's still too expensive and over regulated. I can't say much about wind as I haven't looked into it enough to say. Both thermal and hydro are location dependent, so good when it works but not a general purpose solution.
So that leaves coal and natural gas. We have a lot of both, but switching over to natural gas to coal by retrofitting existing power generation would make a massive difference imo.
At the end of the day, we want diversity in the power grid, not just one thing for every place, since every place is different/has its own history.
Gas produces about 40-50% less CO2 per unit of electricity produced, than coal. Not 85%.
As far as I'm concerned, a planet that is able to support human civilization ranks just a bit higher on the priority list than a diverse power grid and economic viability.
Economic viability is how we support human civilization, no? Economics is literally observing how humans interact and prioritize scarce resources like time and materials. So being not economically viable means it not happening.
Is your goal to reduce global temperatures? If so, it needs to be a sustainable effort. You don't get sustainable effort without economic viability.
If your goal is to dramatically reduce temperatures in the next 5 years, why not dump SiO2 in the atmosphere? That would bring the temperature down pretty fast by reflecting out sunlight in the upper atmosphere.
But if your goal is long-term change, we need an approach that works long-term.
Edit: sorry I forgot to mention your point on coal vs natural gas efficiency, I didn't realize it was not that much gain. I still think it's worth it though, since it's still making progress.
The problem is if you spend the next 5 years building new fossil fuel capabilities, the economic payoff won't be for at least 10 to 15 years more years. We absolutely should not be burning natural gas at that point. Not only would it cause continued havoc on our environment, zero emissions alternatives are already extremely cost competitive in most parts of the world. We should spend the next 5 years, instead, building for the future, not sinking our money into assets that will only cause further harm without providing any real cost savings.
Large scale battery storage, by the way, is already a mostly solved problem, and possible to do at a cost competitive price.
Excess atmospheric CO2 levels in and of itself are a health concern. Geoengineering will not help with the human toll of increasing CO2 and decreasing O2 levels
The only reason fossil fuels are "economically viable" is because we're ignoring the cost of the destruction they will bring in the future, and are already causing today. Nuclear is economically viable. We already have lots of nuclear power. Maybe it's a bit less profitable than fossil, maybe if we invested more into it it would be more profitable. Either way it seems entirely viable to me, except of course for all the trillions of dollars being made by extracting and selling fossil fuels to the detriment of all our futures. The only reason alternatives aren't "viable" is because they're priced out by fossil fuels. Take fossil fuels out of the equation and lots of new things become viable.
How is dumping SiO2 into the atmosphere economically viable? How do you make money doing that? If you're thinking that governments should pay private companies to do it, why can't governments simply pay private companies to produce clean power instead? Without having done any actual research on this topic, I suspect you might find that this would be far more "economically viable" than paying for the experimental climate engineering that might not even work, and might have devastating unintended consequences. For example I imagine shitloads of fine sand in the atmosphere would be a problem for aviation, and that's probably far from the only issue with it.
Yes, your proposal would have been an acceptable approach in 1990. Instead, we have been happily increasing our CO₂ emissions every year since then*. No, we no longer want diversity in the power grid; "reasonable" solutions don't move the needle. Even if the entire world would go carbon zero overnight, the global temperature would continue to rise for decades before settling around a new steady state. It's not a matter of holding out a bit longer for tomorrow's magical solution: every piece of fossil fuel burned today makes the planet more unlivable tomorrow.
We are currently on track to reach the "climate-compatible" scenario of the Paris accords (+1.5°C climate increase by 2100) in 2030. We will exceed the "minor change" scenario (+2°C) in 2050. Those targets are already locked in, they are unavoidable because of the delay between CO₂ emissions and their full effect. Maintaining our current levels of emissions gets us to 3.5°C above historic averages in 2100, which is the lower end of the disaster scenario in the Paris accords.
* except for a short drop in 2020 due to Covid. You may not like it, but that is what full climate change mitigation looks like today because we didn't act sooner.
Not sure if this is relevant, but I was in a discussion about heap layout a while ago, and one of the commenters was talking about how they were able to have classic lisp-style linked lists with decent performance by using a copying garbage collector: https://ziggit.dev/t/memory-layout-suggestions-for-tcl-inter...
Or were you referring more to all the intermediate allocations that aren't the object heap? V8's zones are interesting in this area, because they're like an arena, except that they're only partially reset when a zone ends, so zones can nest inside each other.
It's interesting because I tried to follow this advice when I wrote my own interpreter, but either 1. I just had a bad intuition and it's gotten better, or 2. It's trickier with interpreters when you have thousands of objects.
For example, since I allowed for objects to be shared between threads, I decided to use struct of arrays so the reference count, metadata, and value would be stored in separate cache lines. This ended up hurting me because object initialization touched three separate cache lines (obvious in hindsight, but the advice of using SoA failed me here). I also heard that you want to pack your values as tight as possible, so I used a packed string index, but then I ended up with integer division to unpack the string (also a mistake, but again the advice failed me). I used a custom allocator to avoid indirection with lists (list items were allocated directly after the list head), but then I had heap fragmentation and the implementation complexity exploded.
Anyways, I am now happily using two to three levels of indirection in my data structures, large structs, and malloc for individual objects, and it's still been faster in my end to end testing. So maybe this is unique to interpreters, and maybe I could have done it better, but the suggestions don't automatically apply in my experience.
"Good advice tends to come with a rationale so you can tell when it becomes bad advice" - Raymond Chen
I'd say the rule was followed in this case - the rationale of SoA is to reduce cache misses when iterating all objects and only using some of the attributes, which is something games do all the time, but it's bad if you are always accessing one object at a time. Maybe an array language interpreter would have luck with SoA.
'data oriented' doesn't mean 'just use SoA' it means use data structures which correspond to your data access pattern.
Which is quite difficult to know in complex applications and which can change..
>This ended up hurting me because object initialization touched three separate cache lines (obvious in hindsight, but the advice of using SoA failed me here).
I mean this is kind of what happens with any advice that has nuance to it, that's not carried with the advice.
E.g. if you have a point in 3D space with x, y, z coordinates. Array points as SoA of individual dimensions makes sense only if you do a lot of averaging and such on the individual dimensions.
If you mostly use the 3 coordinates together, SoA will have bad caching behavior.
So the better advice would be to try to keep things that are used together in the same cache line, whether it's on dimension or all 3. Usage makes the difference.
Corridors of Time is still sublime. After I heard that song I had to figure out the notes. Turns out there's this random tool that turns game music rips into midi, so I was able to figure out the chords in that song. I still play it from time to time.
Endianness yes, but float no. They just force software ieee754. It gives you exact bit accuracy on all build machines but it results in math that would differ between build time and run time depending if the function is evaluated as const or not
The biggest reason I use Zig is it's a very explicit language. The creators made a very intentional decision to avoid too many "high level" designs. This doesn't mean there's no capabilities for abstraction (comptime is great for that), but when you see array indexing, you can think "ptr + index * size with bounds check". There's lots of other things like that where the language does exactly one thing, and that thing is a low level operation.
This is terrible when you want to create high level abstractions that hide details from the programmer, but it's what I need when doing realtime audio synthesis or what I'm doing now which is writing an interpreter. I know exactly what allocates, I know what calls IO and can block (both operations explicitly take in an allocator or IO parameter), no data structures have private fields so I can always poke around at the insides. I know what types of errors a function returns, and creating errors is cheap with Zig's error union design.
So I don't use Zig because I think it's the safer language, I know it has sharp edges because of the number of times I've caused a panic on a poisoned pointer or use-after-free. But because it gives me such a transparent view into what is happening I find it liberating.
reply