Ugh. This is something I hate about Go. I would be happy to have unused variables generate warnings, but as errors, they turn the toolchain into an adversary.
It's common for me to temporarily comment out a variable's use when developing new code, as I experiment with ideas. It's even more common when working in unfamiliar code, such as tracking down a bug or incrementally adding a new feature. It's an important part of my exploration process.
When I hit Compile at that point, I expect the compiler to build the work-in-progress exactly as it is in that moment. Executing the output allows me to spot check the snapshot's behavior against my expectations and mental model. The compile step also assures me that no syntax errors have crept in while I was focused on the logic flow or general shape of the code.
When a compiler refuses to do its job, and instead barfs up spurious errors complaining about unused variables, it brings my workflow to a screeching halt. In order to make progress, I am forced to abruptly leave my current context to visit all the different places where those variables are introduced, edit them, try again, discover that those forced edits have left more variables unused, and repeat the process until the combative compiler shuts up and does what I told it to do in the first place. By the time I'm allowed to return to what I was doing, my train of thought has been derailed, the bits of logic that I had been juggling have fallen to the ground, and my focus destroyed. And then, once I have recovered my original thoughts and seen the output of my snapshot build, I have to go back and revert all those forced edits before I can resume my work.
What an aggravating, disruptive, and completely unnecessary waste of my time and attention.
I hope Andrew has the good sense to let errors of this kind be silenced or demoted to warnings, perhaps with a compiler flag or debug build mode.
Yeah it drives me insane. Working in any ide's golang lsp/plugin that tries to solve this for you every time you hit save also drives me insane. Feel like something is lost experiencing/learning/becoming masterful at a language when these types of decisions get automated while you're hand crafting.
I actually really valued my exploration into C where if i did that, id get a fat warning on compile, but I could still proceed to test my stuff. When I'm ready to commit to some cleanup efforts which is usually a headspace-thing, then I go cruise around and cleanup unused variables.
Well its also just idiotic in terms of how some huge number of people write code.
I know I'll need so-and-so import, so i write it at the top of the file before i even start, I press ctrl-s and it dissapears... I honestly laughed out loud the first time i used gopls.
The first time I saw something like this was in a music-focused virtual world from the 2000s. Strangers would strike up conversations with each other, dance (in some cases to well-known artists), wander around to see what others were doing, and generally just hang out.
> If the email matches their GitHub account, GitHub links the commit to their profile and grants them contributor status.
When the article mentioned email matching, I was concerned that it would break down when a contributor's email address changes. (I have contributed to more than a few projects over the years, using email addresses that no longer exist.)
However, it looks like they're not using the email address recorded in the author's original git commit, but instead a GitHub-generated address whose unique parts are the GitHub user ID and username. That should survive authors changing their email addresses. It would still break down if a contributor loses access to their account and has to create a new one, but that's probably less common.
This could be read as reductive, presumptuous, ignorant, and insulting.
At the same time, it's often technically true, but for a good reason that you neglected to mention:
Those old tools tend to be very capable email clients, not web apps with their awkward attempts to simplify complex conversation structure. A good email client can handle large, high-traffic, frequently branching, long-lived threads with ease. All the web forums I've ever used fail miserably here.
The people who are tasked with participating in large scale discussion groups (like the LKML) know this through experience. They prefer email because it works better. It makes their lives easier. It helps them to be more efficient, which is absolutely necessary given the sheer volume of messaging that they handle.
Yes, a specialized tool is required to get these benefits, just as a specialized tool is required to make web server output easily readable. Thankfully, these tools have existed for decades.
- Its cross-platform support was superior to Git's. (Git didn't get good Windows support until some years later.)
- Its ergonomics were superior to Git's, which was an important factor on its own, and especially important when trying to get a whole organization to retrain and retool around a distributed model.
- (It had a third major advantage over Git that I unfortunately cannot recall at the moment.)
So you weren't wrong back then...
...but Git improved over time, tipping the scale closer to a balanced state. It also had unbeatable author recognition, making it the obvious choice for anyone unaware of Mercurial's advantages, and eventually leading it to benefit from the network effect. And GitHub appeared, greatly improving Git's ecosystem with no support for Mercurial.
That's a matter of taste. I used both for serious work, at the time, and found Git much more usable. My experience with Mercurial was "welcome to Mercurial, how can we help you merge and push your work in progress even though that's not what you want?" My experience with Git was one where I felt in control at all times, had a clear workflow for when I did and didn't want to publish my changes (and for when I wanted to edit them first), and allowed me to quickly make and switch branches within a single working copy.
Thank you. I vaguely remember being put off by Mercurial at the time and feeling much more comfortable with git, but couldn't have put it into words as well as you did.
People always say you have to know git internals in order to use it, but that's just not true. Git has the right data model and has always been about empowering users to edit their data. Which makes the data model be "in your face" compared to the alternatives (and I think that's what people latch on to when they talk about "internals"), but it ultimately makes for a better tool.
I don't think the internal design is/was that similar. We switched from CVS to git, and were evaluating multiple choices. What tipped the scale in the end was our trust in the internal data model, which for git was the idea that it stores the snapshots, and they are immutable. The diffs you can get out of it are calculated on demand. Even if on-disk storage can end up using some diffs to save on space, the actual conceptual model of every operation is based on those snapshots, and that is also how every new commit is stored before repacking the repository.
This appealed greatly to us, and always meant that it is effortless to undo any operation because it only creates new snapshots, while the previous ones stay there for a while in case you need to recover the previous state.
This is in contrast with Mercurial, where the data store is (was?) a sequence of diffs, and then the state of the working tree at any time is reconstructed on demand from those diffs.
I don't know what you mean by ergonomics, but I remember trying both Mercurial and Git back in the days after using Subversion before. I didn't like how Mercurial didn't easily let me rewrite history and do stuff like `git commit --ammend` or `git rebase`. Mercurial users kept telling me using an extension to manage patches on top of Mercurial (I think it was quilt).
I agree about the Windows support. hg serve was also nice. Plus TortoiseHg.
Of course, it would also create a demand for open-source game server libraries, which would surely appear after a while and make the whole process much easier.
So while I believe you about all those difficulties existing today, it's plausible that they would mostly fade away over time. I think temporary growing pains would be an acceptable price for the significant long-term public benefit.
Technically DS is an independent sibling of Citroën within Stellantis, a sprawling car conglomerate that owns a dog’s dinner of car brands in Europe and USA.
If we want to get really technical, “DS4” is a model from Citroën and they later spun out the DS lineup into its separate brand, with the “Citroën DS4” becoming “DS 4”, “DS” being the make and “4” being the model.
https://kde.org/community/whatiskde/kdefreeqtfoundation/
reply