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

The Swift Programming Language

developer.apple.com

Post reply on HN
Print view View original

701–710 of 970 posts

Re: The Swift Programming Language

#701

Post by pcwalton »

Pacabel wrote: post #664
stormbrew wrote: post #649

Earlier quoted context omitted.

C++ moving to a 3 year standard cycle is a much bigger 'threat' to rust. But really, the fact that there's so much actual investment in improving mainstream languages from various well-funded sources is probably a rising-tide-lifts-all-boats kind of thing.

Yes, I do agree that the situation is improving across the board. But as an industry, we need practical solutions that are available now, even if somewhat flawed. We need languages we can use today, and know that the code we write today will still compile fine next week and next year, if not a decade or more from now. Modern C++ is getting pretty good at offering this, while offering far a greater degree of safety. G…

> But as an industry, we need practical solutions that are available now, even if somewhat flawed. We need languages we can use today, and know that the code we write today will still compile fine next week and next year, if not a decade or more from now.

By this logic we shouldn't invent any new programming languages at all. There's no such thing as a "practical solution that's available now"; everything takes time to develop.

> Modern C++ is getting pretty good at offering this, while offering far a greater degree of safety. Go isn't bad, either. Scala has its drawbacks, but it's often a reasonable option, too. The key thing to remember is that all of these languages have offered developers a stable target, and they are seriously usable in the present.

You aren't going to use those languages if you want memory safety without garbage collection. Because they can't offer zero-overhead memory safety without breaking existing code.

Re: The Swift Programming Language

#702

Post by dbaupp »

pcwalton wrote: post #700
Pacabel wrote: post #630

Earlier quoted context omitted.

The similarity to Rust should scare the hell out of Rust's creators and proponents. Swift could very well render Rust almost totally irrelevant within the OS X and iOS sphere of software development. If we end up eventually seeing Swift implemented for other platforms, then the chances of Rust's long-term success diminish even more. Things might have been different had a stable, even if somewhat imperfect, initial ve…

Rust's raison d'être is memory safety without garbage collection. Swift requires garbage collection to achieve memory safety. (Reference counting is a form of garbage collection.) In other words, Rust is about safety with zero overhead over C++, and Swift is not zero-overhead. So the people who need Rust are not going to use Swift for Rust's domains. That's fine, as Apple wanted a language for iOS and Mac app develop…

> Why are you so insistent that we freeze an unsafe version of a language that's designed for safety?

Pacabel has made a career of complaining about Rust being unstable.

Re: The Swift Programming Language

#703

Post by pcwalton »

jsmthrowaway wrote: post #673
kibwen wrote: post #643

Earlier quoted context omitted.

Oh hello again, Pacabel. I'm familiar with your game by now. :) We're not scared in the slightest. I'll reconsider when Swift has inline ASM, allocators, linear types, move semantics by default, region analysis, and a type system that guarantees freedom from data races (oh, and when the code is open-sourced, and targets both Linux and Windows as a first-class citizen). Swift isn't intended to be a systems language: i…

It's interesting that inline assembly is your first bullet point, since there's nothing I can think of that ruins a code file more than inline assembly in a host language. Put that crap in a .S file and link it in like everything else, for crying out loud. The one time you need inline assembly is when you don't want to build a function frame, such as a tight loop, but come on. Also, even in systems, I can think of ab…

I wouldn't lead with inline assembler as the selling point of Rust. The main selling point of Rust is memory safety without garbage collection; it still is the only industry language that allows this (as reference counting is a form of GC).

That said, I think inline assembler is an important feature:

> It's interesting that inline assembly is your first bullet point, since there's nothing I can think of that ruins a code file more than inline assembly in a host language. Put that crap in a .S file and link it in like everything else, for crying out loud.

That's too slow. You need to give the optimizer more information than that, and the overhead of the procedure call can be significant.

> The one time you need inline assembly is when you don't want to build a function frame, such as a tight loop, but come on.

But that's a very important use case.

> Also, even in systems, I can think of about once a decade I even need to write assembly, so... maybe grasping at straws a bit?

It's all over the place in the Linux kernel.

Re: The Swift Programming Language

#704

Post by dbaupp »

jernfrost wrote: post #686
angersock wrote: post #393

Earlier quoted context omitted.

I'm not really that impressed--it looks like a hodgepodge of ideas from ES6, Ruby, Go, and maybe Rust, with a bit of backend work done to let it work on their existing infrastructure. I dislike that Apple has continued the special snowflake approach, that for some reason we as developers need to learn yet another different-but-almost-the-same language to develop for them, instead of just adding proper support and doc…

There is already MacRuby and RubyMotion. They tried using Java years ago. It failed. Developers didn't like it. Existing stuff simply doesn't mix that well with Cocoa and that style of programming. That is why something like Swift was needed. I really don't get why you can bring up languages such as Rust and Go, and complain about Apple's special snowflake approach. Suddenly Apple is doing something developers have b…

It's unfair to lump Mozilla in with the rest, since Rust isn't at all propriety. It has been open source for a long long time: https://github.com/mozilla/rust

Re: The Swift Programming Language

#705

Post by curveship »

kevingadd wrote: post #680
curveship wrote: post #629

Earlier quoted context omitted.

> It has the concept of explicitly capturing variables from the surrounding context inside closures, like PHP does, instead of keeping the entire context alive forever like Ruby or JS. Just as a point of fact, javascript -- at least the v8 implementation I'm most knowledgeable of -- doesn't "keep the entire context alive forever." Only variables used in the closure are allocated into the closure (i.e. on the heap), t…

