upvote
How so? I can indeed target every layer of the software stack using Swift, today.

E.g. ClearSurgery[0] is written fully in Swift, including the real-time components running on the Linux boxes.

[0] https://clearsurgery.vision

reply
I _can_ do the same with Rust, doesn't mean it's "the language I reach for" for making e.g. a website. Because the tooling, ergonomics, hireability factor, etc. are still very harshly against it.

Same with Swift, but I'd call that more of a wasted opportunity because Apple, unlike Rust Foundation, has a mountain of money to make it happen, and yet they don't seem to care.

reply
> They don't seem to care.

I don’t believe that’s true. Things are moving constantly, and in the right direction. Then again it would help if you cited particular grievances, because being a regular (cross-platform/cross-target) Swift user I am not sure what you are talking about…

I did not choose ClearSurgery’s example randomly. I was at a conference recently where the CTO was here, and he explicitly told us they were moving fast thanks to the Swift ecosystem. (I am not working there personally, nor am I affiliated.)

reply
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 happen, so people won't use it

reply
> 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?

reply
> these features are opt-in. If you don't want to use them, you don't have to.

Using a language is more than just writing it with a pre-established knowledge of what subset of features you think is worth the tradeoffs. More keywords/features means when you try to figure out how to do something new, there may be 15 different ways and you need to analyze and figure out which is the best one for this scenario, which ones are nonstarters, etc.

That's was more or less the whole design goal of Go. It was made by C++ programmers who were fed up with how many features were in the language, so they kept the feature set limited. Even the formatting is decided by the language. You may not agree with every decision, but what matters is decisions were made and they're standardized, so everyone is on the same page. You can read anyone else's code, and you know exactly what's going on.

reply
> 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.

reply
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.
reply
I don't know why anyone would want to use Apple tools if they are not developing for Apple platforms. Apple barely maintains compatibility for their own platforms, using Swift on a non-Apple platform is setting yourself up for doubule pain.
reply
> Apple barely maintains compatibility for their own platforms...

You're commenting on a post about an update... that they apparently don't do? What?

reply
Why are you interpreting this comment as "never receives updates"? It takes great effort to maintain API compatibility, some things aren't improved or are implicitly deprecated.
reply
That was true for Swift 2, maybe a little for Swift 3, but it has not been true since a long time now…
reply
In a way it still is true. Swift works on Windows and Linux until it doesn't. It's taken until a couple years ago for other build systems to get swift support (which I suppose is the fault of said build system, but Swift taking so long to be cross-platform contributed to that), and even now it (still) doesn't quite work right. C interop is a mess requiring hacks to generate clang modules to actually get Swift to see them (and CMake for example provides no easy way of doing this, or last time I checked it didn't). Oh and Swift tends to take over the linker and compilation pipelines when you enable it, at least with CMake, because... Reasons? I honestly don't know why. It causes very weird errors when I integrated Swift code into my C++ project that were a pain to actually diagnose. I eventually got it working, but still, it wasn't simple or seamless.
reply
If cross platform support took so long, it's a major red flag.

Plus Swift is arguably too unnecessarily complex now.

And there's Rust/Zig so why use Swift for low level?

reply
Out of curiosity, could you point to a tech blog or something else going over clearsurgery's stack? That's really interesting
reply
That it's designed for a thing and becoming the go-to choice for that thing can be far apart indeed.
reply
It just works. One language. Many platforms. Incredible performance.

With a simple tooling. No ugly script. Everything is naturally integrated.

reply
> No ugly script

What’s that supposed to mean?

reply
The typical Apple sales pitch. Forgive me for assuming it’s only surface level.
reply
Isn’t that Go?
reply
Go and “simple tooling” don’t really belong in the same sentence. Powerful tooling, sure, but simple?
reply
Would be helpful if you elaborate which part is not simple.

Coming from C++ and JavaScript, there aren't many languages that can claim to have "simpler" tooling than Go.

reply
The tools aren’t bad any more, but you do need a few liners to write safe code. But that’s the case for most languages
reply