5 ms·

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 compo

by frizlab 7mo ago

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 https://clearsurgery.vision

zarzavat 7mo ago
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.
- frizlab 7mo ago
  That was true for Swift 2, maybe a little for Swift 3, but it has not been true since a long time now…
  - hu3 7mo ago
    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?
    - myHNAccount123 7mo ago
      https://github.com/finagolfin/swift-android-sdk https://github.com/finagolfin/swift-android-sdk At least 6 years old.
    - hirvi74 7mo ago
      > Plus Swift is arguably too unnecessarily complex now. I would argue the allegations of complexity against Swift are greatly exaggerated. I find the language to be very elegant and expressive in syntax, high in readability, and fairly terse. Other than that, Swift feels near identical to every other OoP language I have used.
  - ethin 7mo ago
    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.
- myHNAccount123 7mo ago
  > Apple barely maintains compatibility for their own platforms... You're commenting on a post about an update... that they apparently don't do? What?
  - groundzeros2015 7mo ago
    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.
    - myHNAccount123 7mo ago
      2/10
0x3f 7mo ago
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.
- frizlab 7mo ago
  > 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.)
  - hu3 7mo ago
    > 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.
    - ModernMech 7mo ago
      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.
      - frizlab 7mo ago
        Did that happen recently (the compiler just bailing out)? 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.
florentmorin 7mo ago
It just works. One language. Many platforms. Incredible performance. With a simple tooling. No ugly script. Everything is naturally integrated.
- skydhash 7mo ago
  Isn’t that Go?
  - yunwal 7mo ago
    Go and “simple tooling” don’t really belong in the same sentence. Powerful tooling, sure, but simple?
    - g947o 7mo ago
      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.
      - shepherdjerred 7mo ago
        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
      - yunwal 6mo ago
        Things that are not simple about go tooling - Comments as directives[0]. Nobody finds this intuitive. I've never met anyone that saw what directives were doing and thought to change a comment. - Comments as commands for the compiler[1] - The state of go linting[2]. There are 30 different formatting tools that all frequently conflict with each other. It got so complicated that one project exists to manage installations of all the other ones (golangci-lint). Only difficulty is that most IDEs use gofmt and if your golangci-lint uses a different gofmt version than your IDE, you end up getting different formatting when you save vs. when you commit. This is only a problem because golangci-lint can't be installed using the go toolchain[3], so you can't just have dependency resolution solve this for you. I can go on [0] - https://groups.google.com/g/golang-dev/c/r4rdPdsH1Fg/m/yjOOzqIqNPMJ https://groups.google.com/g/golang-dev/c/r4rdPdsH1Fg/m/yjOOz... [1] - https://essentials-of-go-programming.readthedocs.io/tooling.html#conditional-compilation https://essentials-of-go-programming.readthedocs.io/tooling.... [2] - https://go.dev/wiki/CodeTools https://go.dev/wiki/CodeTools [3] - https://github.com/golangci/golangci-lint/issues/1657 https://github.com/golangci/golangci-lint/issues/1657
michaelcampbell 7mo ago
That it's designed for a thing and becoming the go-to choice for that thing can be far apart indeed.
jkman 7mo ago
Out of curiosity, could you point to a tech blog or something else going over clearsurgery's stack? That's really interesting

by frizlab 7mo ago

zarzavat 7mo ago

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.

frizlab 7mo ago
That was true for Swift 2, maybe a little for Swift 3, but it has not been true since a long time now…
- hu3 7mo ago
  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?
  - myHNAccount123 7mo ago
    https://github.com/finagolfin/swift-android-sdk https://github.com/finagolfin/swift-android-sdk At least 6 years old.
  - hirvi74 7mo ago
    > Plus Swift is arguably too unnecessarily complex now. I would argue the allegations of complexity against Swift are greatly exaggerated. I find the language to be very elegant and expressive in syntax, high in readability, and fairly terse. Other than that, Swift feels near identical to every other OoP language I have used.
- ethin 7mo ago
  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.
myHNAccount123 7mo ago
> Apple barely maintains compatibility for their own platforms... You're commenting on a post about an update... that they apparently don't do? What?
- groundzeros2015 7mo ago
  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.
  - myHNAccount123 7mo ago
    2/10

0x3f 7mo ago

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.

frizlab 7mo ago
> 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.)
- hu3 7mo ago
  > 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.
  - ModernMech 7mo ago
    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.
    - frizlab 7mo ago
      Did that happen recently (the compiler just bailing out)? 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.

florentmorin 7mo ago

It just works. One language. Many platforms. Incredible performance. With a simple tooling. No ugly script. Everything is naturally integrated.

skydhash 7mo ago
Isn’t that Go?
- yunwal 7mo ago
  Go and “simple tooling” don’t really belong in the same sentence. Powerful tooling, sure, but simple?
  - g947o 7mo ago
    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.
    - shepherdjerred 7mo ago
      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
    - yunwal 6mo ago
      Things that are not simple about go tooling - Comments as directives[0]. Nobody finds this intuitive. I've never met anyone that saw what directives were doing and thought to change a comment. - Comments as commands for the compiler[1] - The state of go linting[2]. There are 30 different formatting tools that all frequently conflict with each other. It got so complicated that one project exists to manage installations of all the other ones (golangci-lint). Only difficulty is that most IDEs use gofmt and if your golangci-lint uses a different gofmt version than your IDE, you end up getting different formatting when you save vs. when you commit. This is only a problem because golangci-lint can't be installed using the go toolchain[3], so you can't just have dependency resolution solve this for you. I can go on [0] - https://groups.google.com/g/golang-dev/c/r4rdPdsH1Fg/m/yjOOzqIqNPMJ https://groups.google.com/g/golang-dev/c/r4rdPdsH1Fg/m/yjOOz... [1] - https://essentials-of-go-programming.readthedocs.io/tooling.html#conditional-compilation https://essentials-of-go-programming.readthedocs.io/tooling.... [2] - https://go.dev/wiki/CodeTools https://go.dev/wiki/CodeTools [3] - https://github.com/golangci/golangci-lint/issues/1657 https://github.com/golangci/golangci-lint/issues/1657

michaelcampbell 7mo ago

That it's designed for a thing and becoming the go-to choice for that thing can be far apart indeed.

jkman 7mo ago

Out of curiosity, could you point to a tech blog or something else going over clearsurgery's stack? That's really interesting