spf13

100% agree. These factors are generalized and without context. The context you bring is essential to making the right decision. The next post I'm writing is all about how to apply this framework to your specific context.

Hi HN, author here.

While reading Franklin's autobiography, I was completely struck by the systematic, almost algorithmic way he taught himself to write. He designed a process of compressing, reconstructing, and comparing his work against a "gold standard" to find and correct his "faults."

The more I looked at his 4-step loop, the more it resembled the modern training loop for a machine learning model (data collection, forward pass, loss function, backpropagation/gradient descent).

I wrote this piece to explore that parallel, how Franklin basically reverse engineered the principles of deliberate practice and error minimization 250 years before we had the formal language of AI to describe it. It's a fascinating piece of history, but also a practical model for how anyone can learn a complex skill.

Happy to answer any questions!

I never intended this statement to be taken as if I built these alone. Thanks for this candid feedback.

Perhaps a more accurate wording is:

"You may know me from helping to build the Go Language, Docker, MongoDB, and Drupal & creating Hugo, Cobra and spf13-vim"

I built and led the team that was responsible for the MongoDB user experience. We designed and built MongoDB's integrations with programming languages & third party systems (Drupal, Hadoop, Storm, Spark, etc). Our team wrote the MongoDB user manual too and we were responsible for the websites.

My blog has a lot of talks / posts about the work our team did if you want to read up more about it.

Thank you!

I can confirm it's quite accurate. I've been the person responsible for these metrics the entire time cited.

A couple of the Go authors did a lot of the initial coding and continue to code in Acme (rsc, r). The broader Go team use a wider variety: Vim, Emacs, Goland, and VSCode are the most popular from what I've seen.

I did this exact thing when I got frustrated with Jekyll (and friends) and created Hugo. Of course, at the time all SSGs were in dynamic languages and very VERY slow.

Happy to see some Hugo ideas made it into Zola.

This is the first. There have been several designs previously, each of which was refined based on feedback, culminating in this proposal.

I didn't. I'm shocked how awful these ads are. I've turned it off completely.

Disclaimer: I am the creator of Hugo. Trying to provide an impartial perspective here for the readers.

Everyone has different needs and tastes so no tool works for everyone. Here's how I see Hugo's strengths and weaknesses. I'd love to know what other people see are Hugo's strengths and weaknesses.

Hugo's key differentiators: 1. Ease of install 2. Speed (critical for large sites) 3. Integrated live-reload while editing in near realtime 4. Multilingual capabilities 5. Flexible 6. Very strong community 7. Very good & comprehensive documentation (but not perfect...yet)

Hugo struggles with: 1. Not integrated with Github like Jekyll (though webhooks solve this to a large degree) 2. No plugin support 3. Media & Asset processing not tightly integrated

There are many solutions that work around Hugo's limitations, some which are quite elegant, but at the end of the day they are workarounds and require external tooling.

We would love to address these weaknesses in upcoming releases as best we can. If you are interested in helping we would love to have help.

Disclaimer. I am the author of Hugo and former exec at Docker. I don't speak for Docker and I've been gone for over a year so the following is at best a guess.

From my reading of their blog post I see that their primary motivation for the change was first to consolidate all of their documentation into a single repo, instead of spread across all of their various projects. As they have grown as an organization and now have a large number of projects this approach has a lot of strengths and makes a lot of sense. Any SSG could work in this new formation, but the change gave them an opportunity to make a change. Additionally Github provides a lot of Jekyll features out of the box that help with managing these documentation sites.

I believe it is not a question of performance between Hugo and Jekyll, but a question of Docker's specific workflow. As Github already runs Jekyll server side all the contributors need to do is upload the source file and then Github does the rest. In contrast, Hugo based docs would have to be built locally and then uploaded as completed html. There are easy ways to set up services through github hooks that do the exact same thing as Jekyll already does but that requires additional setting up.

Since Github is doing all the work it is easier on the contributors since all they need to do is `git push`. This also enables people to edit right in the github edit screen and not bother with setting up anything client side. The total time to process the site is likely much longer on Jekyll but the time that their contributors spend is much less as they aren't building the site locally.

This is surprising and counter to what most others are experiencing.

Many of the performance optimizations have tradeoffs and while they increase performance for the majority of cases, some cases will experience slight degradation.

This is also a surprisingly long time for initialization. My site with a few hundred pages on a rather old mac (with an SSD) has

Go initialization: 48.00164ms (48.842363ms) 2.14 MB 18299 Allocs

Do you have your site source available publicly so we can do more testing and benchmarking with it? We'd love to understand the places where it's not improving so we can address them further.

Thanks for this feedback. We are striving to make the docs as good as we can. We would love to hear more about your experience so we can improve the docs further.

Hugo is not blog oriented and works well with any site structure.

A good way to a lot of different ways of how people are using Hugo is with the site showcase.

