Keeping your Go modules compatible
blog.golang.org
Keeping your Go modules compatible
1–10 of 57 posts
Re: Keeping your Go modules compatible
#2Reading these blog posts, you get see Go's simplicity start to unravel with modules. Uncomparable structs? Type checking workarounds? You start to wonder if these bandaids would be necessary in a generics world.
For the record, I'm indifferent on the chosen module solution being right or wrong. My ideal module tool is something like npm, but it shows me the impact: diff the module changes, look at my code, and tell me what's impacted by the upgrade. Giving developers more information when upgrading libraries will go a long way towards making "update your libraries" a regular housekeeping task.
Re: Keeping your Go modules compatible
#3Reading these blog posts, you get see Go's simplicity start to unravel with modules. Uncomparable structs? Type checking workarounds? You start to wonder if these bandaids would be necessary in a generics world. For the record, I'm indifferent on the chosen module solution being right or wrong. My ideal module tool is something like npm, but it shows me the impact: diff the module changes, look at my code, and tell m…
> Reading these blog posts, you get see Go's simplicity start to unravel with modules. Uncomparable structs? Type checking workarounds? You start to wonder if these bandaids would be necessary in a generics world.
Nothing of this has to do with or would be better with generics.
Re: Keeping your Go modules compatible
#4Go modules and the entire package management and versioning system is just embarrassingly horrible. It looks like it was designed by people who have no background in software engineering at all. The language as a whole despite being now universally used as the backbone of cloud native, it honestly looks like it's intentionally designed to be horrible and insulting for anyone with sensible mind. Every obvious right decision looks like it's intentionally being replaced by a bad one if it's the right path is easier.
Re: Keeping your Go modules compatible
#5Go modules and the entire package management and versioning system is just embarrassingly horrible. It looks like it was designed by people who have no background in software engineering at all. The language as a whole despite being now universally used as the backbone of cloud native, it honestly looks like it's intentionally designed to be horrible and insulting for anyone with sensible mind. Every obvious right de…
Something I knew starting out, forgot, and learned again, is that there's a huge liability to spending your entire career working for one company.
There will be things they do so well they aren't even on your radar, and you will have a huge blindspot there. And there are things they tolerate that pretty much nobody else will. So you will either suffer in ignorance or learn some nasty, nasty habits.
Without moving you see no diversity, and without seeing diversity you shouldn't be put in charge of building anything for 'everyone'. You are only qualified for niche solutions, which unfortunately outsiders might not clue in on until they've invested heavily in your ideas.
Re: Keeping your Go modules compatible
#6Go modules and the entire package management and versioning system is just embarrassingly horrible. It looks like it was designed by people who have no background in software engineering at all. The language as a whole despite being now universally used as the backbone of cloud native, it honestly looks like it's intentionally designed to be horrible and insulting for anyone with sensible mind. Every obvious right de…
> Go modules and the entire package management and versioning system is just embarrassingly horrible. It looks like it was designed by people who have no background in software engineering at all.
Go modules is probably the most well-wrought versioning system for a programming language. The amount of thought that went into it is insane.
Re: Keeping your Go modules compatible
#7Go modules and the entire package management and versioning system is just embarrassingly horrible. It looks like it was designed by people who have no background in software engineering at all. The language as a whole despite being now universally used as the backbone of cloud native, it honestly looks like it's intentionally designed to be horrible and insulting for anyone with sensible mind. Every obvious right de…
Something I knew starting out, forgot, and learned again, is that there's a huge liability to spending your entire career working for one company. There will be things they do so well they aren't even on your radar, and you will have a huge blindspot there. And there are things they tolerate that pretty much nobody else will. So you will either suffer in ignorance or learn some nasty, nasty habits. Without moving you…
That's true, but Google is big and they use many languages, and the amount of ignorance needed to make Go cannot be explained by that alone.
Re: Keeping your Go modules compatible
#8Reading these blog posts, you get see Go's simplicity start to unravel with modules. Uncomparable structs? Type checking workarounds? You start to wonder if these bandaids would be necessary in a generics world. For the record, I'm indifferent on the chosen module solution being right or wrong. My ideal module tool is something like npm, but it shows me the impact: diff the module changes, look at my code, and tell m…
Gah in every language I want that interface comparison tool, and I keep on being disappointed.
Re: Keeping your Go modules compatible
#9Reading these blog posts, you get see Go's simplicity start to unravel with modules. Uncomparable structs? Type checking workarounds? You start to wonder if these bandaids would be necessary in a generics world. For the record, I'm indifferent on the chosen module solution being right or wrong. My ideal module tool is something like npm, but it shows me the impact: diff the module changes, look at my code, and tell m…
Despite the title, the problems that this article discusses could have happened even before modules were introduced. Before modules, your only choices were to stay compatible or break users. Modules give us the freedom to make breaking changes in a safe, documented way.
Re: Keeping your Go modules compatible
#10Go modules and the entire package management and versioning system is just embarrassingly horrible. It looks like it was designed by people who have no background in software engineering at all. The language as a whole despite being now universally used as the backbone of cloud native, it honestly looks like it's intentionally designed to be horrible and insulting for anyone with sensible mind. Every obvious right de…
Do you have any specific examples in mind?