If HashiCorp stuff is destined to die, something else will eventually rise to fill its niche if it's still valuable.

You can always count on technology to churn for no good reason.

To avoid sounding completely pessimestic: don't discount an IBM comeback either, for the same churning reasons.

I always have mixed feelings when a software company like this grabs their bag and leaves the community that helped build them, high and dry; good for them but still bad for everyone else nine out of ten times.

Be "interesting" to see what happens to the recently-renamed Terraform Cloud (now Hashicorp Cloud Platform Terraform :eyeroll:)

Edited to add: I'm guessing the feature I want added to the terraform language server is never going to happen now. Terraform's language server doesn't support registries inside Terraform Cloud, it doesn't know how to read the token in your terraformrc. bleh.

Also, it's probably the time to archive my Vagrant Machines repository. I guess all HashiCorp tools will be rolling downhill for personal use.

Not a bad place to end up after automating class sign-up at UW!

In the past, IBM was a technology leader, and probably still has substantial talent excellent inhouse, but from what I'm hearing it has become less appreciative of its researchers and engineers: for instance, my IBM friends lost any patenting activity related bonuses already several years ago.

Also, the Watson debacle (trying to monetize the Watson brand and the (impressive) Watson Jeopardy challenge results by quickly acquiring a bunch of stuff, only to then sell it as "our Watson AI technology") didn't help bolster its reputation, but rather harmed it further.

Companies like IBM and HP should go back to the roots, value science and engineering, take on bold blue-sky projects (don't leave those only to Musk!), and lead by example. Perhaps this could happen, but only with an engineer-scientist at the top instead of professional managers or bean counters (I'm not attacking the perormance of any individual here as I have not been following recent leadership activities of either company recently).

It is unlikely, IMHO, that an acquired company can change the culture of the acquirer. The only time I've seen this happening was Nokia benefitting Microsoft's culture, but that's because they made Nokia's CEO Microsoft's CEO, which is not going to happen with any likelihood in IBM's case.

Next up, Canonical, though they’ve been tilting sideways without an acquisition to push them.

Accelerate! Multi-cloud! Automation!

For a lot of developers including me, I never think about IBM or HashiCorp (or Oracle, SAP, etc.) and it's hard to imagine why someone would want to use their software compared to something newer, friendlier, cheaper, and probably faster. Is it just relationships?

Just curious how customers are actually getting value from an IBM or a HashiCorp or an Oracle.

Again, HN users are in a bubble, and HN users think that they’re very trendy.

Setting up a remote state in S3/Dynamo takes 5 minutes with a publicly available module and solves most of the problems TF cloud does.

That’d be my argument specifically against using it to communicate between pieces of software—at least if you’re hand-writing it there’s the excuse that it’s kinda, sorta easy to read and write (at least, people say that—IMO it’s only true for tiny, trivial examples, but that may be a matter of taste)

My take on it as a hand-written config/data language is that it’s simply absurd. JSON-schema is terribly unwieldy, but also the lingua franca, so if you want to keep your sanity you write something better to define your data structures (probably in some actual programming language) and generate JSON schema to share structure definitions among readers. Oh my—why?

https://hocon.dev

Hardly - it's a hack as a data-only subset of JavaScript, as a sibling comment mentions.

It has no support for comments (even though JavaScript does). No support for optimal trailing commas. No integers. No enums.

* IBM had little to do with Red Hat's maneuvers around CentOS (I worked at Red Hat for several years and still have friends there, and nothing anybody there said publicly about CentOS in 2020 or 2023 was materially different from things people there were saying about it internally in 2012). Some people have tried to blame IBM for a general culture shift but as far as I've seen, every bit of the CentOS debacle was laid squarely at the feet of Red Hat staff by most in this industry -- as it should have been, since most of those involved were employed there well before IBM bought the company.

IBM's reputation as an aging dinosaur was well-earned long before it bought Red Hat, and continues to be earned outside it. That earned reputation was why they bought RHT in the first place: IBM Cloud market share was (and still is) declining and they wanted a jumpstart in both revenue and engineering credibility from OpenShift in particular.

What I thought we really needed was a "starter/enterprise" dual-model pricing structure, so that smaller customers could get pricing in some unit they could understand and budget for, that would naturally and predictably grow as they grew, to a point where it would actually be beneficial to them to switch to client-based pricing -- but there seemed to be a general reluctance to have anything but a single pricing model for any of our products.

