Rust/WinRT Public Preview • Hacker News Board

Re: Rust/WinRT Public Preview

#191

Post by sfifs » Fri, May 01, 2020, 2:18 PM UTC

fluffything wrote: post #173

pjmlp wrote: post #166

Earlier quoted context omitted.

It is already available, it is called GObject, KParts, D-Bus. If the community has embraced a proper desktop eco-system around them, like the component vendors on other platforms, they aren't going to start now. I surely don't see job offers for Linux/BSD GUI toolkits as I see for Apple, Microsoft and Google ones. WSL is only for those that use Windows to target GNU/Linux, the demography that used to buy macOS to do…

> WSL is only for those that use Windows to target GNU/Linux, the demography that used to buy macOS to do the same. Do you know many people that used to do this with macOS and are now using Windows ? Like, oh boy, I tried, but after 4 months I ended up back with macOS.

In my experience, one of the the problems is that Macs are hilariously underpowered for many modern dev and analytics use cases. So the workaround is to work off remote machines/clusters over web interfaces/SSH but for many development use cases that's just slow and clunky - the have merit more in productionising. The series of hardware clusterfucks on Mac haven't helped ether.

So I've seen Mac users who work in these areas get sick of the issues and limitations and switch to Win 10 + sometimes WSL.

The people remaining with Macs are executive suite (who go for iPad pros) and account execs who do sales where it looks cool to go pull out a Mac. However even there people are increasingly looking dumb when they want to present something and go on 5 min dongle troubleshooting hunt because Mac killed HDMI and VGA ports and start their presentation appearing incompetent. Sometimes over web screen shares, only the desktop shows and not the applications.

By refusing to focus on hardware/software quality and power users, Apple has lost the game on high end.

Re: Rust/WinRT Public Preview

#192

Post by Ididntdothis » Fri, May 01, 2020, 2:23 PM UTC

pjmlp wrote: post #159

Ididntdothis wrote: post #34

Earlier quoted context omitted.

there is a big difference between out of process COM (like Office Automation) and in process COM (like WinRT and UWP or DirectX). Out of process was always a little tricky and not implemented well. DCOM was even worse. In process COM works really well. Edit: I should add that C# isn’t the best language for COM because it doesn’t release objects when they go out of scope so you either have to release everything manual…

That was kind of sorted out with the COM improvements in .NET 4.0 and SafeHandles.

Can you give more detail?

Re: Rust/WinRT Public Preview

#193

Post by elcritch » Fri, May 01, 2020, 2:27 PM UTC

pjmlp wrote: post #166

peatmoss wrote: post #151

Earlier quoted context omitted.

How can we bring this to Linux/BSD? Specifically the GUI layer? I’ve lamented that Linux desktop world has been fragmented and alien as compared to other major environments. I used to think that things would have been better if we had chased GNUStep and source compatibility with macOS. I feel like the non-GUI userland in Linux is best in class and is effectively a given for any server deployment. But all the develope…

It is already available, it is called GObject, KParts, D-Bus. If the community has embraced a proper desktop eco-system around them, like the component vendors on other platforms, they aren't going to start now. I surely don't see job offers for Linux/BSD GUI toolkits as I see for Apple, Microsoft and Google ones. WSL is only for those that use Windows to target GNU/Linux, the demography that used to buy macOS to do…

No, the point of peatmoss's comment is that Linux doesn't lack components or even tools, they lack a cohesive ecosystem. The parts like GOjbect, or KParts, or D-Bus are present but lack cohesion and coordination. The paid teams at Cannonical, IBM/Red Hat, etc all seem to be more concerned with rewriting the core desktop shell's every other release than making a cohesive ecosystem on their chosen tools.

