Live data from Hacker News

Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions

infoq.com

291–300 of 308 posts

Re: Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions

#291

Earlier quoted context omitted.

Is tensoflow for swift even still a thing?

Some of the first bits of research using it just started coming out last month

I should really start looking at it again

Re: Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions

#292
post #284
post #273

Earlier quoted context omitted.

I beg to differ, having been doing GUI coding since a couple of decades. Guess what, what in most of them I never had any issues to center elements, or create fake UI elements out of list items. Also layout managers were already a thing back in 2000.

I did UI development for quite a while too, and in my experience having very specific layouts (and look) in HTML is easier than in frameworks I used (Gtk, Qt, UIKit...). Main difference is that HTML has affordances to size elements "upwards" whereas in other toolkits you need to do this manually (e.g.: estimating text size is a thing, in html you don't need to care about this) Now, this also encourages original layou…

You also don't need to estimating text size in QML, XAML, Forms, VCL, and when you need it is hardly any different than dealing with CSS fonts.

Re: Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions

#293

Earlier quoted context omitted.

null safety modern C# has optional chaining, Elvis operator and non nullable types value types C# has value types contrary to Java (until project Panama) What would you argue C# has going for it over Swift? feature wise I don't know but it clearly has a far bigger lib ecosystem which is the most important criterion

Yes, some of these have been slowly added, similar with Java slowly moving to embrace features from Scala and Kotlin, but to me it doesn't feel as nice, rather sort of baked on and many of the libraries don't use these latest features. Swift was designed to seamlessly blend functional and OO styles from the get go. Fundamentally, there's still classes and inheritance everywhere in C#, which is also what I hated about…

> Now don't get me wrong, I am not saying C# is a bad language, just that when you compare it with Swift, Kotlin, Rust etc, it's clearly playing catchup.

btw. it's the other way round. most modern stuff was in c# while the others played catchup and some still do. no language has async/await implemented as good as c# has, no language has nullable value types as good as c# no languages has a reflection api that is really easy to use and if that isn't enough there are also expressions which are more like macros and due to the way how generics are implemented no internal api sucks. btw. c# even has channels.

swift has nothing over c# and all features swift has were more likely be in c# before they were in swift.

Re: Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions

#294
post #288
post #270

Earlier quoted context omitted.

Yeah there are some quirks, but that wasn't part of OP's request.

Well, I did specify "modern", which arguably includes sane Unicode handling. I think a reasonable compromise is to have "char" be a 32 bit type, whereas a "string" would be UTF8.

Not sure if I would call string handling in Swift sane, but to each its own.

Re: Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions

#295
post #282

Earlier quoted context omitted.

The exponential issue was still there in version 4 and I think 5 as well. Didn't say SourceKit crashed, but it was virtually useless because it functioned like a crap version of the language parser.

So what's particularly hard on the compiler are hard coded sets of data that have mixed types. For example a dictionary that reflects a JSON response that also has nested dictionaries. It helps if you test declare it like: let json: [String: Any] = [ /** lots of fields here */ ] String concatenation: could you give me a specific piece of code that fails? It could be that I really never write code that triggers the pr…

The string concatenation issue was that if you do a ++ b ++ c... When that got to about 6 variables that single line alone took a minute to compile. Go to 10 variables and just give up on ever seeing a result. I used to try it in online Swift REPLs and it was still happening with whatever was most recent a bit over a year ago.

Re: Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions

#296
post #195

Earlier quoted context omitted.

I'd argue the other way around. Not to mention that developing C# in Visual Studio or Rider feels years ahead of what's considered good enough IDE assistance in other languages. Comparable with Java even.

In some ways, Swift is a higher-level Rust. It places a lot more emphasis on functional programming, null safety, value types and immutability than C# does. The more flexible memory management model added recently, native binaries, (as the default option) and even identifier: Type over type identifier is also a nice plus for me, I agree that the IDE situation is heavily in C#'s favor. If C# is a nicer Java and Kotlin…

I like C# for balancing both implement new features (in easier way IMO) and keep compatibility.

Re: Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions

#297

Earlier quoted context omitted.

> But somehow after nearly 6 years Objective-C stills feels better This experience is shared by basically nobody? I used to love Objective-C, which was unusual even before Swift, but I would not in a million years switch back to using it. Swift is so much better in every single way.

I share it. I love Objective-C and feel its a far superior language over Swift. Swift is too clever by half, with its var, let, func, and the god awful question marks. Objective-C is verbose sure, but that helps readability. I'll never switch to Swift, as Objective-C is so much better in every single way.

Your assertions aren't backed up by anything; your criticisms of Swift are superficial and reek of "I'm unfamiliar with it, therefore it's bad".

Re: Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions

#298

Earlier quoted context omitted.

Both. If you have only one, you have a shit product nobody wants.

I'm not advocating for garbage looking products. All I'm saying is that lets be tolerant on looks because functionality matters the most

You can be as tolerant as you want, that's not how things go for iOS apps. It's certainly not how things go on macOS except when there are no available alternatives.

Windows, Android, and the web, constantly changing so that there's never really been any sense of stability, blind a lot of developers to the fact that good design is both functionality AND looks.

When people complain about designs of controls being out of date, they don't only refer to looks. They refer to how they feel, behave — or more succinctly, don't correspond to the expectations set up by the rest of the system.

To reduce the debate down to looks vs. functionality is reducing things down to the wrong level, missing the forest for the trees, and ignoring the user — a person who often isn't able to express what they need but knows what they want, not often realising that they're the same thing.

Re: Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions

#299

Earlier quoted context omitted.

Hate to say it, but the sanest thing to do if you need a cross platform UI is use Java. Your other choice is Electron, which is way slower and uses many times as much ram

I wonder whether GraalVM native image will play a bigger role in desktop apps in the future. Kotlin + TornadoFX + native-image (if it is supported) sounds like a pretty comfortable to use UI stack.

Gluon has been putting a lot of work into native-image + JavaFX for cross platform. Im not sure if it'll catch on though.

Re: Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions

#300
post #186

Earlier quoted context omitted.

Creating a good cross-platform GUI framework is probably harder than creating a good cross-platform language.

Creating a good cross-platform GUI framework is probably harder than creating a good cross-platform language. Way way way way way harder, I'd think. It's basically never been done in the modern era. All the successful ones from the past look (and work) like garbage on a modern desktop computer (I use gnucash for my dad's business, ha ha). SwiftUI is an interesting re-think, though, and as a Windows 10 user, I can tel…

Beeware did it
Post reply on HN