10 ms·

Show HN: Simple wiki server written in Go

82 points by Spiritus 12y ago

anton_gogolev 12y ago
Whar bothers me in Go (and Python and Ruby, for that matteR) is that there's a strange mix of human-friendly identifiers like ResponseWriter, ParseInt, etc. and old-style Unix'y ones, like stdout, strconv, Println. Wildly inconsistent. I wonder if "creat" is a valid function call somewhere.
- mseepgood 12y ago
  Abbreviations can be human-friendly as well if they are well-established.
- brianobush 12y ago
  stdout and friends should make sense to every developer. I don't think you have to have the library functions in sync with system calls and file descriptors.
- tptacek 12y ago
  Why is "ParseInt" OK, and "Println" or "strconv" not? ("strconv" has to be single-case because it's a package name). Both kinds of names are abbreviated. "Int" for "integer" is approximately as intuitive to developers as "str" is for "string". The other examples you've provided mirror the Unix API; it would be more confusing to rename them, despite their unfortunate terseness.
  - anton_gogolev 12y ago
    Ok, ParseInt and Prinln are not as representative; I should've been more clear. Python's dict/getattr/setttr/iter/etc. and Ruby's unintuitive chop/chomp and PHP-style inconsistent readlines/to_i/to_f/String, plus "there's more than one way to do stuff" (next/succ are the only ones that come to mind ATM) are more representative. As Someone1234 noted, this kind of inconsistency in a relatively new language is very puzzling.
    - tptacek 12y ago
      Could you provide an example of the inconsistency in the Golang standard library? "ParseInt" versus "strconv" has a simple explanation: all package names are lowercase.
      - anton_gogolev 12y ago
        The inconsistency is, for instance, in abbreviated lowercased package names (is "format" really longer to type than "fmt", same for "bufio") with relatively "humane" camelcased class/function names like ReadLines. This, and an occasional "Itoa", which is neither here nor there.
- Someone1234 12y ago
  I strongly agree. That's one of the nice things about the .Net libraries, consistency within the naming and layout. Often times you could guess what something would be called and you would be correct. Powershell took this one step further with their wonderful Verb-Noun pattern for everything: Get-Service, New-Service, Restart-Service, Start-Service, Stop-Service, and so on... When I tried Go for the first time it was a marked improvement over for example C++, but the libraries are poorly laid out in my opinion, and the naming is hugely inconsistent. It is starting from a point of weakness, and I actually find classic C libraries a little better (C++ a lot worse), just because at least C is consistent with itself. Seems like the Go designers thought saving characters was a more important design consideration than clarity. As if tab auto-completion wasn't a "thing."
- shanemhansen 12y ago
  Old style posix identifiers are harder to learn, but I basically only have to learn them once.
  - mechanical_fish 12y ago
    And, honestly, they are not that hard to learn. Compared to the amount of time it takes to understand the semantics of "stdout", the time required to learn the spelling of "stdout" is nothing. In a world where millions of Chinese programmers have to use keywords written in a foreign language who am I to complain? There is little reason to expect that reforming POSIX spelling is going to be any more successful than reforming English spelling.
- natebrennand 12y ago
  FWIW, the Golang core developers regret using the old UNIX conventions in packages. I don't think it's viable at this stage to take them back, but they do agree that it doesn't fit the language well. http://gophercon.sourcegraph.com/post/83845316771/panel-discussion-with-go-team-members http://gophercon.sourcegraph.com/post/83845316771/panel-disc...
  - mseepgood 12y ago
    I think he only regrets having used upper case names for constants (os.O_RDONLY), which is not idiomatic Go.
  - Retra 12y ago
    The keywords thetruthofthematter, notwithstanding, and depiteallobjections are kind of hilarious though.
- alexdowad 12y ago
  This is a question of taste. Personally, I like "Unix'y" identifiers -- though as you say, they should at least be consistent.
lettergram 12y ago
I wrote a similar project a while back, you might be interested in checking out. A friend and I implemented cookies, user login and database. However, I would recommend not using the SHA2 encryption method we used (we did it for fun not for security). https://github.com/lettergram/neptune https://github.com/lettergram/neptune
dmunoz 12y ago
Good job. I see you went a few steps further than the Writing Web Applications with Go tutorial [0]. Definitely a good way to learn. I like your idea of showing the git history including diffs. For anyone who might be interested in Go and is wondering how this is done, read the tutorial I mentioned. Go has solid documentation alongside a handful of tutorial style article that are worth reading. [0] http://golang.org/doc/articles/wiki/ http://golang.org/doc/articles/wiki/
Pinn2 12y ago
As usual, I checked the .gitignore. You may want to try "/gowiki" instead of "gowiki".
- Spiritus 12y ago
  That makes sense. Just pushed a fix[1]. [1] https://github.com/renstrom/go-wiki/commit/535c645fb25252e496396883db8c61fc462ddf6c https://github.com/renstrom/go-wiki/commit/535c645fb25252e49...
Spiritus 12y ago
Author here. As mentioned in the README I created this project as a process to learn to Go. I'm actually quite happy with how it turned out, I wanted something really simple to use but still have some nice features like showing the history of a page by leveraging Git. Unfortunately I didn't get to use channels... Yet. Coming from a Python background mostly I found Go pretty pleasing to work, however it took a while for me to grok the whole `$GOPATH` and dependencies stuff.
rco8786 12y ago
Interesting considering Rob's recent defense of the state of Go error handling. var err error tail.Stdin, err = git.StdoutPipe() if err != nil { log.Println("ERROR", err) } tail.Stdout = &out err = tail.Start() if err != nil { log.Println("ERROR", err) } err = git.Run() if err != nil { log.Println("ERROR", err) } err = tail.Wait() if err != nil { log.Println("ERROR", err) }
- codezero 12y ago
  I think this is also what he was trying to point out: that selecting small snippets to call out from a small code base is not really showing there is a problem. Larger code bases have less of this proportionally.
- Spiritus 12y ago
  Yes, not my proudest moment. To be honest, I wasn't really sure what to with all the err's.
  - buro9 12y ago
    The only issue I'd really be strict about is that you're not doing anything with the errors. Specifically, you've: 1. Encountered an error 2. Detected it 3. Printed it But you've continued execution, and some of those errors are clearly not going to let you continue cleanly. If you couldn't call git on the command line (i.e. it is not installed), then what are you going to do with the stdout? And if git was somehow replaced with something that only returned a status code and no output, then what are you going to do with no output? The important point is that errors can be thrown because errors can plausibly exist in a way that affects you. You should handle them, logging is fine as a bare minimum but you probably also want to return and exit out of the func in a way that communicates to the thing that called the func that "Something went wrong, and I don't have the results you're looking for".
    - Spiritus 12y ago
      I agree. I should probably just add something like this at after every log: log.Println("ERROR", err) return out.Bytes(), err Or just: log.Println("ERROR", err) return []byte, err But I figured since the error will eventually get returned at the end anyway I moved on and kind of forgot about it.

82 points by Spiritus 12y ago

Whar bothers me in Go (and Python and Ruby, for that matteR) is that there's a strange mix of human-friendly identifiers like ResponseWriter, ParseInt, etc. and old-style Unix'y ones, like stdout, strconv, Println. Wildly inconsistent. I wonder if "creat" is a valid function call somewhere.

mseepgood 12y ago
Abbreviations can be human-friendly as well if they are well-established.
brianobush 12y ago
stdout and friends should make sense to every developer. I don't think you have to have the library functions in sync with system calls and file descriptors.
tptacek 12y ago
Why is "ParseInt" OK, and "Println" or "strconv" not? ("strconv" has to be single-case because it's a package name). Both kinds of names are abbreviated. "Int" for "integer" is approximately as intuitive to developers as "str" is for "string". The other examples you've provided mirror the Unix API; it would be more confusing to rename them, despite their unfortunate terseness.
- anton_gogolev 12y ago
  Ok, ParseInt and Prinln are not as representative; I should've been more clear. Python's dict/getattr/setttr/iter/etc. and Ruby's unintuitive chop/chomp and PHP-style inconsistent readlines/to_i/to_f/String, plus "there's more than one way to do stuff" (next/succ are the only ones that come to mind ATM) are more representative. As Someone1234 noted, this kind of inconsistency in a relatively new language is very puzzling.
  - tptacek 12y ago
    Could you provide an example of the inconsistency in the Golang standard library? "ParseInt" versus "strconv" has a simple explanation: all package names are lowercase.
    - anton_gogolev 12y ago
      The inconsistency is, for instance, in abbreviated lowercased package names (is "format" really longer to type than "fmt", same for "bufio") with relatively "humane" camelcased class/function names like ReadLines. This, and an occasional "Itoa", which is neither here nor there.
Someone1234 12y ago
I strongly agree. That's one of the nice things about the .Net libraries, consistency within the naming and layout. Often times you could guess what something would be called and you would be correct. Powershell took this one step further with their wonderful Verb-Noun pattern for everything: Get-Service, New-Service, Restart-Service, Start-Service, Stop-Service, and so on... When I tried Go for the first time it was a marked improvement over for example C++, but the libraries are poorly laid out in my opinion, and the naming is hugely inconsistent. It is starting from a point of weakness, and I actually find classic C libraries a little better (C++ a lot worse), just because at least C is consistent with itself. Seems like the Go designers thought saving characters was a more important design consideration than clarity. As if tab auto-completion wasn't a "thing."
shanemhansen 12y ago
Old style posix identifiers are harder to learn, but I basically only have to learn them once.
- mechanical_fish 12y ago
  And, honestly, they are not that hard to learn. Compared to the amount of time it takes to understand the semantics of "stdout", the time required to learn the spelling of "stdout" is nothing. In a world where millions of Chinese programmers have to use keywords written in a foreign language who am I to complain? There is little reason to expect that reforming POSIX spelling is going to be any more successful than reforming English spelling.
natebrennand 12y ago
FWIW, the Golang core developers regret using the old UNIX conventions in packages. I don't think it's viable at this stage to take them back, but they do agree that it doesn't fit the language well. http://gophercon.sourcegraph.com/post/83845316771/panel-discussion-with-go-team-members http://gophercon.sourcegraph.com/post/83845316771/panel-disc...
- mseepgood 12y ago
  I think he only regrets having used upper case names for constants (os.O_RDONLY), which is not idiomatic Go.
- Retra 12y ago
  The keywords thetruthofthematter, notwithstanding, and depiteallobjections are kind of hilarious though.
alexdowad 12y ago
This is a question of taste. Personally, I like "Unix'y" identifiers -- though as you say, they should at least be consistent.

lettergram 12y ago

I wrote a similar project a while back, you might be interested in checking out. A friend and I implemented cookies, user login and database. However, I would recommend not using the SHA2 encryption method we used (we did it for fun not for security). https://github.com/lettergram/neptune https://github.com/lettergram/neptune

dmunoz 12y ago

Good job. I see you went a few steps further than the Writing Web Applications with Go tutorial [0]. Definitely a good way to learn. I like your idea of showing the git history including diffs. For anyone who might be interested in Go and is wondering how this is done, read the tutorial I mentioned. Go has solid documentation alongside a handful of tutorial style article that are worth reading. [0] http://golang.org/doc/articles/wiki/ http://golang.org/doc/articles/wiki/

Pinn2 12y ago

As usual, I checked the .gitignore. You may want to try "/gowiki" instead of "gowiki".

Spiritus 12y ago
That makes sense. Just pushed a fix[1]. [1] https://github.com/renstrom/go-wiki/commit/535c645fb25252e496396883db8c61fc462ddf6c https://github.com/renstrom/go-wiki/commit/535c645fb25252e49...

Spiritus 12y ago

Author here. As mentioned in the README I created this project as a process to learn to Go. I'm actually quite happy with how it turned out, I wanted something really simple to use but still have some nice features like showing the history of a page by leveraging Git. Unfortunately I didn't get to use channels... Yet. Coming from a Python background mostly I found Go pretty pleasing to work, however it took a while for me to grok the whole `$GOPATH` and dependencies stuff.

rco8786 12y ago

Interesting considering Rob's recent defense of the state of Go error handling. var err error tail.Stdin, err = git.StdoutPipe() if err != nil { log.Println("ERROR", err) } tail.Stdout = &out err = tail.Start() if err != nil { log.Println("ERROR", err) } err = git.Run() if err != nil { log.Println("ERROR", err) } err = tail.Wait() if err != nil { log.Println("ERROR", err) }

codezero 12y ago
I think this is also what he was trying to point out: that selecting small snippets to call out from a small code base is not really showing there is a problem. Larger code bases have less of this proportionally.
Spiritus 12y ago
Yes, not my proudest moment. To be honest, I wasn't really sure what to with all the err's.
- buro9 12y ago
  The only issue I'd really be strict about is that you're not doing anything with the errors. Specifically, you've: 1. Encountered an error 2. Detected it 3. Printed it But you've continued execution, and some of those errors are clearly not going to let you continue cleanly. If you couldn't call git on the command line (i.e. it is not installed), then what are you going to do with the stdout? And if git was somehow replaced with something that only returned a status code and no output, then what are you going to do with no output? The important point is that errors can be thrown because errors can plausibly exist in a way that affects you. You should handle them, logging is fine as a bare minimum but you probably also want to return and exit out of the func in a way that communicates to the thing that called the func that "Something went wrong, and I don't have the results you're looking for".
  - Spiritus 12y ago
    I agree. I should probably just add something like this at after every log: log.Println("ERROR", err) return out.Bytes(), err Or just: log.Println("ERROR", err) return []byte, err But I figured since the error will eventually get returned at the end anyway I moved on and kind of forgot about it.