http://gohugo.io/showcase/

It can optionally use python-pygments for syntax highlighting. It's not a requirement and as you mention alternatives are available.

Hugo provides many of the same features of Harp.js which is also a good project.

Hugo provides a server for local development like jade.

Hugo is a bit easier to install as it doesn't have dependencies and doesn't require an existing environment.

Hugo is noticibly faster.

The big difference between the two is that Hugo has not focused on compiling all the other assets like scss, less, coffee script, etc. While this is planned for a future release today Hugo users have experienced a lot success pairing Hugo with Gulp. You can read more in this discussion on the forum: https://discuss.gohugo.io/t/gulp-hugo-hugo-npm/1121

Unfortunately by introducing gulp it negates some of the benefits of Hugo's one binary install.

Hugo does provide some advanced features that I don't believe Harp provides including:

* Data file loading https://gohugo.io/extras/datafiles/

* Live data https://gohugo.io/extras/datadrivencontent/

* Live reload (this is a huge feature) https://gohugo.io/extras/livereload/

* Menus https://gohugo.io/extras/menus/

* Themes https://themes.gohugo.io

If you are happy with Harp and it serves your needs than there's not really a reason to switch.

The big difference is Hugo + Gulp is a workflow that works really well and has all the features that Harp provides (plus all the Hugo features). If you need a feature that only Hugo provides there really isn't a way to add that to harp.js.

I'm the author of Hugo and haven't ever used Harp so take all of this with a grain of salt.

Currently hugo has not focused on this aspect of development and many people have found success combining Hugo with Gulp. There are a few projects related to this that make it pretty easy. There's a good discussion around this on the forum. https://discuss.gohugo.io/t/gulp-hugo-hugo-npm/1121

Hugo is built is a way that virtually everything you would want to do with a static site generator is configurable without go or recompilation.

Smashing Mag had a good write up explaining this http://www.smashingmagazine.com/2015/11/static-website-gener...

I like Wercker which works well on github pages, s3 and ssh. There's a good tutorial at https://gohugo.io/tutorials/automated-deployments/

I just used this technique for https://stevefrancia.com and the wercker files are at https://github.com/spf13/stevefrancia.com

The v0.13.0 release is the largest Hugo release to date. The release introduced some long sought after features (pagination, sequencing, data loading, tons of template improvements) as well as major internal improvements. In addition to the code changes, the Hugo community has grown significantly and now has over 3000 stars on github, 134 contributors, 24 themes and 1000s of happy users.

This release represents 448 contributions by 65 contributors

A special shout out to @bep and @anthonyfok for their new role as Hugo maintainers and their tremendous contributions this release.

Hugo is a fully featured SSG written in Go. It's considerably faster than other SSGs and has a very easy installation.

http://hugo.spf13.com

I work for MongoDB. There we use go for all of our agents for our various services. Originally they were developed in java and python, but we spent far too much time supporting issues that arose from existing environments run times. A blog post was written that expands on this further. http://blog.mongodb.org/post/51643994762/go-agent-go

In my free time I develop a static site engine called Hugo which is hundreds of times faster than others written in python and ruby and is super easy to install as it is distributed as a single binary without any dependencies. You can learn more about it at http://hugo.spf13.com .

Hugo meets all of your requirements.

It averages ~1ms per page created (hundreds of times faster than most alternatives).

It also boast the easiest installation of all SSGs. Simply download the executable and run. No package managers or dependencies needed.

Hugo is not focused on blogs, but has all the features you would need for any website. Sections & flexible taxonomies are built in. Hugo has support for as many different content types you want.

Hugo defaults are sane and no configuration (other than baseUrl) is needed for most sites.

Learn more at http://hugo.spf13.com

Thanks so much! I would love an invite. email in profile.

The second half of the article is all about refactoring. Very similar to the refactor functionality provided by Eclipse & IntelliJ.

The Go project provides similar functionality for most common editors (Emacs, Vim). The spf13-vim distribution supports this for Vim.

Wasn't intended to offend. I'll reword that sentence. I do go on to explain why it's a mistake. It's really just that one word that seems to offend.

spf13-vim is completely cross platform and has about even distribution across the different platforms of users.

http://vim.spf13.com

spf13-vim is pure vim script. No ruby required. spf13-vim is cross platform and works well on windows. spf13-vim uses a bundle system to make easy maintenance. Git submodules lock you into a specific hash of each plugin and maintenance in keeping these up to date only increases your commit count with empty commits.

spf13-vim is built to be a base and completely customizable. This is built to be your vim config.

Lastly spf13-vim has dozens of contributors supporting a variety of plugins and languages. This seems focused on squares stack, ruby & coffeescript.

Disclaimer... I'm spf13, so a bit partial, but if you look at spf13-vim from 2 or 3 years ago it looked a lot like this... and we've learned a lot from making some mistakes present here.