That really depends. I have several thoughts on this:
For most little apps, this is definitely true. If you just want a view simple views, a map, a contact-us button, and some other stuff like that, performance is certainly not an issue
For server-side apps, it's pretty huge. More efficient code = lower infrastructure costs. Naturally this has to be weighed against the cost of (pre-mature) optimization, but in any case, "performant by default" is a huge plus.
If you're writing a game engine for example, Java is near hopeless (although don't tell Notch that! ).
The lack of structs requires that you manually implement object-pooling patterns, for small, short lived objects (e.g. projectiles, map grid tiles), in order to reduce the cost of heap allocations and decrease GC load.
GC pauses in the middle of game action are particularly unfortunate.
You can drop down to C or C++ using a JNI, where necessary. It's seems to be a common pattern: when performance is an issue, abandon ship and drop to C. (Swift, ObjC, Java, Ruby, Python, Matlab all do this lol)
Good app performance manifests in a way that I don't see frequently advertised: it reduces battery usage. Even if your code runs buttery smooth, keeps up with the 60/90 fps of the screen, etc., it might be using more energy than strictly necessary. You don't want to over-optimize things, but if you're fast-by-default, you can certainly extend device battery lifetimes.
My anecdotal observation is that Android's UI is way choppier than iOS. Not always, but my Android phone definitely drops frames every so often. It's not usually too noticeable, until you use something that doesn't, and then going back makes the effect very obvious. This is despite my Android phone is way higher speced than the iPhone I was comparing against.
Naturally there are lots of variables at play here, so I can't make any strong causal claims. Some of this is certainly attributable to programming language design, some of it not, but I think they're interesting observations nonetheless.
This was noticeably worse back when Android still used a JIT. The JIT optimized code better than the new ahead-of-time (AOT) compiler, but introduced too much overhead too make it worthwhile.
I suspect part of this might have to with ObjC âď¸ C interop being easier (trivial, in fact) compared to Java âď¸ C interop, which makes for less hesitation to drop to C where the performance can benefit from it.
Android phones tend to have way more RAM than iPhones. Many flagship phones have 6-8GB of RAM, whereas the iPhone XS has "only" 4 GB, the XR has 3 GB.
A huge chunk of that RAM exists solely to sacrifice to the GC gods. It's purpose is to fit more garbage, literally. The more excess heap space is available, the lower the memory pressure will be, and the longer the GC can go without sweeping, and the more efficient the sweep can be.
Lol that's more RAM than my MacBook had before I replaced it a year ago.
Go's a much simpler language, that's to be expected. That's not to say we shouldn't want to aim for better compile times in Swift, but fundamentally there's no way it'll ever be on equal footing. Taking this point to its extreme (reductio ad absurdum) implies Assembly is desirable for its fast compilation speed, which is obviously silly.
Although I agree the dismissive attitude does exist, I don't see an instance of it here.
Nobody's against the prospect of faster compilation times, in fact, everybody would be pleased. I just don't see how that thread is relevant to the discussion of runtime performance.
I may be misunderstanding you, but perhaps you're saying something Along the lines of:
The cool features of Swift come at a compilation time cost. Go makes a different set of trade-offs, and gains lightening fast compilation times in exchange for not having these features. I prefer the Go approach
In which case, that's fine, Go is available for your use. But to make the contextless comparison between Go and Swift compilation times isn't valid, and it never will be. As @dlbuckley mentioned, the two compilers do very different things. For one, the Go compiler doesn't have to concern itself with:
Generics
Definite initialization analysis
Synthesizing implementations for Codable/Equatable/Hashable/Comparable
Custom operator resolution
More complex function resolution (which supports overloading over parameter count, parameter types, return types, and even defaulted parameters)
Synthesizing stubs for ObjC interaction
Swift is just a more complex language. That brings benefits and drawbacks. Go just makes a very different set of trade offs. Compilation time is not something a "perfect" Swift compiler could ever be competitive with against a "perfect" Go compiler.
That is definitely not the development team's attitude. Improving compiler performance and the development experience is something we're continuing to work on.
Hey Joe, are there any tasks the compiler does that are particularly time consuming? I imagine type inference is the biggest player, are there any other particularly expensive language features?
In principle, anything that specifically makes compilation too slow to use is a bug; that's not something you ought to have to think about. In practice, overloading is probably the most problematic thing for the type checker to deal with (but then, it's also difficult for humans to reason about, so is usually best avoided regardless).
Whoa! So many answers, thoughts and opinions. I must say - that was an interesting reading for me.
Apart from that I didn't want to accuse anyone of "Verkramptheit" (the german antonym of "Relaxed"). But exactly these subjective opinions and experiences I wanted to hear. Thank you very much! By this way, a forum is way better readable... and attractive.
There's no question you can learn a lot here, of course. :-)
Thanks also for that!
Best regards!
Verkrampftheit would be German. Verkramptheid would be Afrikaans. Crampedhood would be the nearest pseudoâEnglish (where âhood isnât a head covering, but rather the suffix from childhood, statehood, falsehood and the like).
Those are reasonable translations of the whole, but I was deliberately restricting the âpseudoâEnglishâ to cognates of the pieces, to highlight the relationship to familiar words: Krampf/kramp/cramp and -heit/-heid/-hood.
).
