39 comments

[ 2.8 ms ] story [ 96.7 ms ] thread
haha...that name is hideous
Holy crap I can't. stop. laughing.
People in that thread are arguing about exclusion, sexism, etc, but a simple enough reason to change the name is "I can't say I'm using this library in front of the investors and keep a straight face."
(comment deleted)
Laughing and crying. It's sad that people in the community feel alienated in response to something so simple and off the cuff.
At least when I Google it I get relevant results. It's even worse to have some generic name like "footpath" or "cake".
I am really not good at coming up with names.
My thoughts exactly.
in b4 stdlib is better than this framework.
stdlib is better than this framework.
I'm sorry, but does anyone even glance at the source of these frameworks before they're upvoted?
I've withdrawn my upvote after I saw this in the code:

  type Injector struct {
    values          map[reflect.Type]interface{}
    customProviders map[reflect.Type]CustomProvideFunction
  }
I don't understand, what's wrong with that? I've never used Go so I'm asking out of ignorance.
It is not type safe and relies on runtime reflection based checks to make it work correctly, it can crash easily. However, I believe I made all the checks correctly and it should work as intended, but of course it is only 600 LOC, there can arise some issues.
Comments like this could be extremely helpful to the author if you explain more clearly what you mean. Is it because they're using reflection so much? Or is it because a CustomProvideFunction could also be stored as interface{} or something completely different? I'm fairly new to Go as well, so I'm curious.
ERROR 732: Intent unclear. Please elaborate to proceed with discussion. (refcode 567a8-732).
I've said the exact thing on multiple occasions. For example, https://news.ycombinator.com/item?id=12892550. this dude created something that opened a port and listened for commands that would control your OS. He hadn't spent 5 minutes making even some basic form of authentication and came straight to HN for the high 5's. People tried to flame me for pointing out that it seemed irresponsible to be promoting software in such a state.
The current top comments all say what you said without the unwarranted snark.
Unfortunately, to achieve the functionality I described, I must have used reflection like that, which is not really nice, but I really prefer it to context based methods type assuming and casting which is essentially the same. I know people do not like reflection that is used like this, but the performance is not a concern, and I really got tired of transforming user input and checking for errors in each handler.
I'll always advocate learning projects like this, but you're absolutely right that if anyone pulls it for production they deserve what they get.

My personal litmus test for OSS is to read the test suite.

Perhaps due to the fact that upvoting privately saves the story and doesn't forward you to another page as favoriting does (which isn't private), people are upvoting with the intention of browsing it later.

I mention it because it is something I do frequently, and I do this because the favoriting feature isn't quite right (I want to privately save stories for later and I don't want to be redirected).

Looking at this, it looks like a very minimal, reflection heavy framework. While that's not necessarily the wrong set of choices to make, trying to turn Go into a DSL-type language always feels a little strange. Still, kudos to the authors for putting up something nifty in under 1kLoc (excluding tests).
Reflection is also notoriously slow in Go.
>features Angular-like (or Spring like) dependency injection

closes tab

How is this even remotely related to Angular?
"It is like Gin Gonic, but it features Angular-like (or Spring like) dependency injection and better input handling."
Related: https://github.com/go-martini/martini (NOTE: The martini framework is no longer maintained.)
also related - https://codegangsta.io/blog/2014/05/19/my-thoughts-on-martin...

Martini also relied heavily on DI and reflection for convenience and the author basically conceded that this was not idiomatic.

> Martini also relied heavily on DI and reflection for convenience and the author basically conceded that this was not idiomatic.

More like he was bullied into conceding that.

This feels very similar to Martini (https://github.com/go-martini/martini).

Martini had a similar sort of design (and IMO a cleaner source code), but the author decided that reflection and non-idoimatic design was too much of a cost for the HTTP framework in Go. I think 2 years ago when Martini was released people were more open to reflection, but now I'm interested/doubtful if something like this can be accepted.

Funnily enough, I think Gin-Gonic was inspired by Martini, but Gin-Gonic eschewed reflection in favor of performance/idiomatic design. The fact that this project considers Gin Gonic an inspiration is funny.

> haha...that name is hideous

> please.. make it stop..

> closes tab

Look at this sorry thread, the usual open source project bashing going on in the Go community, pathetic, but business as usual in the Go community. The Go community is truly irredeemable and one of the most mean spirited and hateful programming community out there.

Come on man, at least have the remotest sense of irony.
Because calling an entire programming language's community irredeemable, mean spirited, and hateful is reasonable.

There's a reason for the negative comments, and it's that the paradigm of this framework runs against what would be considered idiomatic Go. Spring/Angular style DI is one of the things people use Go to avoid. This is like someone making a library to do goto statements in Java (not as bad of course, just pointing out the conflicting paradigms).

This thread is very negative, and I personally dislike runtime reflection so I wouldn't use this framework in its current design, but don't let the commentors get you down. I assume that you want to just show off something interesting you made, whereas they are looking for something high-enough quality to use in their next project - and a brand-new framework is never going to be that. It's just a mismatch in aims. Keep up the good work, I can appreciate that writing the kind of dependency injection framework often seen in large systems in such a small amount of code is an admirable feat.
Thank you, my thoughts precisely. It was just to show another approach.