https://news.ycombinator.com/item?id=40149230

The problem is it doesn’t go much beyond that, so you’re limited by SSH roundtrip latency and it’s a pain to parallelize (you end up either learning lots of options or mitogen can help). However fundamentally you’re still SSHing to machines, when really at scale you want some kind of agent on the machine (although ansible is a reasonable way to bootstrap something else).

> Requiring minimal configuration changes, it updates Ansible’s slow and wasteful shell-centric implementation with pure-Python equivalents, invoked via highly efficient remote procedure calls to persistent interpreters tunnelled over SSH. No changes are required to target hosts.

Then of course python itself is not very performant and yaml is quite the mess too. With ansible, you have global variables, group level variables that can override them, host level variables that can override those, role level variables, play/book level variables that can override those and ad-hoc level variables that can override all of the above. I am telling you, it can get incredibly messy and needlessly complicated quickly.

As I said though, it's still the best we've got even if not optimal. So I think it's a good idea to implement it to at least have something.

[0]: https://mitogen.networkgenomics.com/ansible_detailed.html

There doesn't seem to be enough forces to create a MPL fork but at the same time we have a gap between "Docker Compose is enough" and running Kubernetes. Because there are many situations where going Kubernetes (or even lighter k0s, k3s type setups) does not make any sense.

My guess is no organisation which can afford to dedicate resources to contribute or create a fork need Nomad. So we end up with a big gap in the ecosystem.

This encouraged at least 4 companies to launch terraform-cloud-like products, and rather than compete and provide better service, Hashicorp responded by saying "take it or leave it, internet!" and they closed the open-source license on the interpreter (BUSL)... At my previous company we were driven away from terraform cloud and into the arms of env0 ... when it often takes 10 minutes for an execution to begin and you have no other executions in progress you realize that the terraform cloud SAAS product is just a total joke...

Every big, old, stagnant company is full of lifers who won’t move on for any number of reasons. The pay is good enough, at least it’s stable, the devil you know is better than the devil you don’t, yada yada yada. There are people in my life who work in jobs like that. They will openly admit that it sucks, but they are risk averse due to a combination of personality and family circumstances, so they stick it out. Their situation sucks, and they assume everything else sucks too. And often, because they’ve only worked in one place so long, they have a hard time finding other opportunities due to a combination of overly narrow experience and ageism.

The movie Office Space is about exactly the sort of company that is filled with lifers who hate their jobs but stay on the path of least resistance.

(I know absolutely nothing about working at Red Hat, so I’m not trying to make a specific claim about them. But I’ve known people in this situation at IBM and other companies that are too big for their own good.)

Before IBM purchase: travel to clients, build and/or fix their stuff, recommend improvements

After IBM purchase: travel to clients, build and/or fix their stuff, recommend improvements

At least on my side of the aisle I haven't noticed any notable changes in my day to day work for Red Hat. IBM has been very light touch on our consulting services.

    > Oh but they don’t innovate anymore.

https://www.ibm.com/docs/en/datapower-gateway/10.5.x?topic=2...

However, strong agree on using your home cloud's service.

We used Vault with Heroku and were happy.

While Hashicorp hasn’t been exciting for a while, I fail to see how an acquisition from IBM will invigorate excitement, much less even a neutral reaction from many developers.

Hashicorp had a huge hand in defining and popularizing the modern DevOps procedures we now declare as best practices. That’s a torch to hold that would be very difficult for a business like IBM.

Perhaps I missed some things but the core of Ansible feels like it’s continuing it’s path to be much less of a priority over the paid value-adds. I can’t help but to think the core of Hashicorp’s products will go down this path, hence my pessimism.

It's funny to characterise people's beef with IBM as that they're boring, old, and stale when IBM are apparently allergic to anyone over 40.

Also their consultants have been some of the most weaponised incompetence laden, rude, and entitled idiots I've ever had the sincere displeasure to deal with.

IBM are an embarrassment to their own legacy imo.

