Swift 5: start your engines • Hacker News Board

Re: Swift 5: start your engines

#101

Post by bsaul » Wed, Aug 09, 2017, 9:28 PM UTC

Jack4E4B wrote: post #99

bsaul wrote: post #70

Earlier quoted context omitted.

I've recently started to investigate web frameworks for swift, and specially the concurrency part. So just to clarify something : current swift web frameworks ( and ios apps for that matter) rely on grand central dispatch, which is a decent library for spawning work on work queues, managed by the OS, and dispatched on OS threads. This type of model is fine and has worked quite well in the past. It is not event loop l…

How much work is expected from the developer point of view? I'd love to have an alternative to Go, but no concurrency for me kills Swift right of the gate for server stuff.

At the moment, it's mostly the framework's job. You write your handler and call the libs for interacting with i/o.

Posting a job ( aka function call) on a queue for async programming is also very very easy.

There's nothing like coroutines or channels though. So you're back to mutex and OS thread constraints in terms of the number of spawnable threads.

Re: Swift 5: start your engines

#102

Post by smegel » Wed, Aug 09, 2017, 9:30 PM UTC

ssijak wrote: post #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…

> How hard and enjoyable is for someone like me to write not very complex native iOS/macOS app in Swift starting from scratch?

Your biggest problem won't be the language, but the 30,000 other apps uploaded to the App Store every single day.

Re: Swift 5: start your engines

#103

Post by slavapestov » Wed, Aug 09, 2017, 9:32 PM UTC

Jack4E4B wrote: post #94

Concurrency finally, it has taken forever. Is there any built-in support now? Server side Swift is lacking this big time.

It doesn't cover everything, but libdispatch is available on both Darwin and Linux, with a "Swift-ified" API.

Re: Swift 5: start your engines

#104

Post by bsaul » Wed, Aug 09, 2017, 9:35 PM UTC

k-mcgrady wrote: post #83

bsaul wrote: post #75

Earlier quoted context omitted.

For ios : look at the number of various apis you can use to do widget positionning and animations : calayer, uiview spring n struts, constraints, physic based, and yet none compose well with each other. IOS also doesn't have any good tech for offline storage ( core data should be burried once and for all) and swift relies on compile-time codegen hack to provide easy struct serialization, because techs like nscoding r…

>> For ios : look at the number of various apis you can use to do widget positionning and animations : calayer, uiview spring n struts, constraints, physic based, and yet none compose well with each other. IOS also doesn't have any good tech for offline storage ( core data should be burried once and for all) I disagree with most of this. Laying out views was a mess for a while but auto layout is easy to get right onc…

Ever tried to have 60fps on a tableview with constraint-based layout cells ? CALayer is definitely not legacy, it's often the only way to get smooth animation. Spring n struts is also sometimes the best way to get fast position for smooth scrolling.

Ever had to deal with Core Data migration on an app that needs to evolve throughout the year ? Migration is a mess, and so is concurrency. My personal conclusion after having used Core Data on a pro application for 4 years, is that most of the time i really don't need a database and so i'm back to file-based backups for my app's data. Works well, no magic, and no performance or threading issue.

Re: Swift 5: start your engines

#105

Post by futurix » Wed, Aug 09, 2017, 9:37 PM UTC

developer2 wrote: post #81

ssijak wrote: post #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…

Regarding iOS and macOS kits, all of the documentation is in Objective-C. The libraries' Obj-C is imported and usable with Swift-only code, but the Swift documentation lazily links you to examples in the Obj-C docs. You have to perform trial-and-error by manually converting the Obj-C examples into the equivalent Swift (which often entails renamed classes, methods, types, etc.). If your projects typically do a lot of…

Did you forget to switch documentation from Objective-C to Swift?

Re: Swift 5: start your engines

#106

Post by xenadu02 » Wed, Aug 09, 2017, 9:38 PM UTC

colordrops wrote: post #30

xenadu02 wrote: post #20

Earlier quoted context omitted.

Swift is open-source. You are welcome to contribute support for other platforms!

This cliche statement feels trite for such a large project. I'd understand it for a 1000 line JS library, but it makes no sense for a complex language ecosystem that requires multiple full time engineers to maintain.

