[chmod775]

That's plenty, especially for stuff like VPN clients.

Many of the protocols you'll be talking were created when computers had maybe 32MB of RAM or less, and you wanted to do more on them than merely connect to a VPN.

Lots of network hardware still in use nowadays doesn't have much more RAM than that either.

Even now, after twenty years of continued development, an openvpn client with all of its shiny new features enabled only uses about 6MB-7MB on my computer.

[pjmlp]

Their problem was using Go in first place, but since they didn't want to add a language to their knowledge pool, they went on with this "solution".

And we all know how fat Go binaries tend to be.

[touisteur]

I know you mean it in jest, but language choice is far more than 'just' knowledge.

In see them young engineers bringing their new fancy stuff, and of course hitting walls everywhere, walls that we (old farts) sweated buckets to handle on our old. Dependency management (not only the libs, packages, but also the underlings OS, or libc, or even ISA...) and upgrade mills, training costs all over, coding standards to draw up, peer review tools and practices to upgrade, interfacing options with other projects to normalize, perf practices to upgrade... I'm forgetting many, and I have this email ready for every new language or tech, with all the hurdles to clear (and the post-mortem costs of clearing them in the past). Do the work, show your org and peers you thought about it seriously and how much we'll win.

If then the juice is worth the squeeze, by all means, let's go. It happens, a lot, but it can't be an individual choice for the whole org, or 'it's just a language'.

Sorry for the Sunday rant...

[pjmlp]

Indeed, however if Apple platforms are a deployment target, the least I would expect from any technical architect would be some kind of Objective-C or Swift knowledge.

This post is one good example of the implications of targeting platforms with languages outside of the ones provided in the SDK.

However as you say that is a lesson most young engineers have to go through, I also went through it.

[AceJohnny2]

> I have this email ready for every new language or tech, with all the hurdles to clear (and the post-mortem costs of clearing them in the past)

I would love for you to share this. (even if it's not english)

[rollcat]

In the end, it turned out to be more of a challenge than a problem, and resulted in improving the Go toolchain for everyone - bringing Go closer to being universally viable for this type of work.

Interesting journey, and a solution that benefits the broader community, not just the authors. It's a win-win in my book.

[pjmlp]

Just like Facebook betting in PHP ended up with Hippo and Hack.

Yet Facebook has learned it wasn't the best way of spending resources and nowadays most of their backend infrastructure is using C++, Java and whatever.