Show HN: GoWork – A Go Distributed Work Library
11–20 of 26 posts
Re: Show HN: GoWork – A Go Distributed Work Library
#12To 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 }.
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 return value, with a single return statement at the end of the method.
There are plenty of blogs and articles debating for or against every permutation of this. But in the end, it really doesn't matter one bit whether there's an else statement on line X Y and Z.
Re: Show HN: GoWork – A Go Distributed Work Library
#13To 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…
From golang.org Effective Go: "In the Go libraries, you'll find that when an if statement doesn't flow into the next statement—that is, the body ends in break, continue, goto, or return—the unnecessary else is omitted."
Re: Show HN: GoWork – A Go Distributed Work Library
#14That 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 design, so feel free to correct me if I'm wrong.
Re: Show HN: GoWork – A Go Distributed Work Library
#15A disclaimer may be appropriate here: I am aware of the limitations preventing one from reimplementing the entire OTP in Go. I still think that what you could get would be "close enough" with a few code guidelines (or a purpose-built static analyzer).
Re: Show HN: GoWork – A Go Distributed Work Library
#16This 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…
Re: Show HN: GoWork – A Go Distributed Work Library
#17Earlier quoted context omitted.
I strongly disagree. The package author means the error will be nil when the secret is 32 characters long; he doesn't mean you can completely ignore checking it. Regarding when to use panic: "The convention in the Go libraries is that even when a package uses panic internally, its external API still presents explicit error return values." http://blog.golang.org/defer-panic-and-recover Panics should only be used in ca…
An idea is to include a function in the library called MustNewServer() that panics instead of returning an error. A usability perk of having single return is that the function can be chained, i. e., ws := gowork.MustNewServer(key).AddParams(...)
As long as there is an alternative function which returns errors :)
Re: Show HN: GoWork – A Go Distributed Work Library
#18This 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…
What do you mean by "OTP"? Do you mean "One Time Password", or is OTP an abbreviation for something else?
Re: Show HN: GoWork – A Go Distributed Work Library
#19This 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…
What do you mean by "OTP"? Do you mean "One Time Password", or is OTP an abbreviation for something else?
Re: Show HN: GoWork – A Go Distributed Work Library
#20This 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…
What do you mean by "OTP"? Do you mean "One Time Password", or is OTP an abbreviation for something else?