171–180 of 209 posts
Earlier quoted context omitted.
Meanwhile on Java and .NET world, it is Microsoft, Oracle, IBM, Azul, Linaro,.... putting the bulk of work.
And thus dictated by their whims only, instead of shepherding and encouraging outside perspectives
Earlier quoted context omitted.
> I call it out as weird because take SwiftUI for example Be careful not to confuse Swift with SwiftUI. SwiftUI is just a UI framework. It's the one Apple is pushing right now, but it doesn't really have any bearing on the cross-platform story for Swift. (I doubt it ever will -- I don't think Apple particularly wants to take it outside the Apple ecosystem, and it would be very high effort to do in any case.)
SwiftUI could not have be written for the public version of Swift. Instead, the Swift language has been changed to have SwiftUI's desired syntax. That level of symbiosis is not "just" a UI framework. Swift is first and foremost Apple's own language for Apple's own frameworks. The frameworks aren't layered on top of an immutable language. The language is evolved to serve the frameworks' needs. This has already started…
The toolchain requires Win10 - but can a resulting executable be deployed on Win7?
I'd be surprised if it could. Mainstream support for Windows 7 ended years ago, extended support ended this year. If the Swift community (or more accurately, the one guy in charge of the Windows port) bothers to support executables running on a deprecated version of Windows, that would come as a mighty surprise to me. Still, you never know, it might manage to do it by fluke!
There are some aspects where Swift is nicer in theory (e.g. Swift enums beat Kotlin sealed classes in terms of ergonomics and, while unnecessary for 99% of projects, we had some genuine use case for custom operators, working on a maths product). But other than those, it seems to be that Kotlin is the superior language in almost every respect. It seems to have none of the major flaws that Swift has, and the tooling is great, which is the exact opposite of my experience with Swift.
Swift has this weird sort of ecosystem where Apple builds much of the platform in a very secret (most of the roadmap isn't shared), closed-source variant for its own OS. Then it has this open source version, with a very public compiler (roadmap IS shared) that allows cross platform toolchains like this one to exist. I call it out as weird because take SwiftUI for example, the main excuse Apple engineers gave for why…
And how easy/worthwhile is it to use Rust for building GUI applications or games on Windows?
DirectX is closed source too, and I don’t even know what UI framework Microsoft is currently championing.
Swift has this weird sort of ecosystem where Apple builds much of the platform in a very secret (most of the roadmap isn't shared), closed-source variant for its own OS. Then it has this open source version, with a very public compiler (roadmap IS shared) that allows cross platform toolchains like this one to exist. I call it out as weird because take SwiftUI for example, the main excuse Apple engineers gave for why…
SwiftUI being closed source is a huge issue for developers. Apple behaves as if every user is immediately on the latest version but the reality is the _lucky_ developers support one major version back. SwiftUI is broken in completely different ways for each minor release of iOS 13 and none of the fixes in 14 are possible to use in 13. It's shocking how mismanaged the SDK development at Apple is.
iOS 14 Adoption Surpasses 25% Across iPhone and iPad Five Days After Release
https://old.reddit.com/r/apple/comments/ix3gve/ios_14_adopti...
How long does it usually take on Android?
Earlier quoted context omitted.
In practice I don't think it's that confusing. You have a large standard library which is available everywhere, and then you have a set of proprietary API's which are only available on Apple platforms. Is the situation that different from C# and windows API's?
.Net 5 and C# 9.0 are very much 100% open all the way down to the core. https://github.com/dotnet/roslyn (c#) https://github.com/dotnet/winforms (UI) https://github.com/dotnet/wpf (UI) https://github.com/dotnet/core (Foundation) I don't consider the Win32 API itself part of .NET or C# as they've existed long before either.
> I don't consider the Win32 API itself part of .NET or C#
SwiftUI isn’t “part” of Swift either, it’s a proprietary application of Swift, and it’s fucking amazing, I don’t want to work with any other framework now.
Earlier quoted context omitted.
SwiftUI being closed source is a huge issue for developers. Apple behaves as if every user is immediately on the latest version but the reality is the _lucky_ developers support one major version back. SwiftUI is broken in completely different ways for each minor release of iOS 13 and none of the fixes in 14 are possible to use in 13. It's shocking how mismanaged the SDK development at Apple is.
> Apple behaves as if every user is immediately on the latest version iOS 14 Adoption Surpasses 25% Across iPhone and iPad Five Days After Release https://old.reddit.com/r/apple/comments/ix3gve/ios_14_adopti... How long does it usually take on Android?
And the number of people still on 12 is significant.
Earlier quoted context omitted.
The docs are very incomplete and common third party dependencies are missing. I know it’s a chicken and egg type situation but vapor is not an appealing option for backend unless you really want/need to use Swift.
I am curious, what did you find missing or unachievable using Vapor?
Edit: looking at the docs again theres an official upgrade guide now so thats a step int he right direction, I'll take a closer look when I get a chance.
Earlier quoted context omitted.
Are you sure? The source is available for both Core and old .NET and to me they all seem to be Win32 controls with some customization... unless I'm missing something. AFAIK WPF uses DirectX for rendering, so it's a bit different (it's more like Flutter... or a game engine). Button: https://github.com/dotnet/winforms/blob/master/src/System.Wi... / https://referencesource.microsoft.com/#System.Windows.Forms/... Toolstr…
Okay, perhaps my wording was off. Yes, they're Win32 controls in that sense, but many (most?) of the newer controls are no longer mere wrappers around something that exists in Win32, but rather implement all functionality in managed code, both behavior and drawing.
But that's how we do custom controls in Win32. You can get very far with only common controls, but as soon as you need something more complicated you have to draw it yourself. Just because they're using C# doesn't mean it's not the same API or is not native controls.
WPF on the other hand is completely different, internally it only uses native calls to get the canvas where everything will be drawn and to handle input/accessibility (plus a few other things).