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

761–770 of 970 posts

Re: The Swift Programming Language

#761

Post by [deleted] »

pcwalton wrote: post #703
jsmthrowaway wrote: post #673

Earlier quoted context omitted.

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…

[deleted]

Re: The Swift Programming Language

#762

Post by dbaupp »

Pacabel wrote: post #731
dbaupp wrote: post #718

Earlier quoted context omitted.

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, t…

Resort to name-calling if you really must. None of that will change reality. Rust is not stable, as you yourself have readily admitted. What I've unfortunately had to be pointing out for such a long time now is absolutely correct. We've been told that we can expect Rust 1.0 by the end of the year. As each month passes, it becomes less and less likely that we will actually see this. We are still seeing significant cha…

What have you been pointing out for so long? That Rust is unstable? That many people/companies won't use Rust while it is unstable? That there are other languages people can use instead?

All of those are highly uncontroversial and universally acknowledged by experienced Rust users.

Also, I don't understand how you have lept from Rust being unstable now, to Rust never being stable.

A 1.0 release by the end of the year doesn't seem at all unreasonable to me; I think you are expecting more from it than what the Rust team is looking for (and have stated publicly repeatedly): stabilising the core language.

Of course, a stable release of that form will still mean some libraries may be unstable (and so that Rust would be unsuitable for many corporate developments). These libraries will be stabilised progressively and iteratively.

Re: The Swift Programming Language

#763

Post by mantrax5 »

Pacabel wrote: post #672
mantrax5 wrote: post #607

Earlier quoted context omitted.

So you take a language with null pointers, unsafe pointer access, possibility of array and buffer overflows (C and Objective-C). And then you take another where you have no null pointers, no direct pointer access, and no possibility for array and buffer overflows (Swift). And you say "nah, I look at these two, and I can't objectively tell which is safer"? Are you fuckin' kidding me? Regarding speed, it's been proven…

I think you're putting words into his mouth, and perhaps intentionally misrepresenting what he wrote. Swift was announced just a few hours ago. While we can make assumptions about its safety based on its feature set, or we can assume that the very vague performance details Apple provided are valid in a real-world setting, none of this has really been tested or verified independently yet. What cratermoon wrote is perf…

I'm not misrepresenting what he wrote, I'm directly responding to it.

While you may not be aware with recent language development and modern LLVM-based languages in general, to me and many others what was announced at WWDC today wasn't just a set of buzzwords and marketing speak.

Anyone who has been into language design and watched the keynote today can make a pretty good guess about the properties of Swift. There's a book with hundreds of pages of examples and description of the language semantics on iBooks right now. I've been reading it before I posted. I've been playing with the beta Xcode as well.

Swift is not revolutionary in terms of its feature set. But what makes it quite interesting is the fact this is now an official language for Apple app development, and it's quite a bit ahead of Objective-C in... yes. Safety, performance and conciseness. Fact.

Re: The Swift Programming Language

#764

Post by kibwen »

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'm confused that you seem to think that my bullet points are ordered from most to least important. It seems like quite a strange thing to attack! I'm sorry to disappoint you, but I do not run these comments by a team of editors first. :)

That said, judging by your other comments, you seem to be of the impression that the Rust team has some sort of vendetta against Go, and have concocted a vendetta in kind. Again, I must sadly disappoint you, but I strive to encourage a culture of respect in all the forums that I visit (and moderate).

Re: The Swift Programming Language

#765

Post by mantrax5 »

sswezey wrote: post #631
mantrax5 wrote: post #476

Earlier quoted context omitted.

It'll be available for all devices supported by iOS 8, so going back to iPhone 4S. The runtime of Swift is also the runtime of Objective-C, but the runtime might need some upgrades to fully support the Swift semantics in a safe manner. EDIT: Correction. It's available also on iOS 7. Just confirmed by Apple. Great :)

Do you have a link for the confirmation?

It was clarified during the "State of the Union" talk immediately following the keynote.

The video should be available on Apple's site (or if not, very shortly).

Re: The Swift Programming Language

#766

Post by anigbrowl »

It seems perfectly serviceable, but I have to admit that my reflex response on opening the page was 'Oh god, another language?'

I can't tell if Apple is proposing this as a great new language everyone should use, or whether it's only intended for developers using Apple hardware and so represents a sort of lock-in strategy. I don't have an opinion on the language itself - it seems to have several neat features that make it easier/safer than competing languages like js, but presumably there are a few shortcomings as well.

Re: The Swift Programming Language

#767

Post by ysleepy »

p0nce wrote: post #648

My thoughts while browsing the site: - function-level type inference much like Rust - no constness in the type-system (I like it) - class are reference types, structs are values types, much like D and C# - runtime dispacthed OO interfaces called "protocols". Blend the difference between runtime or compile-time polymorphism. Classes, structs and enums can implement a protocol. Available as first class runtime values,…

Trap on Overflow is not that expensive: http://www.sei.cmu.edu/reports/10tn008.pdf

I am thrilled they did this. Implicit Overflow is the stupidest shit I know that everyone takes for granted.

Also with CPU support it could be free, and adds negligible complexity to the silicon.

Re: The Swift Programming Language

#769

Post by steveklabnik »

timr wrote: post #684
VeejayRampay wrote: post #639

Earlier quoted context omitted.

Ruby is simple and beautiful, isn't it? Too bad it never got the shower of money from big backers Javascript, PHP and now Swift got blessed with.

Beauty is in the eye of the beholder, but Ruby is anything but simple. It has one of the most complicated syntaxes of any programming language in common use. Perl and C++ are still in the lead, but with stuff like the gratuitous introduction of alternate hash syntax, new-style lambdas, etc., Ruby is catching up.

Ruby's grammar is complex, but it's object model is incredibly simple.

Re: The Swift Programming Language

#770

Post by Pacabel »

mantrax5 wrote: post #763
Pacabel wrote: post #672

Earlier quoted context omitted.

I think you're putting words into his mouth, and perhaps intentionally misrepresenting what he wrote. Swift was announced just a few hours ago. While we can make assumptions about its safety based on its feature set, or we can assume that the very vague performance details Apple provided are valid in a real-world setting, none of this has really been tested or verified independently yet. What cratermoon wrote is perf…

I'm not misrepresenting what he wrote, I'm directly responding to it. While you may not be aware with recent language development and modern LLVM-based languages in general, to me and many others what was announced at WWDC today wasn't just a set of buzzwords and marketing speak. Anyone who has been into language design and watched the keynote today can make a pretty good guess about the properties of Swift. There's…

I'd prefer to see how it fares in the real world before jumping to such conclusions like you seem to be so willing to do.

You may not have been around to experience it first-hand, but we heard a lot of claims made back in the 1990s about how Java and the JVM would increase security and safety.

The arguments made then even overlap with some of those being made in this case! The lack of direct pointer access and manipulation, automated memory management and better bounds checking are some examples of the arguments used then and now.

Yet if you work with computers at all, I'm sure you'd know that many of those claims did not materialize. Flaws have been found in the various implementations of Java and its VM, and these have affected its security and safety in very serious and significant ways, many times over.

Perhaps things are different in the case of Swift. But we won't be able to say for sure until later on, once it has undergone some significant real-world use.

Post reply on HN