austinz

Yeah, except for the facts that the leaky bolts that were the primary source of consternation last year (?) weren't part of the Chinese-built part of the bridge.

For someone who laments the failure of modern programmers to learn from the work of the past, the author seems to completely ignore the contributions of ML, ML-style type systems, and related languages to the profession of software engineering. Perhaps this explains the snide (and, frankly, uninformed) dismissal of Swift as a hype-ridden "subset of Lisp".

Aside from that, I agree with the author's points.

I think an interesting life is important. I also think, though, that many people lead far more interesting lives than they realize. Some people are better than others at noticing and extracting the interesting parts of what would otherwise be humdrum everyday tedium.

He doesn't have actual questions. He's making an ad hominem attack against the author of a language that he's forced to use, but hates.

The pattern matching in Swift isn't much better than what you would get with a tagged C union

In what way? Pattern matching in Swift is quite powerful; definitely better than C's switch statement. This blog post is a good overview of its capabilities. https://appventure.me/2015/08/20/swift-pattern-matching-in-d...

Swift supports ADTs and implements its Optional type as an ADT.

What a great summary of the utter baseness of this type of advertising: a stomach-turning body horror image I never wanted to see, some article calling strangers "morons" based on some stupid superficiality, and gossip about the private lives of strangers that is, quite frankly, none of my business.

That being said, if these companies vanished tomorrow it wouldn't be a complete positive either, since the fine sociopaths of the advertising industry would simply use the resultant vacuum to come up with something even more contemptible. Fuck that industry.

Swift has "if case let" for that use case. (Admittedly, the syntax is a bit esoteric.)

"Advanced manufacturing requires management and communication skills and the ability to operate complex information-based factories" is meaningless consultant jargon. It would have been better to explain exactly what about advanced manufacturing makes it so special that it requires 'management' and 'communication' skills that the managers and workers in non-advanced factories apparently lack. Meanwhile, "ability to operate complex information-based factories" is almost a tautology. Maybe talk about industrial IOT, or what specialized skills are necessary to efficiently operate a factory full of robots, or _something_?

I'm not particularly enthused with how the code was presented. Here's a marginally more readable version of the first large snippet that still doesn't exceed 77 (or 79) characters in width:

https://gist.github.com/austinzheng/dbee353163eb22920d7a567c...

Automatic Reference Counting: https://en.wikipedia.org/wiki/Automatic_Reference_Counting

I've seen interest on the lists for modifying the model to allow a single failure type to be specified. I hope someone will write up a proposal once August rolls around and the lists are open again to new feature ideas.

Scala tries a lot harder than Swift to unify object-oriented and functional programming principles.

For example, in Scala operators are (IIRC) implemented as methods on objects, there's a 'Nothing' bottom type that is used for covariant generic parameterization, and ADTs are implemented using inheritance in the form of case classes.

Swift has no top-level object type or bottom type, and a lot of its more functional style features (ADTs in the form of 'enums', value types that enforce immutability) are completely divorced from the object-oriented part of the language.

That's bizarre.

One thing I've noticed is that performing the string scanning operation is relatively cheap. (If the splitAndTrim code is modified to not use Strings and to return a [String.UTF16View], the runtime is around 1.2 seconds.) It's the process of building Strings out of those UTF16 views that is destroying performance.

I still don't know why changing the way the input data are constructed would have that effect, except to guess that the underlying representation is different somehow. I'll file a ticket.

Weird. I'm using the same version of Xcode, running on a trashcan Mac Pro running OS X 10.11.4.

After a bit more investigation, I found that if you replace the following code:

  result.append(begin == eos ? "" : String(cs[begin..<end.successor()]))

  if begin == eos {
    result.append("")
  } else if let str = String(cs[begin..<end.successor()]) {
    result.append(str)
  }

This is due to a rather insidious API design decision:

  init?(_ view: String.UTF16View)

  init<T>(_ instance: T)

As far as I can tell most of the rest of the time is spent in the Swift native Unicode --> UTF16 decoding machinery, and NSCharacterSet.

"This is a proposal and not a plan of record."

Not only that, the git feature branch, if it ever existed, doesn't anymore.

To be clear, that document contains brainstorming by some core Swift team developers. It's neither implemented in Swift nor officially accepted as a guideline for future development.

Regarding strings...

