> you can't load shared library at runtime with Go. I've read again the documentation, and you're right: it's not possible as of Go 1.6. > Yeah, [Jeremy Saenz

> you can't load shared library at runtime with Go. I've read again the documentation, and you're right: it's not possible as of Go 1.6. > Yeah, [Jeremy Saenz] didn't feel humiliated so much he stopped writing about and programming in Go and interacting with the Go community all together It's true that I don't see Jeremy posting stuff on its blog, Twitter, GitHub or elsewhere since a few months, about Go, or about anything else. But how can you assert it's related to the Go community being harsh? > That doesn't make them more open to changes I'm a bit of a programming language geek because I like beautiful theoretical things. This is why I keep an eye on OCaml, Haskell, Erlang, Elm, Clojure, etc. I sometime share the frustration with Go being verbose and naive. But I also needs to get things done, and want my code to be readable, understandable and maintainable in 10 years. Go is an interesting tradeoff, betting less on the advances of PL theory, and betting more on good engineering (the excellent work on the garbage collector being a good illustration). Yes, I'd like some kind of shortcut for error handling (like the try! macro in rust), I'd like to be able to define custom generic functions and containers like the built-in ones, I'd like being able to declare non-nullable pointers, and I'd like to be able to create "share-nothing" goroutines with a "let it crash" philosophy. But I'm not willing to have these things if they break the language main benefits, especially its simplicity. Maybe the Go team is not open to the changes we're discussing because they just don't align with their goals?