emk + golang   32

Golang SSH Redux : The Grumpy Troll
"I look at two approaches to programming language security. On the one hand, the Golang maintainers have a type-safe language immune from buffer overruns, with text templating systems designed to auto-escape data appropriately to avoid various web-based attacks (JS injections etc) and where an API which is being heavily misused gets changed to force folks to confront their problem space more fully. On the other hand, we have C compiler maintainers who assert that any behavior not defined in the C standard is not something where they have to pick one behavior and stick with it, but can instead declare it an impossible situation, that code which relies upon common assumptions is buggy, and proceed to optimize away the security checks.

If I program in C, I need to defend against the compiler maintainers.

If I program in Go, the language maintainers defend me from my mistakes."
golang  ssh  security 
april 2017 by emk
Go Learn
Common errors. Oh, and Go's map type is not threadsafe.
march 2016 by emk
Certificate authority, automated.
golang  ssl 
april 2015 by emk
Wrapper around some cloud APIs. What about AWS?
golang  cloud 
august 2013 by emk
Introducing Heka | Mozilla Services
Go-based monitoring system. Sounds nice.
server  sysadmin  monitoring  golang 
april 2013 by emk
Why I’m not leaving Python for Go | Ubershmekel's Uberpython Pythonlog
To quote Tim Peters:

Errors should never pass silently
Unless explicitly silenced
golang  programming 
september 2012 by emk
True Scala complexity | @yaaang's blog
Generics really seem to amplify any design flaws in the underlying language. Languages like Scala and C++—which have messy, backwards-compatible type systems—seem to suffer the most.

This does not bode well for Go. Go already has a number of features which will probably lead to headaches:

1. Struct and reference types in the same language. Necessary but not simple.

2. Deliberate conflation of struct and pointer types, thanks to how the "." operator works.

3. new (including implicit initialization to 0) vs. make vs. newFoo

4. Named typed aliases which differ in the interfaces they implement when compared to the underlying types.

It seems to me that if you layer a generics system on top of what Go already provides, you're likely to get a complex mess, because the underlying language is already surprisingly complex.
scala  languagedesign  generics  golang 
january 2012 by emk

Copy this bookmark: