xyzzyz

Again, this paper just looks at the correlations, and does not touch causation at all. You can run a hundred studies, each of them finding high correlation between wet streets and having rained recently, but you cannot conclude from that that the wet streets caused the rain to fall.

As a matter of fact, you cannot do

  let s = “asd”;
  println!(“{}”, s[0]);

You will get a compiler error telling you that you cannot index into &str.

Imagine that you're writing a function that'll walk the directory to copy some files somewhere else, and then delete the directory. Unfortunately, you hit this

https://github.com/golang/go/issues/32334

oops, looks like some files are just inaccessible to you, and you cannot copy them.

Fortunately, when you try to delete the source directory, Go's standard library enters infinite loop, which saves your data.

https://github.com/golang/go/issues/59971

> If you use 3) to create a &str/String from invalid bytes, you can't safely use that string as the standard library is unfortunately designed around the assumption that only valid UTF-8 is stored.

Yes, and that's a good thing. It allows every code that gets &str/String to assume that the input is valid UTF-8. The alternative would be that every single time you write a function that takes a string as an argument, you have to analyze your code, consider what would happen if the argument was not valid UTF-8, and handle that appropriately. You'd also have to redo the whole analysis every time you modify the function. That's a horrible waste of time: it's much better to:

1) Convert things to String early, and assume validity later, and

2) Make functions that explicitly don't care about validity take &[u8] instead.

This is, of course, exactly what Rust does: I am not aware of a single thing that &str allows you to do that you cannot do with &[u8], except things that do require you to assume it's valid UTF-8.

It's actually extremely hard to introduce problems like that, precisely because Rust's standard library is very well designed. Can you give an example scenario where it would be a problem?

You can easily treat `&str` as bytes, just call `.as_bytes()`, and you get `&[u8]`, no questions asked. The reason why you don't want to treat &str as just bytes by default is that it's almost always a wrong thing to do. Moreover, it's the worst kind of a wrong thing, because it actually works correctly 99% of the time, so you might not even realize you have a bug until much too late.

If your API takes &str, and tries to do byte-based indexing, it should almost certainly be taking &[u8] instead.

> There are a lot of operations that are valid and well-defined on binary strings, such as (...), and so on.

Every single thing you listed here is supported by &[u8] type. That's the point: if you want to operate on data without assuming it's valid UTF-8, you just use &[u8] (or allocating Vec<u8>), and the standard library offers what you'd typically want, except of the functions that assume that the string is valid UTF-8 (like e.g. iterating over code points). If you want that, you need to convert your &[u8] to &str, and the process of conversion forces you to check for conversion errors.

The way Rust handles this is perfectly fine. String type promises its contents are valid UTF-8. When you create it from array of bytes, you have three options: 1) ::from_utf8, which will force you to handle invalid UTF-8 error, 2) ::from_utf8_lossy, which will replace invalid code points with replacement character code point, and 3) from_utf8_unchecked, which will not do the validity check and is explicitly marked as unsafe.

This also epitomizes the issue. What's the point of having `string` type at all, if it doesn't allow you to make any extra assumptions about the contents beyond `[]byte`? The answer is that they planned to make conversion to `string` error out when it's invalid UTF-8, and then assume that `string`s are valid UTF-8, but then it caused problems elsewhere, so they dropped it for immediate practical convenience.

Sure, true RAII would be improvement over both, but the author's point is that Java is an improvement over Go, because the resource acquisition is lexical scoped, not function-scoped. Imagine if Java's `try (...) { }` didn't clear the resource when the try block ends, but rather when the wrapping method returns. That's how Go's defer works.

Go was designed by some old-school folks that maybe stuck a bit too hard to their principles, losing sight of the practical conveniences.

I'd say that it's entirely the other way around: they stuck to the practical convenience of solving the problem that they had in front of them, quickly, instead of analyzing the problem from the first principles, and solving the problem correctly (or using a solution that was Not Invented Here).

Go's filesystem API is the perfect example. You need to open files? Great, we'll create

  func Open(name string) (*File, error)

function, you can open files now, done. What if the file name is not valid UTF-8, though? Who cares, hasn't happen to me in the first 5 years I used Go.

This paper is literally just authors coming up with some model and simulating it, without any real world evidence whatsoever. It’s an argument from fictional evidence. Is this the best you can do?

