Live data from Hacker News

The Swift Programming Language

developer.apple.com

751–760 of 970 posts

Re: The Swift Programming Language

#751

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…

This is an honest question: Why do you seem to care so much? Rust is in my view a great project, that yes isn't quite there yet but is making great progress. I'm looking forward to using it when it is stable, and pcwalton and the other contributors are developers that I've looked up to for a number of years: I have nothing but faith in them.

At the end of the day, if Rust fails, well that will be a shame. But I'm seeing nothing that shows that it might, so I'm truly struggling to understand why you seem so upset by a new modern language trying to tackle big problems in ways that have never been done before. That's a good thing, as far as I'm concerned.

Re: The Swift Programming Language

#752
post #483

Earlier quoted context omitted.

No, no, I don't object to your comment. You're just not the only person I've seen making the comparison to Golang, and so I had a big comment bottled up. :)

Ah OK, I understand :)

My hat is off to you gentlemen. Such civility. Good day to you Sirs. Good day.

Re: The Swift Programming Language

#754

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…

> But that's a very important use case.

For Rust. I didn't make the comparison to Rust, I merely was intrigued by the choice of features and in which order to defend the comparison made by someone else. I see Rust and Swift as targeting entirely different things, at least at first (which means that Swift can certainly evolve inline assembly if it is so needed), and any comparison at this stage is pointless.

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

Cool, that's one piece of software. I'll save you the next few: drivers and a couple files in a game engine. You're disputing my point how, exactly?

Re: The Swift Programming Language

#755
post #740
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…

> Swift isn't intended to be a systems language: it's an application language. It may not be ready as a systems language in its pre-1.0 form, but the Swift book claims that it's "designed to scale gracefully from ‘Hello World’ to an entire operating system", so Apple appears to have big goals.

I'm thinking about starting the "Rust contributor points out how Rust is a systems language and $language is an applications language" drinking game. At least now they'll focus on Swift instead of Go. I don't mean this to be rude; I've just noticed a similar set of usernames in threads about certain !Rust languages playing the underdog position and always feeling like they need to compare.

Given Rust's PR, speaking of that -- not a thread about Go passes without at least three pcwalton comments these days -- I actually broke down and gave it a try. I wrote a little Hello World server and then got lambasted by a friend of mine for not working functionally, since, in his words, "Rust is a functional language and the fact that it supports other paradigms is a mistake." I rm -rf'd and ignore it for now, but I look forward to it stabilizing and maybe coming back to it.

Rust has potential but the PR needs to ease up just a little. There is room for more than one language in the world.

Re: The Swift Programming Language

#756
post #37

I'm not even an iOS developer but this is by far the most exciting thing I heard in the keynote. As an amatuer/hobbyist programmer who's self-taught with Ruby, JavaScript, etc., the one thing that was keeping me from experimenting with iOS apps was Objective-C. I know I could tackle it, but it's been hard to take the plunge. I don't know much about Swift yet, but from what I've seen it looks very exciting. So if Appl…

I spent a lot of time trying to do stuff with ObjectiveC, but just hated the syntax. That's been the biggest thing keeping me from developing Mac OSX apps; I just prefer Ruby's simplicity. I'm going to seriously give Swift a try.

Tried http://macruby.org/ ?

Re: The Swift Programming Language

#757
post #751

Earlier quoted context omitted.

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…

This is an honest question: Why do you seem to care so much? Rust is in my view a great project, that yes isn't quite there yet but is making great progress. I'm looking forward to using it when it is stable, and pcwalton and the other contributors are developers that I've looked up to for a number of years: I have nothing but faith in them. At the end of the day, if Rust fails, well that will be a shame. But I'm see…

Having been in industry for a long time, I think that something like Rust would be hugely beneficial. It very well could solve some very real problems.

I bring this up again and again because I'd rather not see Rust fail. I'd much rather see a slightly flawed Rust that's actually usable in the short term, rather than a continually changing Rust that nobody will seriously adopt.

Rust has been in development for years now. That's a very long time in the software industry. A few years of development time without a stable release is understandable. But it's getting beyond that now.

Rust isn't quite there yet, but each day it edges closer to a Perl 6 type of disaster. Perl 6 offered some intriguing ideas, but it just isn't usable, and that's a shame. Meanwhile, other competitors have arisen and blown past it, rendering it far less useful were it ever properly implemented.

Given the increasingly stiff competition that Rust is facing, I suspect we'll see it end up like Haskell or D. Something usable is eventually produced, but it never sees the truly widespread adoption that it could have seen, had it been usable earlier on. It's not as bad as Perl 6's situation, but it is still unfortunate.

Re: The Swift Programming Language

#759

You appear to be advocating a new: [ ] functional [X] imperative [X] object-oriented [X] procedural [X] stack-based [ ] "multi-paradigm" [ ] lazy [ ] eager [X] statically-typed [ ] dynamically-typed [ ] pure [X] impure [ ] non-hygienic [ ] visual [ ] beginner-friendly [ ] non-programmer-friendly [ ] completely incomprehensible programming language. Your language will not work. Here is why it will not work. You appear…

While half of the things you checked in that copy-paste are wrong, let me take the bait and say why it will work: - it's not just an arbitrary language, it's the new officially sanctioned programming interface for Apple's gigantic, wildly profitable ecosystem - it's much more concise than Objective-C - it's faster than Objective-C - it's safer than Objective-C - it has more features than Objective-C - ...yet it's ful…

How is Swift safer than Obj-C?

I'm not sarcastic or anything by the way, I just don't understand yet the foundation behind that statement.

Re: The Swift Programming Language

#760

Earlier quoted context omitted.

Yeah.. Because Scala doesn't have a metric ton of problems. AVOID!

Scala doesn't have a metric ton of problems. It has some problems, sure, but it has a lot of nice features as well.

Plus 'metric' must only accompany 'shitload' or other potty-mouthed quantifiers. Troll fail
Post reply on HN