This much more clear and honestly more impressive (because the first four are so obviously group effort that I discounted the last two - I had my suspicions about spf13-vim, though).
No, Steve that is not accurate. You didn't build MongoDB, Docker or Go. They were all wildly successful before you came on board. It's dishonest of you to insinuate that you built or helped build the core products. I can speak first hand for 10gen. For Docker you were not even there for a year, and for Go Rob was pretty clear who helped build it - Ian, Russ, Adam and a long list of people. You were ancillary involved around the periphery of all these.
Having worked on all these should be good enough you don't need to embellish and constantly overstate and lie about your contributions. Let other people talk about how great you are.
I think your wording was fine. I didn’t read that into it at all. Of course you worked with folks to do them. You also spent the majority of the post thanking people you worked with.
I’ve also read your code. I enjoy it and learned a lot more of go that way.
Whatever. Thanks for helping make Go so much fun for me. I look for excuses to write CLIs with Cobra/Viper. They’re of a very few set of libraries I look forward to using.
I use Hugo for much more than it was intended for.
Heck, I wrote a CLI with Cobra around Hugo and a simple theme for my personal note taking and todo management. I was annoyed with other markdown note tools and DIY was a fun waste of time :).
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.
Thanks, appreciate your response! Didn’t occur to me that you were talking about the UX for the entire ecosystem. Will read your blog for more details.
Technically I don't think "author of article says they can confirm that numbers they used in their article are accurate" really holds up as a valid argument ;).
Tongue-in-cheek feedback aside, congrats on all your achievements and good luck on your future projects!
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.
I know the feeling. In my very meta case I get frustrated with my own SSGs, so every time I start learning a new language an SSG is one of my two standard projects to give a frame of comparison.
I now have my own SSGs written in C#, Go, Node, Python, Ruby, and PHP.
It's totally ridiculous, I know. Yak shaving and shiny to the nth degree.
That makes a lot of sense to me. It used to be that writing a blog engine was the "Hello World" of a new language or framework. So, it makes sense that a SSG would be a good non-trivial project to use to learn or understand the pros/cons of a language.
Sorry to pile on here, but THANKS for Hugo! It’s legitimately great and has helped me quickly and easily updated (with the help of netlify) set up a really useful set of online notes for myself. I truly appreciate your work.
Hey - thanks for making Hugo. We run our blog on it and I love it. Spitting out an AMP version and maintaing it side-by-side with our non-AMP version was a piece of cake.
Edit: noticed you make Cobra too! Damn - I owe you like 1000 man hours of saved work.
When Jekyll was created, all Apple laptops shipped with Ruby, and Apple has (had?) a large share of the “developer/power user” market. That’s my theory, at least.
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.
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"