Linker, can you spare a meg? (2021)
tailscale.com
tailscale.com
But then again, in my day-to-day work we probably solve problems in languages without GC in ways that would raise eyebrows with the Go specialists at Tailscale. To each team their own favorite pet language, I guess!
That number can't possibly be right. Even the most high-end iPhones "only" have 6GB, the rest max out at 4GB and that only recently. And I highly doubt that iOS will let you play with 5GB even on a 6GB device.
why didn't the ios team do this before? 15 MB seems very low for network extensions
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.
And we all know how fat Go binaries tend to be.
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...
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.
I would love for you to share this. (even if it's not english)
Interesting journey, and a solution that benefits the broader community, not just the authors. It's a win-win in my book.
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.
So in some sense, it is the kind of strategy that is required when needed to prove a point instead of trying to convince others just with words, which is always a big pain point when trying to talk about better approaches to secure software development.
The ml framework I use (ncnn) uses vulkan beneath.
For an iPhone 12 (which shipped with iOS 14) just the 2 framebuffers for a double buffered display will take up the 15 MiB. Operating systems that are "significantly less than" 15 MiB would not be suitable to run a modern personal computing device.
Layer upon layer upon yet another layer of abstraction have made it so nobody sees the turtles the whole thing rests on...
Back in those days a screen was often 640x480 = 307 200 pixels
An iPhone 12 Mini has a 1080×2340 screen = 2 527 200 pixels = over 8 times the size of those old screens
Today's OS:es work with much much larger datasets overall, not just in graphics but elsewhere as well, and are optimized for that
Didn't JavaScript runtimes get close to C/C++ performance exactly because they started using JIT compilation?
Languages that benefit from JIT compilation are languages with a dynamic type system: the JIT profiles the hot paths to optimize (e.g. this function is called a lot with integer parameters but only once with string parameters, so I'm going to compile the version with ints to optimal code and compile the string version to a suboptimal but inexpensive code)
Go on the other hand has a static type system, so when you AOT compile it can already produce all the optimal code needed thanks to static types.
Type information is not the only thing that helps though. Partial specialization can be applied to other things.
You can AOT compile them, but the code cannot ever be optiomal without any kind of PGO feedback loop, thus a JIT ends up being a much better option.
Unless they support optional types, like in the Lisp based languages.
So something like Typescript could eventually have a good AOT story, and this is what Microsoft does on their MakeCode project, compiling a Typescript subset via C++ code generation.
I guess another reasonable strategy would be to instrumentalize the code, run it once, and feed the results back to another AOT compiler pass which then optimizes the code based on usage statistics. But that would not apply to Go really, because it has strong typing already.