GoWork

Languages and libraries

distributed work library

SHOW HN2015

68points
25comments
#406of 2,565 in 2015
Top 16%of 2015 by points

How HN took it

CuriousMostly questions and neutral comments

2 positive, 6 neutral or asking, 0 mixed, 0 critical, out of 8 comments about the project. Thread score +0.15.

Design: 1 for, 0 against

The thread, comment by comment

Each row is a top-level comment and its replies, in HN's order. Select a cell to open that comment on HN.

positive neutral or mixed critical about another commenter or something else the maker

What HN said

What people liked

  • Useful API design ideas such as Must-prefixed constructors

    From 2 comments
    • 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…
      bcgraham on HN
    • As much as I hate chaining functions, I do like the idiom of declaring that a function may panic with the 'Must' prefix. As long as there is an alternative function which returns…
      jalfresi on HN

Objections

  • Ignoring returned error from NewServer is risky; suggested panic instead

    From 3 comments
    • > Error is only returned by this function when the secret isn't 32 characters so as long as your secret is definitely 32 characters you can safely ignore the err returned by this…
      nothrabannosir on HN
    • > 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. But that's exactly what will…
      nothrabannosir on HN
    • If a developer is frequently ignoring returned errors, then they have larger problems and it's their fault. Panic was not added to assist lazy programmers. Even though some API…
      nicksardo on HN
  • Code style does not follow Go idiom for else after return

    From 2 comments
    • To 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 {…
      codo2 on HN
    • It's not a critique but a suggestion. Like you are saying, it is not an error, my suggestion is simply to follow the standard library. From golang.org Effective Go: "In the Go…
      codo2 on HN
  • Interface casting may be inefficient in performance-critical code

    From 1 comment
    • I 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.…
      StabbyCutyou on HN

Requests

  • Use channels for collecting worker results

    From 1 comment
    • > Error is only returned by this function when the secret isn't 32 characters so as long as your secret is definitely 32 characters you can safely ignore the err returned by this…
      nothrabannosir on HN
  • Add a MustNewServer constructor that panics

    From 1 comment
    • 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…
      bcgraham on HN
  • Rename or split main.go

    From 2 comments
    • As a little side node I'd personally rename main.go to core.go. Plus, I think there's room for splitting main.go into more little pieces to ease maintainability.
      alediaferia on HN
    • To 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 {…
      codo2 on HN

Questions

  • Does master fetch results from workers or do workers push them

    From 1 comment
    • > Error is only returned by this function when the secret isn't 32 characters so as long as your secret is definitely 32 characters you can safely ignore the err returned by this…
      nothrabannosir on HN

Alternatives named

  • Erlang/OTP

    From 2 comments
    • This 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…
      proveanegative on HN
    • Erlang/OTP: http://www.erlang.org/faq/introduction.html
      aleksi on HN
  • reign (Go distributed system project)

    From 1 comment
    • 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…
      jerf on HN

Category, keywords, summaries and labels on this page were made by AI (Thread Reader v2) and not checked by hand. Each point links to the comments it came from.

Add a badge to your READMEShown on HackerShow
[![Shown on HackerShow](https://hackershow.org/badge.svg)](https://hackershow.org/show/9890566)