7 ms·
> You can build and link shared libraries since Go 1.5: That was not my point and you know it. you can't load shared library at runtime with Go. Like you can d
by spriggan3 11y ago
> You can build and link shared libraries since Go 1.5:
That was not my point and you know it. you can't load shared library at runtime with Go. Like you can do in most languages out there.
> The author of Martini, Jeremy Saenz, didn't feel humiliated:
Yeah, he didn't feel humiliated so much he stopped writing about and programming in Go and interacting with the Go community all together because it's full of bullies.
> The Go team is listening to the community about package management and is even willing to make changes:
The Go team is listening to nothing.
> I would add that I'm tired of people repeating that the Go core team is stubborn and doesn't listen to critics about the lack of generics, even though they have provided substantiated answer on this topic:
That doesn't make them more open to changes, anybody can do an AMA for PR.
Go community is blind to its own shortcomings and the language issues, you just proved my point yet again.
- ngrilly 11y ago> 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?