Zigs tight C integration makes it easy to just start using Zig in an existing C codebase, which is a great way to overcome the challenges you've mentioned. It doesn't need to replace C all at once, just slowly.
Sure but is that really enough to get buy in on a whole new language? Especially when the new language still leaves open the door for so many of the critical problems with C?
Dangling references is about the only C problem that Zig doesn't fix with language/compiler features, everything else is taken care of and mostly in a quite elegant and minimalistic way. Also Zig doesn't need to replace C to be successful, just augment it - and for that it's a already a really good choice.
I agree, the lack of control is frustrating but on the contrary: how much software is actually going to do anything useful if allocation is failing? Designing your std library around the common case then gathering input on what memory fallible APIs should look like is smarter IMO.
Most problems have speed/memory/disk tradeoffs available. Simple coding strategies include "if RAM then do the fast thing, else do the slightly slower thing", "if RAM then allocate that way, else use mmap", "if RAM then continue, else notify operator without throwing away all their work", ....
Rust was still probably right to not expose that at first since memory is supposed be fairly transparent, but Zig forces the user to care about memory, and given that constraint it's nearly free to also inform them of problems. The stdlib is already designed (like in Rust) around allocations succeeding, since those errors are just passed to the caller, but Zig can immediately start collecting data about how people use those capabilities. At a language level, including visibility into allocation failures was IMO a good idea.
andrewrk sees this as a failure but doesn't yet have a solution. It seems difficult to provide users with features they want, such as recursion and C interop, while also statically proving the stack is sufficiently small.
In programs that don't have stack overflows, it's nice to be able to handle allocation failures though :)
The Rust standard library aborts on allocation failure using the basic APIs, but Rust itself doesn't allocate. If someone wanted to write a Zig-style library in Rust, it would work just fine.
Automobiles are more (wear-)efficient at braking when they use the engine to brake, not the brakes, so that would probably be a better approach to automate
A long time ago, in a book whose title I don’t remember, a character said, “but engine parts are more expensive than brake parts”. That has always stuck with me, even as I glide to a stop with almost no braking.
As an avid engine braker who lives in a hilly area and drives in the foothills/mountains often, I figure that at the relatively inconsequential loads and speeds my passenger vehicles operate under, I'm simply leveraging the engine's already constant state of wear while preserving my brakes for a moment when I may need their optimal stopping performance.
Very true - but I drive cars until they die - and have never had a car issue because of engine braking - it is usually another part of the car that goes before whatever damage I am adding to the engine, becomes an issue. So engine brake away!
True, however that statement sort of makes the assumption that engine braking is the same ablative system as friction braking. with the same wear characteristics.
I have to admit I don't know the exact wear characteristics of an IC engine in breaking operation but I don't think it is any different/more than it's normal running wear.
They are certainly in any way identical, but to engine break, you usually need to switch into a lower gear (or a couple gears lower), which means that the clutch needs to reattach while the engine is rolling at a higher rpm than the gearbox can handle in that gear. Every downshift will do another "reattachment" through the clutch.
Which means that there will be some friction braking before internal engine resistance "takes over". Now, while both brake pads and clutches use "similar" material, it's not the same, and the cost is not the same (clutches are usually more expensive in modern cars).
Isn't that simply because the engine provides less resistance through the clutch than brakes do? Would clutch really be spent less than brake pads for the same braking power (light press on the brakes)?
FWIW, modern flywheel clutch kits are way more expensive than brake pads, so the cost is not so clear cut anyway.
You aren't really using clutch surfaces to brake though, mostly you are relying on the friction and energy used to compress your intake air and blow it out the exhaust with either minimal or no combustion/fuel input, and if at speed air resistance. And everything else added up helps too like in friction in transmission and differentials and cam and crank bearings which are hopefully minimal, and also pumping coolant and oil and running the alternator, etc. In an automatic some will be lost lost in heating up fluid in the torque converter too.
Agreed, I mostly referred to gear changes (downshifts) used to engine brake as I described in my other comment: it's certainly less friction than on brake pads, but it's slightly more than with usual gear changes (assuming smoother rpm matching). But we are talking minute wear on either, but the price difference is significant, so I just wonder — translated to thousands of km/mi — how does it compare?
IMO most of the moves were predictable if you actually listened to what theyre saying. If you dismiss everything a govt is saying as misinformation and propaganda, then of course you will never know the next step.
reply