3 ms·

Swift's server support powers Things Cloud

43 points by fultonb 2y ago

tiltowait 2y ago
Interesting reading. I hope Swift grows in popularity outside of the Apple world. Though I’ve only played with it, I quite liked what I saw of Vapor (ditto Swift as a whole, with which I have more experience). The next time I need to build an API, I’ll probably give it a shot.
chrisandchris 2y ago
> We use Xcode for its robust suite of tools for development, debugging, and testing. And from that line on, we knew that it's just about marketing and reality faded away. However, I really love Things and I always bring it up whenever someone talks about usability and intuitive design. It's such a beautiful pie e of software, written in native code (compared to all the bloated, slow electron apps). It just is very nice to work with Things.
- trillic 2y ago
  Xcodes debugger is great when it works. It’s just a GUI on top of lldb.
- easeout 2y ago
  I would love to see what Instruments, the memory debugger, sanitizers, runtime issues, and Xcode's more elaborate kinds of breakpoints can do for a headless service. I've only ever tried them for GUI apps but of course these tools are also made for the daemons that comprise macOS.
- sillywalk 2y ago
  I also love Things. My only worry is that they'll move to a subscription-only model.
- robertjpayne 2y ago
  To their credit Xcode ships with all these things built in and you don’t have to make decisions about what to use. Yes it’s not as good as some other technologies but for Things use case and sorts it’s a good match.
- jmull 2y ago
  It seems to work fine for me.
koinedad 2y ago
Cool to see this, I tried running a side project using Vapor on my local computer but ran into build issues. Maybe I should try again!
grenran 2y ago
> Our Swift server codebase has around 30,000 lines of code. It produces a binary of 60 MB, and builds in ten minutes. Sounds quite slow
- lenkite 2y ago
  They should re-write that in Go and get a <10s compile time. And a binary size less than half of that.
  - danpalmer 2y ago
    And lose the type system, same language as their client apps, the ability to write nice abstractions, etc. Go is a set of trade offs like every language, and clearly the wrong set for this team.
    - lenkite 2y ago
      The trade off for build time here is horrendous and meme worthy. It just shows Swift is not ready for server side. 10m for 30,000 lines of code just causes health issues like high BP for developers.
      - pjmlp 2y ago
        Modula-2, Delphi and Turbo Pascal were already doing circles around Go compile times with hardware running at a fraction of today's hardware, in much more feature rich programming languages. Swift has definitely a problem, a toolchain problem, not a language one.
      - danpalmer 2y ago
        I have a codebase of a similar size, using the same web framework, and my codebase does a full clean build on my Macbook Air in less than 2 mins. A re-compilation dev build is ~5 seconds. I'd guess the 10 mins is a few things... Vapor, and in particular its ORM Fluent, are noticeably slow to compile. It's common for a single function doing an ORM query to take 200ms to compile. I use warnings for >100ms compilation to spot these and adding a few types or extracting a piece into a utility function solves it. I'd guess they also have a ton of dependencies. I have ~20 or so, most aren't very big. At work I use Go, and while builds are fast, on a medium sized codebase with a bunch of codegen, the difference for dev builds doesn't affect my workflow. There's a debate to be had around whether Swift is ready for the server (I'm a strong advocate for yes, but it's not a done deal), but honestly compilation time isn't a factor. Rust is noticeably slower in my experience and I don't see people questioning whether it's ready for server development because of it.
lawgimenez 2y ago
I think this is from the talk here: https://youtu.be/oJArLZIQF8w?si=VZRcsrLkttVjjPzy https://youtu.be/oJArLZIQF8w?si=VZRcsrLkttVjjPzy

43 points by fultonb 2y ago

Interesting reading. I hope Swift grows in popularity outside of the Apple world. Though I’ve only played with it, I quite liked what I saw of Vapor (ditto Swift as a whole, with which I have more experience). The next time I need to build an API, I’ll probably give it a shot.

chrisandchris 2y ago

> We use Xcode for its robust suite of tools for development, debugging, and testing. And from that line on, we knew that it's just about marketing and reality faded away. However, I really love Things and I always bring it up whenever someone talks about usability and intuitive design. It's such a beautiful pie e of software, written in native code (compared to all the bloated, slow electron apps). It just is very nice to work with Things.

trillic 2y ago
Xcodes debugger is great when it works. It’s just a GUI on top of lldb.
easeout 2y ago
I would love to see what Instruments, the memory debugger, sanitizers, runtime issues, and Xcode's more elaborate kinds of breakpoints can do for a headless service. I've only ever tried them for GUI apps but of course these tools are also made for the daemons that comprise macOS.
sillywalk 2y ago
I also love Things. My only worry is that they'll move to a subscription-only model.
robertjpayne 2y ago
To their credit Xcode ships with all these things built in and you don’t have to make decisions about what to use. Yes it’s not as good as some other technologies but for Things use case and sorts it’s a good match.
jmull 2y ago
It seems to work fine for me.

koinedad 2y ago

Cool to see this, I tried running a side project using Vapor on my local computer but ran into build issues. Maybe I should try again!

grenran 2y ago

> Our Swift server codebase has around 30,000 lines of code. It produces a binary of 60 MB, and builds in ten minutes. Sounds quite slow

lenkite 2y ago
They should re-write that in Go and get a <10s compile time. And a binary size less than half of that.
- danpalmer 2y ago
  And lose the type system, same language as their client apps, the ability to write nice abstractions, etc. Go is a set of trade offs like every language, and clearly the wrong set for this team.
  - lenkite 2y ago
    The trade off for build time here is horrendous and meme worthy. It just shows Swift is not ready for server side. 10m for 30,000 lines of code just causes health issues like high BP for developers.
    - pjmlp 2y ago
      Modula-2, Delphi and Turbo Pascal were already doing circles around Go compile times with hardware running at a fraction of today's hardware, in much more feature rich programming languages. Swift has definitely a problem, a toolchain problem, not a language one.
    - danpalmer 2y ago
      I have a codebase of a similar size, using the same web framework, and my codebase does a full clean build on my Macbook Air in less than 2 mins. A re-compilation dev build is ~5 seconds. I'd guess the 10 mins is a few things... Vapor, and in particular its ORM Fluent, are noticeably slow to compile. It's common for a single function doing an ORM query to take 200ms to compile. I use warnings for >100ms compilation to spot these and adding a few types or extracting a piece into a utility function solves it. I'd guess they also have a ton of dependencies. I have ~20 or so, most aren't very big. At work I use Go, and while builds are fast, on a medium sized codebase with a bunch of codegen, the difference for dev builds doesn't affect my workflow. There's a debate to be had around whether Swift is ready for the server (I'm a strong advocate for yes, but it's not a done deal), but honestly compilation time isn't a factor. Rust is noticeably slower in my experience and I don't see people questioning whether it's ready for server development because of it.

lawgimenez 2y ago

I think this is from the talk here: https://youtu.be/oJArLZIQF8w?si=VZRcsrLkttVjjPzy https://youtu.be/oJArLZIQF8w?si=VZRcsrLkttVjjPzy