Also saying Apple reinvented the cursor is a bit much. Highlighting elements, snapping, and changing the cursor weren't just invented. The author really bought into Apple's marketing here.
I've found Chrome OS to provide the most Mac like experience outside of Mac. Its Linux app support is still in development, but I successfully made a Unity game on my Chromebook!
Glad to see Vapor/Perfect has toned down their "we are going to change the world by releasing a new web framework" rhetoric on their sites. When they both first did announced them it was pretty cringe
Value types are great, but they don't help cut down on cyclical references as the type of coding that will cause memory leaks is done in objects. Typically objects with complex dependencies and inheritance hierarchies.
Memory fragmentation is another legit concern I guess, as far as I can remember iOS has no memory compaction. Again not a necessarily an issue for a short live user space application, it is a larger one than memory leaks at least at my company. In some hot spots of our app we specifically slow down reading of some queries to reduce memory fragmentation.
Frankly Chris Lattner's claim that a GC leads to 2x-3x memory consumption over ARC is unfounded and sorta shocking coming from someone held is such high esteem. It's something thats continually shown to be untrue.
It always seems Swift's biggest selling point is it uses ARC instead of a GC, which is either not a large issue or a GC is actually more beneficial. Other than that you still haven't dealt with the toxic "Swifty" community, the terrible tooling situation, the immature libraries and frameworks, etc, etc.
There seems to be so many better solutions to writing server side code. This is all coming from someone who uses the language on a daily basis.
My main issue of Swift's implementation of ARC is it commonly leads to memory leaks. Even experienced developers can cause unintentional memory leaks. It's extremely common in iOS development. It's also hard to even detect and eliminate them, you just seem memory usage climb as your app ages. It not an issue with iOS because it is commonly very small and an app's have such a short lifecycle.
ARC would be just one my issues using Swift outside of iOS.
I think you are overstating the pause duration of a modern GC. I have used both Go and the JVM server side, not at a huge scale but enough to see GC effecting response times. They add some fluctuate, but nothing compared to network latency or the multitude of other factors that fluctuate heavily. It was never significantly relevant for response times. I'm looking at my server logs right now and theres not even a real correlation between GC and response time. Unless you are considering a 0-10ms fluctuation.
If you are interested in using an ARC server side I know Kotlin Native is using ARC however their implementation eliminates the cyclical reference issue.
Also using a Swift like ARC implementation server side that doesn't seem like a good idea. Memory leaks are so common in iOS development. Its just they are usually small enough and an iOS application lifetime is so short it doesn't matter. An ARC implementation that handles cyclical references seems like a more stable solution for a server.
-Note- I'm not saying one is better than the other. ARC works great on iOS for creating applications.
I have written server's in Kotlin, that run on the JVM and thus are practically the same. IMO I am far more productive then using Swift, plus you have access to a huge legacy of stable, well thought out, and documented libraries.
I work in Swift on iOS. I think the "Swift on a server" idea is way over hyped. There are so many issues with the whole Swift stack adopting that servers side would be a mistake IMO. One of issues with Swift on a server is ARC vs a Go-like GC. If a company is legitimately concerned about runtime efficiency, they already have such great solutions. Go being one of those.
I have been using C# a lot recently. I can't stand it. It feels like it it lacks a coherent design. I'm not a huge Java fan either, but at least it feels coherent to me. I have used a lot of different programming languages and can see the values in their different approaches, but I have a hard time seeing it in C#. Also C#'s tooling is only good on Windows.
I'm sorta in the same boat, but after Google announced Chromebooks will be getting first party support for Linux apps that is tempting me. I occasionally work on Linux, but I would love something more polished like ChromeOS.
I have run into the issue a few times. I've run into it most frequently when doing binary operations on 64bit numbers. When I first ran into the issue with going over `Number.MAX_SAFE_INTEGER`, it took me a long time to figure out that was the issue.
I can imagine this is an especially important advancement for server side JS. Not something I personally care about tho.
XCode 9 is unsurprisingly terrible for me. Between it and the Swift tool chain, they use over 10 gbs of memory and constantly using 100% of my CPU. XCode 9 seems like an improvement over 8 in some cases, but its way less stable, uses an insane amount of resources, and crashes more often.
This is a known weakness with differential privacy. Depending on how much noise you inject into your data, your analytics either approach meaninglessness or the privacy decays.
The hype machine surrounding Apple did not want to hear this and were just caught up with the idea "Apple could data mine you while maintaining ur privacy".
This sort of baseless speculation is not fruitful IMO. But I'll participate with my own hunch.
I don't think this is the case. The letter comes off as very genuine. It very much feels like what a immature "tech bro" would write. So much so when I first read it, I only skimmed it because it was so drab. You could have been at a bar surrounded by a bunch of drunk tech employees and heard very much the same thing. I only read it in entirety after the buzz got to loud to ignore.
Also I don't think there's a good chance he'll win a discrimination case against Google.
Also saying Apple reinvented the cursor is a bit much. Highlighting elements, snapping, and changing the cursor weren't just invented. The author really bought into Apple's marketing here.