Constant Time • Hacker News Board

Re: Constant Time

#11

Post by apta » Tue, Jun 11, 2019, 5:30 AM UTC

stouset wrote: post #3

The piece starts off with > “Numbers are just numbers, you’ll never see 0x80ULL in a .go source file”. Yet almost immediately afterward, we see the expression: const uintSize = 32 > 32 & 1) How is `uint(0)` not just `0u` by another name? And doesn't this code snippet unnecessarily depend on specifically 32-bit and 64-bit architectures? As opposed to something like Rust's `mem::size_of:: ()` which is both constant-tim…

It's just more golang hype that people read without questioning. int and uint are just one of the many golang mistakes (ironically, another one is mentioned in the article: the way time is defined).

Finally, just repeating that "golang consts are powerful" doesn't make them so.

Re: Constant Time

#12

Post by apta » Tue, Jun 11, 2019, 5:38 AM UTC

_bxg1 wrote: post #8

> Because, by definition, sentinel errors are exported public variables, any code that imports, for example, the io package could change the value of io.EOF. I haven't tried Go but this already makes it look... dubious.

it's another drop in the bucket of things that make dealing with golang code bases messy and error prone

Re: Constant Time

#13

Post by clappski » Tue, Jun 11, 2019, 1:39 PM UTC

ohazi wrote: post #5

const uintSize = 32 > 32 & 1) > If we’re on a 64 bit platform then the exclusive or of the number zero–all zero bits–is a number with all bits set, sixty four of them to be exact. That's not exclusive or, that's bitwise complement (~ in C). Go reuses the carat symbol for this, but xor needs two inputs.

Why does Go redefine `^` to mean something that it doesn't mean in all the programming languages I know? Is there a reason that xor isn't `^`?