Live data from Hacker News

Swift 5: start your engines

lists.swift.org

41–50 of 186 posts

Re: Swift 5: start your engines

#41
post #15

Can someone with Swift experience comment on the status of Swift on non-Apple platforms? Is it being used outside of the Apple ecosystem? How is the tooling, deployment, availability/support, etc.

Currently trying a web framework, developping on a mac and running it on unbuntu ( vapor framework). I'm extremely positiely surprised by the user experience. Installation is easy, xcode is working fine with autocomplete, libraries seem good enough ( db querying on postgres using a default ORM seems to work).

I've now started to investigate deployment on ubuntu, and the only regret so far is that cloud platform don't support this language very well at the moment ( app engine with dockerfile is a pita, and i gave up to more regular engine instances).

I think starting to develop very basic web apps on this language is beginning to make sense.

Re: Swift 5: start your engines

#42
post #36

Earlier quoted context omitted.

What exactly do you mean "call down into C"? You should be able to call C functions directly from Swift, albeit with UnsafePointer and the like.

I assume, they mean that you don't need to have C at all. See how Go for example doesn't require C on most platforms to make syscalls (IIRC, the exceptions are Windows and Solaris).

So, based on this[1] they've just wrapped the calls with their own…not sure if there are any real benefits here.

[1]: https://golang.org/src/syscall/syscall_linux.go

Re: Swift 5: start your engines

#43
post #22
post #16

Earlier quoted context omitted.

You don't have to "rewrite the app". You run the migrator, then fix up what it didn't migrate. Swift 3 was notorious for having migrator issues, largely due to the fact that it was a pretty radical change and a huge number of method names were changed. Personally, on our hybrid app, the migrator did about 1/3rd of the work, and I did the rest, without any other engineers' involvement. Overall it took maybe 3 days to…

It was a way of talking. I said it that way because the migration to swift and from swift 1 to swift 2 we had the double of developers for iOs than Android and still have to wait for them because of so many issues they were having. Seems like things are not that bad now. But stills scares me that with every new version you lose a developer for some days (or weeks).

The whole 1.x to 2.0 stretch was a rough ride. I had to maintain software without From 2 to 3 was pretty OK since very little changed in the language only API's got updated. From 3 to 4 mainly adds stuff and doesn't break much.

Re: Swift 5: start your engines

#44
And just today I was contemplating writing my first native iOS and macOS app... I was looking at the options and decided to go native with Swift. I have never written Objective-C app and never used x-code for dev. But I have ~10 years of dev experience, mostly Java and Python on the backend and front end dev exp mostly with Angular. Some Android, and a little from because I like to experiment.

So, my question is. How hard and enjoyable is for someone like me to write not very complex native iOS/macOS app in Swift starting from scratch? Best resource to start with?

Re: Swift 5: start your engines

#46
post #28

Earlier quoted context omitted.

Victim of trying it the first week it came out, having to call down into C for anything POSIX, and giving up. If you don't have POSIX bindings, don't call yourself v 1.0.

What exactly do you mean "call down into C"? You should be able to call C functions directly from Swift, albeit with UnsafePointer and the like.

I've been using Swift for a few months and really want to like it. That said, breaking down to unsafepointer for newbie tasks is unacceptable IMHO. Try to do basic stuff like TCP/IP socket coms without a third party library or heck, just get the IPv4 address of your network interface.

Re: Swift 5: start your engines

#47

One of the problems I find with Swift is that Apple doesn't go back and properly update their sample code at developer.apple.com. They have examples that will not build. If you search you can find folks that have patch sets, but they really need to fix the examples.

File a Radar and someone will get around to fixing it: http://bugreport.apple.com/

Yeah, right, that is some serious BS right there. I've filed radars on the Finder (multiple with reproducible crashes), location data, and Quicktime and it holding onto external drives. The only one they have ever fixed is the Quicktime bug but it reappeared later then went away again.

Apple is horrible about bugs and providing feedback. Why the heck would I need to file a radar anyway? Doesn't someone at Apple check the examples to make sure they still work? These are the examples Apple uses to promote and teach the language and how to build apps.

Re: Swift 5: start your engines

#48

One of the problems I find with Swift is that Apple doesn't go back and properly update their sample code at developer.apple.com. They have examples that will not build. If you search you can find folks that have patch sets, but they really need to fix the examples.

This! I tried to learn Swift with the playground that came from "A Swift Tour"... A lot of examples didn't compile and it took WAY too long to figure out that it wasn't a problem on my end.

Definitely not a good way to introduce new programming languages to newbies.

Re: Swift 5: start your engines

#49
About concurrency : does anyone know of a language that would let you tag portions of a codebase in some way, and declare something like "all those methods should execute in the same thread". Those declarations would then be checked by the compiler.

That would be a first step toward agent like concurrency, but it would be general enough to apply to other types of concurrency models.

Re: Swift 5: start your engines

#50
post #22

Earlier quoted context omitted.

It was a way of talking. I said it that way because the migration to swift and from swift 1 to swift 2 we had the double of developers for iOs than Android and still have to wait for them because of so many issues they were having. Seems like things are not that bad now. But stills scares me that with every new version you lose a developer for some days (or weeks).

It really doesn't take all that long. I've migrated apps consisting of 20K-30K lines of code in a couple hours–mind you, many of the changes were not due to Swift 4, but those in the Cocoa/Cocoa Touch Swift overlays.

I said to swift, I meant from objective-c to swift. And also from swift 1 to swift 2, where problems weren't only the language but the apis an integration with the old objective-c library. I doubt it takes a couple of hours do that stuff (hour project was close to 100k lines, to one day for you), but If it really takes you that short time companies are going to fight hard to hire you!
Post reply on HN