This is not accurate. SpiderMonkey and V8 still retain the entire outer scope if any of the variables are used. See here for an example: https://www.meteor.com/blog/2013/08/13/an-interesting-kind-o... This bug is still not fixed. There's an issue open for it on the V8 tracker, I believe. It seems to have not gotten fixed in either engine because it's a difficult problem that affects a small subset of JS applications.

So go ahead and run his test. Things have changed :). Memory builds up 1mb/second, then after a few seconds, you'll see it drop back to zero, as the GC runs.

V8 has seen a lot of really nice optimizations to closures over the last year. My favorite is that closures are no longer considered megamorphic.

Re: The Swift Programming Language

#706

Post by Pacabel »

pcwalton wrote: post #700
Pacabel wrote: post #630

Earlier quoted context omitted.

The similarity to Rust should scare the hell out of Rust's creators and proponents. Swift could very well render Rust almost totally irrelevant within the OS X and iOS sphere of software development. If we end up eventually seeing Swift implemented for other platforms, then the chances of Rust's long-term success diminish even more. Things might have been different had a stable, even if somewhat imperfect, initial ve…

Rust's raison d'être is memory safety without garbage collection. Swift requires garbage collection to achieve memory safety. (Reference counting is a form of garbage collection.) In other words, Rust is about safety with zero overhead over C++, and Swift is not zero-overhead. So the people who need Rust are not going to use Swift for Rust's domains. That's fine, as Apple wanted a language for iOS and Mac app develop…

I think you may be aiming for a level of safety, or perhaps a notion of "perfection", that isn't practically obtainable.

The recent, and rather disruptive, box changes are a good example of this. We see change, and those of us with existing Rust code sure do feel the change, but very little convergence seems to be happening.

Based on past trends, I would not be at all surprised if problems are found with the new approach as it becomes more widely used, and some other approach is then attempted.

Wheel-spinning is something that can quite easily happen with ambitious software projects. It's not a new phenomenon. But when facing ever-increasing competition, and other real-world constraints, it's often better to aim slightly lower and at least be mostly usable in practice.

A memory-safe programming language that can't actually be used is pretty much irrelevant. It's better to accept some slight amount of imperfection if that means it can actually be used.

Re: The Swift Programming Language

#707

Post by curveship »

pjmlp wrote: post #653
curveship wrote: post #629

Earlier quoted context omitted.

> It has the concept of explicitly capturing variables from the surrounding context inside closures, like PHP does, instead of keeping the entire context alive forever like Ruby or JS. Just as a point of fact, javascript -- at least the v8 implementation I'm most knowledgeable of -- doesn't "keep the entire context alive forever." Only variables used in the closure are allocated into the closure (i.e. on the heap), t…

Swift reuses the Objective-C runtime, so it had to be compatible in terms of memory management.

OK, thanks. I guess that makes sense. Now that the website is working, I see that they're aiming at fairly seamless interop between Swift and Objective-C, so I guess they need a similar memory strategy.

Re: The Swift Programming Language

#708

Post by emp »

pwny wrote: post #691
emp wrote: post #584

Earlier quoted context omitted.

I am pretty sure you can sign up without paying - but your code will be limited to running on the simulator. The $99 is to build for device, and submit to the store.

You can't download Beta versions of dev tools without having a paid subscription, only released versions.

I forgot about that, thank you.

Re: The Swift Programming Language

#709

Post by Pacabel »

dbaupp wrote: post #702
pcwalton wrote: post #700

Earlier quoted context omitted.

Rust's raison d'être is memory safety without garbage collection. Swift requires garbage collection to achieve memory safety. (Reference counting is a form of garbage collection.) In other words, Rust is about safety with zero overhead over C++, and Swift is not zero-overhead. So the people who need Rust are not going to use Swift for Rust's domains. That's fine, as Apple wanted a language for iOS and Mac app develop…

> Why are you so insistent that we freeze an unsafe version of a language that's designed for safety? Pacabel has made a career of complaining about Rust being unstable.

Are you honestly suggesting that Rust is stable at this point?

I think that the recent, and very disruptive, ~ and box changes should completely dispel that notion.

I'm merely pointing out the reality of the current situation, which some in the Rust community do not wish to acknowledge, for whatever reason. The situation has yet to change, so what I'm saying is still valid, and will remain so until some actual improvement does take place.

Now that we see yet another serious competitor in the form of Swift, what I've had to unfortunately be saying for some time now becomes more and more relevant. If Rust is to become relevant, it will need to be usable, and that will need to happen very quickly.

Re: The Swift Programming Language

#710

Post by ethyreal »

angersock wrote: post #576
jacobevelyn wrote: post #450

Earlier quoted context omitted.

Agreed that the lack of using an existing (and open-source!) language is annoying and frustrating to deal with (think of where we'd be if they invested that time and effort into improving Ruby/Python/whatever instead!). But because of the desire for compatibility with Objective-C, and Apple's general desire to call all the shots regarding their ecosystem, this move doesn't surprise me in the least.

Apple consistently represents a step backwards for both developers and users, in terms of engineering and freedom, but they've amassed enough capital at this point that the hope of them simply withering on the vine and dying off is probably not going to happen. At least Microsoft and Google show off their new projects and code so everyone can learn from them and read their research.

any proof to back up those claims?
Post reply on HN