In my previous company, we "simply" used fixed versions for our dependencies. And we had our own NPM registry that only had already approved packages for specific version. Approval required a security review by someone from the Security team… At first I was super annoyed by this. But I started to like this approach. It also reduced surprises while developing in a team… "it works on my machine" was rare since everyone was using the exact same versions. And moving to a newer version was done on a regular basis but it was an intentional thing we did.

How did the security team conduct a security review of a non trivial package

they run it throuh a tool that checks online whether any cves relate to that version. They don't care whether you actually hit the vuln, if there's a cve it's "bad". That's usually the level i see.

I always found German unions pretty good.

I mean the union is correct in this case. Robots will replace jobs. A union’s job is to make sure there are jobs for people in the company they are already in.

Usually unions would speak the truth (“robots = jobs go away”) but pair this with some suggestions: eg trying to upskill the affected worker so that they can be moved to a different department).

While I was working in Germany I always felt better at a company with a strong union.

Fundamentally the union should be getting the workers a fair deal for their labour (conditions and wages); once the union starts interfering with the technical aspects or blocking labour saving investment it quickly sours the whole arrangement.

It's not even about blocking investment, they just want to make sure the employees still have jobs. You can invest if you find something else to do with the employee.

The main problem with unions in Germany is that they block companies from adapting to changes in the environment quickly. Companies become heavy behemoths and end up suffering from it, which ends up damaging their own employees as well.

I‘ve read this frequently, but I have yet to be convinced. The union presence seems to be more of a correlation than a causation to me.

Larger companies move slower, larger companies also tend to have a stronger union presence than SMBs

I can try convince you. In unionized companies one can’t fire employees from the 53rd birthday. That makes them similar to care home at the end. Young folks come and go and are minority at the end. Dynamics decrease not from the size, but from getting old. Since the salaries are more or less the same the oldtimers have maxed out bonuses. What do young guys get? Basically nothing since the bonus pool must be distributed equally in the company.

I like the concept of the union, but I think that IG Metall is not the good implementation of that. At least not for white collar workers.

Isn’t “nothing is truly safe” a common saying on HN? Safe is an absolute term and since nothing can be safe people usually avoid using safe as a standalone attribution to something. It is usually qualified in some way.

> Safe is an absolute term

Safe is generally a gradable adjective [1], though can be non-gradable in certain contexts (like programming).

We are getting into the weeds though, aren't we?

[1] https://learnenglish.britishcouncil.org/grammar/b1-b2-gramma...

I was just curious. This “nothing is safe” is just burnt into my brain and simply wanted to know the reason because it sounded so far fetched that safe is not absolute. But I totally agree.

The title is now “She Came Out of the Bathroom Naked, Employee Says”

Even with that there is nothing from you accidentally using [i]. Also there are just a ton of Swift APIS and bridge API that take an index and then crash… for full coverage you would need hundreds of safe wrappers… (doing what you propose though at least gives you. Some peace of mind..

Also Swift has a lot of other areas where it just lacks any safeguards… Memory issues are still a thing. It’s using ARC under the hood after all.

Infinite recursion is still a thing (not sure if this would even detectable - probably not).

Misuse of APIs.

And it introduces new issues: which methods are being called depends on your imports.

In my experience Swift lulls you into a false sense of safety while adding more potential safety issues and “only” solving some of the less important ones. objc has null ability as well. Which can warn u if used appropriately. objc also has lightweight generics. In practice this is all you need.

  > And it introduces new issues: which methods are being called depends on your imports.

also depending on how you casted it, it will call the method of the cast, not the actual one in the instance (which completely caught be off-guard when i started swift)

  > objc also has lightweight generics. In practice this is all you need.

i feel this too sometimes; sometimes simple really is best... tho i think some of these decisions around complexity is to allow for more optimization so c++ can be chucked away at some point...

You can simply import Swift packages and either they expose an Objc interface or you can provide it yourself – by wrapping it in Swift and exposing the things you need via @objc etc. You can - at the same time - also hide the wrapped framework and make it an impl. detail of the wrapper so that you could switch the wrapped framework while keeping your app code mostly stable. This also reduces the number of imported symbols… import 3rdPartyFramework imports all symbols, extensions, classes, types etc. vs. import MyWrapper only brings in the things you really need.

LLMs like the ones from Claude can ask questions and even have you pick from multiple choices or provide your own answer…

I think DevTools can be a very good money maker… I wrote two apps that were basically dev tools and they were the biggest of my money makers. I think it’s easier to make money from dev tools that are “apps” than dev tools that are “fundamental technologies” though so it probably heavily depends on the type of dev tools…

It's probably also easier to make cottage-industry money from a single useful tool and some associated services/consulting than it is to turn the whole thing into a big company expected to do the hockey stick curve thing (eg Docker).

It'll be interesting to see where Astral ends up landing on that; afaik they have a small team and have only raised seed money, but who knows.

I don't know if it's easier. I definitely think it's better, but there can be a lure to VC money that puts a company like Docker on that path. There's a world where Docker is a small company earning individually good money but with no hockey stick curve, and I think that's more sustainable and ultimately better for them.

I suppose they might disagree, of course :)

Docker was not gonna make it as a small individual tool as something podman like would get traction in that market.

Maybe, but I think it could have made a small team very wealthy and successful much more than it did a large company.

It was obviously pitched as an ecosystem/platform play, like "the next vmware" or something, but there was never anything close to a real moat there. Running a registry involved a lot of storage and transfer costs plus spam/abuse management, and private registry was always going to be a better fit for being integrated with CI platforms and the like more than a standalone service with its own auth and billing concerns.

What I like about objective-c’s error handling approach is that a method that can fail is able to tell if a caller considers error handling or not. If the passed *error is NULL you know that that is no way for a caller to properly handle the error. My implementations usually have this logic:

if error == NULL and operationFailed then log error Otherwise Let client side do the error handling (in terms of logging)

This is exactly how Companies are doing it… they put the money in a trust and pay for the ongoing costs by using interests from that trust.