5 ms·

C++ makes people disgusted, from iostreams to meta-templates that slow-down compilation to a crawl. Its natural they wanted to replace C++ with something, but

C++ makes people disgusted, from iostreams to meta-templates that slow-down compilation to a crawl. Its natural they wanted to replace C++ with something, but turns out the big bad C++ optimizes to better code and Swift isn't that great. Perhaps instead of inventing C/C++ replacement language, its better to invest in improving C/C++ standards/libraries and APIs. Forcing developers to adopt Swift/Dart/.NET and framework of the month doesn't magically create an ecosystem of new software, it only appears when developers are maintaining something long-term that doesn't rely on whims of company or the current trend.

bluetomcat 3y ago
Swift is a beautified and pythonified Objective-C without the dynamic dispatch. It uses the same ARC memory model. C++ doesn't lock you to a particular memory management scheme. You can program with raw pointers like it's 1998, or entirely use post-C++11 value-semantic objects without touching new and delete.
- zer0zzz 3y ago
  This is only partly correct. It’s generally encouraged to use value types (or the up coming move only types) unless you actually want the reference semantics or you are interoping with objc apis on Darwin. If you ever watch talks from folks like Dave A. Who wrote the stdlib, he says he only ever uses arc types as a mechanism to enforce COW for the stdlib types and containers.
nxobject 3y ago
Can I provide an alternative interpretation? I don’t think caring about fast fast fast performance, or legacy codebases, is really in Apple’s DNA I think Apple’s always cared about ease of development over the possibility of bare metal optimization - after all, Objective-C was built on dynamic dispatch, and libraries as important Cocoa/AppKit and Apple’s compositors aren’t going to ditch that soon. And, because of C++’s scars and warts, I don’t see Apple ever valuing stable codebases over Apple’s ruthless deprecation habits when it comes to change and development. Instead, I’m convinced it’s really to help people trying to port games to macOS; it’s unusual for Apple to ever invest in an ecosystem of porting from different platforms, but here we are.
- astrange 3y ago
  I think it's odd to say Apple doesn't care about legacy codebases in the same post you mention AppKit. That's 30 years-ish old.
  - jwells89 3y ago
    To add to this, getting an abandoned mid-00s Mac app project compiling and running usually isn’t too bad, actually. Yeah you’ll have deprecation warnings left and right but it’ll run fine anyway, at which point fixing the deprecations can be done at one’s leisure. It’s binary compatibility that Apple doesn’t care about.
- valty 3y ago
  > I think Apple’s always cared about ease of development over the possibility of bare metal optimization I would disagree. Apple avoided managed runtimes this whole time and made people think about memory safety a lot compared with Java/C#. Programming was not as easy as it could have been. It has also always been trivial to fallback to C/C++, and the interop story with ObjC code is a lot cleaner. I think the driver for this was because they highly valued a buttery smooth UI, and this requires a lot of bare metal optimization.
  - pjmlp 3y ago
    Objective-C has a runtime, with automatic resource management, dynamic code loading, metaclasses...
    - valty 3y ago
      By _managed_ runtime I meant virtual machine. The ObjC runtime is just a library that is linked in. It's much easier to drop down to the metal when you need to. > automatic resource management ARC is not runtime-based.
      - pjmlp 3y ago
        A managed runtime is a managed runtime. ARC is definitely runtime based, go read the easily available machine code doing retain / release message calls, when the compiler isn't able to ellide them. You also forgot the remaining capabilities of Objective-C runtime regarding plugins, and metaclasses.
astrange 3y ago
Thinking that C++ "optimizes to better code" or that compiling to faster bigger code is even the right thing to do is the mark of an app developer. This is not relevant to system programming. It's actually anti-relevant, as your #1 job is to be small and stay out of the way of the app code. And your #0 job is to not crash or have security holes.

bluetomcat 3y ago

Swift is a beautified and pythonified Objective-C without the dynamic dispatch. It uses the same ARC memory model. C++ doesn't lock you to a particular memory management scheme. You can program with raw pointers like it's 1998, or entirely use post-C++11 value-semantic objects without touching new and delete.

zer0zzz 3y ago
This is only partly correct. It’s generally encouraged to use value types (or the up coming move only types) unless you actually want the reference semantics or you are interoping with objc apis on Darwin. If you ever watch talks from folks like Dave A. Who wrote the stdlib, he says he only ever uses arc types as a mechanism to enforce COW for the stdlib types and containers.

nxobject 3y ago

Can I provide an alternative interpretation? I don’t think caring about fast fast fast performance, or legacy codebases, is really in Apple’s DNA I think Apple’s always cared about ease of development over the possibility of bare metal optimization - after all, Objective-C was built on dynamic dispatch, and libraries as important Cocoa/AppKit and Apple’s compositors aren’t going to ditch that soon. And, because of C++’s scars and warts, I don’t see Apple ever valuing stable codebases over Apple’s ruthless deprecation habits when it comes to change and development. Instead, I’m convinced it’s really to help people trying to port games to macOS; it’s unusual for Apple to ever invest in an ecosystem of porting from different platforms, but here we are.

astrange 3y ago
I think it's odd to say Apple doesn't care about legacy codebases in the same post you mention AppKit. That's 30 years-ish old.
- jwells89 3y ago
  To add to this, getting an abandoned mid-00s Mac app project compiling and running usually isn’t too bad, actually. Yeah you’ll have deprecation warnings left and right but it’ll run fine anyway, at which point fixing the deprecations can be done at one’s leisure. It’s binary compatibility that Apple doesn’t care about.
valty 3y ago
> I think Apple’s always cared about ease of development over the possibility of bare metal optimization I would disagree. Apple avoided managed runtimes this whole time and made people think about memory safety a lot compared with Java/C#. Programming was not as easy as it could have been. It has also always been trivial to fallback to C/C++, and the interop story with ObjC code is a lot cleaner. I think the driver for this was because they highly valued a buttery smooth UI, and this requires a lot of bare metal optimization.
- pjmlp 3y ago
  Objective-C has a runtime, with automatic resource management, dynamic code loading, metaclasses...
  - valty 3y ago
    By _managed_ runtime I meant virtual machine. The ObjC runtime is just a library that is linked in. It's much easier to drop down to the metal when you need to. > automatic resource management ARC is not runtime-based.
    - pjmlp 3y ago
      A managed runtime is a managed runtime. ARC is definitely runtime based, go read the easily available machine code doing retain / release message calls, when the compiler isn't able to ellide them. You also forgot the remaining capabilities of Objective-C runtime regarding plugins, and metaclasses.

astrange 3y ago

Thinking that C++ "optimizes to better code" or that compiling to faster bigger code is even the right thing to do is the mark of an app developer. This is not relevant to system programming. It's actually anti-relevant, as your #1 job is to be small and stay out of the way of the app code. And your #0 job is to not crash or have security holes.