For example, take high DPI. You have two primary competing toolkits between GTK/QT. It took a while but QT/KDE finally added HiDPI. Great, so I could get Hi-DPI setup on KDE! Then I open Firefox and it all falls apart because GTK. Extrapolate to any other number of issues. Unfortunately, Windows 10 isn't much better wrt to HiDPI (at least a couple years back when I last used it). I think there are more different UI toolkits on Windows than Linux has. Counterpoint: MacOS has one global toolkit with message passing based objects, it was almost trivial for Apple to add HiDPI and then dark modes. GNUStep/ObjectiveC would've provided similar basis on Linux, but it never took off. Now macOS is slowly loosing cohesion, instead of ObjectiveC 3.0, they made Swift which from my perspective appears to only be good at adding bugs to the terminal app while trying to avoiding message passing (no more user hot-loadable, un-sactioned third party plugins for any program on macOS :/ ).

At this point, I vaguely dream that HaikuOS will take off or someone makes a WebOS DE for Linux that has a complete suite of tools... but like peatmoss, I'd settle for a Rust/winRT on Linux.

Re: Rust/WinRT Public Preview

#194

Post by cheez » Fri, May 01, 2020, 2:31 PM UTC

CodeM0nkey wrote: post #116

cheez wrote: post #98

Earlier quoted context omitted.

The Microsoft you remember is at a time when dev tools were "the future". They are now the past. Microsoft's ruthlessness is no doubt focused elsewhere now. For example, do they go out of their way to make your code portable b/w Azure and Google? Probably not.

Off the top of my head here are three different offerings from Microsoft that enable cross cloud applications: - https://azure.microsoft.com/en-us/services/azure-arc/ - https://dapr.io/ - https://keda.sh/

That's pretty cool not an expert so can't know how truly portable it is, or is it like "Visual Java" ;-)

Re: Rust/WinRT Public Preview

#195

Post by ComputerGuru » Fri, May 01, 2020, 3:10 PM UTC

mwcampbell wrote: post #107

Looks like async/await support isn't ready yet. I wonder how challenging it will be to integrate WinRT's async model with Rust's futures and tasks.

IAsyncOperation is pretty flexible. I don’t think it will be technically hard, though perhaps picking the best fit model will be a time consuming process.

Re: Rust/WinRT Public Preview

#196

Post by steveklabnik » Fri, May 01, 2020, 3:28 PM UTC

Ericson2314 wrote: post #153

https://github.com/retep998/winapi-rs they should work with this

These are two different APIs, so it's not clear to me how they would.

Re: Rust/WinRT Public Preview

#197

Post by Rusky » Fri, May 01, 2020, 3:38 PM UTC

ridiculous_fish wrote: post #141

Rusky wrote: post #112

Earlier quoted context omitted.

It works fine- Rust only forbids multiple `&mut T`s to the same object, but `&mut T` doesn't exist outside of Rust, so code in other languages doesn't have to care about that rule at all. These bindings can just expose non-Rust pointers as (wrapped) raw pointers, leaving all the actual dereferencing and mutation to the other language. WinRT objects don't expose anything but virtual methods on opaque objects anyway, s…

