Looks good but I always get reminded of this: https://twitter.com/rob_pike/status/618357610287226880
Show HN: GoWork – A Go Distributed Work Library
21–26 of 26 posts
Re: Show HN: GoWork – A Go Distributed Work Library
#22Looks good but I always get reminded of this: https://twitter.com/rob_pike/status/618357610287226880
I say keep doing it, because it's a good heuristic for enthusiasm, lines of code, and perhaps quality.
Re: Show HN: GoWork – A Go Distributed Work Library
#23This looks nice enough as it is but what I think Go needs now is a more direct OTP clone suitable for new projects. If GoWork grew into that it could very well eat into Erlang's market share. Many people want their distributed systems language statically typed and fast. With Erlang you have the prospect of having to rewrite parts of your applications in C for speed looming menacingly on the horizon at all times. (Edi…
While it may appear that https://github.com/thejerf/reign is asleep, development is actually proceding apace; we're just not committing anything publicly because I'm of the opinion that nobody contributes to a project that doesn't at least have minimal functionality. We're currently on track to getting this put up in our beta environment pretty soon.
As the README.md says, I still wouldn't want this showing up on the HN mainlist, especially that repo as it stands now.
If there is someone who expresses a serious interest in helping out with that, I can see about doing a sync up to github. (If you're not comfortable discussing on HN, see my profile for contact info.)
(I also don't want to overpromise as I haven't looked into the details recently, but we are also working on functioning as an Erlang node sufficient to send and receive messages between Erlang and Go. We realized that we weren't willing to do a "big bang" upgrade, so we're planning on having cross-talk between the Erlang and Go nodes so we can gradually transition. I expect this to appeal to many people.)
Re: Show HN: GoWork – A Go Distributed Work Library
#24To make the code simpler to read, I would suggest removing a bunch of "else {", like the ones on lines 84, 112 and 119 of main.go. When you have something like: if err != nil { return err } you don't need to put a else after the closing }.
Seriously? That's the critique you have? Choices like that are 100% personal preference, and belief of which is "better" again is personal opinion. Foe the counter argument; I find it far more readable to follow the if/else blocks, than to rely on identifying which if blocks contain return statements. Personally, I prefer a step further, keeping all if/else blocks and using a variable inside the method to track the r…
One reason you're getting downvoted is that the note the parent commenter gave is pretty squarely in Go idiom. Go favors early-exit, and the Go community is unusually strict about idiom.
(I'm pretty well acquainted with this particular issue because my C coding style is strictly anti-early-exit, which drives almost everyone I work with up a wall. I had to unlearn that habit to write idiomatic Go.)
Re: Show HN: GoWork – A Go Distributed Work Library
#25I notice you're using interfaces to do your handlers, and (forgive me if i'm reading this wrong) casting those interfaces to a specific "type" of function before invoking them. That seems like it would be inefficient in performance-critical code like a worker system. Have you considered using typed-functions and function pointers to accomplish a similar approach? That said, I could easily be missing something in the…
I've resolved this now, thanks :)
Re: Show HN: GoWork – A Go Distributed Work Library
#26Earlier quoted context omitted.
Seriously? That's the critique you have? Choices like that are 100% personal preference, and belief of which is "better" again is personal opinion. Foe the counter argument; I find it far more readable to follow the if/else blocks, than to rely on identifying which if blocks contain return statements. Personally, I prefer a step further, keeping all if/else blocks and using a variable inside the method to track the r…
One reason you're getting downvoted is that the note the parent commenter gave is pretty squarely in Go idiom. Go favors early-exit, and the Go community is unusually strict about idiom. (I'm pretty well acquainted with this particular issue because my C coding style is strictly anti-early-exit, which drives almost everyone I work with up a wall. I had to unlearn that habit to write idiomatic Go.)
Understandable, thanks for an explanation