Don't use Hugo. The maintainers are so detached from reality it's not even funny. The project is about 12 years old, has +80k stars on github and used in production by many. Despite that still no 1.0 version and they introduce breaking changes for no good reason. You website will break all the time. I made a mistake of creating few websites with it and now I have to rewrite them all in other SSG because I refuse to participate in this circus.
Can't agree, even though I was also hit by breaking changes from time to time with my own templates. Because this has a BIG upside: I am very happy with Hugo and how they love to solve problems in detail and think through features to the end. Because of these frequent re-factorings and sometimes (!) breaking changes, it gets more elegant every year.
And this is really not a production problem. As stated in the comments before, just don't upgrade if you don't want to / have no time yet. It is a self-contained static site generator without external dependencies. It won't break. And the security of an old Hugo binary is mostly a non-issue if you do not load remote content.
And, if you have some time: Their changes are really well documented. The changelogs are really good.
The main problem is sticking with an unmaintained template of a third party which breaks when you finally want to upgrade and don't want to fork / don't know when a an template update comes along. But that's the reason I write my own. It was worth the effort.
Eh. It’s written in go. I just built the binary, stuffed it in my repo and continued to use the same version for years. Then when I wanted to update I rewrote my whole theme from scratch, recompiled and now I’m set for years again.
and a convenience symlink ~/.local/bin/hugo, pointing to my "production" version. I can easliy call whichever version I like with hugo<tab><tab>. What am I missing?
It depends on your workflow I guess, but the advantages of having a Hugo version tagged in an image:
- sharing it easily between computers/users (docker pull registry/image:tag)
- having the appropriate binary version embedded in your code through a docker-compose in your repo
- having custom aliases dedicated to hugo included (build/serve/run...)
- using the exact same image in your CI/CD
- not "polluting" your local computer with some more stuff
In what specific areas Phoenix Live View is so far ahead? Do you mind elaborating?
The unfortunate disadvantage of Live View is that you need to write Elixir. A lovely language, but it would be hard to sell in company that use only <SOME_LANGUAGE>. The hypermedia libraries like d* and htmx can be used with any backend.
I like the idea of bundling Lua with bunch of batteries but the syntactic changes go too far. They seem to be lousily designed attempt at turning Lua into Typescript.
For example coalescing operator. You can do the same in standard Lua with or. Pipe operator might seem like cool idea, but the language needs to be designed around it (Elixir) or you need multiple variants (threading macros in Lisps).
Yeah, there are a lot of odd inclusions like that; things that overlap or replace standard lua flow for no reason (see ternary expressions[0]). I would love an expanded lua, with built-in classes and a more robust standard library, but this feels more like a rewrite into a new langauge with two vastly different design philosophies layered awkwardly on top of each other. Which it is I guess.
I don't mean to discount the work that has gone into it, and there are a lot of really neat features here. But honestly I think it would be stronger as a standalone thing, without all the lua baggage, given how far idiomatic pluto diverges from idiomatic lua.
local function report(result)
print(result ?? "The value was nil.")
end
report(filesize("/path/to/file/of/length/zero"))
If filesize returns nil for file-not-found and the length otherwise. Wouldn't coalescing work and or would not be able to identify existing but empty files.
As a TypeScript fan, I was really happy to read pretty much every one of these changes. This is a language I wouldn't personally use unless it gains massive traction, but one that I hope it gains massive traction so that I can justify spending the time memorizing and learning all these new language additions.
It's particularly exciting that they constantly rebase upstream Lua, and plan to update it to be compatible with Lua 5.5. Especially because Lua 5.5 finally has the ability to turn off globals!
One painful one that is still reverberating a bit in some areas is the renaming of "SafeConfigParser" to just "ConfigParser" in the standard library (in 3.12). This caused a whole lot of breaking in some areas because versioneer (a package for determining a package version from git tags) used it (in code that was placed inside your package, and so couldn't be solved by just upgrading versioneer).
Python 3.7.9 (default, Aug 23 2020, 00:57:53)
[Clang 10.0.1 ] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import cgi
>>>
Python 3.13.0 (main, Oct 8 2024, 01:04:00) [Clang 18.1.8 ] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import cgi
Traceback (most recent call last):
File "<python-input-0>", line 1, in <module>
import cgi
ModuleNotFoundError: No module named 'cgi'
reply