4 ms·

> The bulk of my trust is consolidated in the Go project, and thanks to their stellar reputation and solid operating procedures, I don't feel a need to review t

> The bulk of my trust is consolidated in the Go project, and thanks to their stellar reputation and solid operating procedures, I don't feel a need to review the source code of the Go compiler and standard libraries. Well... I have reviewed the Go runtime, after I ran into a bug in it... And that's one of the reasons I no longer use Go unless forced to. That thing is ugly under the covers. There is seriously quite a bit of insanity and poor design going on, e.g. when they did the ARM port they had to make a ton of changes to data structures/functions to include the link register, because they didn't or couldn't abstract out architecture specific tidbits like that. Also, the whole C interop stuff is nuts with a ridiculous call chain and several stack switches every time you call to or from C code (this is where I found the bug). Not saying people shouldn't use it, but I wouldn't hold the deep guts of Go up as an example of stellar development practices. Maybe all the stdlib stuff on top is prettier, but the runtime sure isn't.

self 7y ago
> That thing is ugly under the covers. Was the code you looked at in Go 1.5 and above? Is it cleaner in 1.4? They used automated tools to convert the C code into Go for 1.5.
- marcan_42 7y ago
  They were halfway through the process when I made my contribution, and in fact I had to rewrite it in Go. The Go version was just a straight conversion; being Go didn't make it inherently cleaner.
  - zeveb 7y ago
    I think his point is that it stands to reason that machine-converted C→Go code may be pretty ugly. Maybe it was better when it was clean, Plan-9-style C? Maybe it is better now, after some number of years of cleanup?
Blackstone4 7y ago
So would you use?
grammarxcore 7y ago
I ran into a speed issue last year messing around with Go RSA keys. Turns out it's an open bug. Even though fixes have been made (see links in the thread), it's not a global fix and Go ciphers can be absysmally slow. https://github.com/golang/go/issues/20058 https://github.com/golang/go/issues/20058 The recommended fix is to use a library like this one. However, that means your containers blow up with complicated dependency trees so it's not really a good solution for a distributed container architecture (eg Kubernetes). https://github.com/ncw/gmp https://github.com/ncw/gmp I love working with Go because of its simple binaries and small containers, but there are some things that it just does not do well.
- dependenttypes 7y ago
  I don't know if using gmp for RSA is a good idea. I am pretty sure that gmp would open you to side channel attacks due to its operations not being constant time.
  - aseipp 7y ago
    GMP has constant time functions for the relevant primitives you'd need to implement RSA (notably, constant-time/space modular power functionality). You'll probably still fuck it up completely anyway if you're doing it yourself, but not because of that.
  - grammarxcore 7y ago
    I abandoned the project because I couldn't find a reasonable solution using standard Go libs that worked in a reasonable timeframe. The bottleneck is this function. math/big.addMulVVW There was some work on it recently. https://go-review.googlesource.com/q/addMulVVW https://go-review.googlesource.com/q/addMulVVW But I feel like this issue might have been ignored. https://go-review.googlesource.com/c/go/+/164966 https://go-review.googlesource.com/c/go/+/164966 It might be addressed in Go 1.14 (although it's been marked as Backlog since I last looked at that issue). https://github.com/golang/go/issues/32492 https://github.com/golang/go/issues/32492 Point being Go, like OP of this thread suggests, has some issues. This is, to me, a critical flaw preventing my teams from using Go as a primary web language. It is both consistently faster and consistently timed to make an external call to, say, gpg2 to generate a key than it is to use the opengpg lib that relies on math/big. That's nuts.
SamWhited 7y ago
The standard library is generally very well designed and has good practices with the caveat that you should stay away from encoding/*, there be dragons.

self 7y ago

> That thing is ugly under the covers. Was the code you looked at in Go 1.5 and above? Is it cleaner in 1.4? They used automated tools to convert the C code into Go for 1.5.

marcan_42 7y ago
They were halfway through the process when I made my contribution, and in fact I had to rewrite it in Go. The Go version was just a straight conversion; being Go didn't make it inherently cleaner.
- zeveb 7y ago
  I think his point is that it stands to reason that machine-converted C→Go code may be pretty ugly. Maybe it was better when it was clean, Plan-9-style C? Maybe it is better now, after some number of years of cleanup?

Blackstone4 7y ago

So would you use?

grammarxcore 7y ago

I ran into a speed issue last year messing around with Go RSA keys. Turns out it's an open bug. Even though fixes have been made (see links in the thread), it's not a global fix and Go ciphers can be absysmally slow. https://github.com/golang/go/issues/20058 https://github.com/golang/go/issues/20058 The recommended fix is to use a library like this one. However, that means your containers blow up with complicated dependency trees so it's not really a good solution for a distributed container architecture (eg Kubernetes). https://github.com/ncw/gmp https://github.com/ncw/gmp I love working with Go because of its simple binaries and small containers, but there are some things that it just does not do well.

dependenttypes 7y ago
I don't know if using gmp for RSA is a good idea. I am pretty sure that gmp would open you to side channel attacks due to its operations not being constant time.
- aseipp 7y ago
  GMP has constant time functions for the relevant primitives you'd need to implement RSA (notably, constant-time/space modular power functionality). You'll probably still fuck it up completely anyway if you're doing it yourself, but not because of that.
- grammarxcore 7y ago
  I abandoned the project because I couldn't find a reasonable solution using standard Go libs that worked in a reasonable timeframe. The bottleneck is this function. math/big.addMulVVW There was some work on it recently. https://go-review.googlesource.com/q/addMulVVW https://go-review.googlesource.com/q/addMulVVW But I feel like this issue might have been ignored. https://go-review.googlesource.com/c/go/+/164966 https://go-review.googlesource.com/c/go/+/164966 It might be addressed in Go 1.14 (although it's been marked as Backlog since I last looked at that issue). https://github.com/golang/go/issues/32492 https://github.com/golang/go/issues/32492 Point being Go, like OP of this thread suggests, has some issues. This is, to me, a critical flaw preventing my teams from using Go as a primary web language. It is both consistently faster and consistently timed to make an external call to, say, gpg2 to generate a key than it is to use the opengpg lib that relies on math/big. That's nuts.

SamWhited 7y ago

The standard library is generally very well designed and has good practices with the caveat that you should stay away from encoding/*, there be dragons.