Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift 5: start your engines

lists.swift.org

Post reply on HN
Print view View original

161–170 of 186 posts

Re: Swift 5: start your engines

#161

Post by Matthias247 »

bsaul wrote: post #70
bjt wrote: post #40

Earlier quoted context omitted.

The linked post talks about concurrency not being a focus until Swift 6 at the earliest. Personally, I don't want to make a commitment to server-side Swift until after that dust has settled.

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…

> 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.

Imho that's just the description of event loop(s). There's a central queue, to which you post work (e.g. in the form of function objects or closures), which will get dequeued and executed in a serialized fashion. The thread look like while ((func = dequeue()) != null) { func(); }. That's the event loop.

The difference to node is that you have multiple of these event loops, which are referred to by queue name. In javascript there's only one single implicit loop. If we look at javascript which webworkers we also get multiple loops and queues (one in each worker). However those are more strongly isolated (no shared memory) than eventloops in multithreaded environments.

Re: Swift 5: start your engines

#162

Post by k-mcgrady »

acmecorps wrote: post #152
k-mcgrady wrote: post #83

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) I disagree with most of this. Laying out views was a mess for a while but auto layout is easy to get right onc…

How in the world did you managed to use storyboard? I hate using it for moderate-complex UI apps. This guy say it better than me on why I hate storyboard (especially the first reason): https://www.youtube.com/watch?v=g6yz5oX5iWc FWIW, if you like and good at it, more power to you.

I use it in combination with programmatic UI for more complex things but find it's so much easier and faster when doing auto layout to just use storyboards.

Re: Swift 5: start your engines

#164

Post by real-hacker »

The only complaint about swift programming is: they keep changing the programming interfaces, so if I import a third-party code file written with earlier versions of Swift, I have to go through the errors of 'obsolete APIs', updating the function signatures. The changes are automated by Xcode, but it is still a hassle.

I am totally OK with introducing new features of Swift language. But changing the API function signatures (even multiple times) seems totally unnecessary, and reflects the API designers' obsession of naming conventions.

Re: Swift 5: start your engines

#165

Post by coldtea »

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

Also Apple uses a lot of patterns that lead to goto hell because of NeXT's foundations in the delegate pattern: https://en.wikipedia.org/wiki/Delegation_pattern So you start some sequence (like a new UIViewController) and interact with it via callback events instead of having a single (blocking) thread of execution that waits for the view controller call to return like a function. This makes it virtually impossible t…

>So you start some sequence (like a new UIViewController) and interact with it via callback events instead of having a single (blocking) thread of execution that waits for the view controller call to return like a function. This makes it virtually impossible to deterministically model flow control.

Why on earth would you have a single blocking thread on a UI app?

Re: Swift 5: start your engines

#166

Post by martijn_himself »

Tangential question- I'm in the UK and I am keen to become a iOS developer (I'm currently a senior .NET developer in a large firm). Are there enough opportunities remaining in iOS development as a contractor / creator of ('enterprise') apps to make a living? I would be very grateful if anyone could share any advice / personal experience.

Re: Swift 5: start your engines

#167

Post by __sr__ »

xenadu02 wrote: post #110
__sr__ wrote: post #33

Earlier quoted context omitted.

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…

Since when did wishing for something mean someone is entitled to something?

“I wish it would stop raining.”

“I wish they'd launch it soon.”

Do any of these statements mean the speaker is entitled to something? Since when did wishing for something become a bad thing?

I am not expecting Apple to release anything. I am hoping for swift.org to one day proclaim that the toolchain and the libraries are available on Windows and other platforms. What I am expecting Apple to do is get behind its own language. I mentioned in another post in this thread -- it is not just about technical work. A lot of it has to do with marketing/evangalism. While individual contributors can help, it takes the backing of large company to get something adopted at a large scale. Why do you think Go succeeded while languages like Nim, D etc are not being adopted as well? What I expect from Apple is to spare a couple of people for the purpose of giving talks, writing blogs etc in addition to working on Swift -- something like what Rob Pike et al have been doing for Go. From what I understand, Apple writes a lot of their backend stuff in Java. Perhaps they could start investing in Swift on server side and open source some of the frameworks/libraries they come up with?

> I really am saying if you want to see better Swift support on platform X then start contributing.

I want to get Swift adopted at my workplace for the next project we are working on. I should tell the management I'll start working on it as soon as I get Swift ported to the platform I use. It would go down really well.

What makes you assume I am not contributing in whatever way I can?

> 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.

IBM has done some good work, alright. But they are the only ones. A lot more work is required If Sipwift were to become a mainstream language.

Re: Swift 5: start your engines

#168

Post by int_19h »

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

Ugh, makes me think of COM https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...

This is different. COM apartments were a runtime mechanism to magically make the code to run on a single thread (or on multiple but specific threads for MTA), by introducing object proxies that "transparently" marshaled calls.

Re: Swift 5: start your engines

#169

Post by westoque »

protomyth wrote: post #37

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.

I propose a solution.

Developer documentations should start following API like structures. For example, in API land we have:

    /api/v1/users
    /api/v2/users
This means that making requests to v1 will only work with v1 and v2 only with v2. This makes sure that the API you are connecting to is using the correct parameters for its version.

Going back to documentations, they should state in the examples or in the documentation that this document is written for V2 of swift or anything more specifc. Even better would be sticking to Semver like specifications for the versioning.

Re: Swift 5: start your engines

#170

Post by cf »

westoque wrote: post #169
protomyth wrote: post #37

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.

I propose a solution. Developer documentations should start following API like structures. For example, in API land we have: /api/v1/users /api/v2/users This means that making requests to v1 will only work with v1 and v2 only with v2. This makes sure that the API you are connecting to is using the correct parameters for its version. Going back to documentations, they should state in the examples or in the documentati…

This is what sklearn does for their documentation and it's fantastic!
Post reply on HN