Fuck IBM.

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 and other, hard to maintain patterns instead of abstracting away things because it's so painful to create abstractions. (The Terraform/OpenTofu codebase is absolutely guilty of this btw, there is a reason why it's over 300k lines of code. There is a lot of procedural code in there with plenty of hidden global scope, so getting anything implemented that touches multiple parts typically requires a lot of contortions.)

It's not a bad language by any stretch, but there are things it is good at and things it is not really suited for.

[1]: [link redacted]

That's from someone who did a bunch - Perl, Ruby, Python, Java, C++, Scala.

Syntax is one thing, assembling an application with maintainable code is something else.

I'm sure you've broken many promises to your younger self.

It's a mistake if you care about the long term health of a company. But... why should you?

Hashicorp had a great run, and contributed a lot of great open source products over the years. Today, their products have large user bases and healthy forks seem likely. The founders and early employees cash out, and it's a win for everybody involved.

Nothing lasts forever.

>The software now branded as CentOS is basically Fedora

CentOS Stream (what replaced CentOS) is vastly more similar to CentOS than Fedora.

It's CentOS with rolling patches instead of bundling those same patches into minor releases every 6 months. Only the release model is different from RHEL / CentOS, otherwise it's built the same and holds to the same policies in terms of testing, how updates are handled and compatibility.

Fedora on the other hand is very, very different. Packages are built with different flags, different defaults (e.g. filesystems), very different package versions, a different package update policy (even within one major release Fedora is much more aggressive than CentOS Stream / RHEL / CentOS), etc.

I understand that not having an near-exact replica of RHEL supported for 10 years was very convenient and the way the EOL was announced, and the timelines, sucked massively. But CentOS Stream is suitable for a large number of the use cases where CentOS was used previously, it is not "basically Fedora". It's more like 98% RHEL-like wheras Fedora is doing something else entirely.

So unrelated to code generated, if that makes sense. The generated code I'm sure had lots of boilerplate, it's just not code we needed to consider when developing.

First of all your percentage of ownership is unrealistic. I joined in November 2019 and got a grant of a few thousand RSUs that fully vested before I left, and that I still have most of, plus I bought some shares in a few rounds of our ESPP when that became available -- as of today I have just under 5,000 shares. HashiCorp has nearly 200 million shares issued, so I own a hair over .0025% of the company. Really early employees got relatively big blocks of options but nobody I knew well there, even employees there long enough to be in that category (and there were very few of them still around by December 2021), was looking at "fuck-you money" just from the IPO.

Second, the current price isn't the whole story for employees. I had RSUs because of when I joined so the story might have been different for earlier employees who had options, but I don't think it differs in ways that matter for this discussion. As background for others:

