Earlier quoted context omitted.
> this attitude to dog fooding isn't great. The Dock and a few other components of macOS Sierra are written in 100% Swift, according to this year's WWDC.
The Dock? Why would they completely rewrite the Dock?
[deleted]
IBM says Swift is ready for the enterprise
161–170 of 235 posts
Re: IBM says Swift is ready for the enterprise
#162Earlier quoted context omitted.
Absolutely. I'm not attempting to put it down as somehow not worthy of anyones time, just thought I'd mention how "cushioned" it all felt :P
What language do you prefer over Swift? I'm curious.
C++11 with review-enforced RAII. Boost if you need special stuff involving odd data structures. gtest/gmock. Depending on what you're doing, add some Qt5, OpenCV, OpenMP, RapidXML/RapidJSON, any C library ever written - and there are BSD/LGPL libraries for pretty much anything. Make plugins with Lua. Run tests in Valgrind.
Re: IBM says Swift is ready for the enterprise
#163So... what's the "elevator pitch" for Swift? It has anything interesting over Elixir or Go (well, go's feature is "lack of feature" but you know what I mean) or Scala or Kotlin? I know that iOS and MacOS desperately needed a modern language, and great for them that they have it now, but does the rest of the world need it?
It's fairly decent as far as OOP languages go, but I'd say it's appeal as server side language is limited to iOS devs though :).
Okey, so what is appealing to you then? (just curious)
Re: IBM says Swift is ready for the enterprise
#164Earlier quoted context omitted.
How does that make them any more difficult to use?
You have to manually optimize away unnecessary reference counting without help from the compiler.
I have never seen unnecessary reference counting be a problem in Rust. That's because not manipulating the reference count requires an explicit action—.clone()—and borrowing is so expressive that you rarely need to manipulate the counts.
Re: IBM says Swift is ready for the enterprise
#165Earlier quoted context omitted.
Speaking only for myself, avoiding or breaking retain cycles is a noticeable problem in Swift code that simply isn't there in languages with a proper garbage collector. Among newer iOS programmers, it's a big point of confusion to figure out when a callback closure should use [weak self] versus capturing self strongly, for example. I've seen a lot of people struggle to understand, completely fail, and end up dogmatic…
It is much easier than in either C++ or Rust.
Technically true, but very misleading in Rust's case. In Rust you rarely have to break retain cycles in the first place, simply because you don't use reference counting much. Things like "weak self" are not a problem, because closures aren't reference counted unless you explicitly make them so (and in fact I don't think I've ever seen a reference counted closure in practice).
Re: IBM says Swift is ready for the enterprise
#166Earlier quoted context omitted.
Can you elaborate on the cognitive overhead vs a GC language like golang or java? (With regards to memory) To me sure there is things you think about but generally memory performance is less of a mental burden. Also, swift 4 is supposed to support a rust like memory model. Not sure if it's opt in or how it will work but my impression is that it's memory model is about to support some new use cases to make it appropri…
Reference counting has upsides and downsides. If you look at the lengths that some Java based projects like Spark have to go to in order tame the GC, then you have to question whether tracing GC is the right choice in the age of hundereds of GBs of memory. On the other hand reference counting is extremely slow. So slow that it puts a lot of restrictions on API design and that is definitely a mental burden. Swift's ow…
> On the other hand reference counting is extremely slow. So slow that it puts a lot of restrictions on API design and that is definitely a mental burden.
This is very wrong on both points. Reference counting has a lot less mental burden compared to GC, because it's predictable. You can rely on destructors to actually work and be useful. For example, you don't have to keep track of whether you closed your file descriptor or not, but in GCd languages you have to do that manually, sometimes even with the same reference counting, but hand-written and explicit. Reference counting is also very fast, with the exception of concurrent decades old implementations, that are irrelevant today.
Re: IBM says Swift is ready for the enterprise
#167Earlier quoted context omitted.
> It automatically manages memory I have to stop you there. You shouldn't compare anything to C/C++ or Rust after that. You are better off comparing Swift with Go(i.e. both have automatic memory management, nice syntax, static typing, dynamic feeling etc) or Java(automatic memory management, well established in the enterprise world). If Apple was to design a language to respond to Go or Java it would be Swift and tha…
Well, technically Swift's memory management is the same as what C++ offers via smart pointers, the only difference is that in C++ it is opt-in (and still very popular). Swift is quite unlike Go or Java's memory management; it is not a GC in the sense that they use it.
Swift memory management isn't nearly as expressive as C++ when it comes to references (i.e. unmanaged pointers). You can use in/out/inout parameters on functions and that's about it.
I agree with the parent that Swift memory management is basically like Go or Java: everything is GC'd (reference counting being a form of GC).
Re: IBM says Swift is ready for the enterprise
#168The article mentions IBM's web framework: https://developer.ibm.com/swift/kitura/ Has this one gained the most traction?
In terms of GitHub stars:
https://github.com/vapor/vapor: 6,300+
Re: IBM says Swift is ready for the enterprise
#169Earlier quoted context omitted.
On the contrary - they've usually raced headfirst into abandoning old technologies for the hot new thing (early to have only CD and no floppy, early to get rid of CD drive altogether, early to go to USB-C, early to go to 802.11ac, etc.) They've used their weight to create a one-company network effect for up-and-coming standards and technology.
Early? All of those changes were made after long using old technologies. I wouldn't consider it "raced headfirst into abandoning", more like "everyone wanted to abandon those old technologies but couldn't survive being the first to, so Apple made the move and everyone soon followed".
I don't think you really contradicted anything the GP said, and in some cases you supported it. Apple raced headfirst into abandoning old technologies, which everyone wanted to do but couldn't easily, and was able to pull it off because of their market position and status. Others soon followed.
So,"early" not as in before expected, but during the beginning of that time (i.e. more akin to "first").
Re: IBM says Swift is ready for the enterprise
#170Earlier quoted context omitted.
I think the pitch is that despite static typing, it offers a lot of multi-paradigm high-level features while remaining elegant with fairly minimal syntax compared to other native static languages like Rust or C++. It automatically manages memory but without a stop-the-world garbage collector and goes a long way to opening a lot of flexible design options to any developer: it has great support for generic programming,…
One other downside is XCode. No refactoring support, and lots of errors that give you little help. For instance, if you're trying to implement a protocol which is itself a few layers of nested protocols, XCode will just tell you it doesn't conform and not what method you're missing, so you have to dig through and check every signature of every method carefully. The swift 2 to 3 migration was absolutely insane, I'd es…
Swift is amazing, Xcode is crap, and I've been using Xcode and its NeXT version for almost 20 years. I work in Xcode every day and every day I want to hurl it. Apparently Apple either doesn't care or is too overwhelmed with building 4 OSs every year. To be effective for building server side apps we need a new dev environment.