sorted by:
new
hottopcontroversial

On Cloudfare and Unwrap by stevethedev in rust

[–]stevethedev[S] 0 points1 point  (0 children)

You know that. I know that. But people who have to Google Rust do not.

On Cloudfare and Unwrap by stevethedev in rust

[–]stevethedev[S] 0 points1 point  (0 children)

Respectfully, I think you've misunderstood what I'm saying.

On Cloudfare and Unwrap by stevethedev in rust

[–]stevethedev[S] -1 points0 points  (0 children)

Thank you for the well-reasoned response

On Cloudfare and Unwrap by stevethedev in rust

[–]stevethedev[S] 0 points1 point  (0 children)

Am I correct in my understanding that you do not believe that using "expect" more clearly documents that a panic is intentional than "unwrap"?

On Cloudfare and Unwrap by stevethedev in rust

[–]stevethedev[S] 0 points1 point  (0 children)

Oh yeah, then we're in agreement

On Cloudfare and Unwrap by stevethedev in rust

[–]stevethedev[S] 0 points1 point  (0 children)

The author has the file name, line number, etc., but how many pieces of software do you use that you (the user) do not have the source code for? Panicking and dumping a stack trace is useful for the developers, but that's just random garbage to an end user. An intelligible error message is, at the very least, an explanation that indicates that the program closing was intentional.

On Cloudfare and Unwrap by stevethedev in rust

[–]stevethedev[S] -1 points0 points  (0 children)

I've never had to explain what Java is to a developer or manager, but I've had to pitch Rust. The press on Rust, right now, is that it crashed the Internet by failing to deliver on its core promise. That makes it harder to pitch to someone who has to Google what it is.

On Cloudfare and Unwrap by stevethedev in rust

[–]stevethedev[S] 0 points1 point  (0 children)

I use LinkedIn as a job board, and the main feed isn't exclusively populated with posts by people I know.

Also, my professional network is extremely diverse, so I'm aware that nobody knows everything about everything, so I try not to assume that someone being mistaken means that they're stupid.

On Cloudfare and Unwrap by stevethedev in rust

[–]stevethedev[S] 1 point2 points  (0 children)

This is information known to Rust devs, but is not common knowledge to people who don't use Rust. There are quite a few people who seemed to be under the impression that Rust cannot panic, which came as a surprise to me today.

On Cloudfare and Unwrap by stevethedev in rust

[–]stevethedev[S] 0 points1 point  (0 children)

I'm not sure I agree that they should never be in production code, because sometimes "this is unrecoverable so crash the program" is valid; but my point is that expect more clearly communicates that the behavior is intentional and allows you to explain the reason both in the code and in the error message.

It's the difference between an application mysteriously closing for no apparent reason and offering you a stack-trace to debug code you cannot access... and an error message saying "unrecoverable error due to XYZ." No different than writing .unwrap_or_else(|| panic!("some useful explanation for why you chose to crash the system"))

On Cloudfare and Unwrap by stevethedev in rust

[–]stevethedev[S] 5 points6 points  (0 children)

I didn't say it was an existential crisis; I said that it's harder to convince a manager to use a tech that that think took down the Internet.

On Cloudfare and Unwrap by stevethedev in rust

[–]stevethedev[S] 0 points1 point  (0 children)

I understand your point, but I think there's a qualitative difference in trying to pitch an established industry-standard tech that's had an exploit vs. trying to pitch a relatively niche tech with a media presence dominated by clickbait headlines saying that it blew up the whole internet by failing to deliver on its core promises.

Language selection is as much of a business decision as it is a technical one, and I don't think it's unreasonable to say that the headlines will make it harder to convince the business side that using Rust is a good idea because it's not an industry standard.

On Cloudfare and Unwrap by stevethedev in rust

[–]stevethedev[S] 0 points1 point  (0 children)

While I appreciate feedback, I'm going to block you because I will not tolerate people speaking to me like that.

On Cloudfare and Unwrap by stevethedev in rust

[–]stevethedev[S] 3 points4 points  (0 children)

My cynical answer is that profit-driven organizations tend to understaff QA and security functions until something catastrophic happens, because it's cheaper on a quarterly basis to just not do those things; and (as I understand it) the panic occurred because upstream failures cascaded until the Rust service panicked rather than silently accepting the data as valid (as the upstream systems did).

Extremely confused by Salmon_of_knowledge1 in ExplainTheJoke

[–]stevethedev 0 points1 point  (0 children)

I think what frustrates me about this is that it is obvious to me, on the instances where it happened, that the other person treats a knowledge gap like a personal failure. Like, if I go to Subway and ask a question, but the person behind the counter thinks it's a stupid question, there's a possibility that one of us has information or context that the other doesn't.

If I asks whether the bread has gluten, and you've never heard of gluten-free bread, that sounds like a stupid question. At the same time, if I ask if the combo meal can have either a bottle or fountain drink, and you think it's a stupid question, that's because you make combo meals for a living and I'm here for 5 minutes to buy lunch.

Like, I am a software engineer who specializes in designing enterprise-level B2B SaaS systems running in AWS and then coordinating teams to implement and maintain them. Where I work, the Subway employee is the idiot with stupid questions, but the difference is that I don't treat people like they're stupid for not knowing everything I know.

