Writing Apps in Go and Swift
youngdynasty.net
Writing Apps in Go and Swift
1–10 of 62 posts
Re: Writing Apps in Go and Swift
#2> Give Emporter a try and let me know how it compares to an Electron app.
I don't see how this technique is comparable to Electron. The article does not describe anything related to a cross-platform user interface, which is what Electron addresses. You can write non-UI logic that is cross-platform in half a dozen mainstream languages and another dozen less popular ones. That's not a big deal. It's the UI component that is harder to achieve, and that is what Electron offers.
Re: Writing Apps in Go and Swift
#3I still find it hard to write maintainable multi-threaded code for macOS or iOS [...] without having to worry about the minutiae of parallelism (threads, semaphores, locks, barriers, etc.).
I find this surprising, as GCD does insulate you from that low-level stuff. When you need to work with mutable data, just create a dispatch queue, and only ever access the data by dispatching a function to the queue. Both Swift and Objective-C have friendly syntax for anonymous functions that makes this lightweight and easy.
Re: Writing Apps in Go and Swift
#4I don't find GCD difficult to write for, maybe if you are used to Go it is different enough. Not sure what exactly you would use Go for in an iOS/Macos app unless maybe you have a Go framework you want to include.
Re: Writing Apps in Go and Swift
#5I still find it hard to write maintainable multi-threaded code for macOS or iOS [...] without having to worry about the minutiae of parallelism (threads, semaphores, locks, barriers, etc.). I find this surprising, as GCD does insulate you from that low-level stuff. When you need to work with mutable data, just create a dispatch queue, and only ever access the data by dispatching a function to the queue. Both Swift an…
This reads like someone who purposely missed that part of the documentation just to write this article.
I think I would have less hang ups if the author just came out and said I wanted to try using Go for multi-threaded code with Swift instead of trying to make GCD sound so confusing.
Re: Writing Apps in Go and Swift
#6Swift Strings can transparently map to UnsafePointer when necessary; is there a reason why this doesn’t work in this case?
Re: Writing Apps in Go and Swift
#7I don't find GCD difficult to write for, maybe if you are used to Go it is different enough. Not sure what exactly you would use Go for in an iOS/Macos app unless maybe you have a Go framework you want to include.
Isn’t this what the author is doing?
Re: Writing Apps in Go and Swift
#8I still find it hard to write maintainable multi-threaded code for macOS or iOS [...] without having to worry about the minutiae of parallelism (threads, semaphores, locks, barriers, etc.). I find this surprising, as GCD does insulate you from that low-level stuff. When you need to work with mutable data, just create a dispatch queue, and only ever access the data by dispatching a function to the queue. Both Swift an…
This reads like someone who purposely missed that part of the documentation just to write this article. I think I would have less hang ups if the author just came out and said I wanted to try using Go for multi-threaded code with Swift instead of trying to make GCD sound so confusing.
Even so, I'm glad it's been written. I didn't know you could call Go code from C code (new feature since Go 1.5 apparently) or that Swift could access compiled files with these "module map" things. I'm really glad to see they've both evolved to include useful interoperability and play nicely with other things now, and I'm glad this article shows how in a practical way.
Re: Writing Apps in Go and Swift
#9> Give Emporter a try and let me know how it compares to an Electron app. I don't see how this technique is comparable to Electron. The article does not describe anything related to a cross-platform user interface, which is what Electron addresses. You can write non-UI logic that is cross-platform in half a dozen mainstream languages and another dozen less popular ones. That's not a big deal. It's the UI component th…
Yeah, I don't understand either. Is he referring to a different 'Electron'?
Re: Writing Apps in Go and Swift
#10Earlier quoted context omitted.
This reads like someone who purposely missed that part of the documentation just to write this article. I think I would have less hang ups if the author just came out and said I wanted to try using Go for multi-threaded code with Swift instead of trying to make GCD sound so confusing.
Even so, I'm glad it's been written. I didn't know you could call Go code from C code (new feature since Go 1.5 apparently) or that Swift could access compiled files with these "module map" things. I'm really glad to see they've both evolved to include useful interoperability and play nicely with other things now, and I'm glad this article shows how in a practical way.
> Swift could access compiled files with these "module map" things
That's been the case since it was released – all Swift C / ObjC interop happens at the "module" level. You write a Clang module map (if you're not using a system library which already has one), point the map at the relevant header(s), then you can import that module into your Swift code.
That said, not everything is capable of being imported (variadics, complex macros, VLA structs, and a few others).