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

211–219 of 219 posts

Re: Rust/WinRT Public Preview

#211

Post by Rusky »

ridiculous_fish wrote: post #210
Rusky wrote: post #197

Earlier quoted context omitted.

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 re…

Hmm. Let's say I install an event handler: Application::Current.OnActivated = move |args| stuff(); and stuff() removes it: fn stuff() { Application::Current.OnActivated = None; } Rust lambdas are not COM objects and are not refcounted. In practice, what prevents the event handler from being deallocated while it is executing?

Right, a Rust lambda is not a COM object on its own, but by the same token you can't just stash one in a COM object's property either- COM object properties don't have a type for "Rust lambda," or "C++ lambda" for that matter.

Instead you need to convert the lambda (from whatever language) into the type of that property- in this case some kind of Delegate, at which point it is ref-counted like any other COM object.

So in this case, installing the handler increments the refcount, reading the handler back out to invoke it increments it again, the handler itself decrements it, and finally whoever invoked it drops their reference and the Delegate gets freed.

Re: Rust/WinRT Public Preview

#212

Post by derefr »

elcritch wrote: post #193
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…

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, t…

Counterpoint: Windows is an Operating System. macOS is an Operating System. But Linux is not an Operating System†.

Rather, individual distributions of Linux are Operating Systems. As are the other Unices, e.g. the BSDs, Solaris/Illumos, all the old ones like IRIX, etc. And all of those, at first, built their own Desktop Environment from the ground up, just like Windows and macOS did.

As it happens, through the power of FOSS, many of these Desktop Environment projects were gradually merged, or the various distributions dropped their own DE in favor of someone else's.

But the historical path-dependence is still there, and the political lines are still mostly clear.

Don't think of KDE as "a Linux Desktop Environment." It's both not just for Linux (you can run it on FreeBSD, too!) and also isn't available for every Linux distro. KDE is still fundamentally, in some sense, "SUSE's Desktop Environment."

Same with GNOME: it might have been created by GNU, but it was mostly funded by RedHat and IBM for many years, even if Debian et al eventually picked it up as well.

Same with CDE: that's HP's desktop environment.

If you think of each of these companies as providing their own Operating System with a GUI composed solely of the graphical applications written for their own DE, the continued non-merging of these DEs makes a lot more sense. There's no more reason for them to merge with each-other than for them to merge with e.g. Android. (These OSes all happen to be based on Linux, but that doesn't really mean anything. macOS is based on BSD; should the macOS DE therefore merge with some DE that runs on BSD?)

† Defining "Operating System" here as "a software ecosystem that tries to deliver a cohesive user experience to the people who deploy it."

---

The thing that makes POSIX DEs different from the ones on Windows and macOS, is that you can install multiple DEs' libraries, and then run applications from one DE "under" another DE.

Except for special one-off internal provisions for their own legacy DEs (Carbon; WoW) you can't run software written for another DE "directly" on Windows or macOS. You can only virtualize such software using e.g. Wine, or an X11 server that runs as a window under your DE.

But the fact that Linux can do this, doesn't mean that the software was designed with this in mind. There's no "Linux integrated GUI experience" that all these applications are trying to target (FreeDesktop is forum for "meet in the middle" consensus solutions to be generated when required, not a working group for creating an encompassing standard for everyone to converge toward.) There's just the individual Operating Systems' GUI experiences (plural), where a given GUI app will fit in with the OS it was written for—and maybe with any other OS that happens to share its DE as the primary DE that the system is cohered around.

tl;dr: there is no "Linux." There's just RedHat, Debian, Canonical, openSUSE, Slackware, etc. all with their own goals. And also FreeBSD, NetBSD, Illumos, and whatever wacky proprietary Unices are still in play, who all also run and support these same DEs on very different substrates, with their own even-more-different goals. Each corporate player delivers you their own experience. There's no intent, between these companies, to try to commodify that experience into the same experience. Where would these companies/projects be, if they did?

Re: Rust/WinRT Public Preview

#213

Post by barrkel »

pjmlp wrote: post #78
barrkel wrote: post #75

Earlier quoted context omitted.

It would have been no good for web application servers, which is where the competition was going. Native would have chased the declining native GUI market.

Sure it would, after all that is where backend development is going to, back to AOT compilation toolchains. If Delphi never managed much on the server side, it has more to do with the downfall from Borland than anything else. So ASP + COM would be ASP.NET with COM+ Runtime instead.

I just don't buy it. Delphi could have done better, but not good enough. I think on its best day it would have had a hard time time competing with Java, much less Python or Ruby, and Rails was on the up as Delphi's .NET strategy was on the wane.

It needed to be an open source cross-platform compiler to be truly viable in the Linux ecosystem, and Linux would be needed to compete with Windows and its licensing fees. Anything other than C# is always a step or two behind on .NET, and .NET was the best route to web apps on Windows.

The only reason AOT is coming back for web apps is FaaS, IMO. FaaS works best with minimal boot-up latency, and FaaS delivers operationally as a way to scale out stateless compute on demand, which optimally means acquiring those compute resources just for the duration of a request or job, and no longer.

Re: Rust/WinRT Public Preview

#214

Post by afiori »

dustinmoris wrote: post #165
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…

> that doesn't seem susceptible to not-invented-here syndrome Really? Compelte opposite from my experience, Microsoft is re-inventing their own version of literally everything, even the smallest thing which doesn't have any strategic benefits. That shows me that they suffer extremely from not-invented-here syndrome. For example, why does Microsoft need to invent their own Redis cache alternative (=AppFabric)? Why doe…

those are product offerings, it is like saying why are there new fast-food chains if McDonald's already exists.

specifically the alternative you list are commercial offerings from other companies, that is just wanting a piece of the cake.

and for example, "internet explorer" is now going to be based on chromium, a terrible news for the web, but definitely a invented-elsewhere case.

regarding Rust a not invented here situation would be trying to develop their own rustc/cargo or a new similar language, sort of like apple with swift (not saying this is what motivated apple)

Re: Rust/WinRT Public Preview

#216

Post by steveklabnik »

Ericson2314 wrote: post #215
steveklabnik wrote: post #196

Earlier quoted context omitted.

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

I thought there was much overlap

My understanding is that there’s a lot of overlap but also stuff that only one or the other can do.

Re: Rust/WinRT Public Preview

#217

Post by [deleted] »

DeathArrow wrote: post #180
jacobush wrote: post #170

Earlier quoted context omitted.

Yeah, that may be true, but on the other hand, had they made it useable, portabilith with other Unix would have been a simpler option. Simpler than Win32 + Unix portability in any case. Or in some cases, software would have been ported to Win32 at all.

>Yeah, that may be true, but on the other hand, had they made it useable, portabilith with other Unix would have been a simpler option. That's not necessarily the case. See macOS which is using different GUI libraries, Metal instead of Vulkan etc. So you can't recompile macOS apps to use them on Linux.

[deleted]

Re: Rust/WinRT Public Preview

#218

Post by fluffything »

sfifs wrote: post #205
fluffything wrote: post #203

Earlier quoted context omitted.

> In my experience, one of the the problems is that Macs are hilariously underpowered for many modern dev and analytics use cases. This is what I do and works perfectly. My dev machines are 82 cores xeon platinums with Terabytes of RAM or nodes with 8 V100 GPUs attached, etc. I don't know of any workstation, much less laptop, that could be a replacement for any of that. For the stuff I do on the laptop itself (Word/P…

Bulk of business analytics and modeling in the world happens in the zone between "regular business laptop" and "82 Core Xeon machines". Laptops with Xeons and reasonably powerful NVIDIA GPUs thrive in that environment.

The CPU and GPU is rarely the problem. The problem is the amount of data to analyze. In a laptop with a 1TB SSD, if I need to analyze 200Gbs of data here and there, I just don't have enough hard-disk space, so I need to SSH somewhere anyways. Once you have to do that, then you might just analyze it there. Bringing it to your laptop makes no sense.
Post reply on HN