7 ms·

ARC is a whole debate, but the one thing it is not is simple and I would argue its more error prone than a traditional GC. I've used it for most of my career an

ARC is a whole debate, but the one thing it is not is simple and I would argue its more error prone than a traditional GC. I've used it for most of my career and I have seen what sloppy/unaware coding can do to it. Lattner is a well known expert on compilers. Having used Swift since its inception, I would call into question the reliability of the Swift LLVM compiler. In its current state (3.0.2) its absolutely terrible and does not back up the sentiment; "But fast-moving Silicon Valley needs a fundamental shift in quality standards when it comes to safety-critical software, and if you look closely, Lattner has been leading this charge at the language and compiler level".

9935c101ab17a66 10y ago
Can you explain why you call into question the reliability of the Swift LLVM compiler?
- devsquid 10y ago
  Do you use Swift at all? -edit- I meant it as a serious question. But the person who responded to me sums up the issues.
  - chris_7 10y ago
    This is downvoted presumably for lack of information, but it's pretty much true. The Swift compiler segfaults very frequently. I do find this amusing in that it's the compiler for a theoretically largely-memory-safe language (yes the compiler is written in C++, it's still funny). The syntax highlighter in Xcode, which is driven by the same stuff, also crashes, which breaks autocompletion and even indentation. Using Xcode, you just have to get used to it. It frequently reports the wrong error message - just something that isn't even close to related. Sometimes object files just become 0 bytes and you either need to clean (and experience the Swift compiler's blazing performance again) or go and modify that file so that the incremental compiler will pick it up. I've found most of these to be triggered by using a lot of closures and possibly type inference. Shaking out the incorrect errors or segfaults is... not fun.
    - devsquid 10y ago
      Oh? I meant it as a srs question. I wasn't sure what parts I should include. But thanks for essentially saying most of it. I should mention I also find the community to be sorta toxic. They are so focused on Swift being the one language to rule them all and they use terms like "Swifty".
      - pjmlp 10y ago
        All language communities do that.
        devsquid 10y ago
        I get your point, programming language communities all have a certain level of fan-boyism. However I find Swift's community to be particularly abhorrent. I stopped partcipating when people started to ask if certain codes is "Swifty" and people would judge the merit of something on whether its "Swifty". It also got tiring with how militant they were with other programming languages, especially Java.
        pjmlp 10y ago
        So I get you don't use Python as well. https://blog.startifact.com/posts/older/what-is-pythonic.html https://blog.startifact.com/posts/older/what-is-pythonic.htm... https://www.python.org/dev/peps/pep-0008/ https://www.python.org/dev/peps/pep-0008/ https://www.python.org/dev/peps/pep-0020/ https://www.python.org/dev/peps/pep-0020/
    - nodamage 10y ago
      The most annoying one is the incremental compiler is broken under Xcode 8, leading to full recompiles every time a line of code is modified. https://forums.developer.apple.com/thread/62737?start=0&tstart=0 https://forums.developer.apple.com/thread/62737?start=0&tsta...
    - 72deluxe 10y ago
      Yes I can agree with these. I wonder if we'll have refactoring in Xcode for C++ now Lattner has gone. I wonder why they never added it.
- nekitamo 10y ago
  It would be apparent if you were a regular user of the compiler. Random crashes while compiling well-formed code and performance problems with larger files/projects are quite common. Still, I would say it's mostly usable now. It used to be a lot worse.
  - devsquid 10y ago
    You find it better than before? I find that Swift 3.+ is drastically worse than Swift 2.
abalone 10y ago
I'm not claiming Swift 3.0.2 is the most reliable language ever. All systems require time to mature and it is very young historically speaking. I am saying Lattner's design principles should realize better results for safety-critical software in the long run. Compiler bugs can be fixed; programmer error is tied to design. It might be Swift, it might be something more pared down, but he's a good guy to have in charge of an autonomous driving software platform.
- devsquid 10y ago
  Well I'm sure he's a very experienced manager for technical projects and also brings a large amount of experience with compilers to the table. His online presence always has that Apple Arrogance™ to it. Thats coming from someone who was born and raised an Apple fan.
webjprgm 10y ago
I'm not sure I would say Swift is the kind of robust that is needed for safety critical software, but it is a nice step forward for application code. It mostly forces you to deal with things safely while still allowing Objective-C dynamic behaviors when you need to get around the restrictions (often to interact with other Obj-C code). So, yes I can see why one would call Lattner at the forefront of making more reliable compilers and pushing shifts in quality standards in fast-moving Silicon Valley. It is an awesome achievement to create a new language that improves both readability and safety and even more awesome to get it mainstreamed so quickly. There are a few people who I would like to trade places with. Lattner is one of them, Musk is another. They both fulfill different parts of my long-held dreams. So I consider them to both be quite awesome. Its cool that they'll be working together too I guess.
- devsquid 10y ago
  Sure Lattner and Musk are interesting people, but I find the level of hero worship in the tech industry to be sickening. Having used compilers for a few new languages (Rust, Go, Dart, Kotlin, Swift). Swift is the only one I've had any issues with as well as Swift seems to be the only language to have adopted the "move fast and break things" philosophy of Silicon Valley. I dunno, I just don't see the argument.
  - abalone 10y ago
    You're confusing language development with autonomous vehicle development. Think of the long term goal. It's desirable to move fast and fix things with language development in the near term, to achieve a more perfect design and accelerate its maturation at the temporary cost of more volatility. After this process achieves a high level of maturity, said design principles may offer a safer, more reliable programming system that would be better suited to safety-critical applications. Additionally I'm sure we can all agree there is no substitute for maturation through time and usage in the field. Which frankly is an argument for more popular languages over obscure ones. None of the ones you mentioned are ready for safety-critical system development (including Swift 3), but which one is most likely to achieve widespread adoption and field testing in the long run?
solidsnack9000 10y ago
The right comparison for ARC is with manual memory management -- not GC.
- brokencode 10y ago
  Not really. They are both valid comparisons, since ARC is much easier to work with than manual management and can offer more predictable performance than GC. That said, it's also slower than manual management and can be trickier to work with than GC.
  - pjmlp 10y ago
    ARC is a GC implementation algorithm, you probably mean tracing GC algorithm. "The Garbage Collection Handbook", chapter 5 http://gchandbook.org/ http://gchandbook.org/
- adevine 10y ago
  Depends on what your point is. Both ARC and GC are approaches to limit the complexity and difficulty of memory management. As such, I think it's very reasonable to compare them, because they're different approaches to the same underlying problem. FWIW, as someone who was a Java programmer for over a decade before learning Objective C right after ARC came on the scene, I greatly prefer ARC over garbage collection. I find the things you have to remember to think about with both ARC and GC (e.g. circular references and unintentionally strongly reachable references) to be about the same cognitive load, but the deterministic, predictable behavior of ARC means you won't have to try to debug random GC hangs that only happen in prod under heavy load and the subsequent fiddling with a million GC options to get performance to be acceptable.
  - pjmlp 10y ago
    ARC is a GC implementation algorithm, you probably mean tracing GC algorithm. "The Garbage Collection Handbook", chapter 5 http://gchandbook.org/ http://gchandbook.org/
    - 10y ago
hamstergene 10y ago
ARC is a tradeoff between manual and automatic memory management. Requring a little bit more care from programmer is intentional, not a disadvantage as you picture it, it is a price for not having, you know, GC. GC is less error prone not for free but at the price of eating CPU and memory, which in the world of mobile devices equal less battery life, so it is quite desirable for iPhones and MacBooks software not to have it.
- pjmlp 10y ago
  ARC is automatic memory management. "The Garbage Collection Handbook", chapter 5 http://gchandbook.org/ http://gchandbook.org/
  - devsquid 10y ago
    Yup but people love to argue over the small shit. Chris Lattner even refers to ARC as a form of GC.
  - hamstergene 10y ago
    Different approaches to memory management differ in extent of how much of programmer's job they automate. Garbage collectors are fully automatic and rarely if ever require to mind anything; automatic RC does almost everything but requires programmer to analyze and annotate some things as 'weak'; manual RC requires a lot more programmer's effort while still technically being "automatic"; and manual memory management means the programmer does everything. Automatic/manual is a scale, not a boolean yes/no, and the point is that ARC lies on it a bit closer to manual than garbage collectors.
    - pjmlp 10y ago
      The thing is, ARC is a garbage collection algorithm. There isn't anything like ARC vs GC, that is layman knowledge and just wrong from CS point of view.
      - hamstergene 10y ago
nicky0 10y ago
Just to point out that the Swift LLVM compiler is written in C++. So it being unreliable doesn't necessarily say much about the reliability or goals of Swift as a language.
- steeve 10y ago
  It looks like you haven't used C++ in a while. C++14 is a whole other world, and can be written with most (if not all) the safety guarantees you would expect from Swift or Rust. I had to use it for a project and was very surprised about this too...
  - nicky0 10y ago
    I wasn't trying to suggest that C++ was the cause of the compiler issues, just that Swift wasn't.
  - autoreleasepool 10y ago
    You're lucky if you get to use C++14 in the real world. My last C++ job was maintaining a 2 millions of line of legacy MFC code.
    - pjmlp 10y ago
      Even there one can write quite safe C++ code with help of CArray, CString, CComPtr, ... I used MFC like that in the late 90's/early 2000. The problem are the team mates that write Win32/C like code, instead of MFC/C++ code.

9935c101ab17a66 10y ago

Can you explain why you call into question the reliability of the Swift LLVM compiler?

devsquid 10y ago
Do you use Swift at all? -edit- I meant it as a serious question. But the person who responded to me sums up the issues.
- chris_7 10y ago
  This is downvoted presumably for lack of information, but it's pretty much true. The Swift compiler segfaults very frequently. I do find this amusing in that it's the compiler for a theoretically largely-memory-safe language (yes the compiler is written in C++, it's still funny). The syntax highlighter in Xcode, which is driven by the same stuff, also crashes, which breaks autocompletion and even indentation. Using Xcode, you just have to get used to it. It frequently reports the wrong error message - just something that isn't even close to related. Sometimes object files just become 0 bytes and you either need to clean (and experience the Swift compiler's blazing performance again) or go and modify that file so that the incremental compiler will pick it up. I've found most of these to be triggered by using a lot of closures and possibly type inference. Shaking out the incorrect errors or segfaults is... not fun.
  - devsquid 10y ago
    Oh? I meant it as a srs question. I wasn't sure what parts I should include. But thanks for essentially saying most of it. I should mention I also find the community to be sorta toxic. They are so focused on Swift being the one language to rule them all and they use terms like "Swifty".
    - pjmlp 10y ago
      All language communities do that.
      - devsquid 10y ago
        I get your point, programming language communities all have a certain level of fan-boyism. However I find Swift's community to be particularly abhorrent. I stopped partcipating when people started to ask if certain codes is "Swifty" and people would judge the merit of something on whether its "Swifty". It also got tiring with how militant they were with other programming languages, especially Java.
        pjmlp 10y ago
        So I get you don't use Python as well. https://blog.startifact.com/posts/older/what-is-pythonic.html https://blog.startifact.com/posts/older/what-is-pythonic.htm... https://www.python.org/dev/peps/pep-0008/ https://www.python.org/dev/peps/pep-0008/ https://www.python.org/dev/peps/pep-0020/ https://www.python.org/dev/peps/pep-0020/
  - nodamage 10y ago
    The most annoying one is the incremental compiler is broken under Xcode 8, leading to full recompiles every time a line of code is modified. https://forums.developer.apple.com/thread/62737?start=0&tstart=0 https://forums.developer.apple.com/thread/62737?start=0&tsta...
  - 72deluxe 10y ago
    Yes I can agree with these. I wonder if we'll have refactoring in Xcode for C++ now Lattner has gone. I wonder why they never added it.
nekitamo 10y ago
It would be apparent if you were a regular user of the compiler. Random crashes while compiling well-formed code and performance problems with larger files/projects are quite common. Still, I would say it's mostly usable now. It used to be a lot worse.
- devsquid 10y ago
  You find it better than before? I find that Swift 3.+ is drastically worse than Swift 2.

abalone 10y ago

I'm not claiming Swift 3.0.2 is the most reliable language ever. All systems require time to mature and it is very young historically speaking. I am saying Lattner's design principles should realize better results for safety-critical software in the long run. Compiler bugs can be fixed; programmer error is tied to design. It might be Swift, it might be something more pared down, but he's a good guy to have in charge of an autonomous driving software platform.

devsquid 10y ago
Well I'm sure he's a very experienced manager for technical projects and also brings a large amount of experience with compilers to the table. His online presence always has that Apple Arrogance™ to it. Thats coming from someone who was born and raised an Apple fan.

webjprgm 10y ago

I'm not sure I would say Swift is the kind of robust that is needed for safety critical software, but it is a nice step forward for application code. It mostly forces you to deal with things safely while still allowing Objective-C dynamic behaviors when you need to get around the restrictions (often to interact with other Obj-C code). So, yes I can see why one would call Lattner at the forefront of making more reliable compilers and pushing shifts in quality standards in fast-moving Silicon Valley. It is an awesome achievement to create a new language that improves both readability and safety and even more awesome to get it mainstreamed so quickly. There are a few people who I would like to trade places with. Lattner is one of them, Musk is another. They both fulfill different parts of my long-held dreams. So I consider them to both be quite awesome. Its cool that they'll be working together too I guess.

devsquid 10y ago
Sure Lattner and Musk are interesting people, but I find the level of hero worship in the tech industry to be sickening. Having used compilers for a few new languages (Rust, Go, Dart, Kotlin, Swift). Swift is the only one I've had any issues with as well as Swift seems to be the only language to have adopted the "move fast and break things" philosophy of Silicon Valley. I dunno, I just don't see the argument.
- abalone 10y ago
  You're confusing language development with autonomous vehicle development. Think of the long term goal. It's desirable to move fast and fix things with language development in the near term, to achieve a more perfect design and accelerate its maturation at the temporary cost of more volatility. After this process achieves a high level of maturity, said design principles may offer a safer, more reliable programming system that would be better suited to safety-critical applications. Additionally I'm sure we can all agree there is no substitute for maturation through time and usage in the field. Which frankly is an argument for more popular languages over obscure ones. None of the ones you mentioned are ready for safety-critical system development (including Swift 3), but which one is most likely to achieve widespread adoption and field testing in the long run?

solidsnack9000 10y ago

The right comparison for ARC is with manual memory management -- not GC.

brokencode 10y ago
Not really. They are both valid comparisons, since ARC is much easier to work with than manual management and can offer more predictable performance than GC. That said, it's also slower than manual management and can be trickier to work with than GC.
- pjmlp 10y ago
  ARC is a GC implementation algorithm, you probably mean tracing GC algorithm. "The Garbage Collection Handbook", chapter 5 http://gchandbook.org/ http://gchandbook.org/
adevine 10y ago
Depends on what your point is. Both ARC and GC are approaches to limit the complexity and difficulty of memory management. As such, I think it's very reasonable to compare them, because they're different approaches to the same underlying problem. FWIW, as someone who was a Java programmer for over a decade before learning Objective C right after ARC came on the scene, I greatly prefer ARC over garbage collection. I find the things you have to remember to think about with both ARC and GC (e.g. circular references and unintentionally strongly reachable references) to be about the same cognitive load, but the deterministic, predictable behavior of ARC means you won't have to try to debug random GC hangs that only happen in prod under heavy load and the subsequent fiddling with a million GC options to get performance to be acceptable.
- pjmlp 10y ago
  ARC is a GC implementation algorithm, you probably mean tracing GC algorithm. "The Garbage Collection Handbook", chapter 5 http://gchandbook.org/ http://gchandbook.org/
  - 10y ago

hamstergene 10y ago

ARC is a tradeoff between manual and automatic memory management. Requring a little bit more care from programmer is intentional, not a disadvantage as you picture it, it is a price for not having, you know, GC. GC is less error prone not for free but at the price of eating CPU and memory, which in the world of mobile devices equal less battery life, so it is quite desirable for iPhones and MacBooks software not to have it.

pjmlp 10y ago
ARC is automatic memory management. "The Garbage Collection Handbook", chapter 5 http://gchandbook.org/ http://gchandbook.org/
- devsquid 10y ago
  Yup but people love to argue over the small shit. Chris Lattner even refers to ARC as a form of GC.
- hamstergene 10y ago
  Different approaches to memory management differ in extent of how much of programmer's job they automate. Garbage collectors are fully automatic and rarely if ever require to mind anything; automatic RC does almost everything but requires programmer to analyze and annotate some things as 'weak'; manual RC requires a lot more programmer's effort while still technically being "automatic"; and manual memory management means the programmer does everything. Automatic/manual is a scale, not a boolean yes/no, and the point is that ARC lies on it a bit closer to manual than garbage collectors.
  - pjmlp 10y ago
    The thing is, ARC is a garbage collection algorithm. There isn't anything like ARC vs GC, that is layman knowledge and just wrong from CS point of view.
    - hamstergene 10y ago

nicky0 10y ago

Just to point out that the Swift LLVM compiler is written in C++. So it being unreliable doesn't necessarily say much about the reliability or goals of Swift as a language.

steeve 10y ago
It looks like you haven't used C++ in a while. C++14 is a whole other world, and can be written with most (if not all) the safety guarantees you would expect from Swift or Rust. I had to use it for a project and was very surprised about this too...
- nicky0 10y ago
  I wasn't trying to suggest that C++ was the cause of the compiler issues, just that Swift wasn't.
- autoreleasepool 10y ago
  You're lucky if you get to use C++14 in the real world. My last C++ job was maintaining a 2 millions of line of legacy MFC code.
  - pjmlp 10y ago
    Even there one can write quite safe C++ code with help of CArray, CString, CComPtr, ... I used MFC like that in the late 90's/early 2000. The problem are the team mates that write Win32/C like code, instead of MFC/C++ code.