Personally, I would like to highlight the part about Martini not being idiomatic. Being idiomatic in Go is a fairly big deal. It makes your code predictable and easier to read and maintain for other Go developers, and learning idiomatic practices can help a Go developer more easily pick up other Go frameworks and libraries.
That's really the only concern I would have about using Martini to "get started" with Go, as it would actually lead you down a wholly different direction from the rest of the community and may actually make learning Go more difficult for a new developer.
I've been watching the Go "web framework" scene over the past year, and more and more I'm inclined to think that the Rails/Django/Sinatra paradigm simply isn't going to work with Go and pursuing it is futile. There is an interesting article on why ORM (ORM's and web frameworks tend to go together) does not work in Go http://www.hydrogen18.com/blog/golang-orms-and-why-im-still-..., lots of interesting points in it. Especially regarding how some people start out thinking in terms of objects, while others think in terms of database schema. Go is geared towards the latter kind, people who prefer to think at the low level, and the idea of a very high level tool that provides you web abstractions and ORM is foreign to that. In this respect it's not all that different from the C world, where there aren't any web/orm frameworks either and nobody misses them.
I've tried out a number of new-fangled languages from a web development perspective (Rust, Go with gorilla, primarily) and in my opinion don't really provide the same set of tools for this sort of web development as higher-level languages like python, ruby, js w/node. That's not to say they don't have important use cases, they just aren't designed with this sort of web development in mind.
And of course, it's totally valid to prefer the different paradigm that these provide! Hasn't been ideal for me, though.
Services though? Totally an appropriate time to fire up Go, in my opinion.
And, even then, Python (which I'm most familiar with) has downsides for JSON services. Translating from an ORM (sqlalchemy) to formatted JSON is something you have to relegate to some magical methods or do one by one, neither is a great solution.
Yes, services is where Go has a huge advantage over Python and Ruby in particular because of their inability to leverage SMP due to the GIL. With Go you don't need to run a whole bunch of processes behind haproxy or whatever which makes life much easier.
Perhaps I should revise with more of a focus on JSON/Services. I was trying to stick to a common pattern across languages. But that might not be the best approach.
Yes I can write an unmaintainable spaghetti mess, or I can isolate a specific business domain and write or use a library that solves this problem once and for all.
Because at the end of the day it's me who end up testing and running that code, not you.
I think you ought to reconsider what the other guy said. His suggestions were quite good because they lead to simple, idiomatic code that relies solely on the standard library.
I read matt ryer's excellent book "Go Blueprints" already. I know all that stuff. I use middlewares with complex logic, I write apps with hundreds of controllers, so with all due respect I'm not going to reinvent the wheel , each time I need to finish a project with tight deadlines.
I don't understand this Go community mindset which says that "nothing is needed but the std lib". My use case isn't Google's or anybody else's.
If the Go team wanted an idiomatic router or middleware stack well they should have provided fully featured ones in the standard lib. There are none. It means "user land".
Have you seen Negroni? It provides a simple framework which solves some the middleware problem. It doesn't use dep injection, the code is more idiomatic and you can use it with any HTTP mux/router you want.
The main thing lacking from net/http is a flexible router. Using the standard mux and parse params out of the request is doable but something like httprouter is often worthwhile.
Wrapping Handle or HandleFunc is easy enough that you don't really need some framework for middleware. If you keep to the standard interface there is plenty of middleware about if you need it. Though you can use things like Gorilla context for request context it is so easy to use a map of requests pointers to data protected by a mutex it seems silly to use a library to do it.
I feel like Go is a bit of an anti-framework language in general. Anyone trying to offer an all-things-to-everyone solution is going to stray into reflection and interface{} everywhere and I think the more Go you write, the less happy you get with this sort of approach.
Personally, I would like to highlight the part about Martini not being idiomatic. Being idiomatic in Go is a fairly big deal. It makes your code predictable and easier to read and maintain for other Go developers, and learning idiomatic practices can help a Go developer more easily pick up other Go frameworks and libraries.
That's really the only concern I would have about using Martini to "get started" with Go, as it would actually lead you down a wholly different direction from the rest of the community and may actually make learning Go more difficult for a new developer.
As an alternative, I would recommend the wonderful Go By Example: http://gobyexample.com/