There's some space for improvement, but really... not a lot? Result is a pretty basic type, sure, but needing to choose a dependency to get a nicer abstraction is not generally considered a problem for Rust. The stdlib is not really batteries included.
Doing error handling properly is hard, but it's a lot harder when error types lose information (integer/bool returns) or you can't really tell what errors you might get (exceptions, except for checked exceptions which have their own issues).
Sometimes error handling comes down to "tell the user", where all that info is not ideal. It's too verbose, and that's when you need anyhow.
In other cases where you need details, anyhow is terrible. Instead you want something like thiserror, or just roll your own error type. Then you keep a lot more information, which might allow for better handling. (HttpError or IoError - try a different server? ParseError - maybe a different parse format? etc.)
So I'm not sure it's that Result is clumsy, so much that there are a lot of ways to handle errors. So you have to pick a library to match your use case. That seems acceptable to me?
FWIW, errors not propagating via `?` is entirely a problem on the error type being propagated to. And `?` in closures does work, occasionally with some type annotating required.
I agree with you, but it’s definitely inconvenient. Result also doesn’t capture a stack trace. I spent a long time tracking down bugs in some custom binary parsing code awhile ago because I had no idea which stack trace my Result::Err’s were coming from. I could have switched to another library - but I didn’t want to inflict extra dependencies on people using my crate.
As you say, it’s not “batteries included”. I think that’s a fine answer given rust is a systems language. But in application code I want batteries to be included. I don’t want to need to opt in to the right 3rd party library.
I think rust could learn a thing or two from Swift here. Swift’s equivalent is better thought through. Result is more part of the language, and less just bolted on:
Physical thank you cards are pretty dead. I don't even keep track of mailing addresses for a number of my friends (and a couple siblings, come to think of it) - how would I send them a physical card?
Even older relatives - we sent a physical gift a bit ago, but the response/thanks was by text. It just doesn't make sense to send a letter, have it take a week, never know whether it got lost, etc.
There are legitimate criticisms that AI is harming creative endeavours. AI output is sort of by definition not particularly innovative. By flooding spaces with repetitive AI work, it may be drowning out the basis for truly innovative creation. And maybe it does suppress development of skills it tries to replace.
The appropriation argument is somewhat unsound. Creative endeavors, by definition, build on what's come before. This isn't any different between code, creative writing, drawing, painting, photography, fashion design, music, or anything else creative. Creation builds on what came before, that's how it works. No one accuses playwrights of appropriating Shakespeare just because they write a tragic romance set in Europe.
The hyperbolic way you've made whatever arguments you had, though, is actively working against you.
The people who built this technology needed to use hundreds of millions of images without permission. They regularly speak explicitly about all the jobs they plan to destroy. If you think I'm being hyperbolic then you don't understand the scale of the issue, frankly.
> The people who built this technology needed to use hundreds of millions of images without permission.
It remains unclear if they needed permission in the first place. Aside from Meta's stunt with torrents I'm not aware of any legal precedent forbidding me to (internally) do as I please with public content that I scrape.
> They regularly speak explicitly about all the jobs they plan to destroy.
A fully legal endeavor that is very strongly rewarded by the market.
> I'm not aware of any legal precedent forbidding me to (internally) do as I please with public content that I scrape.
Because all the litigation is currently ongoing.
> A fully legal endeavor that is very strongly rewarded by the market.
Yes let's sacrifice all production of cultural artifacts for the market. This is honestly another thing that's being litigated. So far these companies have lost a lot of money on making a product that most consumers seem to actively hate.
Precisely. So when you say they used the images without permission, you are knowingly making a false implication - that it was known to them that they needed permission and that they intentionally disregarded that fact. In reality that has yet to be legally established.
Who said anything about sacrificing production? The entire point of the tooling is to reduce the production cost to as near zero as possible. If you didn't expect it to work then I doubt you would be so bent out of shape over it.
I find your stance quite perplexing. The tech can't be un-invented. It's very much Pandora's box. Whatever consequences that has for the market, all we can do is wait and see.
Worst case scenario (for the AI purveyors) is a clear legal determination that the current training data situation isn't legal. I seriously doubt that would set them back by more than a couple of years.
You might be surprised to learn that ethics and legality are not always the same and you can do something that's technically legal but also extremely shitty like training AI models on work you didn't create without permission.
There's a difference between contempt (i.e. "users are stupid") and realism, though. And realism can range from "users don't want to troubleshoot" to "some users are near-violently anti-tech and won't read errors", depending on context.
The unfortunate truth is that if you're doing B2C or even B2B outside of tech companies, the second one will often come up...
Bad devs exist. Bad users do too. Thing is, you can't usually fire the bad users.
> And realism can range from "users don't want to troubleshoot" to "some users are near-violently anti-tech and won't read errors", depending on context.
No dude, I have things to do and your little software is a tiny roadblock in my day. I dont want to become a fellow expert in your niche, do the thing and get out of my way.
Building UI for work and for consumers is completely different. I’ve done both, user attitudes are veeeery different. Building an ecommerce page is also very different to building an engagement trap for users to sit in.
Problems start when engineers/designers/producters don’t understand their users and their goals. Or when the user is not also the customer (this is the worst)
There's a third category too, users looking for security weakness and probing the system with a spectrum of inputs. The response to these inputs can reveal a lot about how the backend is designed.
Also, as a Vancouverite... 5-6 stories, cheaper to live there, AND more comfortable? Dunno about that.
I've got doubts about cheaper, and 5-6 story buildings in Vancouver always seem less comfortable than a skyscraper (for whatever reason - maybe just that the 5-6 story buildings are mostly old?)
> You can see plenty of other skyscapers, some looking similar height or nearly as tall. Just not any on the side of the river the Squamish are planning on building.
That's kind of the entire point of Vancouver NIMBYism, at least around Kits/Point Grey. The "backyard" for them is basically "anywhere except the downtown peninsula" (the other side of the inlet in the picture).
They won't care too much if someone builds a 20-40 story building on the West End/peninsula. Do the same thing on the west side ([1], off the peninsula) and they'll throw an absolute fit.
[1] The West End neighbourhood and the colloquial west side are a solid 10-20 minutes apart from each other, driving time. Geographically - West End is on the peninsula, and the west side is basically the various neighbourhoods across the inlet (False Creek) from it.
More importantly, knowing and caring are two different things.
I know that Velcro/Kleenex/Google are specific brands, but I don't really care - the common usage is so far gone that there's rarely a reason to use hook & loop fastener/tissue paper/internet search instead.
Hell, for some people, "iPad" is a semi-generic term for a tablet. (Though I don't get that one, personally.)
> Hell, for some people, "iPad" is a semi-generic term for a tablet. (Though I don't get that one, personally.)
I remember when the NFL first started using Microsoft Surface tablets during the broadcast, except the commentators would keep referring to them as iPads. By the next week's broadcast, every single commentator had a giant "Microsoft Surface" branded tablet cover in front of them at the desk and overall the logos were plastered everywhere.
Eh. Military aircraft would also have a transponder, they just wouldn't necessarily have active broadcasts.
Civilian aircraft do broadcast actively (ADS-B). But they also respond to secondary radar for Mode A/C, which are basically cases of IFF Mode III (okay, maybe not exact term, but the idea applies.) So it's still a challenge-response/IFF, just in this case always responding.
Military aircraft use different modes and presumably don't respond unless interrogated with an appropriate challenge, but the principles are the same.
This still doesn't explain why the language of the compiler matters. I could write a C compiler in Pony-lang targeting a 30-year-old MCU were I so inclined.
The available compilers targeting your microcontroller certainly matter, though. You certainly still find lots of options that aren't Rust-compatible, but a non-trivial number microcontrollers are ARM or RISC-V based now, and can be targeted by LLVM/Rust.
The point is that you limit where you're doing that.
Like just as an example - I can write an allocator and toggle register bits etc. All of that requires unsafe code, raw pointers, etc.
But I can then build on top of that in safe Rust, with all the guarantees that brings. I still have to check that the unsafe allocator or whatever work soundly, but Rust checks the stuff on top of it.
Doing error handling properly is hard, but it's a lot harder when error types lose information (integer/bool returns) or you can't really tell what errors you might get (exceptions, except for checked exceptions which have their own issues).
Sometimes error handling comes down to "tell the user", where all that info is not ideal. It's too verbose, and that's when you need anyhow.
In other cases where you need details, anyhow is terrible. Instead you want something like thiserror, or just roll your own error type. Then you keep a lot more information, which might allow for better handling. (HttpError or IoError - try a different server? ParseError - maybe a different parse format? etc.)
So I'm not sure it's that Result is clumsy, so much that there are a lot of ways to handle errors. So you have to pick a library to match your use case. That seems acceptable to me?
FWIW, errors not propagating via `?` is entirely a problem on the error type being propagated to. And `?` in closures does work, occasionally with some type annotating required.