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

711–720 of 970 posts

Re: The Swift Programming Language

#711

Post by pcwalton »

Pacabel wrote: post #706
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…

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 appr…

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

I believe it is, as the basic structure and rules of the borrow check (which is the part of Rust that's truly unique) have proven themselves to be quite usable. The usability problems remaining are implementation and precision (e.g. issue #6393), not big problems that will require large redesigns.

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

Yes, it is. The number of outstanding backwards incompatible language changes is decreasing. People who do Rust upgrades notice how the language is changing less and less.

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

"Some slight amount of imperfection" means not memory-safe. Java didn't settle for that, C# didn't settle for that, Swift isn't settling for that, and we aren't settling for it.

Re: The Swift Programming Language

#712

Post by timgws »

tsuraan wrote: post #290
andrewtbham wrote: post #261

Earlier quoted context omitted.

Yeh, I agree. I was surprised when they open sourced webkit. But like you said, it's strategic. I don't think they care that much about the browser. Their emphasis is on apps running in their ecosystem.

They didn't have a choice about webkit; it was a fork of KHTML, which was a part of KDE (and available under the terms of the GPL).

Actually, WebKit was a fork of KHTML, correct, but it is licensed under the terms of LGPL. One extra letter, but a world of difference. This is why they had to open source KHTML, but they could get away with not open sourcing Safari (if KHTML was licensed under the GPL, any app that linked against the library would need to be licensed under the GPL, too.)

Let's not forget that webkit when it was released was little more then a code dump - one big patch that had to be applied to KHTML.

Re: The Swift Programming Language

#714

Post by BrandonM »

Pacabel wrote: post #690
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…

My apologies, I didn't realize that expecting a programming language to have a stable syntax, stable semantics, a stable standard library and at least one stable and robust implementation before using it seriously in industry was merely a "game". Perhaps this is news to you, but those of us who work on and are responsible for large-scale software systems tend to take such factors very seriously. This may sound harsh,…

You seem to desire both stability and a faster 1.0 release. The realistic choices are:

    1. Release fast and iterate
    2. Release fast and be stuck with mistakes
    3. Release slow
Option #1 breaks stability, so that's out.

Swift appears to be taking option #2 (Apple doesn't commonly break APIs, do they?), but we can't even really be sure because it hasn't been developed in the open the way that Rust has. It's possible that it's been in development as long as Rust, and we simply haven't heard about it yet. Either way, option #2 is a perfectly reasonable one to go with; it has served Java quite well (for a loose definition of fast), though it has required some creative approaches to language improvements.

Rust is taking option #3. C has been around for over 40 years now. If Rust hopes to supplant it, it seems reasonable to take a few extra months (or even an extra year) to put out a solid version 1 that won't hamstring the language or force a breaking change down the line.

Re: The Swift Programming Language

#715

Post by Alphasite_ »

myko wrote: post #610
Alphasite_ wrote: post #583

Earlier quoted context omitted.

Could you post the message (or thread) somewhere? I think that post is paywalled.

Sure, sorry - I'm not sure which SA threads are free and which require payment. This is the relevant bit: "Is this under NDA? No. Is this open source? Not yet. It probably will be, but I can't make promises. Right now, our repository still has a lot of history that we don't want to make public, and we have a lot of work to do before we release."

Thanks.

Re: The Swift Programming Language

#716

Post by pcwalton »

Pacabel wrote: post #709
dbaupp wrote: post #702

Earlier quoted context omitted.

> 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 improv…

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

No, he didn't say that anywhere.

Re: The Swift Programming Language

#718

Post by dbaupp »

Pacabel wrote: post #709
dbaupp wrote: post #702

Earlier quoted context omitted.

> 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 improv…

No, I'm not suggesting that Rust is stable. It wasn't even slightly implied by what I said. I was just pointing out that you're a broken record on this topic, to the point of being a troll (you seem to just ignore the meat of any response you get and only focus on the current state of Rust).

To be crystal clear: no-one is suggesting that Rust is stable and no-one is suggesting it is ready for adoption (if they are, they are wrong). However, being unstable now is very very different to not ever being stable.

In any case, Swift is only tangentially a Rust competitor as kibwen demonstrated.

Re: The Swift Programming Language

#720

Post by anonymoushn »

curveship wrote: post #696
Udo wrote: post #687

Earlier quoted context omitted.

> Right, but it knew you were going to use eval, and to support that, it had to allocate all local variables in the closure. Wow, so there is actually special handling in the engine for this? So it does static analysis whenever it can, but not in these two cases?

Yes, the V8 compiler bails out of several optimizations if your function uses eval. You can see this in the profiler: functions which V8 wasn't able to optimize will have an alert sign next to them, and if you click it, it'll tell you what the issue was.

This is a bit troublesome!

  function f() {var x = 99; return function(a,b) {return a(b)};}
  f()(eval, 'console.log(x);')
  ReferenceError: x is not defined
  function f() {var x = 99; return function(a,b) {return eval(b)};}
  f()(eval, 'console.log(x);')
  99
  undefined
Post reply on HN