And all foreign agents should be allowed to freely operate everywhere simply because Putin has falsely accused at least one person of being a foreign agent? Espionage sure is easy these days.
I think you need look no further than the fact that they removed “don’t be evil” from the top of their code of conduct for evidence that their PR isn’t great. It was an essentially meaningless move and the headlines wrote themselves.
The switches with defaults are both switching over a String with only literal cases. That can't be exhaustive without a default, and switch expressions must be exhaustive.
I'm saying telling people they shouldn't do something is about as useless as farting in the wind. Blaming someone does nothing, it's the force of action behind the words that mean something.
But, because this person could be anyone, anywhere your words are hollow and empty. You are impotent to stop their future actions.
That this is too simplistic. There are obviously many solutions with different trade offs, but this one sacrifices secrecy to help catch fraud, and it’s not even effective at catching fraud.
I don't understand how you could arrive at this perspective. If you're doing business with ExampleCorp and one of their subcontractors malfeasantly mishandles things, would you say that ExampleCorp had nothing to do with it? If not, why does that change when the interaction happens via example.com?
Eh. Java was released in 1995. Smashing the Stack for Fun and Profit was published in 1996. The big selling point for java in the beginning was write-once-run-everywhere. Being a GCed language was also a selling point, but that is distinct from memory safety as a selling point.
No mainstream compiler is formally proven. If you want a verified compiler, you pretty much have to choose between using a subset of standardml or a subset of C and the one proven compiler for each.
You're mistaking the semantics of the type system, from the implementation. I'm not talking about verifying the compiler. There's nothing to verify there.... literally. There is no spec to the language. By definition it is verified because the only verification you can do is tautological: "does this rust compiler do what this rust compiler does?"
But the unsoundness is because the type system itself, abstractly, was not verified. Or the interactions between parts. I.e. If you verified the compiler you'll find that it implements the algorithms perfectly. But tells you nothing about whether those implemented algorithms, however perfectly implemented, actually provided those guarantees.
They probably meant things like LLVM and the various optimization passes. None of those are verified, there’s probably all sorts of correctness issues, and yet it’s still ok. Rust’s usage also has issues and bugs emitting the right intermediate form for LLVM to consume and usually also it’s ok.
Would it be nice if we had even higher level of quality? Yes. But what’s neat is we have empirical evidence - Rust code does achieve the memory safety goals over C++ even though there’s bugs in the compiler. That’s why Rust is very quickly eating all things C and C++. A huge amount of value that the industry would just be unable to access for a long time if you waited for everything to be formally proven.
Okay, but verifying a type system and language specification for soundness wouldn't actually give you any of the guarantees you want if the compiler toolchain isn't verified to implement them correctly. And this sort of thing just isn't standard practice in the industry and never has been. Sure it would be nice if more things were verified, and we are somewhat headed in that direction, but it seems weird to say that rust specifically is just a bunch of half-baked yoloing because it doesn't do something that essentially no other language is doing either.
reply