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

Winding down the Swift 3 release

thread.gmane.org

Post reply on HN
Print view View original

41–50 of 65 posts

Re: Winding down the Swift 3 release

#41

Post by Someone »

joewillsher wrote: post #33
kibwen wrote: post #25

Earlier quoted context omitted.

Swift's GC is in the form of pervasive reference counting for reference types with no automatic cycle detection. Though as we're demonstrating, calling this GC is contentious, it would be better if people weren't too lazy to type out "pervasive reference counting for reference types with no automatic cycle detection". :P (For the record, I believe Chris Lattner is on the record as saying "yes, Swift has a runtime, le…

Does saying 'ARC' not work for you? :) And the Swift runtime is pretty minimal, mostly used for storing dynamic type information, dispatching protocol methods, generating (unspecialised) generic types, checking conformances etc. It's mostly used by the compiler to add the dynamic features of the language; for example, the compiler observes the lifetimes of variables and inserts retain/release instructions, which are…

It is simpler than a full GC, but I would not call that "pretty minimal". In particular, weak and unowned references and the guarantee that referencing them after the object they referred to was deallocated crashes your program make swift_release nontrivial.

Re: Winding down the Swift 3 release

#42

Post by WoodenChair »

chc wrote: post #39
DrJokepu wrote: post #31

Earlier quoted context omitted.

Isn't that what libdispatch is though?

Is libdispatch part of the cross-platform Swift effort? AFAIK that's a Mac technology that isn't really used anywhere else.

Yes it is part of a the cross-platform base set of libraries that have been prioritized. You should probably Google before just commenting AFAIKs IMHO.

Re: Winding down the Swift 3 release

#43

Post by pjmlp »

swsieber wrote: post #8
pjmlp wrote: post #6

Earlier quoted context omitted.

Swift, most likely. Go I don't like the design, but I will always suggest it to anyone wanting a simple safe C like language. D, the community is great, but they still need to decide which direction the language is supposed to grow. Rust community and language are great, but I think they need to get into an OS SDK to really accomplish the goal of replacing C++. Swift is replacing C and Objective-C as the official sys…

Could you expand on an OS SDK in relation to Rust?

If you look at the history of computing, since the early 60's, there were tons of system programming languages.

But the ones that kept surviving between OS generations were the ones being sold by the OS / hardware vendors for their systems, not the ones being sold by third party software companies.

You just need to compare the tooling offered for the programming languages that are part of an OS SDK, with the platform support for other programming languages not part of the SDK.

Bringing an external systems programming language means additional development effort, spent in wrapping OS libraries, integration with debugging tools, compiler toolchains.

Hence why many companies are willing only to work with programming languages that have first class support on the platforms they are targeting.

However, there are also some companies for which such issues don't matter. So if there is a big number of such companies, eventually an OS vendor does pay attention and adds such a language into their offerings.

Re: Winding down the Swift 3 release

#44

Post by matt_m »

rubber_duck wrote: post #36
matt_m wrote: post #32

Earlier quoted context omitted.

Might be worth considering C# here too. The open-source cross platform tooling is new and still immature, but it's getting serious resources lately, with new language features (including more null safety) coming, cross platform IDE from Jetbrains in development, Mac / Windows / Linux / Android / iOS support, good concurrency features for server side development, JIT and AOT compilers + runtime, development mostly on…

And F#/other .NET languages. As for displacing Java - this is never going to happen - I prefer .NET but soo many companies have invested man-milenias probably in to Java deveopment - it might losr popularity, especially with Oracle at the helm.

