Live data from Hacker News

Winding down the Swift 3 release

thread.gmane.org

51–60 of 65 posts

Re: Winding down the Swift 3 release

#51
post #30
post #5

Earlier quoted context omitted.

Swift for GUIs on OSX / iOS. Go for everything else. Haven't had much reason to play with Rust or D, but also haven't seen nearly as much of them in the wild...

Go for everything else? Swift is moving for everything too, with the cross platform support, IBM adoption, etc...

Cross platform isn't there yet though. I'll definitely give it more thought, especially if it does cross-platform GUIs (something Go does not have good libraries for).

That said, Go's tooling, documentation, and ecosystem are much friendlier than Swift's. And since most of us spend more time doing that stuff than actually typing code, it's an important point for me in the comparison.

Re: Winding down the Swift 3 release

#52
post #47
post #45

Earlier quoted context omitted.

> Swift is a successor to both the C and Objective-C languages. Source: https://developer.apple.com/swift/

Objective-C requires a runtime, and the Darwin kernel is not implemented in Objective-C. Also, Swift, unlike Objective-C, is not a superset of C.

[deleted]

Re: Winding down the Swift 3 release

#53
post #47
post #45

Earlier quoted context omitted.

> Swift is a successor to both the C and Objective-C languages. Source: https://developer.apple.com/swift/

Objective-C requires a runtime, and the Darwin kernel is not implemented in Objective-C. Also, Swift, unlike Objective-C, is not a superset of C.

Interesting that you decided to ignore the fact that Apple also mentions C, which is what the Darwin kernel is implemented on, isn't so?

Which also happens to have a runtime, crt0.o.

Re: Winding down the Swift 3 release

#54
post #53
post #47

Earlier quoted context omitted.

Objective-C requires a runtime, and the Darwin kernel is not implemented in Objective-C. Also, Swift, unlike Objective-C, is not a superset of C.

Interesting that you decided to ignore the fact that Apple also mentions C, which is what the Darwin kernel is implemented on, isn't so? Which also happens to have a runtime, crt0.o.

C has a runtime, used in a "hosted" implementation (your typical *NIX user-space program) - but it's optional, and there is the alternative "freestanding" implementation that doesn't need to have a runtime or standard library, and this is generally used to implement kernels.

http://www.iso-9899.info/n1570.html#4.p6

Re: Winding down the Swift 3 release

#55
post #29

Earlier quoted context omitted.

can you give more details why dlang is not a good bet. I actually like the language and feature set :) I have the feeling that is to much noise on dlang, and they do not have a clear path, but still :)

Mostly because it's been going on for a decade, and while itself is not catching (much adoptions), other languages that have appeared since have already gotten much more traction, including Go and Swift -- and potentially Rust.

That could be a function of the marketing rather than the language.

Re: Winding down the Swift 3 release

#56
post #3

Now, with swift 3 around the corner, I will ask some most experience fellow developers the following question. There is golang, swift, rust, dlang. If you will put some energy, what language will be, and why? :)

I like Go. The language is sane and small, the standard library is great, and the tooling is nice, the community is getting quite large. It's a bit too high level for me to call it a C successor, but I get similar joy from coding in it as I do with C. It's just so clean and neat, and I still get native code, and with no dependencies either. Pretty great. Go is so good thanks to the sum of all its properties. I think it will be around for a long time.

I'm not too much into Rust, but sure, if you absolutely cannot have even a low latency garbage collector involved or do very low level work like drivers, I guess it is useful. As soon as I don't, I feel like the pragmatic nature of Go is very appealing. I wonder about Rust's future, where it will be in 5-10 years.

I'd prefer Swift more if stuff started happening here as for cross-platform support. I hear the Linux support isn't even quite there yet, and as for Windows, it just recently saw _any_ kind of progress. I feel like it will take a long time until Swift feels like a natural general purpose choice across the largest three operating systems, rather than an iOS / OS X development platform ported to said platforms. But sure, Swift as a language feels modern and just great. Sometimes like a merge of Rust and Go, with the similar focus on safe code of Rust from guards, optionals, seeing the good in immutability, pattern matching. I wish Swift was much more popular and with much better cross-platform support.

