williamsmj

They introduced levels 2.5 years ago. Almost all existing engineers were converted to L5 at that time (I was told ~90% during a recent job interview there). A very small number of L6s were created when they introduced levels (something like 20 according to my interviewer). L4s are post-9/2022 hires.

All of which is to say, the fact that most people are L5s, including people who've been there for a long time, is due entirely to the very recent introduction of leveling and the high bar for L6. It tells you nothing on its own about whether L5 is perceived as a terminal level.

You'd know better than us if you work there, and reading between the lines of your comment it sounds like maybe it is?

Bloomberg. The terminal level on their IC ladder is "Senior". They have no formal concept of Staff or Principal engineer. People spend decades there.

https://www.wired.com/story/x-ddos-attack-march-2025/

Seems like they forgot to put some services behind Cloudflare. CTO should be fired then. Oh, wait.

His claim is that it's a DDOS attack.

Not my area of engineering, so forgive me, but: is an external DDOS a plausible threat for competently engineered public service in 2025? I kind of got the impression those were solved problems in practice?

Were the "various overblown controversies" when he said "There is a trait in the Jewish character that does provoke animosity, maybe it's a kind of lack of generosity towards non-Jews. I mean there is always a reason why anti-anything crops up anywhere; even a stinker like Hitler didn't just pick on them for no reason"?

Or when he said the United States is "utterly dominated by the great Jewish financial institutions over there"?

Or when he said "I am certainly anti-Israel, and I have become anti-Semitic"?

Or are there others?

https://www.nytimes.com/1990/12/07/opinion/l-roald-dahl-also...

Fair. Deleted.

Deleted comment based on a misunderstanding.

Looks like a 2016 Nissan.

I was the owner of the domain potooooo.ooo from June 2020 to July 2021. I was pretty bored during early lockdown. I let it lapse. whois tells me someone else has now fallen into the trap of the $30 dad joke.

For what it's worth, the use case that caused me to finally "get" chatbots was as a support while reading the Aubrey-Maturin series. The first conversation in my Claude history is me asking it "Compare the relative strengths of cannon and carronades. Which was more accurate?"

(But if you prefer a book, https://www.amazon.com/Patrick-OBrian-Muster-Book-Aubrey-Mat... is very useful.)

Again, python does not use semantic versioning. 3.12 and 3.13 are different major versions. The deprecation policy is documented and public. https://peps.python.org/pep-0387/.

1. That python 3 statement was not drawn up by "the Python maintainers". It was drawn up by downstream library owners.

2. To the extent you object to changes in the core language, the python maintainers do have a backwards compatibility statement and prominent timelines for deprecation. You may disagree with these, but they are public.

3. At the time it was written, the python 3 statement proposed dropping support for a version of python with known security problems and no plans for security updates. It seems like your argument is with the python 2 to python 3 transition, which feels like a conversation we've had here before.

I’d be all for a deprecation warning on bare excepts. That might nudge a lot of people to fix their code without actively breaking anything.

The PEP proposes a deprecation timeline for exactly this.

It's obvious this construct is just injecting some additional information in a passing exception

There is a good chance it will fail to do that. See elsewhere in this thread.

"except:" is explicit enough and "except BaseException" is redundant.

Take that up with the consensus view of the python community, as reflected by python linters in their default configuration, almost all of which warn on bare except.

The debate in the PEP is whether this should be a syntax error. The debate about whether it is good style is over though.

It's also not worth breaking production code over this.

Agreed.

Python does the same thing. It just calls Throwable something different.

Java Throwable ~= Python BaseException.

Java Exception ~= Python Exception.

The problem here is that a bare except catches something similar to Throwable, not something similar to Exception.

1. Such a script is proposed in the PEP.

2. Python does not use semantic versioning. 3.13 is a different major version to 3.12.

Anyone reading your code is going to assume this is a bug. The PEP is right that explicit is better than implicit. You should write `except BaseException` (whether or not this PEP is approved).

Personally I think that would have been a better choice in Python's original design, but to change it now would be a backwards-incompatible change, i.e. it suffers from the same big problem everyone is highlighting in the PEP.

I have mixed feelings about this.

There are two "problems" this PEP is trying to solve.

One is that bare excepts are permitted. The argument against this is that explicit is better than implicit. A matter of taste, but I don't find this convincing.

The other problem is what bare excepts mean. Bare excepts are syntactic sugar for `except BaseException`. This means that an application containing a bare `except` followed by the vast majority of real-world error handling will continue to run even if SystemExit or KeyboardInterrupt is raised. This is almost always a bug.

I do find this second argument convincing, and I wish Python did not contain this design wart.

If I could go back in time and change Python syntax, it would make it hard for people to silently treat these special interrupts as "handleable" like regular errors. The tiny set of applications that really can and should handle them (e.g. TUIs or the mailman example discussed in the final section of the PEP) can explicitly do so with e.g. `except KeyboardInterrurpt` or even `except BaseException`.

But I agree with the consensus here that this does not rise to the level of something being worth a backwards-incompatible change.

With a bare except, your code will continue to retry even if SystemExit or KeyboardInterrupt is raised. This is almost always a bug.

In other words, your comment is an argument for the proposal!

I don't think it's a good enough argument to make a backwards incompatible change. This is a wart Python has to live with now. But I do think it's a shame that bare excepts behave in a way that is almost always a bug.

I'm weakly opposed to the PEP, but if your concern is that you're going to lose the ability to catch all exceptions in new code, then that's wrong as discussed in the Backwards Compatibility section, i.e. do "except BaseException".

We may never know https://news.ycombinator.com/item?id=41234180.

If you're referring to this PEP's "twin", i.e. "PEP 758 – Allow except and except* expressions without parentheses", that is not an opposing PEP. These two PEPs are orthogonal. One does not contradict the other. They are twins only in the sense that they are both about exception handling syntax.

This is just the Verge regurgitating a Reuters article that has already been posted https://news.ycombinator.com/item?id=40297126.

If the CTO builds an engineering team that lacks the expertise to write a regex that matches the company's own name, and builds a culture of security and quality process that failed to catch this before shipping to production, then the CTO should be fired for cause.

Unfortunately the CTO also owns the company.

People love trucks, so this might work out great for TSLA.

1. there is essentially no market for pick-up trucks outside the US.

2. the market for pick-up trucks inside the US is dominated by suburban American dads. They love trucks because they can imagine pulling up to a job site in one. We all know, even the suburban dads, that if you pull up to a job site in a Cybertruck, the guys working there are going to laugh at you. Look into your heart. You know this to be true. That's the kiss of death. (That and the fact the panel gaps are like two inches.)

The technological gap is tightening, Tesla was alone before, the same way that Nvidia is "alone" for now.

It's worse than that. Nvidia has a moat (deployed software and the open source software ecosystem) that buys them at least a few years, even if a well-resourced hardware peer appeared out of thin air tomorrow. Tesla has nothing like this. The cost of switching away from them is negligible, and they have half a dozen extremely well-resourced competitors.

22% of households in Manhattan own a car. There are about half a million households below 60th St. So there are about 100,000 cars in lower Manhattan that belong to residents. Of those, about 25,000 are used to get to work each day. The rest sit in garages.

So no, residents will not mostly be the ones paying the costs.

But suppose they were. So what? Sounds fair to me. We don't make the subway free for residents. Why should it be free to drive and store your vehicle just because you're a resident?

Ah, fair point! I don't see <title> elements in my browser setup and missed that. It's not the title shown in the article.