Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift Regrets

belkadan.com

Post reply on HN
Print view View original

81–90 of 207 posts

Re: Swift Regrets

#81

Post by bsaul »

w0mbat wrote: post #45
kennywinker wrote: post #12

Earlier quoted context omitted.

I find it hard to believe that anybody is faster coding in objc than swift, if you control for garbage code. It was easy to quickly write buggy messes in objc - swift made that a lot harder, and is also a much more ergonomic and productive language in my experience. I feel like there has to be some other factors at play if that’s the results you’re seeing. (Source: I’ve been doing objc since 2009, and swift since ver…

I code several times faster in ObjC than Swift, and this is after writing two released Swift apps. Just a simple thing like writing string to num to string that works in different bases is a nightmare in Swift.

the swift string / substring api is still incredibly convoluted (or poorly documented, or both), but my feeling is that it's because it does a lot.

Re: Swift Regrets

#82

Post by jbluepolarbear »

iainmerrick wrote: post #68
jbluepolarbear wrote: post #49

Earlier quoted context omitted.

No it’s not. If you have multiple parameters Obj-C is much longer and ugly.

Where are you getting this from? Swift’s mandatory named parameters come from Objective-C. For the most part only the bracket placement is different.

Swift supports default and objc doesn’t. This makes calls smaller. Swift also has argument hiding with the underscore before the parameter. Swift also ask variable arguments. Hiding named parameters and variable arguments make calls much smaller. My point stands.

Re: Swift Regrets

#83

Post by jlarcombe »

gumby wrote: post #73
zozbot234 wrote: post #46

Earlier quoted context omitted.

C++ is of course a vastly more complex language than Swift. I don't think anyone would want to code in C++ these days if they can avoid it.

Actually plenty of people do want to and do so.

...and of course it was simple to interoperate with Objective-C in C++, in a way that it isn't for Swift, sadly

Re: Swift Regrets

#84

Post by joeberon »

protomyth wrote: post #10

I guess I was in the minority who loved Objective-C and it's selector syntax. I think my main objection to Swift is that it seems to be written by people who hate Objective-C and made the calling syntax much more complicated. I dearly wish a more mature F-Script had been the next Apple language. A lot of the other problems is Apple not providing good documentation and making sure sample programs continue to compile.…

I don’t understand why Apple’s developer documentation is so terrible

Re: Swift Regrets

#85

Post by lpapez »

zozbot234 wrote: post #46
protomyth wrote: post #43

Earlier quoted context omitted.

How is this true? Swift is very straightforward, and similar to other languages That's the argument, most people want to program in JavaScript or C++, learning is such a bother. The Swift syntax is more characters than ObjC's syntax.

C++ is of course a vastly more complex language than Swift. I don't think anyone would want to code in C++ these days if they can avoid it.

If besides best possible performance you also value ergonomics, security, maturity and tooling then IMO nothing comes close to C++, especially C++17 and later. Not that there is much choice really, only C and Rust can realistically get you comparable performance, each with their own problems.

Re: Swift Regrets

#86

Post by Apocryphon »

zionic wrote: post #11
protomyth wrote: post #10

I guess I was in the minority who loved Objective-C and it's selector syntax. I think my main objection to Swift is that it seems to be written by people who hate Objective-C and made the calling syntax much more complicated. I dearly wish a more mature F-Script had been the next Apple language. A lot of the other problems is Apple not providing good documentation and making sure sample programs continue to compile.…

> I think my main objection to Swift is that it seems to be written by people who hate Objective-C I mean that's the vast majority of people >and made the calling syntax much more complicated. How is this true? Swift is very straightforward, and similar to other languages Meanwhile Objective-C is slow, unsafe by default, with super ugly syntax only a mother could love. More than half of Apple's CVE/iOS vulnerabilitie…

> I mean that's the vast majority of people

Maybe...

https://news.ycombinator.com/item?id=15421073

It's an old article by now, but check out the responders- Marco Arment, Steve Troughton-Smith, Marcel Weiher- pretty eminent iOS devs among them.

Re: Swift Regrets

#87

Post by Apocryphon »

jbluepolarbear wrote: post #82
iainmerrick wrote: post #68

Earlier quoted context omitted.

Where are you getting this from? Swift’s mandatory named parameters come from Objective-C. For the most part only the bracket placement is different.

Swift supports default and objc doesn’t. This makes calls smaller. Swift also has argument hiding with the underscore before the parameter. Swift also ask variable arguments. Hiding named parameters and variable arguments make calls much smaller. My point stands.

That's not really "much" longer. And in some cases the brevity saved could really increase obfuscation and confusion.

Re: Swift Regrets

#88

Post by jbluepolarbear »

Apocryphon wrote: post #87
jbluepolarbear wrote: post #82

Earlier quoted context omitted.

Swift supports default and objc doesn’t. This makes calls smaller. Swift also has argument hiding with the underscore before the parameter. Swift also ask variable arguments. Hiding named parameters and variable arguments make calls much smaller. My point stands.

That's not really "much" longer. And in some cases the brevity saved could really increase obfuscation and confusion.

Yes it is; especially, if there’s long parameter names. And I disagree with the obfuscation and confusion, but that’s a discussion on Swifts goal of self documentation not code length.

Re: Swift Regrets

#90

Post by jarpadat »

zozbot234 wrote: post #33
jshier wrote: post #29

Earlier quoted context omitted.

The main point of Swift was to create a memory-safe language Apple could use across its OSes. Trying to change Obj-C's syntax doesn't help with that goal.

Swift does not provide memory safety for concurrent code. It has comparable pitfalls to Go. (You can use Thread Sanitizer to try and diagnose these issues, but that's best-effort and runtime-only; it does not make your code totally safe.)

Concurrent memory safety is definitely a goal. Try the new ‘-warn-concurrency’ flag to see what I mean, it is comparable to rust and quite different than thread sanitizer. There’s also a new runtime sanitizer this year with swift intrinsics, not best effort like tsan was.

That said. Swift is in the tough position of trying to be a lot of things at once to users with competing needs. Applications, systems, performance, education, prototyping, etc. While there’s broad agreement concurrency safety is important, not everybody thinks it is important enough to bury your working build under a thousand errors (though that view is represented)

Ultimately swift’s philosophy is that safety is practice and not theory. Some people do turn on ‘-warn-concurrency’ and fix their errors, others would want to ignore them and find some escape hatch to squash them which doesn’t appreciably improve safety, still others might not upgrade if that was required and maybe the ecosystem as a whole becomes less safe for it. Swift feels responsible for these kinds of outcomes.

It’s a tough problem but it does lead to interesting ideas that make safety more practical and productive. Remains to be seen how much of both worlds you can have, but swift/clang/llvm have a long history of doing stuff like that better than you expect.

Post reply on HN