Sure, I agree Java isn't going anywhere, I just meant it might grow some at Java's expense since it has some of the same strengths (and while the ecosystem might not be up there with Java it's surely competitive with some of the other languages used for backend development).

Re: Winding down the Swift 3 release

#45

Post by pjmlp »

nardi wrote: post #10
Scarbutt wrote: post #9

Earlier quoted context omitted.

In the long run, Swift, IMO. It has all the advantages of Go but with a more expressive language, much better C interop and a platform that will create a community around it very quickly, the other day I saw somewhere that there are already more Swift books and courses than Go. Swift will also let you do everything Rust can, very low level stuff.

> Swift will also let you do everything Rust can, very low level stuff. Not quite. Swift requires a runtime, so you probably won't see people writing OS kernels in Swift.

> Swift is a successor to both the C and Objective-C languages.

Source: https://developer.apple.com/swift/

Re: Winding down the Swift 3 release

#46

Post by ghthor »

WoodenChair wrote: post #42
chc wrote: post #39

Earlier quoted context omitted.

Is libdispatch part of the cross-platform Swift effort? AFAIK that's a Mac technology that isn't really used anywhere else.

Yes it is part of a the cross-platform base set of libraries that have been prioritized. You should probably Google before just commenting AFAIKs IMHO.

Don't be a dick. Have a conversation. Be kind.

Re: Winding down the Swift 3 release

#47

Post by nardi »

pjmlp wrote: post #45
nardi wrote: post #10

Earlier quoted context omitted.

> Swift will also let you do everything Rust can, very low level stuff. Not quite. Swift requires a runtime, so you probably won't see people writing OS kernels in Swift.

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

Re: Winding down the Swift 3 release

#49

Post by chc »

WoodenChair wrote: post #42
chc wrote: post #39

Earlier quoted context omitted.

Is libdispatch part of the cross-platform Swift effort? AFAIK that's a Mac technology that isn't really used anywhere else.

Yes it is part of a the cross-platform base set of libraries that have been prioritized. You should probably Google before just commenting AFAIKs IMHO.

I did. The top result for "libdispatch linux" is a third-party library, and the second one is a project from Apple with very little activity (looked like a couple dozen LOC changed since the beginning of April) that sounds very far from "winding down" and looked to be more in the mode of "hey, it's open source, so you could theoretically run it on Linux if you wanted" that libdispatch has been in for over half a decade now — so it seemed like a fair question.

Re: Winding down the Swift 3 release

#50

Post by ori_b »

claudiug wrote: post #27
yarrel wrote: post #20

Earlier quoted context omitted.

D isn't going to happen. Go is a wonderfully boring language. That's its technical strength and social downfall. Rust is the anti-Go. It's an adoption cult with a good language attached. Swift is pleasantly surprising me with its evolution and cross-platform direction. I'd recommend Rust, Swift or Go in that order. Personally I'm most interested in Go but I don't think it's the most useful intellectual exercise or ca…

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 :)

I've been using D in production at work. I can't say that it'll never happen, but it's up against some very strong competition, and given its age, I'm not optimistic about it catching up.

D has been going for a long time, and still needs a decent more work before I'd call it mature. Its garbage collector still has global locks around every allocation and scan. On top of that, I've had memory leaks where it turned out that some anonymous closure just wasn't being released by the garbage collector. The fix for that memory leak was giving the anonymous closure a name to eliminate the environment capture.

For that matter, the tooling around things like taking heap snapshots and profiling is rather painful -- there are no good runtime tracing solutions, and the memory profiler built into the GC breaks down allocations by type, and not by allocation site, which is generally not all that useful. Valgrind dies when I try to debug invalid memory use in C code bound to D. Symbols in the local stack frame are spotty in gdb. And, in general, debugging support could stand to be much better.

The threading library (std.concurrency) can't send objects between threads without lots of lying to the type system to make things happy: You can't send shared references by default (we've hacked around this at work, still need to upstream the patch), and you can't send unshared references unless they're immutable. Sounds ok from a safety perspective until you realize that D is built around mutable objects, and there's no way to declare a value class.

There are lots of things to like about D, but I would be very antsy about using D for a system that I had to rely on in any critical capacity, as things stand. At least, not without a willingness to commit to changing the libraries and runtime.

I haven't used Go, Swift, or Rust in production enough to have an opinion on them and their production readiness.

Post reply on HN