101–110 of 235 posts
Earlier quoted context omitted.
My mistake, I shouldn't have put a number there since that is what you focused on. Rewriting it in assembly is the way to go, but that has other tradeoffs.
I’m not focused on a number, I’m just pointing out Go’s optimisation potential is lower than other options. Of course it’s a trade off and their reasons are fine, but rewrites are expensive and disruptive. I would have picked something that can avoid a second rewrite later on.
I understand there may be some bias in this article, but the resource usage improvements are hard to ignore for a company that pays for cloud compute/memory usage. I'm gonna look into server-side Swift. Looks like it'll take some fiddling to find the right non-xcode tools approach for developing on linux. I prefer Jetbrains tools over VSCode, if anyone has any hints in that direction.
I don’t know that there’s anything that magical about Swift in particular, but rather the difference of running without the big runtime of the JVM and the advantages of memory management. Go will probably give improvements (and likely be an easier mental adjustment from a JVM language), and Rust, once you mentally adapt to its model will give even bigger improvements. Swift has the advantage of being object-oriented…
Earlier quoted context omitted.
As a C# dev, I guess I've just taken it for granted that we have value types. Learned something new today (that Java apparently does not).
It does for primitives. For user defined stuff we’ve recently gained records, which are a step in that direction, and a full solution is coming.
> One of the challenges faced by our Java service was its inability to quickly provision and decommission instances due to the overhead of the JVM. ... To efficiently manage this, we aim to scale down when demand is low and scale up as demand peaks in different regions. but this seems to be a totally asynchronous service with extremely liberal latency requirements: > On a regular interval, Password Monitoring checks…
> "why not just run the checks at the backend's discretion?" Because the other side may not be listening when the compute is done, and you don't want to cache the result of the computation because of privacy. The sequence of events is: 1. Phone fires off a request to the backend. 2. Phone waits for response from backend. The gap between 1 and 2 cannot be long because the phone is burning battery the entire time while…
> One of the challenges faced by our Java service was its inability to quickly provision and decommission instances due to the overhead of the JVM. ... To efficiently manage this, we aim to scale down when demand is low and scale up as demand peaks in different regions. but this seems to be a totally asynchronous service with extremely liberal latency requirements: > On a regular interval, Password Monitoring checks…
> "why not just run the checks at the backend's discretion?" Because the other side may not be listening when the compute is done, and you don't want to cache the result of the computation because of privacy. The sequence of events is: 1. Phone fires off a request to the backend. 2. Phone waits for response from backend. The gap between 1 and 2 cannot be long because the phone is burning battery the entire time while…
I've always wondered a slight amount as to why larger enterprises (which have the resources to hire specialists) don't hire people with expertise in say things like Rust, or Elixir/Phoenix? It's one thing to say that we want to hire commonly available developers like in Java or C#, but if you have a long term plan and execution strategy, why not pick technology that may pay off larger dividends? ITT: I get why they c…
Earlier quoted context omitted.
Go is similar to Swift when it comes to mandatory costly abstractions. It’s only Rust (or C++, but unsafe) that have mostly zero-cost abstractions.
Swift, Rust, and C++ all share the same underlying techniques for implementing zero-cost abstrations (primarily, fully-specialized generics). The distinction in Swift's case is that generics can also be executed without specialization (which is what allows generic methods to be called over a stable ABI boundary). Swift and Rust also allow their protocols to be erased and dispatched dynamically (dyn in Rust, any in Sw…
This is not a bad thing, I was just pointing out that Go doesn't have a performance advantage over Swift.
> In comparison with the previous Java service, the updated backend delivers a 40% increase in performance, along with improved scalability, security, and availability. As is always the case with such rewrites, the big question is whether the improvements came from the choice of language or because they updated a crusty legacy codebase and fixed bugs/bottlenecks.
I'd like to give server-side Swift a go but it's hard when the best tooling is tied to one platform.
I'm hoping to hear some good news at WWDC for swift development in editors other than Xcode (VSCode, Neovim, etc.) Last year they said "we need to meet backend developers where they are" and announced plans to improve sourcekit-lsp and other efforts.