IBM to buy HashiCorp in $6.4B deal
221–230 of 391 posts
Re: IBM to buy HashiCorp in $6.4B deal
#222Earlier quoted context omitted.
After having written probably over 100k lines of Go code, my impression is that Go is simple, but not easy. The language has very few features to learn, but that results in a lot of boilerplate code and there are more than a few footguns burried in the language itself. (My favorite [1]) I find it very hard to write expressive, easy to read code and more often than not I see people using massive switch-case statements…
Is it because secondSlice is a reference (pointer?) to firstSlice?
Both slices start out having the same underlying (bigger) array -so appending to one slice can affect the other one.
In the "bonus" part, though, the appends outgrew the original array, so new underlying arrays were allocated (i.e. the slices stopped sharing the same backing array).
Thanks for the heads-up, janosdebugs :)
Re: IBM to buy HashiCorp in $6.4B deal
#223Re: IBM to buy HashiCorp in $6.4B deal
#224Earlier quoted context omitted.
I am not used to writing code where 2/3 of it is "if err" statements. Also, refactoring my logging statements so I could see the chain of events seemed like work I rarely had to do in other languages. It's a language the designers of which - with ALL due respect - clearly have not built a modern large application in decades.
Yes because other language just hide errors from the user. I think the reason people find go a bit annoying with the error condition is because go actually treats errors as a primary thought, not an after thought like Python, Java.
My preference is a language like Elixir where most methods have an error-code returning version and a ! version that might raise an exception. Then you (the programmer) can choose what you need. If you're writing a controller method that is for production important code, use explicit. If you're writing tests and just want to catch and handle any exception and log it, use exceptions. Or whatever makes the most sense in each situation.
Re: IBM to buy HashiCorp in $6.4B deal
#225Well, it was nice while it lasted! HashiCorp always felt like a company made by actual engineers, not "bean counters". Now it will just be another cog in the IBM machine, slowly grinding it down, removing everything attractive, just like RedHat and CentOS. Hopefully this will create a new wave off innovation, and someone will create something to replace the monopoly on IaC that IBM now owns.
> HashiCorp always felt like a company made by actual engineers. IDK about this, in 2018 I was in a position to pay for their services. They asked for stupid amount of money and got none because they asked so much. Can't remember what the exact numbers were but but it felt like ElasticSearch or Oracle.
Re: IBM to buy HashiCorp in $6.4B deal
#226Earlier quoted context omitted.
After having written probably over 100k lines of Go code, my impression is that Go is simple, but not easy. The language has very few features to learn, but that results in a lot of boilerplate code and there are more than a few footguns burried in the language itself. (My favorite [1]) I find it very hard to write expressive, easy to read code and more often than not I see people using massive switch-case statements…
Is it because secondSlice is a reference (pointer?) to firstSlice?
So, when you slice a slice, if you perform an array operation like “append” while there is existing capacity, it will use that array space for the new value.
When the sliced value is assigned to another variable, it’s not a pointer that’s copied, it’s a new slice value (with the old length). So, this new value thinks it has capacity to overwrite that last array value - and it does.
So, that also overwrites the other slice’s last value.
If you append again, though, you get a (new) expanded array. It’s easier to see with more variables as demonstrated here: https://go.dev/play/p/AZR5E5ALnLR
(Sorry for formatting issues in that link, on phone)
Check out this post for more details: https://go.dev/blog/slices-intro
Re: IBM to buy HashiCorp in $6.4B deal
#227Earlier quoted context omitted.
If companies didn’t go public regular people would not be able to invest in innovation. As much as people hate it, public markets democratize access to investments
True but no company has a vested interest in the democratization of investment. IPOs are purely about getting paydays for founders.
Re: IBM to buy HashiCorp in $6.4B deal
#228Although I think they have very different use cases this means IBM own both Ansible and Terraform, both claiming to be IaC
Although there is significant overlap between the two, I prefer Terraform for resource provisioning and Ansible for resource configuration.
Re: IBM to buy HashiCorp in $6.4B deal
#229Earlier quoted context omitted.
They IPO'd in 2021.
Yes. And many of the Heroku employees you speak of would have got RSUs that owed taxes on an $80 basis, been trading far below that for most of that time, and now have a maximum expected value of $35. This is not a pay day for many people. Anybody who got a pay day were those that could liquidate in the IPO.
Smaller and bigger percentages will be different but that's retirement money for hundreds and hundreds unless you pretend to live in very high CoL area. Also, most of them will likely have to keep working thereyears before cashing out some other millions likely.
Re: IBM to buy HashiCorp in $6.4B deal
#230Well, it was nice while it lasted! HashiCorp always felt like a company made by actual engineers, not "bean counters". Now it will just be another cog in the IBM machine, slowly grinding it down, removing everything attractive, just like RedHat and CentOS. Hopefully this will create a new wave off innovation, and someone will create something to replace the monopoly on IaC that IBM now owns.
I don’t understand people’s beef with IBM. They have been responsible for incredible R&D within computing. I even LIKE redhat/fedora! HashiCorp had already been sold out since waaaay before this acquisition and I also don’t understand why their engineers are seen as “special”…
Self selection, to be sure, but their beefs were mostly about the crushing bureaucracy that was imposed on what was supposed to be a nimble type domain; (network) security is, after all, mostly leapfrog with the black hats.