I briefly ran the code sample you graciously provided me with a month ago through the profiler (https://gist.github.com/austinzheng/d6c674780a58cb63832c4df3...).

Long story short, it looks like the reflection machinery in the standard library is improperly being used to construct String instances. Doing so, while probably not sufficient to account for the entirety of the awful performance, is probably quite expensive. This looks like a bug and I'll try to dig deeper into it this week.

Swift also badly needs a native version of NSCharacterSet, even if only for programmer ergonomics.

The developer in charge of the standard library has mentioned that that team intends on redesigning the String API in the near future; this should provide an opportunity to reexamine the performance implications of the current implementations.

VHDL vs Verilog flame wars everywhere. Also, discussions on people's favorite idiosyncratic, vendor-specific dialect of C for embedded devices.

I'm not saying the experiments were trustworthy or conducted properly. Only that the author of the article misunderstood the experimental setup.

(To be precise, the comment about the null thruster was made by the author in a comment on this article, and by a previous article written by the author, which this one references. It is not in the article itself.)

I am skeptical about the EmDrive (although I would very much like it to be real), and my opinion on the drive or its theoretical underpinnings is not really relevant, given my lack of knowledge about the field. But I don't think that writeup is very good either:

From the IO9 article:

The experimental setup is so flawed that it’s continuing to produce measurable “thrust” while in null mode when it should do nothing.

From the Wikipedia page on RF resonant cavity thrusters (and corroborated by the citations):

the 'null test article', was designed without the internal slotting that the Cannae Drive's creator theorised was necessary to produce thrust

The null test device was not intended to be the experimental control.

The article's author seems to fundamentally misunderstand the purpose of the null test setup. Setting everything else aside, if the null articles did produce thrust, this would disprove the Cannae theory (which requires the slotted configuration), but would say nothing about the efficacy of RF thrusters in general.

Their quotes from various physicists about why the drive is probably nonsense are a lot more compelling.

My (highly speculative) guess is that your String issues were due to either/both:

- Swift performance issues involving working with strings, some of which have been ameliorated by later releases;

- 'Hidden' bridging between NSString and String, which can be expensive and might have something to do with some of String's APIs actually being Foundation APIs in disguise.

There is much to be done with regards to Swift performance, though. If you have any sample benchmarks I would be interested in writing/running them myself, just for personal edification.

In terms of 'close to the metal', I freely admit this is a ill-defined term I am using for my own benefit. Swift code doesn't execute on something akin to the JVM or CLR; it still requires a heavier runtime than (e.g.) Rust. It is AOT-compiled to machine code. (But then again, this is possible to some degree for Java as far as I can tell, although it is certainly not the most popular way to run Java code.)

I agree that mandatory RC for classes and boxed types makes Swift impractical for a certain definition of 'systems software' typically written in C++ and occasionally Rust. For a different definition, one that encompasses the garbage-collected Go, Swift is theoretically suitable. The language designer has mentioned that he would personally like to see Swift gain some form of borrowing/lifetimes, although even if that did happen Swift would not get it for years to come.

It's possible to write non-GUI command-line Swift programs that run on Linux (and certain other platforms). In terms of 'close to the metal', Swift is probably much closer to Rust or C++ than C# or Java, and is at least at the same level as Go.

I love C# and think it's a great language, but when it was as old as Swift is now it was widely perceived as a Java clone. In fact, even today C# and Java are much closer in language design philosophy and implementation than C# and Swift, and calling Swift a "C# clone" betrays a profound lack of familiarity with what Swift is or how it works.

No, just a 'greatest hits' compilation of the same things China detractors have been complaining about since 1995. Their analysis is no better than the already dubious "official" numbers.

Yes, because moving from vtables to message passing eliminates a whole class of semantic errors whose genesis is independent of the implementation details of the language. Thanks for making this clear.

Since I expect nothing less than clear, well-informed commentary from Hacker News regulars, I would be very interested in learning exactly what technical aspects make Rust, Python, and Go superior to Swift in each use case, as well as lessons that future PL designers might draw from the Swift team's missteps.

If you don't know the specifics, why the hell are you even arguing this point?

The difference between traditional and simplified Chinese characters is more than simply different fonts. Part of the difficulty is that some simplified characters map to multiple traditional characters, which means that converting from one to the other may be lossy. There's also the Japanese equivalent of simplified characters (shinjitai), many of which differ from their Chinese counterparts, as well as characters that were invented in Japan and may or may not have Chinese equivalents (kokuji).