Live data from Hacker News

The Decade of Swift

swiftbysundell.com

131–140 of 145 posts

Re: The Decade of Swift

#131
post #129
post #123

Earlier quoted context omitted.

How do you spin S4TF on Windows Containers or any kind of Linux distribution in-house?

Using Docker Edit: or on Ubuntu just download the toolchain.

So instead of using the native tooling provided by Julia, ML.NET, PyTorch, the solution is to somehow either emulate Linux on Windows, or being stuck with Ubuntu as distribution.

Re: The Decade of Swift

#132

Earlier quoted context omitted.

Would you mind expanding on these feature sets a bit more? Because I just started playing with SwiftUI/Combine without ever using ObjC/UIKit, I don't know what parts of ObjC shined.

Objective-C was a good fit for dynamic, object-oriented GUI frameworks like Cocoa because that’s how it itself was structured. SwiftUI and Combine are simply a different way of structuring UI code that fits a lot better with Swift’s strengths.

Could you expand on that? How do the structures differ?

Re: The Decade of Swift

#133
post #128

Earlier quoted context omitted.

But didn't some version of Objective-C use a GC? My understanding was that the reason it didn't work well was because of issues with the language and not the libraries. So they could still have used a GC for Swift?

The reason it did not work was indeed the language, given the underlying C semantics of Objective-C. However Objective-C ARC is basically the compiler taking care of Cocoa retain/release patterns. Swift needed to provide a seemless path forward to integrate with Objective-C libraries so reference counting was the easist way forward. Microsoft has chosen another way to interoperate with COM from .NET, which requires a…

So if I understand it correctly, Apple decided to move that complexity to the language itself? I was reading up on the rules for references in Swift, and it looks like a lot of complexity and lots of opportunities for introducing errors leading to leaks.

Re: The Decade of Swift

#134
post #131
post #129

Earlier quoted context omitted.

Using Docker Edit: or on Ubuntu just download the toolchain.

So instead of using the native tooling provided by Julia, ML.NET, PyTorch, the solution is to somehow either emulate Linux on Windows, or being stuck with Ubuntu as distribution.

I mean containerization is not the same as emulation.

But I would assume a lot of people just want a notebook to do their work in. Does it really matter if it’s running in a container or natively? Most python projects run inside a virtual environment anyway, which is comparable if not more poorly encapsulated.

Also the cloud use-case is expanding. Environment basically doesn’t matter at all in that case.

Re: The Decade of Swift

#135
post #130
post #125

Earlier quoted context omitted.

Yeah, while Rust is paving the way for affine type systems among mainstream languages, and it already influenced design decisions on other system programming languages, including Swift (memory ownership manifest), it isn't the first on my list for UI or distributed computing applications.

Yeah to me Rust almost feels like the prototype for the next great programming language. There are a lot of great ideas there, but there are also a lot of awkward edges. Like what it accomplishes from a technical perspective is super impressive, but it would be great if somebody could synthesize all of those concepts behind a cleaner front-end which really nails the ergonomics.

A few people have tossed around the idea of “what if Rust but drop the commitment to zero cost abstractions.” That’s probably our principle that causes the most ergonomic hit.

Of course, Rust won’t start taking that path, but if I were to start a new language today, that’s what it would look like.

Re: The Decade of Swift

#136
post #128

Earlier quoted context omitted.

The reason it did not work was indeed the language, given the underlying C semantics of Objective-C. However Objective-C ARC is basically the compiler taking care of Cocoa retain/release patterns. Swift needed to provide a seemless path forward to integrate with Objective-C libraries so reference counting was the easist way forward. Microsoft has chosen another way to interoperate with COM from .NET, which requires a…

So if I understand it correctly, Apple decided to move that complexity to the language itself? I was reading up on the rules for references in Swift, and it looks like a lot of complexity and lots of opportunities for introducing errors leading to leaks.

That is the price to pay for reference counting as approach to automatic memory management.

If you want to hide circular references from developers, then a cycle collector is required on the runtime.

For example this was the approach taken by Mesa/Cedar, or for a more modern reference CPython.

If you look into C++/CX or C++/WinRT, this issue is also surfaced to the programmer.

Rust makes it even more explicit with its reference counting library types.

At the end of the day, it depends on what Swift designers were optimising for.

Which to me looks like the easiest and less performance impact to integrate with the Objective-C runtime and respective libraries.

Swift's approach is still easier than doing the same from Objective-C, its target audience.

Re: The Decade of Swift

#137
post #134
post #131

Earlier quoted context omitted.

So instead of using the native tooling provided by Julia, ML.NET, PyTorch, the solution is to somehow either emulate Linux on Windows, or being stuck with Ubuntu as distribution.

I mean containerization is not the same as emulation. But I would assume a lot of people just want a notebook to do their work in. Does it really matter if it’s running in a container or natively? Most python projects run inside a virtual environment anyway, which is comparable if not more poorly encapsulated. Also the cloud use-case is expanding. Environment basically doesn’t matter at all in that case.

It is on Windows, because Swift hardly runs there, if at all.

Yes it matters, because many organisations get development stations managed by IT, and there are very strict compliance regulations regarding where data processing takes place.

Re: The Decade of Swift

#138
post #14

Earlier quoted context omitted.

I think Rust supersedes it in most aspects, especially in not being Apple driven.

So we’ll refuse go, typescript and react? Apple has the best engineering talent of all tech companies.

> Apple has the best engineering talent of all tech companies.

Are you trolling or are you that kind of extremist apple fanboy?

Re: The Decade of Swift

#139
post #114

Earlier quoted context omitted.

I assumed it was there for compatibility with Objective-C, I can't imagine any other justification.

What would it have to do with Objective-C?

Because objective-c has the same feature, if you want seamless integration with existing libraries then you need it.

Re: The Decade of Swift

#140
post #130

Earlier quoted context omitted.

Yeah to me Rust almost feels like the prototype for the next great programming language. There are a lot of great ideas there, but there are also a lot of awkward edges. Like what it accomplishes from a technical perspective is super impressive, but it would be great if somebody could synthesize all of those concepts behind a cleaner front-end which really nails the ergonomics.

A few people have tossed around the idea of “what if Rust but drop the commitment to zero cost abstractions.” That’s probably our principle that causes the most ergonomic hit. Of course, Rust won’t start taking that path, but if I were to start a new language today, that’s what it would look like.

Interesting. There was a really good talk at the last CPPCon by Chandler Carruth about how there is really no such thing as a zero-cost abstraction. The main point being, while you might be able to optimize against a runtime performance cost for abstractions, the cost will almost always be shifted to compile time, or to the cognitive burden on the developer.

It really makes me think there must be something like the first law of thermodynamics for logical complexity.

Post reply on HN