It isn't my intention to sound "trite". I've personally contributed a little bit to Swift. You don't have to be a compiler genius to help out - you can contribute to Swift Foundation which is almost entirely Swift code and would directly improve cross-platform support.

I would also note that saying "I wish more effort were being made" is a bit entitled when you're talking about an open source project. No one working on any open source project owes you anything. If you want the project to get better then find a way to contribute.

Re: Swift 5: start your engines

#107

Post by alexashka » Wed, Aug 09, 2017, 9:39 PM UTC

ssijak wrote: post #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…

I'm surprised no one has mentioned this but I'd say the #1 resource for learning the practical 'how do I get X thing done in a couple of hours' are tutorials on https://www.raywenderlich.com/ without a doubt.

It has tutorials for every basic question imaginable in a very easy to follow manner.

It'll definitely take some time, as for being enjoyable - I don't get a kick out of learning an entire new set of libraries and idioms for achieving the same thing I can do in another toolset, but if you do, then great :)

One last thing - the amount of information for macOS is about 1% compared to iOS, so I'd definitely go the iOS route.

Re: Swift 5: start your engines

#108

Post by bsaul » Wed, Aug 09, 2017, 9:41 PM UTC

BinaryIdiot wrote: post #69

bsaul wrote: post #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.

That's an interesting concept. Would you also suggest having a way of saying "this method should execute in another thread" or "all of those methods should execute in another thread"?

I'm still in the process of figuring how that would work. But mostly it would look something like annotation @threading("BACKGROUND_WORK_QUEUE_A") func someWork(data) {}

@threading("BACKGROUND_WORK_QUEUE_A") func someSubWork(data) {}

@threading("MAIN_QUEUE") func requestHandler() {}

and you wouldn't be able to directly call someWork() from requestHandler() directly, but calling someSubWork() from someWork() would be fine.

The idea is that i've observed that my code could often be split into parts running in their own threads, and the complex thread splitting code would be at the junction.

Adding annotation like that would help me make sure that a function designed to run inside some part wouldn't accidentaly be called directly from another part.

Re: Swift 5: start your engines

#109

Post by LeoNatan25 » Wed, Aug 09, 2017, 9:41 PM UTC

ssijak wrote: post #58

caiob wrote: post #52

Earlier quoted context omitted.

This is the question I've been asking my iOS dev buddies, with a catch: I want up-to-date resources. None of them were able to share a link so far.

Yeah, up-to-date was assumed in my post. I don`t want a post about Objective-C from 2012. I don`t know if it is against the guidelines to post this kind of links but I found this https://designcode.io/ (I have 0 affiliations with the product) that looks just like what I need. From 0 to app in the newest stack, would probably buy and try it if somebody does not have something better in mind?

> Yeah, up-to-date was assumed in my post. I don`t want a post about Objective-C from 2012.

What a ridiculous statement. Most of those resources are excellent and relevant today. An article/blog post on calendrical or localization or accessibility is still as relegate today, as “back in the day” in 2012. This is not some web “dev” nonsense where the “stack” changes every year and a half. iOS and macOS consist of some tried and tested APIs that are decades old.

Re: Swift 5: start your engines

#110

Post by xenadu02 » Wed, Aug 09, 2017, 9:43 PM UTC

__sr__ wrote: post #33

xenadu02 wrote: post #20

Earlier quoted context omitted.

Swift is open-source. You are welcome to contribute support for other platforms!

I am talking about "official" support here. Enterprises are not going to risk using an unofficial port. And unless there is a large scale adoption, it will become another niche language which only the enthusiasts would care about. More importantly, it needs to happen while Swift still has momentum. Once a language gets old enough, it builds a certain kind of reputation. Once that happens, it is almost impossible to i…

> I am talking about "official" support here

You can take a look at what IBM has been doing in this space, but in general I'm not sure what you are asking for. Do you expect Apple to release a fully-baked Windows port?

It's a free project that is open-source. Cross-platform support will come from contributions by individual developers, testers, and documentation writers, or companies who find some strategic value in supporting it.

Sitting back and saying "I wish" seems a bit entitled, no? I'm not being glib, I really am saying if you want to see better Swift support on platform X then start contributing. Swift Foundation needs help filling out implementations on Linux and Windows. For the more adventurous you can contribute directly to the standard library or compiler.