Readit NewsI wish these disclaimers went upfront, the way a newspaper by-line would have been. I've never engaged much with Fortune anyway, but this makes me much less interested in doing so moving forward--if I wanted to know what an LLM thought of airport lounge crowding, I could ask one myself.
It’s like having dinner at a restaurant that you know is owned by a mafia boss and then being surprised when you get robbed while you eat there.
I'd actually be surprised if I got robbed at a mobbed-up restaurant; my naive understanding was that they actual put a lot of effort into keeping places like that above-board so they have legit businesses to attach their name/revenue/employees to, while still retaining muscle in case a rival tries something. It's arguably one of the last places I'd expected to get robbed outright.
What they would (and do) sign-off on is a one-time purchase of a desktop from an approved vendor for that desktop, which comes with out-of-the-box support for the NVIDIA GPU I've selected. That's more the niche that I feel System76 is really filling.
Edit: By the way I’m aware that there are LabVIEW specific SWEs as mentioned in the article who are able to do wizardry with it, but I wanted to highlight its usability beyond that.
I know it's a classic "don't blame your tools!" situation, but the ability for even moderately-experienced programmers to accidentally build high-incidental-complexity tooling that becomes a nightmare to re-learn once you've lost your mental model of the program is, in my experience, unique (and frightening).
I once spent weeks trying to get a LabView-based tool up and running that a senior engineer in another section had written. Sketching out the relationships between components, documenting I/O, etc. After finally giving up the ghost, I went to that engineer for help. After spending hours (like, 5-6 hours, not 1-2) sitting next to him in my lab, he said "yeah, I'm not really sure what I was doing with this...", and proceeded to need to take the entire program back to his desk for nearly a week before he could finally explain how it worked.
This situation wasn't a one-off; it's happened with nearly every non-trivial codebase that I've ever touched that used it. In my experience, LabView is really fantastic in only two situations:
a) Very simple GUI-based DAQ tools that the person who wrote the program, and them alone, will need to use
b) Complex tools that are owned by a team of engineers who have written LabView for years and will now be dedicated exclusively to those tools
Multiple years later, what was the state of things? We had a portion of the codebase in Kotlin with dedicated native/Kotlin developers, and a portion of the codebase in RN with dedicated RN/JS developers.
Any time there's a bug it's a constant shuffle between the teams of who owns it, which part of the code, native or JS the bug is coming from, who's responsible for it. A lot of time time nobody even knows because each team is only familiar with part of the app now.
The teams silo themselves apart. Each team tries its best to hold on to the codebase - native teams tries to prevent JS team from making the whole thing JS, the JS team tries to covert as much to JS as possible. Native team argues why JS features aren't good, JS team argues the benefits over writing in native. Constant back and forth.
Now, no team has a holistic view of how the app works. There's massive chunks of the app that some other team owns and maintains in some other language. The ability to have developers "own" the app, know how it works, have a holistic understanding of the whole product, rapidly drops.
Every time there's a new feature there's an argument about whether it should be native or RN. Native team points out performance and look-and-feel concerns, RN team points out code sharing / rapid development benefits. Constant back and forth. Usually whoever has the most persuasive managers wins, rather than on technical merit.
Did we end up with a better app with our new setup, compared to one app, written in one language, with a team of developers that develop and own and know the entire app? No, no I don't think so.
Feels like pretty parallel of a situation compared to Rust/C there.
The Linux kernel's first "release" was in 1991, hit 1.0 in 1994, and arguably the first modern-ish release in 2004 with the 2.6 kernel. Rust's stable 1.0 release was in 2015, 13 years ago. There are people in the workforce now who were in middle school when Rust was first released. Since then, it has seen 85 minor releases and three follow-on editions, and built both a community of developers and gotten institutional buy-in from large orgs in business-critical code.
Even if you take the 1991 date as the actual first release, Rust as a stable language has existed for over 1/3 of Linux's public development history (and of course had a number of years of development prior to that). In that framing, I think that it's a little unfair to include it in the "hip new thing" box.
But the point is that I need to now do this with every use of a third party library. And for example with pdf-rs it was happening on relatively minor things e.g. incorrect date format. And what if I want to set panic=abort on my app to prevent data corruption in my code.
Setting panic in an app shouldn’t mean it is applied globally.
Well, yes. You have to manage your dependencies (by either catching potential panics or forking/modifying them to meet your needs) or accept their behavior. You're using someone else's code for free; this is no one's responsibility but yours, nor is your convenience guaranteed. "This software is provided as is, without warranty" and whatnot.
> And what if I want to set panic=abort on my app to prevent data corruption in my code.
I obviously don't have direct insight into your application, but you could likely use std::process::abort if you feel that data corruption is a risk in a given circumstance (to be fair, I've never personally seen data corruption caused by an unwinding that would have been prevented with an aborting panic instead). Globally setting panic=abort is not necessarily the only approach to achieving your desired behavior.
> Setting panic in an app shouldn’t mean it is applied globally.
You could make a case for a more granular approach to specifying panic behavior. Sure. I don't even disagree with this. But do you see how that's moving the goalposts on your original comment? From "there's no way to wrap this behavior" to "It's possible, but I wish managing this was more convenient for my particular situation."
> Presume is used when someone is making an informed guess based on reasonable evidence. Assume is used when the guess is based on little or no evidence.
I'm not assuming they don't know what they're talking about, I'm asserting (or presuming) that they don't know what they're talking about based on supporting evidence showing that it is possible to catch panics. Similarly, I didn't say that they didn't know how to Google. I presumed it was likely they didn't put in a good-faith effort to do so, because in my judgement if they had, it would have been trivial to find the aforementioned information per my experience having just done the same.
I'll bet $20 USD to the open source project of your choice that the authors of whatever PDF library was being referenced here did not go out of their way to abort on panic, and that it's just a normal unwind.
Cars, dogs, and water.
These are the big three common things that children interact with regularly that can, and will, cause irreparable harm or death with functionally no warning and virtually instantaneously. Kids also don't have the experience or the intuition to figure out if a situation is dangerous; cars move too fast, dogs are too hard to read, and water danger is hard to grasp even for adults (the number of people, including grown adults, I've seen panic and had to get pulled out after gleefully jumping into water where it turns out they can't reliably touch the bottom is fairly high).
The first two require some strictness (i.e. being very clear about rules like never going near a road without an adult, and never hitting a dog or pulling it's ears), but water basically requires regular swimming lessons from qualified instructors. It's something I wish happened earlier, and that more families had easy access to.