Just one nitpick on the marketing copy: why does it matter what it's written in? As a user it could be written in assembler for all I care. As long as it works as advertised on the tin and it's what I'm looking for, who cares if it's written in Go?
Anyway, I'm looking forward to checking it out and seeing if it'll fit my use case.
As jpalomaki pointed out, it matters since it's open source. If the user chooses Hugo and wants to modify or extend it down the line, he or she will be writing Go.
And it might also matter to the author for a few more reasons:
First, Go is a language rising in popularity (http://www.google.com/trends/explore?q=golang#q=golang&cmpt=...), and seems especially popular on HN lately. Mere mention of Go will drive more traffic to his site. (This could be supported by the fact that he constantly refers to the language as GoLang, which is much more search-engine friendly than the proper name Go).
Second, if he enjoys working with Go, then raising the language's visibility will be good for the language, and good for developers who have invested in the language.
http://www.google.com/trends/explore?q=golang#q=golang%2C%20...
With Go, the second you step outside the box, you'd have to recompile the site compiler first. I've had so many experiences in the Java world with having to get a whole development environment and build working just to change one little piece of text, that I really think interpreted languages are a plus here.
Hugo adds some external dependencies which can be fetched with `go get` (fsnotify, fsync, pflag, hugolib). One command deps are filled and you still have all the Go goodness.
Jekyll requires (or generally expects) gem and requires at runtime (classifier, colorator, commander, directory_watcher, kramdown, liquid, maruku, pygments, redcarpet, safe_yaml) and for development (activesupport, cucumber, launchy, rake, rdiscount, rdoc, RedCloth, redgreen, rr, shoulda, simplecov, simplecov-gem-adapter)
So, it all depends on what you value.
HN. Static site generators in Visual Basic, PL/SQL, Java etc are not going to upvoted and will garner no job offers.
I strongly recommend against using external dependencies (e.g. bitbucket.org/howeyc/fsnotify) for something important. It's fine for development, but if "howeyc" decides he's sick of bitbucket and deletes his account, you're now screwed.
If you want to use "go get" to install Hugo, make forks of the external dependencies. bitbucket.org/spf13/fsnotify and what not. You can then keep those updated at your own pace, rather than waking up to see that someone has changed their API and your code no longer compiles.
Remember the game "Haunts"? IIRC this was one of their problems--they failed to manage dependencies appropriately and got into major hell. Many C and C++ programs ship source to external libraries along with their own source for this exact reason. We've taken to doing the same.
Here's what Brian Fitzpatrick has to say about "go get":
"Go get is nice, for you know, playing around, but if you're doing something serious and you're going to deploy binaries to production, your deploy to production script should not involve fetching some random dude's stuff on Github"
We have taken to making a go "workspace" in our repos, with a bash script at the top level and a src/ directory containing all the libraries and such we've written. The bash script sets GOPATH and compiles everything in src/. It's quick and you avoid dependency hell.
How? When you `go get` a package, it physically becomes part of your repository. If "howeyc" deletes his account, it doesn't affect the copy checked out under my repository. Unless you go out of your way to exclude the `go get` packages from getting checked in, you are safe.
Now, what you as the developer can do, as I mentioned in my original post, is get all the packages you need and put them in a $GOPATH directory, so you have $GOPATH/src/hugo and $GOPATH/src/fsnotify etc., then check in the entire $GOPATH directory. Your code then imports "fsnotify" rather than "bitbucket.org/howeyc/fsnotify" and so on. This repository is no longer trivially fetchable+compileable with "go get", but in my opinion that's a small price to pay--and compilation is still very simple.
It also makes things easier if you decide to modify the libraries, or if the author abandons his code and someone else becomes the "canonical" source. Your code will just import "fsnotify", and you can put whatever source you prefer in $GOPATH/src/fsnotify/
Unfortunately it has no pretty documentation, only README on Github. On the other hand, Hugo seems to have a bit more hardcoded configuration, while gostatic was written with 'whatever you want' idea in mind and is (maybe, I just skimmed though Hugo docs) a bit more tech-savvy people oriented.
Anyway, it would be interesting to compare performance. :)
It would be great to compare approaches to things and see if we can't share and improve both in the process.
The shortcodes feature impacts performance quite a bit as it's all runtime inspection, but I felt it was an essential feature. Even with it it's still fast enough that it still builds the entire site in what feels like realtime.
Indeed. Do you track dependencies to not re-render things which were not changed?
> The shortcodes feature impacts performance quite a bit as it's all runtime inspection
Ha-ha, in gostatic you have this `inner-template` processor, which parses your page as go template and then renders it. Naturally, it slows down rendering a bit, but still it renders my site from scratch in 0.5s (~250 pages with some inner-templates, heh).
- Theme plugins; text based as input to Hugo, not golang packages that would have to be compiled.
- Editor integration so others can make a WordPress-style site editor. Just conventions about layout, I think?
For the theme plugins, could you expand a bit on what you mean or how this would work?
I was thinking about a WordPress replacement in Golang. WordPress themes can be zipped and shared as a bundle, which has made a large variety of themes freely available.
I wrote something similar myself, also in python, and put it all in one file, organized logically, with extra tools for making management easier. I'm not sure I really see how this is "more lightweight" compared to something else...
For reference, it's located at https://github.com/dkuntz2/essays/blob/master/pavement.py.
Those dependencies give me pause.
Also thanks to everyone posting their projects.
Would have been such a nice fit.
It's at https://github.com/celsomiranda/generator-hugo
There's not much done yet, but all contributions/ideas are welcome.