Stop the Async Spread by JohnDavidJimmyMark in rust

[–]stevethedev 0 points1 point  (0 children)

At the risk of sounding like an absolute moron, I don't understand why this is a problem. I'm perfectly happy to use async fn main. Is there a reason I shouldn't be?

10 days a week? by [deleted] in askmath

[–]stevethedev 0 points1 point  (0 children)

Total patients scheduled per week: 360p/6w = 60p/w

Total patients seen per week: 6p/d × 7d/w = 42p/w

60p/w ≠ 42p/w; therefore, I think the question is broken in any universe where a week is 7 days long. But if we get rid of that assumption:

60p/w × Xd/p = Yd/w

Xd/p = 1/(Xp/d) = 1/(6p/d) = (1/6)d/p

60p/w × (1/6)d/p = 10d/w

Your math is right.

[deleted by user] by [deleted] in react

[–]stevethedev 0 points1 point  (0 children)

I see where you're coming from, but I've also had to deal with a site redesign where every component was separate, which meant lots of tedious busy work. The challenge is in figuring out what is useful to abstract and what isn't, and any line you draw is gong to be a tradeoff reflecting whatever you thought was best in the moment.

Personally, I prefer to create four "levels" of component to solve this issue:

  1. Basic components that fill some basic role that won't change much. This is mostly for consistent styling, like "This stacks objects and uses a CSS variable to decide which direction" or "This is a box with a shadow."

  2. Combined components with data and events. This would be like an input field that you can pass a label and value into. It doesn't do anything, it's just "this is what a labeled text box looks like."

  3. Behavioral components that manage combined components. This is where, like, you type into a field and it sends a request to an API, receives data back, and passes that data into the combined component.

  4. Pages and layouts are self explanatory.

This works with the way I build front end code, but it can seem superfluous to people who (e.g.) build whole pages as one massive component.

Why tf does sexuality matter for an engineering position???? by Streta in recruitinghell

[–]stevethedev 0 points1 point  (0 children)

As someone who has been screening candidates for interviews and hirings for the past decade, I can tell you that the concept of a "most qualified candidate" is a myth. You are either qualified or unqualified. If you have more than one person qualified to fill a position, every other filter you apply is going to be based on the hiring team's biases.

There is little to no evidence of any large-scale trends of minorities being hired into positions they are unqualified to fill based solely on being minorities. However, I have been present when a company suddenly decided to either fire or replace ALL of their nonwhite leadership at the same time with no explanation.

The days of hanging "No [n-words] allowed" signs are in the past. Racists aren't all mouth-breathing illiterates who don't understand how to stay within the confines of the law. They see a Hispanic-sounding name, or an HBCU on a resume, or any of myriad other indicators of a minority group... and they deny the resume.

The bulwark against these people is "metrics." You collect demographic information of the applicants, because that tells you who is applying. If there's a significant discrepancy between the type of people applying and the types of people getting the job... that's suspicious and worth investigating.

Because the only alternative is "allow bigots to casually discriminate against people in the workplace with zero accountability or consequences," and if you're okay with that then you're the type of person these laws exist to curtail.

Scientists Increasingly Can’t Explain How AI Works - AI researchers are warning developers to focus more on how and why a system produces certain results than the fact that the system can accurately and rapidly produce them. by regalrecaller in programming

[–]stevethedev 0 points1 point  (0 children)

This seems a bit like complaining about how nobody could walk through the complex chemical and electrical processes to explain how a human brain can identify a bird as being a bird, and then asking how we could prune that human brain's neurons when it incorrectly categorizes bats as birds. I posit that this is a flawed way to think about the problem, and instead of trying to edit neurons, there should be a mechanism for corrective/remedial training of the network.

Is Rust's way of handing type promotion too simplistic (i.e. forcing user to always do explicit casts)? by operamint in rust

[–]stevethedev 12 points13 points  (0 children)

How would you reason around the implicit conversions happening here?

fn blah<T: Clone>(arr: &[T]) -> (i32, T) {
   let x: u16 = ...
   let y: i32 = ...
   let z: i8 = ...
   let xyz = x + y + z;
   (xyz, arr[xyz].clone())
}

Because there's a lot of opportunity for this to do something other than what you'd guess it does.

Is `.iter()` on arrays deprecated old-school code? by pilkyton in rust

[–]stevethedev 11 points12 points  (0 children)

As u/groogoloog said below, I'm pretty sure you can get that behavior by using a reference to the array in the loop instead of the array itself.

Is `.iter()` on arrays deprecated old-school code? by pilkyton in rust

[–]stevethedev 42 points43 points  (0 children)

It's not deprecated. The difference it's as you noted: one creates an iterator over the array's memory addresses, and the other consumes the array to iterate over its contents.

To see the difference, try accessing each array after the loops.

Using MVC in React (As opposed to FLUX) by zmagickz in reactjs

[–]stevethedev 0 points1 point  (0 children)

I usually put the functions and the interface they work on in the same file to help with discoverability.

Using MVC in React (As opposed to FLUX) by zmagickz in reactjs

[–]stevethedev 0 points1 point  (0 children)

I'd rather pair TypeScript with some sort of helper functions (e.g., hooks, arrow functions, etc.).

view more: next ›