Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Also: x86 is very much statically typed. Your types are 8-, 16-, 32- and 64-bit words. Each machine instruction knows the exact types of its operands, so there's no overhead on determining the types of values at runtime (like you'd need to do in case of dynamic typing).


It's a tangent but a good one.

Machine code, at least x64/aarch64/amdgpu and the like, cannot be considered statically typed.

1/ there is no static checker

2/ if there was, the interpreter would run the failing code anyway

3/ memory can be integers, floats, machine instructions all at the same time

4/ registers overlap, e.g. writing to a 'i32' probably zeros the adjacent 32 bits in the same register

5/ instructions on the same register sometimes refer to floats and sometimes to integers

It also isn't dynamically typed, though a kernel might kill the program or hardware crash on some operations.

I think it's most usefully considered untyped in that there's no ahead of time verification and there's no runtime checking either.


What is "untyped" exactly? Google tells me it's the same as "dynamically typed".

Remember the context. The thread started with Elang VM making it impossible to make code faster, due to the need to accommodate Erlang's dynamic typing features and do runtime checks for that. Top comment said that dynamic typing per se can't be the obstacle for programs being faster, and gave x86 as an example of a presumably dynamic VM which does not limit the speed of the programs.

So "dynamically typed" from the article here meant that there's some runtime checks you can't unsubscribe from, and due to them there's a cap on how much faster you can make your code. It applies to some extent to x86, there's also checks there like segfault for example, and maybe you could save some space on silicon if you removed them and required the machine code to be verified to never cause segfaults. But I argue that this is too much of a stretch. Runtime checks that x86 performs are negligibly simple, and x86 is not a valid counter-example for the article's point. In my view the article's point is valid.

> 1/ there is no static checker

"return 0" is the static checker for x86 machine code.

But seriously: this is not a necessary condition for something to be statically typed, it can't be.

> 2/ if there was, the interpreter would run the failing code anyway

Failing code does not exist. All code is valid.

Haskell is undoubtedly statically typed. But division by zero will still cause a runtime error.

> 3/ memory can be integers, floats, machine instructions all at the same time

Ok. Disregard what I said about machine words. The only datatype in x86 is byte. Some operations use 2 bytes, some use 4. They may interpret them differently (some may see an int, some float), but it changes nothing, since both int and float operations are operations on bytes.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: