Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust/WinRT Public Preview

blogs.windows.com

Post reply on HN
Print view View original

151–160 of 219 posts

Re: Rust/WinRT Public Preview

#151

Post by peatmoss »

blinkingled wrote: post #7

https://github.com/robmikh/minesweeper-rs - I just love how they brilliantly avoided mixing up C++/COM things into this. Tough one to pull when you're dealing with bindings for a foreign language. The code looks fairly standard Rust (except maybe for the winrt::import that looks like Go?). > If you are familiar with Rust, you will notice this looks far more like Rust than it looks like C++ or C#. Notice the snake_cas…

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 developers I know cobble together a mediocre Linux-like environment on macOS so they can have a first-class desktop environment and an okay development environment.

On the other hand I read about people using Windows as development environment by using WSL.

I feel like Linux will never organically gain critical mass for a desktop environment—substantial source compatibility with some major platform seems like the way to go. How are the Windows APIs vs the Cocoa APIs these days? Assuming source compatibility could help boost desktop Linux’s fortunes, is Windows or Cocoa a better target? Does consideration of iOS change the calculus?

Re: Rust/WinRT Public Preview

#152

Post by [deleted] »

tambourine_man wrote: post #89
cs702 wrote: post #15

You have to hand it to Microsoft: It may be the only large software company that doesn't seem susceptible to not-invented-here syndrome. It's true that Microsoft historically has been an intensely competitive company, often trying to undermine competing technologies, e.g., with "embrace and extend" strategies. But whenever a competing technology -- whether a language, or a framework, or an application -- gains adopti…

It’s always easy to be an open source proponent when you are the underdog. And Microsoft, as crazy as it sounds to me, kinda is when it comes to cool dev stuff. We'll have to see if they have really changed or just waiting to regain ground and going back to the extinguish part. But what I can confidently say is that, of all the BigCorps, Microsoft is the only one actively trying to make developer's life easier. Apple…

[deleted]

Re: Rust/WinRT Public Preview

#154

Post by jacobush »

wongarsu wrote: post #144
VWWHFSfQ wrote: post #138

Earlier quoted context omitted.

It will be very difficult until Windows is POSIX-compatible. Whatever that means, I don't know. But it can't just be the Windows Subsystem for Linux. The whole OS needs to have POSIX compatibilities.

Windows NT used to have a POSIX subsystem [1] that applications could use instead of the Win32 subsystem. So the Windows NT kernel is designed with the option of POSIX compatibility. Arguably the Subsystem for Linux is the current successor of the POSIX subsystem, providing POSIX compatible access to the kernel along with a POSIX compatible shell and UNIX commands. Obviously the Win32 subsystem isn't POSIX compatible…

That subsystem was just so they could tick off the “POSIX” box for Department of Defence.

Re: Rust/WinRT Public Preview

#155

Post by jdub »

jfkebwjsbx wrote: post #101
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…

What is the point of "In process COM"? Is the same as any other library? I thought COM was meant to communicate between processes? Any enlightenment is appreciated...

It lets you use libraries written in numerous supported languages with a richer, more object oriented interface than a C ABI. You can use the same underlying interface to call out of process or distributed objects.

Re: Rust/WinRT Public Preview

#156

Post by pjmlp »

Koshkin wrote: post #48
blinkingled wrote: post #7

https://github.com/robmikh/minesweeper-rs - I just love how they brilliantly avoided mixing up C++/COM things into this. Tough one to pull when you're dealing with bindings for a foreign language. The code looks fairly standard Rust (except maybe for the winrt::import that looks like Go?). > If you are familiar with Rust, you will notice this looks far more like Rust than it looks like C++ or C#. Notice the snake_cas…

> brilliantly avoided mixing up C++/COM I remember VB6 was also exceptionally good at this.

COM is both an evolution of VBX and a subset of OLE 2.0.

.NET was going to be what UWP is now, an evolution of COM, but then Java happened, and they went with something similar instead.

There are some references to how this all happened in the story of F# evolution, given that Don Syme was part of the team since the early days.

Re: Rust/WinRT Public Preview

#157

Post by rk06 »

mycall wrote: post #148
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…

Is these problems fixed with AOT C# (CoreRT)?

Unlikely, as those problems are coming because of Garbage Collection which is a core part of language. C++/Rust don't have GC, so they don't have those problems

Re: Rust/WinRT Public Preview

#158

Post by pjmlp »

amaranth wrote: post #108
pjmlp wrote: post #25

Earlier quoted context omitted.

Yes it is. After the whole political disaster that was Longhorn, the Windows team decided to rebuilt Longhorn ideas, originally based on .NET, and redo them with COM. So while many outside Windows have considered COM dead, actually since Vista all major Windows APIs have been provided as COM interfaces, the large majority of Win32 surface has been frozen since Windows XP. With WinRT/UA/UAP/UWP they have gone back to…

I think the most similar thing to WinRT on Linux would be GObject Introspection since the main point appears to be a way to somewhat automatically surface the platform API in multiple languages using language-specific idioms. D-Bus is instead for RPC and events, which I guess COM also gets used for?

I guess you are kind of right, then it would be a mix of GObject, KParts and D-BUS then.

As for COM, yes there are multiple models, in-process, external process and across the network (with DCOM).

GObject and KParts would be the in-process variant, with D-BUS for the other execution models.

Re: Rust/WinRT Public Preview

#159

Post by pjmlp »

Ididntdothis wrote: post #34
recursive wrote: post #24

Earlier quoted context omitted.

My only experience with COM (that I know of) was trying to do MS Office automation from C# >10 years ago. I recall that it was very awkward, and somehow prone to memory leaks, and unclosed resources. To this day, I still don't really understand what COM is, or is supposed to be. But I still have a negative visceral reaction.

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.

Re: Rust/WinRT Public Preview

#160

Post by pjmlp »

optimiz3 wrote: post #115

Coding in C++/WinRT (similaly, C++/CX) is in my experience a major mistake when targeting WinRT/UWP using C++. The primary use case for WinRT/UWP is making apps for the Microsoft Store, where most of the time you're going to be sharing code also targeting Google Play and the Apple Store given those markets are vastly larger (and have viable ad-platforms; Microsoft is shutting theirs down on June 1st). The C++/WinRT a…

Just like Qt depends on moc.

GCC and clang are also full of language extensions.

In fact if it wasn't for the work of Google, to this day Linux would only be compilable with GCC C.

I remember C devs on Apple platforms being happy for their lambdas extensions when they were introduced.

So I never understand why everyone else is allowed to create language extensions, but when Microsoft does it is bad.

Post reply on HN