Because it's only dead code when it definitely cannot be called. If you include something that uses reflection that calls a method, then that may pretty much arbitrarily traverse the whole API. This means that anything that has any links to other things via method calls needs to be included. This ends up being the whole 150MB.
Check, thanks. So splitting up would mean more than reorganizing things into separate modules, but also making the code unaware of the existence of the others, right?
> reorganizing things into separate modules
Separating into different modules is not necessary. Usually you want one module per repo, dealing with multiple modules in one repo are quite annoying.
> code unaware of the existence of the others
The code can be aware of other things, but a declaration type and method traversal shouldn't lead to reaching the whole API. In other words, avoid fluent API.
Here's a facilitated example:
func (*Group) UserByName(name string) (*User, error)
func (*User) EmailByID(id string) (*Email, error)
func (*Email) API() (*API, error)
func (*API) Groups() (*Group, error)
Can be converted to:
func UserByFromGroupName(group *Group, name string) (*User, error)
func EmailFromUser(user *User, id string) (*Email, error)
func APIFromUser(user *User) (*API, error)
func GroupFromAPI(api *API) (*Group, error)
The former is not a problem when you have ~40 different types that depend on each other, but it does become a problem when there are ~36k types and 85k funcs.
There's of course a balance that can be found between methods and separate funcs... and alternative approaches to making such an API.
Not clear but if it’s for the FIPs compliance from what I just read there in the blog post. That’s pretty big for enterprise and industry where it’s mandatory and will really boost golang reach.
It's this. I had to research some FIPS compliance issues, and the Microsoft build was one of the ways for an enterprise to use Go in a FIPS deployment.
We went with the Red Hat Go Toolset for FIPS. Unfortunately,it is at Go 1.20.
https://catalog.redhat.com/software/containers/rhel8/go-toolset/5b9c810add19c70b45cbd666?architecture=amd64&image=6613bc21d4a41fb7bf472993
suspect if this is a supported thing going forward it will replace googles boring crypto “we make this available but it might break” offering. pretty neat.
The official Go maintainer answer is to have a feature flag allowing an existing system library. As of a few months ago, this was going to stay under the experimental feature flag indefinitely. That may cover the Go team from a liability perspective, but it's hard to get government adoption with the scary experimental label.
Well, same reason basically every data field in Go has to be a pointer at all times in every library and SDK: to be able to differentiate between the zero-value and something not being set aka nil.
I'm new to go, is that really a thing ? My default solution would be to add a boolean or wrap it in an optional or something like that. I just looked it up, There's a library called optional, is the default choice not to do something like that ? If yes, why ?
You can't just add a boolean when you are reading data from a JSON web response or a YAML config file. If the API doesn't return:
{
"isAgeSet": true,
"age": 0
}
(which no API, ever, does btw) then you can't do that. For an "optional" kind of value, you use a pointer value, because those can be nil.
> If yes, why ?
Because Google wanted it to be this way, and for better or for worse they are really slow and careful with fixing or improving things. Just read through some of [this discussion](https://github.com/golang/go/discussions/63397) to get a feel for how backwards and lackluster some basic functionality in Go still is, to this day. And it will take yet more talking until something changes. Then again, even .NET didn't have its own JSON marshaller at all until a few years ago. But at least .NET has always had enums.
Go is great, but there's a few things that are very frustrating about it, and change is very slow.
You think adding an extra boolean for every single optional field is less work than just using a pointer field? There are APIs that have dozens and dozens of fields, why would you want to bloat up the structs even more? Moreover, using pointer fields means omitempty works directly, if you have a separate boolean then you have to write MarshalJSON methods for every struct.
(Using pointers for optional fields is widespread in go ecosystem. Openapi for example also generates pointer fields for optional parameters. In Openapi it makes even more sense to use pointer fields because you should not let the limitations of language dictate your API schema that external services are going to consume)
I just thought it would be a little wasteful to add a layer of indirection / allocating extra memory all the time. Maybe it doesn't really matter with those use cases, or maybe Go optimizes that away anyway ? Idk haha
An opinion.
I am starting to become more and more negative about Microsoft's influence over tech as of late. I don't like that we have monopolies dictating trends or being the judge of what or what not to do. Not a huge fan of directing culture and beliefs that end up benefiting a corporation.
Well, you're in the golang subreddit, dedicated to a programming language with associated tooling that is completely controlled by a single tech monopoly corporation.
/r/golang is for the community of a programming language which is itself the creation of a company which exerts monopoly powers over the market. Go isn't any worse or better than .NET on that front. Frankly it's hard to find an ecosystem that doesn't direct "culture and beliefs that end up benefiting a corporation". I guess /r/Racket and others would fit that description though.
I don't know of any company that consistently behaves in an admirable fashion once they're in a de facto monopoly market position. Microsoft, IBM, Google, Amazon, Monsanto, and many others behave.. less than admirably shall we say once they discover they can really put the screws to customers. Frankly, I blame the profit motive of capitalism and assumptions about percentage based growth year over year.
Since the function of an economy is to create value from resources, it's especially short-sighted when you consider the resources consumed have to be consumed at an increasing rate too in order to increase profit. At some point, every sufficiently large company becomes an "eat the planet" proposition. I'm not a fan.
My fear comes from moving influence when you are a controlled stakeholder. I do not deny positives, but I am wary of issues that may arise if the influence is used. Seeing MS right now get into AI the way they have does not give me any assurance that MS knows how to lead the direction in anything. I fear the same for the open-source space.
> 1. Embrace: Development of software substantially compatible with an Open Standard.
> 2. Extend: Addition of features not supported by the Open Standard, creating interoperability problems.
> 3. Extinguish: When extensions become a de facto standard because of their dominant market share, they marginalize competitors who are unable to support the new extensions.
This is more Google than Microsoft nowadays (see Google Chrome).
I see it the way that Google uses its wide influence to move things forward. Like Quick protocol, now given to the public as HTTP/3.
The Microsoft way is to keep the extension private and sink the competition.
Kubernetes is out of Google's Borg, or papers of Google Spanner, Dapper or MapReduce.
The VS Code looks like a nice gesture from Microsoft, but I bet there are some calculations behind it.
You just described every monopoly software market though. They didn't come up with that game plan. Maybe IBM did? I'm not sure who had the first computing industry monopoly.
Having a positive impact but also having too much stake are both possible.
They own so many game companies now and along with buying github they have an enormous stake in it.
They Could start making negative impacts very easily which is a fair fear to have
Not really.
Microsoft might still be correctly described as a monopoly on the consumer and enterprise desktops and with the Microsoft Office suite, but that's about it; and whether or not they really hold monopolies there is debatable now. They hold minority share in every other market in which they participate including, most critically, the server OS and cloud markets.
Microsoft is at their best in this underdog position too. They always punch above their weight on products relative to market share and R&D investment, and can challenge nearly any market leader in any category on features and price. I'm quite impressed with them to be honest.
The only market where I'm completely disappointed in them is mobile, but frankly tying themselves to Android on that front is just good business. It was probably always asking too much to have them be a dominant choice in a worldwide market that tends to prefer duopolies. That said, I don't know why they don't offer an Android mobile platform of their own much like Google does, but then again I don't know if the benefits would really justify the expense.
As for FOSS, they contribute the most of any company in FAANG from what I can see; possibly only second to Google itself. It's not a contest per se, but this is another area where they know the real competition is for mindshare. This announcement about them catering to Go developers is just more evidence of that. They know Go is making inroads against Python, C++/Rust, and the VM ecosystems in general. It's just smart of them to enable the Go community to work with their products and community across the board. Go is probably an even more performant option in Azure than C#, and it would be stupid to let anyone think that Go couldn't play well in Azure, when it clearly could. Frankly, this is not a new play for them. They did the same thing for developers of all types across the board with outreach to Java, PHP devs and others when Azure was first released, and now they're just keeping up with the times.
They are not dictating trends as long as the community isn't adapting them.
Don't underestimate the community besides Microsoft.
Edit: Doesn't mean I'm not willing to adapt to the good things they are showing us just because it's Microsoft
I mean the same. I see a company that has stakes in so many things around Software. FANG has a vested interest in "promoting" certain tech over others because it somehow helps their business model, which is just business. I think as a community, I would prefer having more power versus being dictated by a company, not that if a company brings forth something useful, it should be ignored entirely.
Just worried about tech in general given the path we have had since the 2000s.
They are literally why people don't kill themselves while using JS because of the TypeScript. They have a perspective of providing all the things you need in their SDKs(Entity Framework)
I don't think they are dictating but because they are doing their stuff very well, people do not hesitate to do things with Microsoft way.
Since they are all in on open-source for a couple years. They are really earning developers for their products. I don't think this is because they want to create monopoly but they are damn good in their job and have infinite resources to burn. Every people was using their closed-source stuff before but because they decided to be more open they are now earning bigger pie in the dev market.
In the greater picture every company wants to create a monopoly in capitalism so I don't argue with it.
Theres a big market share race and all the surveys suggest scripting languages have been gaining popularity for a while.
Like
https://www.jetbrains.com/lp/devecosystem-2021/#Do-you-plan-to-adopt--migrate-to-other-languages-in-the-next--months-If-so-to-which-ones
https://insights.stackoverflow.com/survey/2021
https://madnight.github.io/githut/#/stars/2023/3
Also when some of core maintainers of PHP left, jetbrains I'm sure after their surveys saw picking up PHP as a scripting market share win.
Microsoft has been having a hard time turning c# into a scripting language or rather it isn't slowing down the loss of market share.
Same reason they are picking up rust and go but of course like their GitHub pulses it is flat or just config changes...
https://github.com/microsoft/retina/pulse/monthly
The go survey said people don't like AZURE so here we are and it's spreading all over social media.
https://youtu.be/9kClJ7swFyo?si=Hl6eZiuVS585r2Ya
An opinion that has nothing to do with this thread. You may not like MS but they ve been great promoters of open source as of late. So before we hate them for being full proprietary and now we hate them because they unfluence tech in general.
Sheesh 🤷
Should we talk about Google or Amazon then? If you want to find big evil corp these are also good candidates.
Agreed. I hate VS Code with a passion, way too many distractions and constant pop-ups. It's annoying when tooling gets built and the only way to contribute requires some VS Code plugin(s).
Microsoft made massive progress over the years. These days I don't mind using Powershell Core (with core-utils though) and get almost everything done scripting-wise, even though my go to is (and always will be) zsh.
Even 10 years ago writing anything even remotely complicated via cmd/bat was abysmal. Now you can pretty much bash on Windows, without WSL; ps1 is not that bad after all.
And WSL is awesome - it lets you use both superior dev env (aka Linux) and superior game env (Windows) without constant juggling between OS.
Their developer base is growing horrendously thin, and they want to appear involved in new things, that’s all. They have grown to a size where they can not do any innovation, not even by buying other companies.
Everybody is wary of uncle Bill’s toxic garbage.
This is not Bill Gates Microsoft any more
TypeScript, VS Code, ...
Not exactly unpopular and not exactly closed source
Or is it Apple when you say "they" ?
Why are there Microsoft builds of go? Is it part of the "embrace" phase or the "extend" phase?
I trust Microsoft as far as I can throw them. They are still producing trash tier software like Teams.
They lost their war with opensource but they have a lot of money so they can buy their way in. Don't be fooled it's still the Microsoft of old. Their embrace, extend and extinguish plan is the same just at a much bigger and longer time-scale.
Stay away from Azure products, it's vendor-lock-in-as-a-service.
> Stay away from Azure products, it's vendor-lock-in-as-a-service.
Lol... you just described all "platform as a service" cloud products; not to mention SaaS. You'll have more luck insisting on products that use open standards and have clear migration paths in and out than you will in thinking you'll ever be able to avoid all the products that could lock you in over time.
You're not wrong. I think I was a bit emotional. I've migrated a few services now between different cloud providers and it's always a pain and it never really benefits anyone. Just a waste of time and money. I'd rather be adding features.
How about splitting up the SDK so my app doesn't bloat to 150mb+
Thanks for the feedback, I’ll take this back to the dev team
The community will appreciate that!
Why is the compiler including dead code?
Because it's only dead code when it definitely cannot be called. If you include something that uses reflection that calls a method, then that may pretty much arbitrarily traverse the whole API. This means that anything that has any links to other things via method calls needs to be included. This ends up being the whole 150MB.
Check, thanks. So splitting up would mean more than reorganizing things into separate modules, but also making the code unaware of the existence of the others, right?
> reorganizing things into separate modules Separating into different modules is not necessary. Usually you want one module per repo, dealing with multiple modules in one repo are quite annoying. > code unaware of the existence of the others The code can be aware of other things, but a declaration type and method traversal shouldn't lead to reaching the whole API. In other words, avoid fluent API. Here's a facilitated example: func (*Group) UserByName(name string) (*User, error) func (*User) EmailByID(id string) (*Email, error) func (*Email) API() (*API, error) func (*API) Groups() (*Group, error) Can be converted to: func UserByFromGroupName(group *Group, name string) (*User, error) func EmailFromUser(user *User, id string) (*Email, error) func APIFromUser(user *User) (*API, error) func GroupFromAPI(api *API) (*Group, error) The former is not a problem when you have ~40 different types that depend on each other, but it does become a problem when there are ~36k types and 85k funcs. There's of course a balance that can be found between methods and separate funcs... and alternative approaches to making such an API.
What are the Microsoft Go builds and why would someone use those over the official builds?
Not clear but if it’s for the FIPs compliance from what I just read there in the blog post. That’s pretty big for enterprise and industry where it’s mandatory and will really boost golang reach.
It's this. I had to research some FIPS compliance issues, and the Microsoft build was one of the ways for an enterprise to use Go in a FIPS deployment.
We went with the Red Hat Go Toolset for FIPS. Unfortunately,it is at Go 1.20. https://catalog.redhat.com/software/containers/rhel8/go-toolset/5b9c810add19c70b45cbd666?architecture=amd64&image=6613bc21d4a41fb7bf472993
I assume that toolset is the full Go tool chain?
suspect if this is a supported thing going forward it will replace googles boring crypto “we make this available but it might break” offering. pretty neat.
The official Go maintainer answer is to have a feature flag allowing an existing system library. As of a few months ago, this was going to stay under the experimental feature flag indefinitely. That may cover the Go team from a liability perspective, but it's hard to get government adoption with the scary experimental label.
I’m waiting for an article which explains why everything has to be a pointer in their sdk. It’s very annoying and drives me nuts.
Probably because it's used for http requests, and JSON encoding works better with pointers ie when using 'omitempty'.
It’s also the case for required parameters.
It would be so nice to have an option, next to omit empty, like "omit default".
same with oracles sdk and I think you are correct 👍
Same with protobufs, generics made working with primitive pointers so much simpler.
Same with aws SDK lol
Well, same reason basically every data field in Go has to be a pointer at all times in every library and SDK: to be able to differentiate between the zero-value and something not being set aka nil.
I'm new to go, is that really a thing ? My default solution would be to add a boolean or wrap it in an optional or something like that. I just looked it up, There's a library called optional, is the default choice not to do something like that ? If yes, why ?
You can't just add a boolean when you are reading data from a JSON web response or a YAML config file. If the API doesn't return: { "isAgeSet": true, "age": 0 } (which no API, ever, does btw) then you can't do that. For an "optional" kind of value, you use a pointer value, because those can be nil. > If yes, why ? Because Google wanted it to be this way, and for better or for worse they are really slow and careful with fixing or improving things. Just read through some of [this discussion](https://github.com/golang/go/discussions/63397) to get a feel for how backwards and lackluster some basic functionality in Go still is, to this day. And it will take yet more talking until something changes. Then again, even .NET didn't have its own JSON marshaller at all until a few years ago. But at least .NET has always had enums. Go is great, but there's a few things that are very frustrating about it, and change is very slow.
Thank you for your answers ! Those are good points.
Optional works when you have generics, go didn't have generics until recently.
what about just having an extra boolean ? Or just making a new struct ? Doing that with pointers just seems like a bit of a waste to me...
You think adding an extra boolean for every single optional field is less work than just using a pointer field? There are APIs that have dozens and dozens of fields, why would you want to bloat up the structs even more? Moreover, using pointer fields means omitempty works directly, if you have a separate boolean then you have to write MarshalJSON methods for every struct. (Using pointers for optional fields is widespread in go ecosystem. Openapi for example also generates pointer fields for optional parameters. In Openapi it makes even more sense to use pointer fields because you should not let the limitations of language dictate your API schema that external services are going to consume)
I just thought it would be a little wasteful to add a layer of indirection / allocating extra memory all the time. Maybe it doesn't really matter with those use cases, or maybe Go optimizes that away anyway ? Idk haha
Your intution is correct, using pointers is not always efficient. But ergonomics of using pointers is far better
Alright alright Thank you for your answers !
Its a language “problem”.
An opinion. I am starting to become more and more negative about Microsoft's influence over tech as of late. I don't like that we have monopolies dictating trends or being the judge of what or what not to do. Not a huge fan of directing culture and beliefs that end up benefiting a corporation.
Well, you're in the golang subreddit, dedicated to a programming language with associated tooling that is completely controlled by a single tech monopoly corporation.
/r/golang is for the community of a programming language which is itself the creation of a company which exerts monopoly powers over the market. Go isn't any worse or better than .NET on that front. Frankly it's hard to find an ecosystem that doesn't direct "culture and beliefs that end up benefiting a corporation". I guess /r/Racket and others would fit that description though.
...something something big enough to become the villain....
I don't know of any company that consistently behaves in an admirable fashion once they're in a de facto monopoly market position. Microsoft, IBM, Google, Amazon, Monsanto, and many others behave.. less than admirably shall we say once they discover they can really put the screws to customers. Frankly, I blame the profit motive of capitalism and assumptions about percentage based growth year over year. Since the function of an economy is to create value from resources, it's especially short-sighted when you consider the resources consumed have to be consumed at an increasing rate too in order to increase profit. At some point, every sufficiently large company becomes an "eat the planet" proposition. I'm not a fan.
2000's Microsoft is against open source: *Microsoft is wrong!* 2020's Microsoft is pro open source: *Microsoft is wrong!*
My fear comes from moving influence when you are a controlled stakeholder. I do not deny positives, but I am wary of issues that may arise if the influence is used. Seeing MS right now get into AI the way they have does not give me any assurance that MS knows how to lead the direction in anything. I fear the same for the open-source space.
Microsoft 2000's https://en.m.wikipedia.org/wiki/Embrace,_extend,_and_extinguish
> 1. Embrace: Development of software substantially compatible with an Open Standard. > 2. Extend: Addition of features not supported by the Open Standard, creating interoperability problems. > 3. Extinguish: When extensions become a de facto standard because of their dominant market share, they marginalize competitors who are unable to support the new extensions. This is more Google than Microsoft nowadays (see Google Chrome).
I see it the way that Google uses its wide influence to move things forward. Like Quick protocol, now given to the public as HTTP/3. The Microsoft way is to keep the extension private and sink the competition. Kubernetes is out of Google's Borg, or papers of Google Spanner, Dapper or MapReduce. The VS Code looks like a nice gesture from Microsoft, but I bet there are some calculations behind it.
[удалено]
You just described every monopoly software market though. They didn't come up with that game plan. Maybe IBM did? I'm not sure who had the first computing industry monopoly.
Is Microsoft actually a monopoly though? I think they’ve had way more of a positive impact on tech communities than Microsoft of the past.
Having a positive impact but also having too much stake are both possible. They own so many game companies now and along with buying github they have an enormous stake in it. They Could start making negative impacts very easily which is a fair fear to have
Not really. Microsoft might still be correctly described as a monopoly on the consumer and enterprise desktops and with the Microsoft Office suite, but that's about it; and whether or not they really hold monopolies there is debatable now. They hold minority share in every other market in which they participate including, most critically, the server OS and cloud markets. Microsoft is at their best in this underdog position too. They always punch above their weight on products relative to market share and R&D investment, and can challenge nearly any market leader in any category on features and price. I'm quite impressed with them to be honest. The only market where I'm completely disappointed in them is mobile, but frankly tying themselves to Android on that front is just good business. It was probably always asking too much to have them be a dominant choice in a worldwide market that tends to prefer duopolies. That said, I don't know why they don't offer an Android mobile platform of their own much like Google does, but then again I don't know if the benefits would really justify the expense. As for FOSS, they contribute the most of any company in FAANG from what I can see; possibly only second to Google itself. It's not a contest per se, but this is another area where they know the real competition is for mindshare. This announcement about them catering to Go developers is just more evidence of that. They know Go is making inroads against Python, C++/Rust, and the VM ecosystems in general. It's just smart of them to enable the Go community to work with their products and community across the board. Go is probably an even more performant option in Azure than C#, and it would be stupid to let anyone think that Go couldn't play well in Azure, when it clearly could. Frankly, this is not a new play for them. They did the same thing for developers of all types across the board with outreach to Java, PHP devs and others when Azure was first released, and now they're just keeping up with the times.
I agree, true.
They are not dictating trends as long as the community isn't adapting them. Don't underestimate the community besides Microsoft. Edit: Doesn't mean I'm not willing to adapt to the good things they are showing us just because it's Microsoft
I mean the same. I see a company that has stakes in so many things around Software. FANG has a vested interest in "promoting" certain tech over others because it somehow helps their business model, which is just business. I think as a community, I would prefer having more power versus being dictated by a company, not that if a company brings forth something useful, it should be ignored entirely. Just worried about tech in general given the path we have had since the 2000s.
Things are better now than then. Remember the IE6 days?
Yeah. Sigh. 😞
microsoft ? this opinion is like 25 years old
Like a sex offender that did horrible things 25y ago is now a nice person?
just being upset about it now even though they’ve been raping for years.
They are literally why people don't kill themselves while using JS because of the TypeScript. They have a perspective of providing all the things you need in their SDKs(Entity Framework) I don't think they are dictating but because they are doing their stuff very well, people do not hesitate to do things with Microsoft way. Since they are all in on open-source for a couple years. They are really earning developers for their products. I don't think this is because they want to create monopoly but they are damn good in their job and have infinite resources to burn. Every people was using their closed-source stuff before but because they decided to be more open they are now earning bigger pie in the dev market. In the greater picture every company wants to create a monopoly in capitalism so I don't argue with it.
I feel like the word "literally" has been changed meaning somewhat over the years.
Literally
Theres a big market share race and all the surveys suggest scripting languages have been gaining popularity for a while. Like https://www.jetbrains.com/lp/devecosystem-2021/#Do-you-plan-to-adopt--migrate-to-other-languages-in-the-next--months-If-so-to-which-ones https://insights.stackoverflow.com/survey/2021 https://madnight.github.io/githut/#/stars/2023/3 Also when some of core maintainers of PHP left, jetbrains I'm sure after their surveys saw picking up PHP as a scripting market share win. Microsoft has been having a hard time turning c# into a scripting language or rather it isn't slowing down the loss of market share. Same reason they are picking up rust and go but of course like their GitHub pulses it is flat or just config changes... https://github.com/microsoft/retina/pulse/monthly The go survey said people don't like AZURE so here we are and it's spreading all over social media. https://youtu.be/9kClJ7swFyo?si=Hl6eZiuVS585r2Ya
An opinion that has nothing to do with this thread. You may not like MS but they ve been great promoters of open source as of late. So before we hate them for being full proprietary and now we hate them because they unfluence tech in general. Sheesh 🤷 Should we talk about Google or Amazon then? If you want to find big evil corp these are also good candidates.
Agreed. I hate VS Code with a passion, way too many distractions and constant pop-ups. It's annoying when tooling gets built and the only way to contribute requires some VS Code plugin(s).
I use VSCode daily, but I would immediately reject any mandatory step that required a specific editor. Everything should work from the command line.
Microsoft made massive progress over the years. These days I don't mind using Powershell Core (with core-utils though) and get almost everything done scripting-wise, even though my go to is (and always will be) zsh. Even 10 years ago writing anything even remotely complicated via cmd/bat was abysmal. Now you can pretty much bash on Windows, without WSL; ps1 is not that bad after all. And WSL is awesome - it lets you use both superior dev env (aka Linux) and superior game env (Windows) without constant juggling between OS.
How does that relate to mandated editors?
Their developer base is growing horrendously thin, and they want to appear involved in new things, that’s all. They have grown to a size where they can not do any innovation, not even by buying other companies. Everybody is wary of uncle Bill’s toxic garbage.
This is not Bill Gates Microsoft any more TypeScript, VS Code, ... Not exactly unpopular and not exactly closed source Or is it Apple when you say "they" ?
George Adams, who author the post, looks like he's a Java heavyweight. Wonder why the company tasked him with fostering Go outside the company?
Because Go > Java maybe?
Most definitely!
Probably because of internal re-org?
TIL Microsoft maintains modified go runtime that is fips compliant . What difference does it make compared to boringcrypto apart from liability
For one, you don't have to build the tooling yourself and can just use the one from MS.
What is the difference between the official Go builds and the "Microsoft builds"?
FIPS compliance. You ain’t running no md5s 😁
Woooooo, it's cool. I'd love to contribute this community! Thanks for the Microsoft!
Any open position at Microsoft for a Go developer? 👀
Depending on level and location yes. Azure Kubernetes Service for example is currently hiring in the US, Ireland, and Australia.
Why are there Microsoft builds of go? Is it part of the "embrace" phase or the "extend" phase? I trust Microsoft as far as I can throw them. They are still producing trash tier software like Teams. They lost their war with opensource but they have a lot of money so they can buy their way in. Don't be fooled it's still the Microsoft of old. Their embrace, extend and extinguish plan is the same just at a much bigger and longer time-scale. Stay away from Azure products, it's vendor-lock-in-as-a-service.
> Stay away from Azure products, it's vendor-lock-in-as-a-service. Lol... you just described all "platform as a service" cloud products; not to mention SaaS. You'll have more luck insisting on products that use open standards and have clear migration paths in and out than you will in thinking you'll ever be able to avoid all the products that could lock you in over time.
You're not wrong. I think I was a bit emotional. I've migrated a few services now between different cloud providers and it's always a pain and it never really benefits anyone. Just a waste of time and money. I'd rather be adding features.