> 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.
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.
> 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.
Xcodes debugger is great when it works. It’s just a GUI on top of lldb.
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.
It seems to work fine for me.
I also love Things. My only worry is that they'll move to a subscription-only model.
> 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
My guess is 30k is their code, but their dependencies are much larger and 10 mins includes a clean build.
I also wonder if that's developer machine time, or CI build job duration.
Hopefully developer incremental builds are much faster.
Yea, sounds painful. That’s only 50 lines of code per second.
Swift is the slowest on the compilation benchmarks at https://github.com/nordlow/compiler-benchmark.
They should re-write that in Go and get a <10s compile time. And a binary size less than half of that.
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.
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.
I think this is from the talk here:
https://youtu.be/oJArLZIQF8w?si=VZRcsrLkttVjjPzy
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!