Show HN: Simple wiki server written in Go

[lettergram]

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

[anton_gogolev]

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.

[Someone1234]

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."

[tptacek]

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.

[brianobush]

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.

[natebrennand]

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-disc...

[shanemhansen]

Old style posix identifiers are harder to learn, but I basically only have to learn them once.

[mseepgood]

Abbreviations can be human-friendly as well if they are well-established.

[alexdowad]

This is a question of taste. Personally, I like "Unix'y" identifiers -- though as you say, they should at least be consistent.

[Spiritus]

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.

[dmunoz]

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/

[Pinn2]

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

[Spiritus]

That makes sense. Just pushed a fix[1].

[1] https://github.com/renstrom/go-wiki/commit/535c645fb25252e49...

[rco8786]

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]

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]

Yes, not my proudest moment. To be honest, I wasn't really sure what to with all the err's.