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

191–200 of 207 posts

Re: Swift Regrets

#191

Post by fingerlocks »

selcuka wrote: post #127
bsaul wrote: post #76

Earlier quoted context omitted.

My impression following swift forums is that original core team members were very concerned about relying a lot on first principles, whereas the new generation is more about building powerful constructs, in a fast paced way.

The new generation doesn't seem to have a need for extracting substrings from strings then. The existing Swift syntax for slicing strings [1] is horrible. [1] https://www.cocoaphile.com/posts/string-slicing-in-swift

That article is terrible. Simple wrapping a string in Array() converting it to characters achieves what the author desired and makes the rest of the article pointless.

Re: Swift Regrets

#192

Post by stephencanon »

whatshisface wrote: post #135
stephencanon wrote: post #120

Earlier quoted context omitted.

> Objective-C is quite fast–in many cases faster than Swift–and as (memory) safe as Swift for the most part. Ehhhh. If you write Swift the same way you write Obj-C, it will generally be as fast or faster. You only fall off the happy performance path when you use Swift features that don't even exist in Obj-C. That's not Swift being slower, that's Swift letting you use abstractions that aren't possible in Obj-C. But yo…

> That's not Swift being slower, that's Swift letting you use abstractions that aren't possible in Obj-C. But you don't _have_ to use them. What happens in practice is that the libraries you're consuming use them, and then you have to use them.

You can use the existing Obj-C libraries instead, which by definition do not use them.

I find it hilarious that Obj-C devotees object to this, since it precisely mirrors their argument for decades in the face of bogus performance complaints: “you can just use normal C functions”. They were right then, and you can just use Obj-C libraries today.

Re: Swift Regrets

#193

Post by selcuka »

fingerlocks wrote: post #191
selcuka wrote: post #127

Earlier quoted context omitted.

The new generation doesn't seem to have a need for extracting substrings from strings then. The existing Swift syntax for slicing strings [1] is horrible. [1] https://www.cocoaphile.com/posts/string-slicing-in-swift

That article is terrible. Simple wrapping a string in Array() converting it to characters achieves what the author desired and makes the rest of the article pointless.

The article is only for demonstrating how standard library works (it was the first Google result for me). The point is we shouldn't need to convert a string to an array of characters to manipulate it.

Re: Swift Regrets

#194

Post by saagarjha »

pjmlp wrote: post #151
saagarjha wrote: post #66

Earlier quoted context omitted.

In my experience post-ARC almost all memory safety issues are thread-safety related.

Except ARC only works for Cocoa like classes, everything else is traditional C like memory management.

Yes, but most of the time you’re not using that in your Objective-C code.

Re: Swift Regrets

#195

Post by saagarjha »

mpweiher wrote: post #144
saagarjha wrote: post #64

Earlier quoted context omitted.

That's solved by ARC, not Swift.

It was really solved by reference counting, way back when Foundation was introduced. The ARC increment was tiny.

Tiny? It made it so you’d never have to deal with an overrelease ever again…

Re: Swift Regrets

#196

Post by saagarjha »

stephencanon wrote: post #120
saagarjha wrote: post #62

Earlier quoted context omitted.

> 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 vulnerabilities lately have been from parts of the OS that still use ObjC, Objective-C is quite fast–in many cases faster than Swift–and as (memory) safe as Swift for the most part. Most of Apple's CVEs come from code written in C or C++, not Objective-C.

> Objective-C is quite fast–in many cases faster than Swift–and as (memory) safe as Swift for the most part. Ehhhh. If you write Swift the same way you write Obj-C, it will generally be as fast or faster. You only fall off the happy performance path when you use Swift features that don't even exist in Obj-C. That's not Swift being slower, that's Swift letting you use abstractions that aren't possible in Obj-C. But yo…

I think it’s a fair comparison to look at the idiomatic way to do something in a language and use that as the reference. Doing things on arrays in Swift often means people will call filter and reduce and map a bunch, while an Objective-C programmer might write a loop. It just so happens that LLVM can sometimes optimize the latter better. I mean, I could make the exact same argument you’re making about Objective-C being “as fast as C”: it literally is C. But when people use it they write methods and create objects, which are not things they can do in C. So I think it’s fair to call it “slower” if it needs to go through dynamic dispatch to enable the code that a normal developer would write.

Re: Swift Regrets

#197

Post by saagarjha »

mpweiher wrote: post #108
zionic wrote: post #93

Earlier quoted context omitted.

This shouldn’t be true, ObjC’s only innate advantage is compile time, because the compiler is simply doing less and is capable of producing far worse (unsafe) code. At runtime Swift can utilize static dispatch, where objective C is mostly dynamic. Good swift code should generally be faster.

> This shouldn’t be true Performance isn't about what you believe should be true, but about what actually is true. Kinda like science. (versus religion) > ObjC’s only innate advantage is compile time Objective-C has a bunch of advantages. Compile time isn't really one of them, except when compared to Swift, which is ridiculously slow to compile. And there are languages with very comparable feature sets to Swift that…

Agree with most of your comment, but Uber’s thing was probably just as likely to be a team unable to say “no” to new code rather than one that “needed” people to anneal compiler passes

Re: Swift Regrets

#198

Post by akmarinov »

whiddershins wrote: post #111

So is Objective-C kinda going away after all? If I did a greenfield iOS or OSX app would it be malpractice to do it in Objective-C? Because I actually adore that language. Haven’t used it lately, but I do love it.

Looks like it, Apple has been pumping out new frameworks that you just can’t use from Objective-C

Re: Swift Regrets

#199

Post by fingerlocks »

selcuka wrote: post #193
fingerlocks wrote: post #191

Earlier quoted context omitted.

That article is terrible. Simple wrapping a string in Array() converting it to characters achieves what the author desired and makes the rest of the article pointless.

The article is only for demonstrating how standard library works (it was the first Google result for me). The point is we shouldn't need to convert a string to an array of characters to manipulate it.

> The point is we shouldn't need to convert a string to an array

Yes we should. Unicode strings have ambiguous lengths. I would encourage you to try slicing Unicode strings sometime to understand why this is true.

Consider the black Santa emoji. What is the length of that emoji? Backspacing an emoji deletes it, so it could be one. But then how would you substring slice out the skin color component of the emoji?

Converting a string to an array yields the symbols on the screen separated by the cursor position, but that’s not a true representation of the data.

Re: Swift Regrets

#200

Post by mpweiher »

saagarjha wrote: post #195
mpweiher wrote: post #144

Earlier quoted context omitted.

It was really solved by reference counting, way back when Foundation was introduced. The ARC increment was tiny.

Tiny? It made it so you’d never have to deal with an overrelease ever again…

Yes, tiny.

Not sure what you're on about with the "overrelease" bit, but all ARC did was automate things with additional compiler support that were already automated.

And it caused additional crashes in code that shouldn't even be able to crash:

https://blog.metaobject.com/2014/06/compiler-writers-gone-wi...

Post reply on HN