Isn't that sort of just the cost of doing business in C? It's a sparse language, so it falls to the programmer to cobble together more.
I do also think the concrete example of emails should be taken as a stand-in. Errors like swapping a parameter for an email application is likely not very harmful and detected early given the volume of email that exists. But in other, less fault-tolerant applications it becomes a lot more valuable.
It is pretty funny that C's type system can be described pretty differently based on the speaker's experience. The parable of the Blub language comes to mind.
Parsing is a way of "validating early". You either get a successful parse and the program continues working on known-good data with that knowledge encoded in the type system, or you handle incorrect data as soon as it's encountered.
I used Ratpoison for well over a decade, and only replaced it with sway once I had a new machine and figured it was time to try Wayland. Apparently that's some 4-5 years ago already.
I feel I gotta point out it's a pretty funny example—email comes up so frequently as a thing that you're recommended to neither parse nor validate, just try to send an email to the address and see if it works. If you need to know that it was received successfully, a link to click is the general method.
But "parse, don't validate" is still a generally good idea, no matter the example used. :)
DAP stands for Debugger Adapter Protocol or something close to that. My impression is it's pretty much the debugger variant of the Language Server Protocol (LSP).
I think this also influences our coffee habits. The water is kind of a significant influence on the result, and some roasting styles are likely better than others at covering up unpleasant water.
Do also note that by saying that some % of crates use unsafe, it's not implied that 100% of the code in that crate is marked unsafe. It could be as little as one line; it could be a whole lot; it could be well-documented and tested; it might not be. (This is part of what the talk is about.)
It's also rather to be expected that there's more unsafe in embedded. As Steve Klabnik gets into in How to Do Embedded Development with Rust (GOTO 2023), it's used when you e.g. want to set a certain memory address to a certain value, which in a lot of contexts is nonsense, but in some contexts makes a LED light up.
The induced demand part involves a cycle of expanding roadways and then building detached housing to use that roadway.
This would happen with buses, trams and bikes as well but for them the matching housing is a high-density urban fabric, and this is much more frequently blocked by zoning than detached houses. So we get essentially housing crises with incredible prices for quality urban areas as the demand is pretty huge, and some absolutely jam-packed bus and train routes, but following up on that is politically much harder than destroying some farmland or nature area to build suburbs.
If traffic is bad then it's treated as a problem that must be solved
If transit is packed like sardines then it's often ignored
If housing that enables a low-car lifestyle is incredibly scarce and expensive it gets waved off with stuff like "it's not a human right to live in the city" or "but a big building will cast a shadow on my lawn!"
systemd is a relatively new utility that provides an array of components for Linux systems.
what
Snideness aside, systemd timers can be pretty neat. They also have some features like being able to specify "Daily" and setting some looseness in when it triggers if you e.g. have a fleet of machines and don't want them all to do something at exactly the same time.
Might be tempted to view it through a housing & transportation comparison too. Someone who lives in a too-big house, drives a pickup to the office and complains about expenses and how annoying it is to sit in traffic might not be particularly interested to hear from someone who lives in a comfortable flat, rarely has to go more than 15 minutes by bike and does a lot of bike maintenance themselves, leaving a lot of time & money available for fun.
Big houses and SUVs and pickups have their place, but investing in them because it's normal and I want to be normal is likely to lead to a lot of complaints.
That said, Kids These Days seem to be treating phones and tablets as their default OS. There's some push in workplaces to use cheaper laptops like Chromebooks if they can get away with it, which with the rise of webapps is increasingly likely. Personally I wouldn't be very surprised if Windows users in the future can be grouped into people who need:
something that's barely not chromeos
something more like a desktop xbox os for gamers, and
something that's kind of a platform for specialized native non-game apps (which may or may not be legacy stuff)
Yeah, the article comes off as needing so much context that the article itself is sus. Like
Hejlsberg stated the obvious when saying that TS isn't the fastest language. Although it can laughably run Doom at 0.0000009645 fps.
… which is referencing an implementation of Doom in the TS type system. It's a funny idea, but an arbitrary reader who doesn't know about that and doesn't bother clicking through will get a very wrong impression.
The reimplementation (which they've done partially automated; Go apparently lets them do a very simple translation while Rust or C# would require more work to fit) should be a boon for TS devs, but not noticeable for those who just run stuff that happens to be written in TS.
Would be kinda interesting to see the effect if stuff targeted deno rather than node, though.
This is simpler than the download, ./configure, make, make install steps we had some decades ago, but not all that different in that you wind up with arbitrary, unmanaged stuff.
Preferably use the distro native packages, or else their build system if it's easily available (e.g. AUR in Arch)
What, like an anglophone who can't tell the difference between the i and y sounds?
(Or do the anglos actually pronounce it "tajpst"?)