There's even more to it — real conversations are interactive, so if a statement causes confusion, it can be cleared up immediately. Forum posts, however, must stand alone for the most part.
You probably also know the person you're talking to irl, so it's way easier to make the judgement call on whether they're serious or not, compared to a random person online.
So upgrade to 1.25? What reason could you possibly have to be so far behind?
I can understand staying one version behind latest, to not be exposed to brand new bugs, which do happen, but staying two versions behind is pointless.
Using a release less than two months is hardly “so far behind”. The 1.24 series had considerable regressions that have taken a number of patch releases to fix, it stands to reason that the same would be true of newer releases. Given there's still miscompilations getting fixed as late as 1.25.8, and 1.25 brought in large changesets for the new experimental GC, sticking it out while 1.24 is still getting patches a mere handful of weeks ago is not unreasonable.
> The version is the minimum version your project can be compiled with.
No, it's the minimum version my project is tested with.
> This means when you put a version like 1.25.7, you are deciding for everyone that imports you, transitively or directly, that they MUST be on Go 1.25.7+ to compile their project.
That is fine. This isn't Python or Java, you have no reason to ever be more than one version behind the current release. Just upgrade, it's painless.
> The fact that it defaults to the latest version is just a bad default that people should change.
Thanks for the link! I could have sworn this was "fixed" and was surprised testing 1.26.1 showed the same (IMO bad) behavior! Didn't realize there was a revert. https://github.com/golang/go/issues/77923 looks like a hopeful path forward.
> Words that are acronyms or initialisms (like API, URL or HTTP) should use a consistent case within the identifier. So, for example, apiKey or APIKey are conventional, but ApiKey is not. This rule also applies to ID when it is used as shorthand for the words "identity" or "identifier" — so that means write userID rather than userId.
Outdated.
Over time, it's become clear that breaking the camelCase convention in this manner is inappropriate:
- The inconsistency with the convention is jarring, consider `APIURL` - is that a variable (ApiUrl) or a constant (APIURL)?
- The inconsistency introduces doubt on how to write any given identifier - which is why the above advice even needs to exist
- The whole point of the convention is to make separate parts of the name visually separate, consider `someAPIURLHTMLJSONExtension` vs `someApiUrlHtmlJsonExtension`
- It's hard to keep this consistent - we may reasonably disagree whether `ID` should be capitalized or not, meaning you may just as well find both `ID` and `id` across codebases. This erases the benefits of capitalization altogether.
The benefits of keeping these acronyms capitalized are dubious and don't outweigh the downsides.
And of course, the real solution is to use the one correct naming convention - `snake_case`. Then you can capitalize all you want without trouble - `some_API_URL_HTML_JSON_extension`.
> The first thing that I dislike about this is that it encourages thinking of semicolons being inserted instead of statements being terminated
It might, but that's irrelevant since you never think about semicolons in Go at all.
> I like these formatting choices, but I'd prefer if the "wrong style" was still syntactically valid and a formatter would be able to fix it.
Your preference likely comes from some idealistic idea of "cleaniness" or similar, which isn't very convincing. Forcing everyone to use the same style is a huge win, to the point that it's a mistake to do anything else, as seen in the description of what Odin does. Completely wrong priorities there and refusal to learn from the past.
"Code formatting" isn't some inherent property of code that we must preserve at all costs, just a consequence of some unfortunate syntactical choices. There's no inherent reason why a language needs to allow you freedom to choose how to "format" your code. And there are in fact a lot of reasons why it shouldn't.
EVs are only quieter at very low speeds. If they're going 20 mph or less, they're great, but any faster and air and rolling resistance is most of what you hear.
It's also just as easy for a sociopath in an EV to roll down the windows and blast the neighborhood with noise from the stereo.
EVs are better in the sense that the mufflers of ICE vehicles can be deliberately defeated by twits.
The starting point is anti-anything-but-a-car, so it's understandable that in the process of getting to any sort of parity you'd feel like it's "harassment".
It's like claiming getting rid of slavery is "harassment", because your unfair privileges are being taken back.
You probably also know the person you're talking to irl, so it's way easier to make the judgement call on whether they're serious or not, compared to a random person online.
reply