All rust code is UB because there is no spec. I don't mean this as a knock against rust, but against UB fear.

That is not what UB means. Undefined Behaviour is behaviour that the compiler is allowed to assume will never happen, and which can consequently cause miscompilations due to optimisation passes gone wrong if it does in fact occur in the source code.

It's true that Rust does not have a written specification that clearly delineates what is and isn't UB in a single place. But:

1. UB is impossible in safe code (modulo bugs in unsafe code)

2. There are resources such as the Rustinomicon (https://doc.rust-lang.org/nomicon/) that provide a detailed guide on what is and isn't allowed in unsafe code.

In practice, it's much easier to avoid UB in Rust than it is in C++.

I am familiar with UB as a result of memory unsafety, but the way it is talked about it sounds like the only ways to ever cause UB is with memory unsafety.

Based on that definition it feels like it should be possible to have UB outside of memory violations, is there really no UB in languages like Java/Haskell/Go?

You can have it for reasons other than memory safety, for example signed integer overflow is UB in C and C++ (but not in Rust). However, higher level languages typically go to great lengths to avoid it. For example, in Java you will get a NullPointerException rather a null pointer actually being dereferenced, which immediately rules out any UB due to a pointer being dereferenced where doing so is not allowed.

Wow signed overflow is UB? I would have assumed it was defined, it just allows overflow.

And I am assuming something like the NullPointerException comes with a huge performance hit? Otherwise I assume every systems language would do something similar.

I cannot think of a useful way to define signed overflow. I can make it do something, but at the end of the day no matter how you define it, if it happens in the real world your program has a bug.

Since we can be sure if it ever happens your code has a bug, making it undefined is a good thing: the compiler can then assume it doesn't happen and so back track to prove some other things can't happen and so make your program run a little faster.

I'd much rather have a bug in my program than UB. At least the bug is easy to track down and fix, and is limited in scope to the line of code that contains the error.

You sacrifice speedy code for this case that probably won't even happen and so you probably won't have to debug anyway. Is it really worth it?

> Wow signed overflow is UB? I would have assumed it was defined, it just allows overflow.

Presumably it's not defined because the behaviour depends on the signedness representation.

But Rust has kind of a spec: https://doc.rust-lang.org/reference/ Sure, it's not as well-specified as C++; so one could say it's "not a real spec".

But C++ also isn't perfect, there are plenty of programs for which no two compiler developers can agree on whether they have UB. The C++ spec language is just too ambiguous and underspecified in several areas.

If you want to be sure, you need an actual machine-checkable formal specification. Neither C++ nor Rust have that.

In the end, what really matter is the contract between the programmer and the compiler: are compilers allowed to break a program in weird ways because the programmer forgot about one of the arcane rules in the spec? For C++ and unsafe Rust, the answer is yes (we don't know how to build optimizing compilers for low-level languages otherwise). But for safe Rust, the answer is no. That's a big deal.

https://youtu.be/lKEqU2itOiw fear

Looking up information is vastly different than asking it to produce code to be included in a product.

Studies show you buy more with a credit card than cash. You think you're saving 1-3% but you would easily save that with slightly more conservative spending.

It's also worth mentioning the real business is analyzing the consumer data you give them for pennies.

I'd love to see the distribution on this. My bet is that most people don't spend more and a minority spend a lot more.

It's something as small as throwing in a milk shake with lunch. you don't experience the money leaving.

I'm still not sure. I don't use a credit card for most purchases, only big things, and I think a lot of people are in that boat.

I would guess 80% of the career value is captured by satisfying admissions and graduating. I think the actual grading isn't looked at except to rank similar peers for admission to other competitive programs.

This is exactly why companies should drop degree requirements. If 80% of the degree requirements are met when you graduate from HS (and I would say it's more than 80%), then why make them wait 4 years and take on a pile of debt?

OP didn’t specifically saying graduating high school. I read the post as graduating college was part of that 80%

And they afforded that working a job at a furniture store with no degree at age 24.

Only because discrimination was legal.

This kind of thing is why we have such long interview cycles and strong bias against false positives

...because a false negative is so much worse than a false positive.

I'll take less opportunities for more stability. Many people would. That's what this article is all about. Better for most to have less that you can rely on than more one year and less the other and no sense of calm.

You may be willing to make the tradeoff, but you should acknowledge the downsides.

The most extreme example is in academia where they get a lot of stability in exchange for an excruciating job hunt and interview process. And if they don't like the job, they are stuck.

I would rather have a world where we can take a chance on someone, then not. If you have all your ducks in a polished row, and look and act the right way, maybe you prefer protection against that.

For that to explain the gap I think you would have to consider how many of those employees who get written up live with their families vs more detached living arrangements. With that consideration, it seems unlikely that change alone could make up 15% for the overall group.

Indeed, hence the word “maybe”

That was my guess. A 14% reduction in efficiency or perhaps just hours worked sounds about right.

Because they also have vastly different cultures and shared understandings which often require skilled management.

Each thread opens its own connection. Set a non-zero timeout. I think that's all you need.