361–370 of 391 posts
Earlier 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.
Earlier 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.
I prefer to handle errors than ignore them. "If err" is actually one of the best things about Go
Access forbidden? Log a warning and show a 403 page. Is is JSON? Then return JSON.
Exception-handling in general is a pretty small part of most applications. In Go, MOST of the application is error-handling, often just duplicate code that is a nightmare to maintain. I just don't get why people insist it's somehow better, after we "evolved" from the brute-force way.
Earlier quoted context omitted.
They where under IBM ownership at the time, so IBM did kill it. The software now branded as CentOS is basically Fedora, which is fine for desktops, but never felt good on servers. CentOS was perfect for a lot of us SysAdmins back in the day to use on our own servers etc, while using Red Hat at work. We also used it for anything PoC or servers that did not require support. These days licensing is easier using models l…
I work at Red Hat. IBM was not involved in the decision to kill CentOS. >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 th…
5 years is less than 10, but it's a lot less different than 10 vs 1
Earlier quoted context omitted.
You'd write in a language designed for humans, and that would get translated into a language for computers. In other words, JSON. What are your reasons for disliking JSON?
> language designed for humans 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.
It goes like this:
- XML was created to allow humans to write human-friendly data encoding (AKA "markup") that had lots of features they wanted programs to take advantage of.
- It turned out the format they chose was great for the machines, but really annoying for humans.
- They refused to change the format for humans, so humans got sick of it, and decided the problem was it was "too complicated" (as opposed to merely "too clunky").
- So they created some other formats, which weren't in any way better, but were simpler, so they could ignore the fact that they made the formats too clunky.
- Some formats' designers were opinionated, and decided things like "comments are an anti-pattern in a data format", so they took those features out.
- So now humans could manage the formats better. But they still wanted programs to take advantage of useful features - like multiple data types. So they implemented multiple data types in the formats.
- But the humans forgot that humans are still pretty dumb, and that most people never read specifications. So the users of the new format would incorrectly use the format, and run into the different data types accidentally (like true/false or null in JSON, or "The Norway Problem" in YAML), and claim the problem was the format, and not their own ignorance of it. (isn't the human ego amazing?)
- So the humans, not having learned from history, invented yet more data formats, with even fewer features, so that they would not continue to screw up the things they themselves invented. And so you get things like "restricted yaml" or "toml" (which is basically an .ini file, a format from 50 years before).
A data format that allows comments is called a "configuration file", and is supposed to be primarily read and written by humans, and requires a machine to implement a parser for it. Those are not always easy to write, which is why most people today have chosen to use data formats rather than configuration formats. But that has the unintended consequence of humans not understanding that types in data formats are a thing.
Back in the day we wrote the configuration format for the human, and used data formats for machinemachine communication. Some of those data formats were very easy for humans to read, but that was largely an accident of the fact that most programs had records so simple that we separated everything with newlines... not an engineering decision as much as a "hey, it's really easy to just read an entire data record as everything up to '\n'" thing.
Over time people have sort of become confused about what each format is and how it should be used, and what for. The data format churn (and constant griping) will continue, forever, because humans never learn their history.
Earlier quoted context omitted.
> Nomad especially holds a special place in my tech-heart. Same. I'm not a fan of the recent licensing changes and probably won't use it for any new installations, but Nomad enabled me to be an entire ops team AND do all my other startupy engineer duties as well with minimal babysitting. It really just works, and works fantastically for what it is. Nomad is like the perfect mix of functional and easy to manage.
The question is what to replace it with? 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 N…
Earlier quoted context omitted.
I prefer to handle errors than ignore them. "If err" is actually one of the best things about Go
In most web applications I write, I have one error-handling block. Access forbidden? Log a warning and show a 403 page. Is is JSON? Then return JSON. Exception-handling in general is a pretty small part of most applications. In Go, MOST of the application is error-handling, often just duplicate code that is a nightmare to maintain. I just don't get why people insist it's somehow better, after we "evolved" from the br…
But If you are coming from java I can understand the single error handling block is more comfortable, but coming from JavaScript/Typescript it's much more easy to check if err != nil, than to debug errors I forgot to handle, during runtime.
Well, 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”…
Well, 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”…
Earlier quoted context omitted.
I was an extremely early user and owner of a very large-scale Vault deployment on Kubernetes. Worked with a few of their sales engineers closely on it - was always told early on that although they supported vault on kubernetes via a helm chart, they did not recommend using it on anything but EC2 instances (because of "security" which never really made sense their reasoning). During every meeting and conference I'd as…
> was always told early on that although they supported vault on kubernetes via a helm chart, they did not recommend using it on anything but EC2 instances (because of "security" which never really made sense their reasoning). The reasoning is basically that there are some security and isolation guarantees you don't get in Kubernetes that you do get on bare metal or (to a somewhat lesser extent) in VMs. In particular…