Ah yeah I misread your comment. 100% agree.

I don’t want to sound condescending, but what do you think all this talk about Rust and AI tools is about?

Yeah I am aware. It's very good that they're looking at it and great that Linus is supportive and not a stuck-in-the-mud. Doesn't invalidate my comment thought. He's still saying security bugs are no worse than other bugs.

And if some feature turns out to be a gaping security hole you’ll quickly see it turn into a bug. That’s what the quote is about. Every security issue is a bug so it has to be handled like a bug and squashed.

I mean... I don't think that's what he's saying. Nobody is saying not to fix security bugs...

Should what be handled? Security vulnerabilities? Here's how you should handle security bugs differently to other bugs:

1. Report them separately and clearly. Don't hide by omission the fact that they are security bugs (common practice in Linux apparently). Coordinate with major vendors how to push fixes.

2. They are generally more important than other bugs so you should put more effort into detecting and preventing them. E.g. using fuzzing, sandboxing, formal methods, safer languages, safety annotations, etc.

3. They have high value on the grey market and people actively try to create them, so you need to design your system under that assumption. An obvious thing to do is software isolation so a bug in - to pick a random example xz - can't bring down ssh. Software isolation, microkernels, sandboxing etc. help with this.

There's no way you can say "they're just bugs". Maybe in the 80s. It's not the 80s.

On the web I would stick entirely with Typescript. There are plenty of server side Typescript systems; you don't need to resort to Python.

Most recently I've been using Deno's Fresh framework which is fantastic. Very easy to use and suitable for beginners IMO since you can start with traditional request per page & static templated responses - no complex state management.

Well this isn't a standard library either then. But seeing as it is literally called that I'd say your unusually restrictive definition is nonsense.

Yeah I agree.

formatting does depend on the type of variables. Go look at ktfmt’s codebase and come back after you’ve done so…

I skimmed it. It appears to visit the AST of the code and format that, as any formatter does. ASTs have not been type checked.

Can you give an example?

it gives you an option, just like if it was an interface. Did you actually try this out before commenting?

Precisely! It doesn't know the answer so it has to guess, or make you guess.

And how often are you naming functions the exact same thing across two different classes without using an interface?

You mean how often does the same field name come up more than once? All the time obviously! Think about common names like id, size, begin, children, etc. etc.

I’m sorry, but you clearly haven’t thought this out, or you’re really quite ignorant as to how intellisense works in all languages (including Ruby, and including statically typed languages).

I'm sorry but you clearly haven't thought this through, or you're just happy to ignore the limitations of Ruby. I suspect the latter. Please don't pretend they aren't limitations though. It's ok to say "yes this isn't very good but I like Ruby anyway".

Yeah I have yet to really use Deno in anger because so many people are like "but Python exists!" and unsurprisingly we now find ourselves with a mess of virtual environments and pip nonsense that has literally cost me weeks of my life.

Though if you're using Numpy that source like "proper work" not the infrastructure scripting we use Python for so I probably would go with Rust over Deno. I don't know of mature linear algebra libraries for Typescript (though I also haven't looked).

IMO probably the biggest benefit of Rust over most languages is the lower number of bugs and reduced debugging time due to the "if it compiles it probably works" thing.

that’s a tough sale to the product team

Sounds like you're not the boss enough!

I agree Rust has a pretty steep learning curve so it's definitely reasonable to worry about people learning it, especially existing employees. Though I don't really buy the "easier to hire people" argument. There are plenty of Rust developers actively looking for Rust jobs, so I suspect you get fewer candidates but the ones you do get are higher quality and more interested.

But anyway I don't think that argument holds for Deno. Typescript is in the same difficulty league as Python. Anyone that knows Python should be able to transition easily.

Yeah I was very impressed. The only problem with uv and third party tools in general is that the main reason we're using Python is because my boss didn't want people to have to install extra stuff to use it. I would prefer using Deno, but apparently a one-line rock solid install command is too much to ask compared to the mess of Python infra... smh.

Line numbers are absolute, not relative (normally anyway; I think some editors allow showing relative line numbers). Anyway I think holding down (page) up/down is going to be just as fast.

If I was using TS I would still document using TSDoc anyway.

Yeah but you wouldn't put the types there. Putting types in JSDoc is awkward.

You can use jsconfig.json instead.

Unfortunately not. I even went as far as reading the source code for VSCode. There's no way to e.g. set noUncheckedIndexedAccess.