[peaky_blinder]

> Also, in Python integers do not overflow, unlike in Rust, C and other buggy languages.

There is no such thing as a buggy language. Software can be buggy (or language implementation), but not the language. And the reason you do not have integer overflow is because integers are implemented as integer objects of arbitrary size, which is great if you're doing something quick and dirty, but could be disastrous for a serious work.

[still_grokking]

> There is no such thing as a buggy language.

How can you know if you don't have a verified formal description of your language's semantics?

It's very much possible (and imho even quite likely) that a lot of language definitions are self contradicting.

Of course one could argue that such self contradictions aren't "bugs" at all. But such an argumentation would seem very odd, imho, no matter one can actually "define" whatever one likes.

[hnfong]

http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

> Signed integer overflow: If arithmetic on an 'int' type (for example) overflows, the result is undefined. One example is that "INT_MAX+1" is not guaranteed to be INT_MIN.

Probably not what the GP meant, but I think this qualifies as a "buggy language (spec)"

[still_grokking]

I don't think defining something as undefined is buggy per se. That's not what I've meant.

But defining some things in a contradicting manner would make up a buggy spec, I guess.

Regarding the int example, funny enough I made a comment about that just before here:

https://news.ycombinator.com/item?id=32457056

[pratk]

Well, we have defect reports in language specs too: https://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm

[dannymi]

>could be disastrous for a serious work.

How so?