> for example just now I wanted to wrangle some bits so I asked it to make the masks for me.
Why do you think it will get that right? You have to do the work anyway to verify those are correct, that is exactly the kind of thing you shouldn't use an LLM for.
I have to actively, preemptively teach passengers how to open the door lest they crank it open manually, instinctively. My dad opened it manually 3x before understanding what I was saying.
The author goes on to explain a few scenarios where the pattern is helpful. It's not to keep main.go as small as possible, it's so that you can test parts of your main.go file properly. In my experience, if all of my logic is stuffed into `func main() {}`, then I can't actually test it. If I have a helper method(like run in this case), I can test out specific scenarios and ensure the application handles it properly. Some of the examples Mat gave were handling context cancellations properly.
There are so many situations where I have a feeling that people are solving problems that don’t exist. In code I run into at work, code and projects I see online, etc
The “whose dreams are you making come true” really applies here, because dreams are exactly what they are.
I spent quite some time writing an automatic image resizer and optimiser for my blog. Does it matter? No! Should I have spent that time writing blog posts instead? Yes! Still I was chasing some dream.
I've never been a fan of making main.go one line. I create the logger, parse the flags, create objects from the flags, and call Run() or something. In the tests, you aren't ever going to do those things in the same way, so there is really no point in putting them in some other file.
Usually your main function can't be used by any other part of your program. You should move all component implementations to modules so they can be re-used elsewhere.
For bespoke internal services, I like to keep main.go as flat as reasonable, like a "script". Handlers can have their own files but the bulk of the control flow and moving parts should be apparent from reading the main file.
Abstracting things away from main makes it less readable and is general pointless for bespoke services that will be deployed in exactly one configuration.
That's a nice way of putting it. When exploring a new codebase for the first time it can be very helpful to have main.go give you a high level idea about the overall structure of the program.
main() is the only place where you can't return an error. In order to keep as much of the code as idiomatic as possible you just call something like run() where you can do so.
In addition there is the testing aspect. You can't invoke main() from your tests.
The idea is to keep the untestable code as small as possible but in practice you just add a layer of indirection and all of your untestable init code is in a different castle.
This was going to be my complaint with the headset as well. I use 2x 49" super ultrawide displays, as well as 2x 27" 4k displays. Lots of real estate.
But then I started to think harder about what I was consuming display space with, and started to peel those things out into their Vision or iPad app equivalents. I'll not get into the obvious trade-offs of using iPad apps, but it largely suits the need.
Once I had Slack, Outlook, a Terminal, and TablePlus floating separately from the Mac display, I started to see a path toward potentially not caring if I even had the Mac display.
My teenage daughter came to me with tears in her eyes earlier today and asked me to watch a video. I watched with her and my heart sank. We shed a tear together for them. She had just made a ceramic pig mask at school a month ago, and regularly wears his merch. I'm glad he has been able to touch so many lives positively.
A great project Brendan. But as stated in Github issues, it is not worked on newer version of Go. I'm trying in Windows 10 and get error which look like:
`Error: 'date-time' main.go:59: open C:\Program Files Direct\duck\pings.json: The system cannot find the file specified.`
`not supported by windows. Request timeout for icmp_seq xx`
This is exactly why I got involved and support it on Patreon. I played this a ton as a teenager.
It is also written in my favorite language, Go, which means that on my Mac running Catalina this will likely be the only way to play the game in the future. I couldn't even get the game files without using a High Sierra VM. There's also the impending ARM transition, which this project should also easily support.
Excellent point! I remember back when the original Rosetta was discontinued, and I couldn't play WarCraft 3 on my Mac. Haven't played D2 for a couple of years, but very excited by your points that even ARM can't kill this project. If the OS merges between iPad and Mac then maybe even D2 on iPad using OpenDiablo2. Very cool!
I only joined the project just this week, but I can tell you that the game isn't playable yet. It launches and runs, allowing you to create a character and walk around in town. Most functionality isn't wired up yet. There are a lot of opportunities to contribute.
There are no plans to support any other games, but it sounds like they expect to be able to use it to create new games.
With productivity being measured as what, exactly?
The Venn diagram of "discussions about LLMs" and "Idea Guys Talking" is close to a circle in my experience.