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

831–840 of 970 posts

Re: The Swift Programming Language

#831

Post by jsmthrowaway »

nnethercote wrote: post #810
jsmthrowaway wrote: post #755

Earlier quoted context omitted.

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

> not a thread about Go passes without at least three pcwalton comments these days Well, every thread about Go inevitably has numerous comments comparing it to Rust, often erroneously, and pcwalton is one of the primary Rust developers.

A fair point.

Re: The Swift Programming Language

#832

Post by pling »

dbaupp wrote: post #806
pling wrote: post #622

Earlier quoted context omitted.

Yes it was entirely covered by that :) I think it was covered by "naive memory management" and "shitty outsourcing". I'm paid to fix their stuff.

If the problem was just the time taken to do a 1MB copy inside a loop, why did you say the problem was clearing the CPU caches?

Because the CPU has 32k of cache in this case (ARM) so the memcpy was evicting the entire cache several times in the loop as a side effect of doing the work. The actual function of the loop had good cache locality as the data was 6 stack vars totalling about 8k.

Re: The Swift Programming Language

#834

Post by dbaupp »

pling wrote: post #832
dbaupp wrote: post #806

Earlier quoted context omitted.

If the problem was just the time taken to do a 1MB copy inside a loop, why did you say the problem was clearing the CPU caches?

Because the CPU has 32k of cache in this case (ARM) so the memcpy was evicting the entire cache several times in the loop as a side effect of doing the work. The actual function of the loop had good cache locality as the data was 6 stack vars totalling about 8k.

So? Copying a megabyte is a really expensive thing to do inside a loop, even ignoring caches. (A full speed memcpy would take 40 microseconds, based on a memory bandwidth of 24 GB/s, which is a long time.)

Re: The Swift Programming Language

#835

Post by eden-san »

I am surprised noone mentioned Erlang!

Tuples and pattern matching are the bread and butter in Erlang and deserve to be mentioned as one of the source of inspiration for the Swift language.

The '_' character used to ignore some values in loops/patterns was also taken from Erlang (for _ in array { ... }).

Re: The Swift Programming Language

#836

Post by msie »

andybak wrote: post #186

I'm reading the manual and liking nearly everything. But then I stumble across: > Alternatively, remove a key-value pair from a dictionary with the removeValueForKey method. Is that the day where an Objective-C got to choose method names? Why not dict.delete() or similar?

That sounds bad. Heh, you can define your own extension and rename that method.

Re: The Swift Programming Language

#837

Post by [deleted] »

steveklabnik wrote: post #769
timr wrote: post #684

Earlier quoted context omitted.

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.

[deleted]

Re: The Swift Programming Language

#838

Post by tluyben2 »

reuven wrote: post #739

I find it a bit sad that with all of the languages that already exist, Apple found it necessary to invent a completely new one -- and then make it proprietary. Why not use Ruby, or Python, or JavaScript -- or even Go, Rust, Clojure, or Scala? (Yes, I realize that the latter two run on the JVM, which would have been problematic in other ways.) Heck, they could have bought RubyMotion and made Ruby the high-level langua…

I would've voted for buying/licensing Xamarin instead; C#/F# would've given them everything including a lot of fresh programmers. On the other hand i'm happy they didn't as they would've tossed out Android and (at least for me) there is no alternative yet to the speed / power of development here.

Re: The Swift Programming Language

#839

Post by gcv »

roberthahn wrote: post #727

My first instinct was to be cautious about new languages from Apple - Dylan was supposed to be something awesome until Apple cancelled it. But I only learned of the existence of Dylan years after it was cancelled. Looked awesome, but it was so niche I didn't want to spend time learning it. So I took a moment to look at why Dylan was cancelled.[1] Veryin interesting stuff. What it came down to was: - Apple was in dire…

Based on my skimming of the Swift documentation, Dylan is a much nicer language (both in its original form and in its modern OpenDylan incarnation). That said, Swift just needs to improve on Objective C, which does not set the bar high.

Re: The Swift Programming Language

#840

Post by pjmlp »

jiyinyiyong wrote: post #773
tptacek wrote: post #480

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

Including me, I think some syntaxes of Switft look like Go, while they actully don't share the same vision. Go tries to be a language great for system programming so it introduces channels, interfaces. But Swift want to help GUI programming and it needs the whole class system but without crazy stuffs like channels. But for others aspects that are not related these two(class system, concurrency), I would say they look…

For Go to be great for systems programming, the unsafe package needs a few more primitives and better control over the GC.
Post reply on HN