* On IPO day in December 2021, 10% of our vested RSUs were "unlocked" -- a bit of an unusual deal where we could sell those shares immediately (or at any later time). Note "vested" there -- if you had joined the day before the IPO and not vested any RSUs yet, nothing unlocked for you. (Most of the time, as I understand it, you don't have any unlocked shares as an employee when your company IPOs -- you get to watch the stock price do whatever it does, usually go down a lot, for six months to a year.) * At a later date, if some criteria were met (which were both a report of quarterly earnings coming out and some specific financial metrics I forget), an additional tranche of vested shares (I think an additional 15%) unlocked -- I believe this was targeted at June 2022 and did happen on schedule. * After 1 year, everything vested unlocked.

At the moment of the IPO the price was $80, but it initially climbed into the $90's pretty fast. At one point, during intraday trading, it actually (very briefly) broke just above $100.

So, if you were aware ahead of time that the normal trajectory of stock post-IPO is down, and if you put in the right kind and size of limit orders, and if you were lucky enough to not overestimate the limit and end up not selling anything at all, then you could sell enough shares while it was up to cover the taxes on all of it and potentially make a little money over that. I was that lucky, and managed to hit all of those conditions while selling almost all of my unlocked shares (I even managed to sell a small block of shares at $100), plus my entire first post-IPO vesting block, and ended up with enough to cover the taxes on the whole ball of already-vested shares, plus a few grand left over. Since then, I haven't sold any shares except for what was automatically sold at each of my RSU vesting events.

For RSUs not yet vested at the IPO, the IPO price didn't matter because they sold a tranche of each new vesting block at market price to cover the taxes on them when they vested -- you could end up owing additional taxes but only, as I understand it, if the share price rose between vesting and sale of the remaining shares in the block, so you would inherently have the funds to pay the taxes on the difference. (And if the price fell in that time, you could correspondingly claim a loss to reduce your taxes owed.)

There were a fair number of people who held onto all their shares till it was way down, though, and had to sell a lot to cover their tax bill in early 2022 -- I think if you waited that long you had to sell pretty much all your unlocked shares because the price was well down by tax time (it bottomed out under $30 in early March 2022, then rose for awhile till it was back up over $55 right before tax day, so again, if you were lucky and bet on the timing right, you didn't end up too bad off, but waiting till the day before April 15 was not something I bet a lot of people felt comfortable doing while they were watching the price slide below $50 in late February). I even warned one of the sales reps I worked with, while the price was still up, about the big tax bill he should prepare for, and he was certain I was wrong and that he would only be taxed when he sold, and only on the sale price. (He was of course wrong, but I tried...)

The June unlock was pretty much irrelevant for me because by that point the share price was down under $30 -- it spent the whole month of June after the first week under $35. The highest it went between June 30, 2022 and today, was $44.34. The entire last year it's only made it above $35 on three days, and only closed above $35 on one of them. I figured long-term the company was likely to eventually either become profitable, or get bought, and in either case the price would bump back up.

I was thinking about cutting my losses and cashing out entirely when it dropped below $30 after the June layoffs, and again in November when it was below $20, and then yet again when I left the company in January of this year, but the analyst consensus seemed to be around $32-34 through all of that so I held on -- kinda glad I did now instead of selling at the bottom.

... Barely any employees could have that much stock. There's 2200 employees from the most recent data I see. Even if the outstanding shares were 100% employee owned, a uniform allocation would at best see a 0.045% between them all. Obviously, the shares are not uniformly distributed across employees, nor is hashicorp 100% employee owned.

There are many many people who made a loss on this, even before the acquisition announcement.

Also I think your ownership % is way off. There's a pretty small group of people, most of them the earliest employees + execs, who would have got out with $10M. HashiCorp currently has thousands of employees and would have churned through thousands more over the years.

If you are looking at OpenAPI in Golang I can recommend having a look at https://goa.design/. It's a DSL that generates OpenAPI specs and provides an implementation of the endpoints described. Can also generate gRPC from the same definitions.

We found this removed the need to write almost all of the API layer and a lot of the associated validation. We found the generated code including the server element to be production ready from the get go.

People got RSUs. They owed tax on said RSUs. The tax cannot be higher than the value of the RSU at the time of vest.

If people did not have enough cash to pay their tax bill, and did not sell enough RSUs to get cash to pay said tax bill, then yes, I can see those people "with a loss" because they had a "surprise" tax bill, RSUs price went down and a cash problem now. Is this what you mean happened?

They shouldn't have had to "sell everything" -- at most like 50%.

I'm arguing with you here because this stuff is complex, and many people shy away from trying to understand it, and that's a huge disservice for those in our industry.

For anyone reading along -- It's as simple as this: understand the tax implications of the assets you own, pay your taxes.

The problem occurs when 22% isn’t enough, which is often the case.

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.

I agree on the logging point but my experience was the explicit error handling and with good test coverage meant we rarely got into situations were we had non-deterministic situation were we relied extensively on logging to resolve. But we also went through several iterations of tuning how we logged errors. It's definitely a rough edge in what is readily available in the language.

    > I am not used to writing code where 2/3 of it is "if err" statements.

> Standard go error handling maximises for locality. You don't see many "long range" effects where you have to go and read the rest of the code to understand what's going to happen. Ideally everything you need is in the diff in front of you.

I'm assuming you're comparing to exceptions.

I don't know about that. I think this relies on discipline of the software engineer. I can see for example someone who is strict and only uses exceptions on failures and returns normal responses during usual operation.

With Go you can use errors.Is and errors.As which take away that locality. Or what's worse, you could have someone actually react based on the string of the error message (although with some packages, this might be the only way).

I still see your point though, but I also think Rust implemented what Go was trying to do.

You get a Result type, which you can either match to get the data and check the error, you can also pass it downward (yes, this will take away that locality, but then compiler will warn you if you have a new unhanded error downstream), or you can chose to unwrap without checking error, which will trigger panic on error.