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

71–80 of 207 posts

Re: Swift Regrets

#71

Post by iainmerrick »

kennywinker wrote: post #12
rapsey wrote: post #7

Before Swift/Kotlin our iOS team was way more productive than android. Everything was done in half the time. They both switched to new languages. Now it has flipped. Android does things in half the time the other team needs.

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 prefer Swift on balance, but there’s still a lot I miss from Obj-C.

For one thing, Obj-C compiles much faster. Swift compilation is ludicrously slow.

Re: Swift Regrets

#72

Post by iainmerrick »

jshier wrote: post #35
novok wrote: post #28

Earlier quoted context omitted.

I have a lot of experience in both languages, and TBH it's just not true. I'm less productive in swift in many ways, mostly because of it's slow build and indexing times. It's infuriating. You are still coding against the same UIKit and other apple libraries in both. SwiftUI has a chance to make it better, but it's incomplete and has bugs/gotchas that make it not as productive as UIKit when you run into that, which i…

It would be impossible to evolve Obj-C to add most of Swift's capabilities unless you drop binary and source back compatibility. At that point it's just another new language and you've lost the things you say made Obj-C simpler. I have a hard time believing any engineer is productivity bound by Swift's build times and especially indexing times, since indexing doesn't affect your ability actually write code. Typically…

indexing doesn't affect your ability actually write code

What! Of course it does. If it doesn’t impact coding at all, what is it for?

Re: Swift Regrets

#73

Post by gumby »

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.

Actually plenty of people do want to and do so.

Re: Swift Regrets

#74

Post by azakai »

saagarjha wrote: post #64
azakai wrote: post #55

Earlier quoted context omitted.

That would not have helped with use-after-free, though, which Swift does solve.

That's solved by ARC, not Swift.

Oh right, good point. Other types of memory safety are more relevant here then.

Re: Swift Regrets

#75

Post by gavinray »

iainmerrick wrote: post #70
dhritzkiv wrote: post #42

Earlier quoted context omitted.

Totally. To add to this: when looking for third party libraries (Swift/Objective-C or Kotlin/Android Java), aside from those from large organizations (Square, Airbnb, etc.), I've found the selection and quality of those available for iOS to be better, on average.

I think it helps that C and C++ just work on iOS, so you can easily use or wrap existing code in those languages. Unless things have changed a lot recently, C/C++ sort-of-works on Android but it’s a pain to use and the tooling support is very weak.

There's a tool called "scapix" that's popped up recently that fixes this and is really impressive.

It's zero-boilerplate (IE, don't need to manually write bindings like most tools) bindings from C++ code for both Swift/ObjC and Java. The idea being you can write C++ code and then consume it on both mobile platforms, making your life easier.

  https://github.com/scapix-com/scapix
It also is really useful if you want to use Java from C++. Manual JNI invocation and type translation is awful, this just smoothes over all of it.

  https://github.com/scapix-com/scapix#java-link
Good usecase being when you want to extend a Java app with some native capabilities.

I've had a scenario where another app handed me the pointer to a window to render to, and so the only way to use it from JVM was to write some bridge code. Where C++ started the JVM & invoked my Java app's entrypoint, sending over the window pointer, and then from there I could render/paint into the window.

Re: Swift Regrets

#76

Post by bsaul »

kyralis wrote: post #56
msoad wrote: post #2

Swift has way too many shorthand syntaxes. It feels nice from a language design perspective but when teaching Swift, you can see how confusing it is for the students. In larger codebases a lot of shorthands are forbidden by the organizations for consistency. So I'm not sure who's the real beneficiary for all those shorthands?

Very much this. The original discussions around Swift talked about the value of being explicit rather than implicit and reducing surface area (for instance, no ++/-- increment/decrement operators). That goal appears to have been completely lost recently.

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.

Re: Swift Regrets

#77

Post by germandiago »

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.

I want. I do it. It gives me a level of control and a number of libs that no other language can give me, including all the C libs available as well.

Yes, it is not pretty sometimes, but if you take a look at well-written C++ code you would be very surprised at how clean it can look. With its quirks from time to time, but very clean:

- mark virtual overrides with override

- use move semantics to increase performance

- take advantage of RVO

- write GUIs, CLIs, or servers

- use lambdas and ranges

- use smart pointers to get rid of most memory management

- tune your server to allocate and deallocate in the desired patterns via polymorphic allocators or just plain allocators

- take advantage of SIMD and parallelism (via parallel algorithms library, among many examples)

- create generic infrastructure in algorithms with zero overhead penalty that is not even possible in other languages

- keep things working for the next 2 or 3 decades without touching the code

- Program in HPC environments

C++ is much better than what most people that do not use it all the time think. It is not as bad as they put it, and, more important, it is very high performance. I admit this is one of the big reasons why people use it, but C++ for application programming does not look to me like crazy either.

Re: Swift Regrets

#78

Post by dddddddan »

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

It does now with actor based concurrency

Re: Swift Regrets

#79

Post by germandiago »

tialaramex wrote: post #48
novok wrote: post #24

I'm surprised he doesn't bring up minor features that lead to huge compile time issues, like operator overloading and imports being module sized vs file or folder wide and type inference in some cases. Not to mention how the language doesn't actually scale that well with core count vs. many, many other programming languages. Throwing 64 cores / 128 threads at a C++ code base speeds up builds in a linear fashion durin…

C++ pays an extraordinary price for the fully parallel builds, concealed in the "One Definition Rule". The price is, if you violate the ODR the standard says your program is not valid C++ (and thus has no defined meaning) but there is no requirement for a diagnostic (ie a compile or link error) and the build might complete. This has sometimes been described as "False positives for the question is this a program?" and…

Modules mitigate in a big measure ODR violations. It will be quite more difficult. Compile times will also be better, at least incremental ones.

Re: Swift Regrets

#80

Post by bsaul »

iainmerrick wrote: post #71
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 prefer Swift on balance, but there’s still a lot I miss from Obj-C. For one thing, Obj-C compiles much faster. Swift compilation is ludicrously slow.

Recently had to update an old objc ios codebase, and the first time i built i thought something went wrong, because it completed way too fast.

Swift compilation is an order of magnitude too slow, especially in incremental built, compared to objc.

Post reply on HN