Hacker News Reader

Comment by turnsout | Hacker News Reader

Right, but unlike Swift, the type system in JS is not doing computationally expensive type checking for each element. This is the equivalent of creating 1M DOM trees in JS and expecting it to be responsive.

Rather than trying to force Swift to create fixed dimension arrays, the uncomfortable part about Swift for control freaks is that you should just make the array dynamic, and trust that the compiler is smart.

It's not blaming the user, but the compiler team has to balance functionality ("Why can't the type system give me a better error?") and speed. There's no way they can handle every pathological edge case gracefully.

View on HN

> computationally expensive type checking

So, an hour's worth of compilation time = 3600 seconds, divided by a million elements, that's 3.6 ms, or about 10 million instructions per element. Just what in the heck is this compiler doing with 10 million instructions on an integer literal? Like, it's never seen integer literals before? And they're all integers. Every element. It's not a "pathological edge case". The whole thread is absurd. People are speaking up and blaming programmers, the language, the type system, when this is so obviously the compiler's fault.

We have absurdly fast hardware these days.

I can barely believe that a single thread, copy pasted quicksort can sort 1M elements in less than 50ms on my computer.

Fast compilers such as TCC should be frequently used as a reality check for compiler teams. Of course the constraints are not the same but still...

I have no idea what's going on under the hood, but I'm sure it's not a linear time process, and all it takes is one of those elements to be "109.1" to flip 1M elements from Ints to Doubles. Yes, they could special-case this (and arrays of Doubles, and Strings), but where do you draw the line? That's now extra code to maintain in the compiler just to support a behavior that should be discouraged. If you need to read in 1M integers, put them in a file and read them in.

> should be discouraged. If you need to read in 1M integers, put them in a file and read them in.

This is exactly the attitude that needs to be addressed. It's hostile to argue with users who are doing something completely legal and tell them they shouldn't do that, they should do it another way, that that behavior needs to be discouraged, etc.

We went through this all the time with V8, trying to tell JS developers they just shouldn't do that because V8 had couldn't run that code fast. Or worse, that it had a particular pathology that made certain code absurdly slow. It just doesn't fly. It's V8's job to not go off the rails for user inputs; it should provide good default performance all the time, not get stuck in deopt loops, use absurd amounts of memory, etc. Yeah, and that's hard work.

I hear you, ideally the compiler should be able to manage any arbitrary input in a reasonable time, and catch itself if necessary. Usually it does—sometimes with complex ungrouped arithmetic operations with ambiguous types, Swift will error out and tell you to break up your expression, rather than get stuck.

I would love for the Swift compiler to be dramatically faster, but I understand the challenge, with a powerful type inference engine that supports Generics. It's a resource scarcity problem. If the Swift team spends 10 hours to handle long strings of integer literals, that's 10 hours they haven't put toward features that would benefit a larger audience.

Your take sounds more reasonable. I would think you would get diminishing returns if you try to solve all pathological cases.

Sometimes it is the fault of the language design too. Maybe the language spec needs to be changed. Imagine all the wasted effort to optimize V8 when you could have put static typing into Javascript itself.

Indeed—Chris Lattner has mentioned recently that in retrospect, he regrets certain Swift design decisions which have made the compiler so complex and relatively slow.

> If you need to read in 1M integers, put them in a file and read them in.

..and if you're in a context where you need that data in the binary, because you don't have a reliable place to store a file?

> That's now extra code to maintain in the compiler just to support a behavior that should be discouraged.

If you don't want to maintain the code to properly support a language feature, don't include that feature in the language.

For a compiled language it seems reasonable to assume that "put them in a file and read them in" means at compile time, like the C23 pre-processor feature #embed and the Rust macro include_bytes!

Now, #embed and include_bytes! always give you bytes (in Rust these are definitely u8, an unsigned 8-bit integer, I don't know what is promised in C but in practice I expect you get the same) because that's what modern files are - whereas maybe you want, say, 32-bit big endian signed integers in this Swift example. But, Swift is a higher level language, it's OK if it has some more nuance here and maybe pays a small performance penalty for it. 10% slower wouldn't be objectionable if we can specify the type of data for example.

> But, Swift is a higher level language, it's OK if it has some more nuance here and maybe pays a small performance penalty for it.

I thought the concern was about compile time performance? I'm not sure what Swift being higher-level has to do with that.

The comments on that Swift forum seem to indicate that the slowness is not caused by the type checker though.

Reply on news.ycombinator.com