4 ms·

As it's written, this is untrue. You don't need a Mac to develop Swift. However, you really ought to have one, because the development experience is subpar on L

As it's written, this is untrue. You don't need a Mac to develop Swift. However, you really ought to have one, because the development experience is subpar on Linux: - there is no free IDE (XCode is only for macOS, and CLion costs money - plus, it has its own bugs) - a lot of tips and tricks on the internet (e.g. about profiling your application, etc.) heavily rely on XCode. Actually, even Apple's own documentation usually references XCode settings (or other apple tools) instead of exposing a good cross-platform interface - the code just behaves differently on Linux than it does on the Mac (especially with Foundation)

scarface74 7y ago
This is server side Swift. It supports the LSP and is supported by Visual Studio Code.
- Tainnor 7y ago
  Apart from the fact that you ignored the other two arguments I made, the LSP is not production ready. It even says so on its very own github page: https://github.com/apple/sourcekit-lsp#status https://github.com/apple/sourcekit-lsp#status
  - scarface74 7y ago
    The XCode profiling is mostly for iOS apps - not server side code. You wouldn’t really be better off using a Mac for profiling server side code. And what server side code “behaves differently” Where does it say it’s not “production ready” on the GitHub link?
    - badrequest 7y ago
      Your response to "there's no good tools for profiling Swift apps on Linux" is "you only want to do that for iOS apps anyway?" I profile server code all the time, it's simply unacceptable to think I'd ever use a language that didn't facilitate it. Go does (https://blog.golang.org/profiling-go-programs https://blog.golang.org/profiling-go-programs). I've not used Rust, so I can't speak to that.
      - scarface74 7y ago
        You mentioned specific profiling in XCode and how that makes it necessary for server development. XCode doesn’t have much of any profiling that would be beneficial to server development - the entire topic of the submission.
    - Eric_WVGG 7y ago
      > And what server side code “behaves differently” [mean] Spend a bit of time on the Vapor Discord channel and read about all the quirks Linux users have to deal with that the rest of us don’t. (My impression is that it’s due to Foundation libs.)
      - scarface74 7y ago
        So instead of a specific example you want us to go to a random discourse channel?
        veidr 7y ago
        But that _is_ true: the Foundation library — which because Swift has a super small core library is really kind of critical to basically any kind of program — behaves differently on Linux. I write Swift code that runs on Linux and also on macOS or iOS, and we frequently have to have sections of "if Linux, run this code, else run this other code". And while that's trivial to write, it's not trivial to find all the places where you have to do that. (Nevertheless, I like Swift a lot and am using it on Linux.)
    - saagarjha 7y ago
      > The XCode profiling is mostly for iOS apps - not server side code. You wouldn’t really be better off using a Mac for profiling server side code. Instruments, which ships with Xcode, is quite powerful.
    - Redoubts 7y ago
      > Behaves differently For me, lots of string and substring operations throw NotImplemented exceptions on Linux, when they just work on Mac. This kinda sucks because there’s no compiletime or linttime warning for this.
- pjmlp 7y ago
  On Ubuntu...

scarface74 7y ago

This is server side Swift. It supports the LSP and is supported by Visual Studio Code.

Tainnor 7y ago
Apart from the fact that you ignored the other two arguments I made, the LSP is not production ready. It even says so on its very own github page: https://github.com/apple/sourcekit-lsp#status https://github.com/apple/sourcekit-lsp#status
- scarface74 7y ago
  The XCode profiling is mostly for iOS apps - not server side code. You wouldn’t really be better off using a Mac for profiling server side code. And what server side code “behaves differently” Where does it say it’s not “production ready” on the GitHub link?
  - badrequest 7y ago
    Your response to "there's no good tools for profiling Swift apps on Linux" is "you only want to do that for iOS apps anyway?" I profile server code all the time, it's simply unacceptable to think I'd ever use a language that didn't facilitate it. Go does (https://blog.golang.org/profiling-go-programs https://blog.golang.org/profiling-go-programs). I've not used Rust, so I can't speak to that.
    - scarface74 7y ago
      You mentioned specific profiling in XCode and how that makes it necessary for server development. XCode doesn’t have much of any profiling that would be beneficial to server development - the entire topic of the submission.
  - Eric_WVGG 7y ago
    > And what server side code “behaves differently” [mean] Spend a bit of time on the Vapor Discord channel and read about all the quirks Linux users have to deal with that the rest of us don’t. (My impression is that it’s due to Foundation libs.)
    - scarface74 7y ago
      So instead of a specific example you want us to go to a random discourse channel?
      - veidr 7y ago
        But that _is_ true: the Foundation library — which because Swift has a super small core library is really kind of critical to basically any kind of program — behaves differently on Linux. I write Swift code that runs on Linux and also on macOS or iOS, and we frequently have to have sections of "if Linux, run this code, else run this other code". And while that's trivial to write, it's not trivial to find all the places where you have to do that. (Nevertheless, I like Swift a lot and am using it on Linux.)
  - saagarjha 7y ago
    > The XCode profiling is mostly for iOS apps - not server side code. You wouldn’t really be better off using a Mac for profiling server side code. Instruments, which ships with Xcode, is quite powerful.
  - Redoubts 7y ago
    > Behaves differently For me, lots of string and substring operations throw NotImplemented exceptions on Linux, when they just work on Mac. This kinda sucks because there’s no compiletime or linttime warning for this.
pjmlp 7y ago
On Ubuntu...