No, the claim was that inequality drives crime, and all you’re showing is correlation. As I’m sure you’re aware, correlation is not causation.

No, that’s absurd. When poor people kill other poor people, this is not a fault of rich people who happen to live nearby.

Only a tiny fraction of EV chargers are 100+ kW. Most are 10-20 kW. These are great for office parking garages or shopping malls, but stopping at one for 15 minutes gets you nowhere.

That’s just not how it works. There might be electricity there, but only enough to charge one car at a time. Works for my home garage, but would not work for apartment complex.

The constitution has already existing answer: instead of agencies passing regulation, Congress passes laws. Agencies continue to enforce the law, and appeals are adjudicated by actual federal courts.

College freshmen actually consume way more electricity than LLMs on the same task.

That's fine, because the powers not delegated to the United States by the Constitution are reserved to the people.

Congrats man, but that's not really germane to the point, which is that a 6 year old iPhone adequately satisfies the needs of majority of the population.

The "buy borrow die" strategy is a meme. It just doesn't work the way you think it works. People just repeat stuff they heard on the internet with no real understanding. It is useful to avoid paying the capital gains tax in the very short term, but is useless for periods over 4-5 years, because it loses you more money than you'd spend on taxes.

To be specific: let's say that you own $1.1B worth of stock, $1B of which is unrealized long term capital gains. If you sold it all today, you'd owe $200M. Let's say that you're 40, you spend $5M a year, and you die at 80. So, you need $200M to finance your lifestyle, and then the remainder is a part of your estate. If you just sold $240M today, you'd pay $40M in tax, and had $200M after tax cash in your checking account to spend over the next 40 years. If you instead borrow $5M a year against your stock at very attractive terms like interest rate of 5%, and no payments until your death, you'll owe $200M on interest over these 40 years. Just paying the tax would have saved you $160M! It's even worse if you get more realistic terms, because 5% rate on a personal loan is too good to be true, and you'll need to borrow even more to make the regular payments.

What about the remainder of your estate? Depending on whether you just sell as you go, or borrow to finance your spending, your estate is left with something between $500M and $800M. Guess what, now they owe estate tax, which is 40% of this sum (minus $30M exemption). Oops!

You can avoid the estate tax, though, but the kicker is that all of the ways of doing that do not allow you to step up the basis upon death: they just allow you to avoid the gift tax, but they do little to escape the capital gains income tax. No free lunch here either.

No, that’s just not how it works. People cannot become corporations. You cannot hire an army of tax lawyers to avoid owing any tax. There are no major “loopholes” either that would help you avoid paying tax on actual income you make. You are just repeating some vague bullshit people say on the internet, but it’s just not true.

I understand that you don’t like the European taxation regime, where the bulk of the tax burden is carried by the middle class, but I find it strange that then you give Bezos as a negative example. It is strange, because in US, unlike in Europe, it is the wealthy who pay most of the taxes. Our middle class pays very little tax, unlike middle class in Europe.

The fact of the matter is that “let the money vote” works much better than alternatives. “Reason and restraint” is precisely how we got to where we are.

Yes, and why did people ask for these oversized networks? That’s right, because addresses were free.

I don’t know anyone who uses their phone to play full graphics games or use it to plan out interior design, and for everything else, a 6 year old iPhone can most definitely do all of that. I know, because I did all of these things on an iPhone 11 up until earlier this year, and I only replaced it because the charging port was damaged.

We are in crisis precisely because nobody charged for IPv4 addresses in the past, and so overwhelming majority of those are wastefully allocated. What you want would exacerbate the crisis.

I don’t even know which group you mean, but “my group has good values and motivations, but the enemy group just values winning at any cost” is exactly what a total partisan who values winning at any cost would say.

That’s just confusing cause and effect. If your seats are safe, you have no reason to agree to forming an independent commission. The same is true in both heavily blue and heavily red states. Are districts more competitive in states where Democrats draw maps? I don’t think so.

> like not catastrophically breaking if you can't generate a unique random "k" for ECDSA

How does that work? I thought that this vulnerability was independent of the curve that is used. Ed25519 has a bunch of other nice properties related to resistance to programming errors, but I never heard of this one.