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

151–160 of 207 posts

Re: Swift Regrets

#151

Post by pjmlp »

saagarjha wrote: post #66
azakai wrote: post #53

Earlier quoted context omitted.

That is true, but the great majority of memory safety issues are not concurrent ones. In practice Swift and Go are huge improvements over C, C++, and Objective-C in terms of memory safety. I'd also say they are in a reasonable space in the state of the art of safety in general. While they do not make concurrency safe and Rust does, in Rust you need to use unsafe to write things like doubly-linked lists and graphs (or…

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.

Re: Swift Regrets

#152

Post by pjmlp »

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.

For Cocoa like classes, it did not solve anything else for the rest.

Re: Swift Regrets

#153

Post by [deleted] »

w0mbat wrote: post #50
drclau wrote: post #21

Earlier quoted context omitted.

If you develop for iOS|macOS professionally, you may be interested in Jetbrains' AppCode [0]. Note: I'm not connected in any way to Jetbrains, and I have not used AppCode myself, but I used other tools from them, and they're quite competent, I'd say. [0]: https://www.jetbrains.com/objc/

Apple professionals use Xcode. Using different tools than the ones Apple uses leads to a lot of problems that Apple are not interested in fixing. The days when a company like Metrowerks or Symantec could be a viable third party IDE supplier are long gone.

[deleted]

Re: Swift Regrets

#154

Post by pjmlp »

jamesfinlayson wrote: post #123
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.

I thought Objective C was dead - it'll still be supported (probably) but https://developer.apple.com/ calls out Swift a lot but makes no mention of Objective C.

Then Metal is dead as well.

Re: Swift Regrets

#155

Post by pjmlp »

johnthuss wrote: post #128
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.

Yes, you should learn Swift. The naming of things in Apple's APIs still comes through strong in Swift (due to named parameters), so it feels at home to programmers who were familiar with ObjC. Swift protects you from many crashes/bugs with its null safety and more strict compiler. In ObjC many clear coding mistakes are only marked with warnings, which is not helpful. Apple has clearly moved to Swift for all future de…

Metal is a mix of Objective-C and C++ (MSL C++14 dialect).

So it will stay around for a while.

Re: Swift Regrets

#156

Post by fooker »

jb1991 wrote: post #145
fingerlocks wrote: post #133

Earlier quoted context omitted.

> along with the question marks I'd take the question marks any day over tracking a nil passed around a dozen source files before landing in a dictionary literal.

Absolutely this. Having accidental null values floating around a program should not be a thing in the year 2021. And that’s exactly what some languages are fixing, like Swift. This problem is also one of the reasons why I got so frustrated using clojure.

The question mark syntax just moves this burden to some other layer of abstraction.

Re: Swift Regrets

#157

Post by stefanfisk »

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.

you can define ObjC method parameters with empty selector names if you want.

This for example is perfectly legal ObjC, callable as [foo gimmeAString:10 :"hey "].

  - (NSString*)gimmeAString:(NSUInteger)count :(NSString*)piece {
      return [@"" stringByPaddingToLength:count withString:piece startingAtIndex:0];
  }

Re: Swift Regrets

#158

Post by gurkendoktor »

pjmlp wrote: post #148
mpweiher wrote: post #101

Earlier quoted context omitted.

> > and made the calling syntax much more complicated. > How is this true? Swift is very straightforward, and similar to other languages Swift is objectively one of the most complex languages out there[1]. Just recently, they adopted basically the entirety of Smalltalk syntax as an edge case of an edge case[2]. Just the rules for initialisers are more complex than many languages and still don't cover all the cases[3]…

> The parts that make C dangerous, particularly strings and other raw pointer accesses are abstracted away behind safe NSString, NSArray, NSData and friends. True, and just like in C++, the C tribe that came into the language just ends up using char * most of the time, instead of the safe variants.

I have jumped into several badly written ObjC projects and I skimmed the source code of every CocoaPod that I've used, and I have never seen ObjC code that used C string/memory handling "most of the time". Not even when ObjC required manual reference counting.

Except for a couple of malloc'd C arrays (as an optimization over using NSArray), most of it was for interop with C libraries, the same code where in Swift you'd have to use UnsafeMutablePointer.

Re: Swift Regrets

#159

Post by nmfisher »

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 can't stand Objective-C, but I'm pretty apathetic towards Swift. As far as I can see, Swift simply swapped Obj-C's terrible syntax for its own, equally terrible syntax.

I probably would have been more enthusiastic about "Obj-C 2.0" than Swift.

Re: Swift Regrets

#160

Post by pjmlp »

gurkendoktor wrote: post #158
pjmlp wrote: post #148

Earlier quoted context omitted.

> The parts that make C dangerous, particularly strings and other raw pointer accesses are abstracted away behind safe NSString, NSArray, NSData and friends. True, and just like in C++, the C tribe that came into the language just ends up using char * most of the time, instead of the safe variants.

I have jumped into several badly written ObjC projects and I skimmed the source code of every CocoaPod that I've used, and I have never seen ObjC code that used C string/memory handling "most of the time". Not even when ObjC required manual reference counting. Except for a couple of malloc'd C arrays (as an optimization over using NSArray ), most of it was for interop with C libraries, the same code where in Swift yo…

What can I say, lucky you.

Now try the same with a couple of offshored projects from some famous consulting companies.

Post reply on HN