Swift lives only for macOS,iOS and besides those ecosystems does not have a solid and robust ecosystem to be used for anything else. It's a shame but it for sure needs BigTech for it to be used anywhere else.
I still have hope Swift will break free like C# has. I hope one day something like Vapor or Kitura takes off.
Swift 6.3
211–220 of 239 posts
Re: Swift 6.3
#212Earlier quoted context omitted.
I was enthusiastic about early TensorFlow in Swift efforts, sorry when the effort ended. My interest then flowed into early Mojo development for a while. I wrote an eBook on Swift several ago but rarely update that book anymore. Count me as one of the many developers who for a while thought Swift would take over the world. At least Swift is a fun language to use, and now with LLM coding tools writing macOS/iOS/iPadOS…
funnily enough, I talked recently to someone working on the swift compiler (not an Apple employee) to make Swift functions differentiable. So its not all dead yet
Re: Swift 6.3
#213Re: Swift 6.3
#214good to see incredible stuff being shipped in Swift. Haven't used it since v3 though. around 2015-17 - Swift could have easily dethroned Python. it was simple enough - very fast - could plug into the C/C++ ecosystem. Hence all the numeric stuff people were doing in Python powered by C++ libraries could've been done with Swift. the server ecosystem was starting to come to life, even supported by IBM. I think the letdo…
The thing what people don't get with C++'s complexity is that complexity is unavoidable. It is also there in Ada, C#, Java, Python, Common Lisp,.... Even if the languages started tiny, complexity eventually grows on them. C23 + compiler extensions is quite far from where K&R C was. Scheme R7 is quite far from where Scheme started. Go's warts are directly related to ignoring history of growing pains from other ecosyst…
They aren’t able to bring concepts like “a file” into the standard because one standards body member maintains a compiler in some baroque ancient environment without the concept of a fs. Too much is forced to implement at the library level instead of in the compiler, and end up feeling half baked for real users (modules, coroutines etc).
Re: Swift 6.3
#215Re: Swift 6.3
#216Earlier quoted context omitted.
Lattner probably left because Apple didn't give the team any breathing room to properly implement the language. It was "we must have this feature yesterday". A lot of Swift is the equivalent of Javascrip's "we have 10 days to implement and ship it": https://youtu.be/ovYbgbrQ-v8?si=tAko6n88PmpWrzvO&t=1400 --- start quote --- Swift has turned into a gigantic super complicated bag of special cases, special syntax, speci…
> Swift has turned into a gigantic super complicated bag of special cases, special syntax, special stuff... That's true, but only partly true. It already was a gigantic super complicated bag of special cases right from the start. Rob Rix noted the following 10 years ago: Swift is a crescendo of special cases stopping just short of the general; the result is complexity in the semantics, complexity in the behaviour (i.…
Re: Swift 6.3
#217did they ever add #define? bridging constants from the build system to swift with static NSString * const kConstValue = @XSTR(CONST_VALUE); is soooo annoying.
But you can bridge build setting variables using some clever xcconfig macros that combine both preprocessor systems.
Re: Swift 6.3
#218good to see incredible stuff being shipped in Swift. Haven't used it since v3 though. around 2015-17 - Swift could have easily dethroned Python. it was simple enough - very fast - could plug into the C/C++ ecosystem. Hence all the numeric stuff people were doing in Python powered by C++ libraries could've been done with Swift. the server ecosystem was starting to come to life, even supported by IBM. I think the letdo…
Python powered by C++ libraries comes from HPC folks, places like CERN and Fermilab, they would hardly touched Swift instead.
Re: Swift 6.3
#219Earlier quoted context omitted.
> I don’t believe that’s true. Things are moving constantly, and in the right direction. Hah! I'll use that argument if I ever get PIP'd. No but seriously, constantly moving doesn't mean fast enough. Swift took took long to have cross-platform support. And it is still uberslow to compile. To the point of language servers giving up on analyzing it and timeout.
Not just uber slow to compile, because as a Rust dev I could take that. But it rejects correct programs without telling you why! The compiler will just time out and ask you to refactor so it has a better shot. I understand that kind of pathological behavior is present in many compilers but I hit it way too often in Swift on seemingly benign code.
Because they got much better at that, and it’s been a long while since that happened to me. Like “I don’t even remember when was the last time it happened” long.
Re: Swift 6.3
#220Earlier quoted context omitted.
they seem to be adding more and more keywords if they really want me to use this lang for everything, they'd have to 1. massively improve compilation speed, 2. get the ecosystem going (what's the correct way to spin up an http server like with express?) and 3. get rid of roughly 150 of the 200 keywords there are especially w.r.t. the last one, of course everyone frets at huge breaking changes like this, so it won't h…
> 3. get rid of roughly 150 of the 200 keywords there are I don't understand this point. Could you explain? The new keywords enable new language features (ex: async/await, any, actor), and these features are opt-in. If you don't want to use them, you don't have to. What are they keywords you think should be removed?
reading someone else's code is part of working with the language (as is understanding LLM output nowadays). i can't just make others not use the keywords i don't know/beed/like. especially if working within teams, or using OSS.