> That being said, have you tried writing a web app in Go? You can do it, but it isn't exactly entertaining. All those nice form-handling libraries you are used to in Python and Ruby? Yeah, they aren't nearly as good. You can try writing some validation functions for different form inputs, but you'll probably run into limitations with the type system and find there are certain things you cannot express in the same way you could with the languages you came from. Database handling gets more verbose, models get very ugly with tags for JSON, databases, and whatever else. It isn't an ideal situation. I'm ready to embrace simplicity, but writing web apps is already pretty menial work, Go only exacerbates that with so many simple tasks.
This.
And don't even try to work around these limitations and share your work for free, or you're going to get trashed by the Go community( i.e. the Martini fiasco )
But think of go more as a blueprint. Go has great ideas(CSP,go routines,...)
Hopefully it can inspire a new wave of languages that don't rely on a VM, that are statically typed and safe without a fucked up syntax.
The language that succeeds in striking the right balance between minimalism and features with an excellent support for concurrency will be the next big thing.
The author of Martini released his framework, some people in the community said it wasn't idiomatic Go, he agreed and eventually released another one called Negroni.
I don't know if he was "trashed", or whether there was a "fiasco".
Jeremy Saenz certainly remains a well respected member of the Go community.
Martini is very 'magical' and makes it hard to see exactly what's going on, making it quite unusual as a Go framework, so naturally it drew some criticisms. After some experience with the library, Jeremy realized that he actually needed a lot less to do what he wanted, so he wrote Negroni.
The "short" version is that Martini did a lot of 'magic' stuff with run-time reflection. This made it really easy to use for those coming from dynamic languages but also isolated it from the rest of the Go HTTP ecosystem (which rallies around the http.Handler interface). There were also some discussions about that being "slow", but it was still really fast relative to (e.g.) Python.
My opinion is that Martini took a pragmatic approach to getting things done. It was also a bit of a gotcha for newbies who jumped into it and then struggled to learn why things didn't work around the edges of its feature base.
This.
And don't even try to work around these limitations and share your work for free, or you're going to get trashed by the Go community( i.e. the Martini fiasco )
But think of go more as a blueprint. Go has great ideas(CSP,go routines,...)
Hopefully it can inspire a new wave of languages that don't rely on a VM, that are statically typed and safe without a fucked up syntax.
The language that succeeds in striking the right balance between minimalism and features with an excellent support for concurrency will be the next big thing.