Is the projection literally "wrapped raw pointers?" How are the raw pointers wrapped - for example is there interop between COM reference counting and Rust Arc? Or something else? Here's a classic trap: you get a reference to something interior, and then the parent is deallocated. My event handler gets a ref to this button's label and then replaces the button. Is this possible with Rust/WinRT? (No judgement either wa…

The raw pointers are wrapped in `ComPtr` defined here: https://github.com/microsoft/winrt-rs/blob/master/src/com_pt...

Those `ComPtr`s are then wrapped in convenience types that handle method dispatch, via code generated here: https://github.com/microsoft/winrt-rs/blob/master/crates/win...

There is no integration with Rust Arc, but that's just because in COM/WinRT each object is in charge of its own allocation and ref-counting- AddRef and Release are just methods of IUnknown, the root of the interface hierarchy.

That particular trap doesn't really come up in COM/WinRT- COM objects only expose methods that pass around references to full objects. This is because a given object might exist in another process or even on another machine, in which case you are only holding a proxy created by the runtime.

So any references held by your event handler, to the button or its label, are ref-counted (though they may be weak references), and replacing an object is fine because it just decrements its refcount.

In the general case (e.g. implementing an interface yourself, or some other non-COM-based scenario), pornel's sibling comment is correct- just like with Rust's own Rc/Arc types, you can borrow from some particular ref-counted pointer and the compiler will ensure that it outlives those borrows, keeping the object alive.

Re: Rust/WinRT Public Preview

#198

Post by 29athrowaway » Fri, May 01, 2020, 3:51 PM UTC

fortran77 wrote: post #53

29athrowaway wrote: post #44

Earlier quoted context omitted.

Let me introduce you to Steve Ballmer, the CEO before the current one, Satya Nadella: https://www.theregister.co.uk/2001/06/02/ballmer_linux_is_a_... He was CEO of Microsoft until 2014, that is, 6 years ago. Microsoft changed strategies because they tried everything they possible could to counter open source and Linux and lost. Now they are forced to play nice. Being forced to be nice is not the same as being nice ou…

They _lost_? They have a 1.36 trillion USD Market cap (today). That's more than Apple's 1.29 trillion USD Market cap. It's hilarious how people on hacker news live in this bubble where Microsoft has faded away into irrelevance. And they're also very good. I'm running Windows 10 right now on a dual-monitor, dual NVidia GPU, dual Xeon system and everything "just works."

As if you could not do that on another OS.

You can use Nvidia GPUs in SLI mode in Linux and BSD too. I am using an Nvidia GPU right now and I am not using Windows, and "everything just works" too, no terminals involved. Are you implying that it's not possible to do this outside Windows?

How much of that market capitalization comes from running a de-facto monopoly of office suites for decades? As a consumer, it's hard to see how corporations like Microsoft push governments around the world to buy licenses in bulk because there are no alternatives.

Re: Rust/WinRT Public Preview

#199

Post by blinkingled » Fri, May 01, 2020, 4:07 PM UTC

fluffything wrote: post #173

pjmlp wrote: post #166

Earlier quoted context omitted.

It is already available, it is called GObject, KParts, D-Bus. If the community has embraced a proper desktop eco-system around them, like the component vendors on other platforms, they aren't going to start now. I surely don't see job offers for Linux/BSD GUI toolkits as I see for Apple, Microsoft and Google ones. WSL is only for those that use Windows to target GNU/Linux, the demography that used to buy macOS to do…

> WSL is only for those that use Windows to target GNU/Linux, the demography that used to buy macOS to do the same. Do you know many people that used to do this with macOS and are now using Windows ? Like, oh boy, I tried, but after 4 months I ended up back with macOS.

Few years ago I did this transition - I had a MBP that I used for all Unix based things - after realizing how great Ubuntu runs under Hyper-V I just began to use that. It wasn't as seamless but no big deal opening up SecureCrt to connect. Then WSL came along and I used that but found the file system access to be too slow so back to Hyper-V VM. Now that WSL2 is actually a more seamless Hyper-V VM I am planning to just use that. I truly haven't needed a Mac for anything at least 4 years. I do a bunch of Enterprise Java development along with learning Rust etc. - VSCode with Remote Extension Pack makes it all even better.

Re: Rust/WinRT Public Preview

#200

Post by ratmice » Fri, May 01, 2020, 4:13 PM UTC

steveklabnik wrote: post #190

masklinn wrote: post #188

Earlier quoted context omitted.

Seems sensible though, the build.rs solution would require every project using rust/winrt to have a build.rs and code to load & codegen the modules (probably copy/pasted), so it'd be a lot more work for users of rust/winrt, though I guess it'd be less magic.

Oh yeah, I agree. I’m really interested to see if this approach would work better than build.rs for some other projects too.

Bah... This seems like exactly the kind of thing that makes dependency tracking, and sandboxing compilation harder.