4 ms·

I don't doubt that, but someone is definitely trying. For example they moved Swift out of the Apple GitHub org and the announcement blog post[0] calls out Swif

I don't doubt that, but someone is definitely trying. For example they moved Swift out of the Apple GitHub org and the announcement blog post[0] calls out Swift's use outside Apple's ecosystems. Their blog archives has more posts that I read as a focus on improving Swift outside the Apple ecosystem, some examples: * Updating the Visual Studio Code extension for Swift[1] * Introducing Oblivious HTTP support in Swift[2] * How Swift's server support powers Things Cloud[3] I can see arguments for how wider adoption of Swift outside of Apple, and especially in the server ecosystem, helps Apple. In particular, lots of apps are being written using React Native and Flutter and at least one hurdle there is that Swift lacks developer mindshare. 0: https://www.swift.org/blog/swiftlang-github/ https://www.swift.org/blog/swiftlang-github/ 1: https://www.swift.org/blog/the-next-chapter-in-swift-build-technologies/ https://www.swift.org/blog/the-next-chapter-in-swift-build-t... 2: https://www.swift.org/blog/introducing-swift-nio-oblivious-http/ https://www.swift.org/blog/introducing-swift-nio-oblivious-h... 3: https://www.swift.org/blog/how-swifts-server-support-powers-things-cloud/ https://www.swift.org/blog/how-swifts-server-support-powers-...

yyyk 2y ago
>3:... Our Swift server codebase has around 30,000 lines of code. It produces a binary of 60 MB, and builds in ten minutes. Ten minutes isn't very good for 30K lines.
- e28eta 2y ago
  My guess is that 30k LOC is the 1st party code, and there’s probably a bunch of 3rd party dependencies that are also compiled as part of that. But maybe I’m wrong
cosmic_cheese 2y ago
It’s nice that a Swift LSP exists, is supported by the company behind the language, and is actively being worked on, because that makes it much more feasible to do things like build alternative IDEs. Contrast this to Kotlin, which doesn’t have an LSP due to conflicts of interest with Jetbrains’ business. You either use a Jetbrains IDE or you don’t write Kotlin.
- theli0nheart 2y ago
  What about this? https://github.com/fwcd/kotlin-language-server https://github.com/fwcd/kotlin-language-server
  - cosmic_cheese 2y ago
    It’s wholly a community effort and not supported by Jetbrains, which means it will always be at a disadvantage. Even development on it continues, it’ll always be a few steps behind the current version of Kotlin and will probably be missing a number of things compared to the autocomplete in Jetbrains IDEs. It’s also built on the internal APIs of the Kotlin compiler, which are subject to change at any time. If Jetbrains shifts those around too dramatically it could break the LSP beyond the point that anybody is willing to repair it. For corporate-developed languages first party LSPs are important.
- pjmlp 2y ago
  This and the whole anti-Java attitude on Android circles is what made me disregard Kotlin, how can one be so out of touch with what makes their ecosystem possible in first place.
  - cosmic_cheese 2y ago
    Well, for Android specifically I’m not sure anti-Java sentiment is necessarily entirely unjustified with how Android tends to be stuck on some ancient version, and it’s not as if the JVM ecosystem doesn’t have its warts (though those are largely shared by Kotlin).
    - pjmlp 2y ago
      Which is made on purpose to sell Kotlin on the platform, those having had this decision are part of the same anti-Java group I was mentioning, as per remarks on podcasts and other appearances.

yyyk 2y ago

>3:... Our Swift server codebase has around 30,000 lines of code. It produces a binary of 60 MB, and builds in ten minutes. Ten minutes isn't very good for 30K lines.

e28eta 2y ago
My guess is that 30k LOC is the 1st party code, and there’s probably a bunch of 3rd party dependencies that are also compiled as part of that. But maybe I’m wrong

cosmic_cheese 2y ago

It’s nice that a Swift LSP exists, is supported by the company behind the language, and is actively being worked on, because that makes it much more feasible to do things like build alternative IDEs. Contrast this to Kotlin, which doesn’t have an LSP due to conflicts of interest with Jetbrains’ business. You either use a Jetbrains IDE or you don’t write Kotlin.

theli0nheart 2y ago
What about this? https://github.com/fwcd/kotlin-language-server https://github.com/fwcd/kotlin-language-server
- cosmic_cheese 2y ago
  It’s wholly a community effort and not supported by Jetbrains, which means it will always be at a disadvantage. Even development on it continues, it’ll always be a few steps behind the current version of Kotlin and will probably be missing a number of things compared to the autocomplete in Jetbrains IDEs. It’s also built on the internal APIs of the Kotlin compiler, which are subject to change at any time. If Jetbrains shifts those around too dramatically it could break the LSP beyond the point that anybody is willing to repair it. For corporate-developed languages first party LSPs are important.
pjmlp 2y ago
This and the whole anti-Java attitude on Android circles is what made me disregard Kotlin, how can one be so out of touch with what makes their ecosystem possible in first place.
- cosmic_cheese 2y ago
  Well, for Android specifically I’m not sure anti-Java sentiment is necessarily entirely unjustified with how Android tends to be stuck on some ancient version, and it’s not as if the JVM ecosystem doesn’t have its warts (though those are largely shared by Kotlin).
  - pjmlp 2y ago
    Which is made on purpose to sell Kotlin on the platform, those having had this decision are part of the same anti-Java group I was mentioning, as per remarks on podcasts and other appearances.