691–700 of 970 posts
I really wish we could play with it, without having to be a paid member. It's crazy how Apple is always so scared to release dev tools, at the end it will be out-there on bittorrent anyway...
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.
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…
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…
FWIW, Swift is categorized as a systems language in the opening pages. But, then, so does Go in its FAQ. To Swift's credit, at least it has deterministic memory management through ARC.
As someone who always disliked Objective C, I think Swift looks very promising. I'll check it out right away :) Software-wise, I feel these current WWDC announcements are the most exciting in years. Looking at the Swift docs right now, I can see many interesting inspirations at work: there's some Lua/Go in there (multiple return values), some Ruby (closure passed as the last argument to a function can appear immediat…
Is it realistic to try to dive right in to the 500-page book they provided without a computer science background, just HTML/CSS/PHP self-taught experience, to learn the language? Or should I take other steps first?
Earlier quoted context omitted.
> In this example, the compiler could not possibly have known I was going to access x. Right, but it knew you were going to use eval, and to support that, it had to allocate all local variables in the closure. That's why you saw this behavior. The same would happen if you used a 'with' construct.
> 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?
Earlier quoted context omitted.
Perhaps if you take language features directly, it's not a good comparison with Go. There are some things that did strike me as similar. The approach Go takes is to bring C language to a more modern world (i.e. C without some of the language burdens that we know so well). Swift is attempting to do the same. The way it does type inference is nice. var x = "Hi" reminds me of Go's const types. The ARC usage reminds me o…
> The approach Go takes is to bring C language to a more modern world Like all the other thousands of languages with C based syntax. > var x = "Hi" reminds me of Go's const types Why does it remind you of Go and not of all the other languages that use 'var x = "Hi"' like JavaScript, ActionScript, C#, Scala, Kotlin? > The ARC usage reminds me of Go's garbage collection Why does it remind you of Go and not of all the o…
You sound old. ;)
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.
As someone who always disliked Objective C, I think Swift looks very promising. I'll check it out right away :) Software-wise, I feel these current WWDC announcements are the most exciting in years. Looking at the Swift docs right now, I can see many interesting inspirations at work: there's some Lua/Go in there (multiple return values), some Ruby (closure passed as the last argument to a function can appear immediat…
Is it realistic to try to dive right in to the 500-page book they provided without a computer science background, just HTML/CSS/PHP self-taught experience, to learn the language? Or should I take other steps first?
Earlier quoted context omitted.
Indeed, I'm not sure what Swift's concurrency story is yet. Other than that it's encouragingly similar to Rust (we're evolving in the right direction!), but not quite as low-level.
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…
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 development with tight integration with Objective-C, and from what I've seen they've done a great job of developing one.
> Things might have been different had a stable, even if somewhat imperfect, initial version of Rust had been released by now, thus allowing it to gain some adoption and traction.
Why are you so insistent that we freeze an unsafe version of a language that's designed for safety?