I have played just very little with D and it has a bit much feature creep and bad traction for my taste (community _does_ matter). It had a chance of becoming more popular before, but I can't really see it anymore with these new languages. They already seem to have overtaken it in popularity, leaving D as a used but very niche language.

Re: Winding down the Swift 3 release

#57
post #53

Earlier quoted context omitted.

Interesting that you decided to ignore the fact that Apple also mentions C, which is what the Darwin kernel is implemented on, isn't so? Which also happens to have a runtime, crt0.o.

C has a runtime, used in a "hosted" implementation (your typical *NIX user-space program) - but it's optional, and there is the alternative "freestanding" implementation that doesn't need to have a runtime or standard library, and this is generally used to implement kernels. http://www.iso-9899.info/n1570.html#4.p6

Doesn't invalidate the fact that Swift could eventually be used in similar scenarios.

Usually in these scenarios I believe it just requires a company to bully developers to accept it and an eventual generation change.

If tomorrow Apple decides, for whatever reason, that new kext or IOKit modules are to be written in Swift, then whoever cares about their Apple OS customers will just comply with it.

Re: Winding down the Swift 3 release

#58
post #57

Earlier quoted context omitted.

C has a runtime, used in a "hosted" implementation (your typical *NIX user-space program) - but it's optional, and there is the alternative "freestanding" implementation that doesn't need to have a runtime or standard library, and this is generally used to implement kernels. http://www.iso-9899.info/n1570.html#4.p6

Doesn't invalidate the fact that Swift could eventually be used in similar scenarios. Usually in these scenarios I believe it just requires a company to bully developers to accept it and an eventual generation change. If tomorrow Apple decides, for whatever reason, that new kext or IOKit modules are to be written in Swift, then whoever cares about their Apple OS customers will just comply with it.

What I think you're missing is that using a runtime is impossible in an OS kernel, unless the runtime doesn't use any OS features. You at least need to bootstrap enough of an OS before you can use the runtime. It's not the same thing as kexts or IOKit modules.

Re: Winding down the Swift 3 release

#59
post #57

Earlier quoted context omitted.

C has a runtime, used in a "hosted" implementation (your typical *NIX user-space program) - but it's optional, and there is the alternative "freestanding" implementation that doesn't need to have a runtime or standard library, and this is generally used to implement kernels. http://www.iso-9899.info/n1570.html#4.p6

Doesn't invalidate the fact that Swift could eventually be used in similar scenarios. Usually in these scenarios I believe it just requires a company to bully developers to accept it and an eventual generation change. If tomorrow Apple decides, for whatever reason, that new kext or IOKit modules are to be written in Swift, then whoever cares about their Apple OS customers will just comply with it.

Could be, I wouldn't rule it out, but if so I've got serious doubts that it would be the full Swift language - the Objective-C style "dynamic" dispatch seems rather inappropriate for kernel space.

Re: Winding down the Swift 3 release

#60
post #58
post #57

Earlier quoted context omitted.

Doesn't invalidate the fact that Swift could eventually be used in similar scenarios. Usually in these scenarios I believe it just requires a company to bully developers to accept it and an eventual generation change. If tomorrow Apple decides, for whatever reason, that new kext or IOKit modules are to be written in Swift, then whoever cares about their Apple OS customers will just comply with it.

What I think you're missing is that using a runtime is impossible in an OS kernel, unless the runtime doesn't use any OS features. You at least need to bootstrap enough of an OS before you can use the runtime. It's not the same thing as kexts or IOKit modules.

It is so impossible that history of computing is full of such examples, but the C community likes to re-write history so thay younger generations don't feel the need to dive into ACM papers about how the world was outside AT&T walls.
Post reply on HN