LWN: Comments on "A look at Dart"

A look at Dart

Cyberax — Wed, 19 Aug 2020 22:21:27 +0000

The early UWP required basically full rewrite of applications and was hard to use from C++. It's been changed recently by allowing better interoperation with legacy Win32 code (UWP islands) and by untying UWP from the Windows Store.

But this is a bit too late. I can't fathom NOT using Electron these days instead of UWP. It

A look at Dart

zlynx — Wed, 19 Aug 2020 22:17:22 +0000

Windows 7 installs are dying away so resistance to UWP will also.

I prefer UWP to using the old Windows APIs. The problem was not losing support for older Windows versions. And soon no one will care.

A look at Dart

nybble41 — Tue, 18 Aug 2020 12:53:38 +0000

You joke, but I've actually *done* that. With QEMU user mode emulation thrown into the mix to support 32-bit Linux binaries under WSL on 64-bit Windows. Binfmt support was a bit of a pain since WSL skips the usual startup sequence, but it worked (more or less) once I configured it manually.

A better solution, however, is OTVDM[1], which provides a WineVDM-based alternative to the Virtual DOS Machine (VDM) subsystem which was not implemented natively for 64-bit Windows. (This is still a work in progress; I've had better luck with the development version than the latest formal release.)

[1] http://www.columbia.edu/~em36/otvdm.html

A look at Dart

Wol — Tue, 18 Aug 2020 11:12:40 +0000

I've got a working XP vm, but of course the other problem is that Microsoft has shut down the validation servers, so it's impossible (without cracking it) to get a new working copy of XP.

And iirc a decent chunk of software either doesn't work, or doesn't work properly, on XP. For example I have the Terry Pratchett game (which was notoriously buggy :-( and doesn't even work properly on 98!

At some point I need to get a copy of WP6.1 for Windows working again (that, or WP8 for linux, which requires libc5 ...) - unless of course I get a copy of the latest WordPerfect which I bet has had most of the WPisms replaced with Wordisms and is crap as a result...

My wife has some artist program (converts photos into paintings) which again was buggy on 98/2000 and iirc broke completely on XP ...

Cheers,
Wol

A look at Dart

farnz — Tue, 18 Aug 2020 09:28:12 +0000

The problem Microsoft has is different to IBM's problem. WoW works just fine for allowing the OS to be updated without requiring legacy apps to be updated; however, people still write apps for the Win32 API, which is full of design decisions from Win16, which in turn has a certain amount of MS-DOS legacy, and of course DOS has CP/M legacy.

IBM has no direct equivalent - people did write code for CPF as well as for MVS, and they moved from MVS to PC-DOS and/or AIX. Microsoft can't get people to do the equivalent of moving MVS to CPF - when they attempt it, people come up with ways to use CPF stuff from MVS (stubs etc) so that you don't need to migrate.

Now, I'm not saying this is a bad problem to have, but it's a problem for Microsoft nonetheless; they cannot persuade developers onto APIs that replace the misdesigns in Win32, because developers don't move from the Win32 platform onto the new platform. Worse, they include escape hatches like P/Invoke, which developers latch onto and use for core functionality.

It's notable that Microsoft was only able to kill off Win16 entirely by refusing to support it on modern hardware (AMD64), despite it having been deprecated for 10 years by that point. And even then, they had to include a set of compat shims that replaced common Win16 code with Win32 equivalents. Had they not done that, there would be new Win16 code being shipped now, 25 years after Win32 was supposed to replace it.

A look at Dart

james — Tue, 18 Aug 2020 08:40:36 +0000

The rate things are going, we might be able to run 16-bit Windows programs on Wine on Linux inside WSL on 64-bit Windows. And yes, I can imagine that some people might find that useful.

(We can already run 16-bit Windows programs on Wine on x86-64 Linux. It was only Microsoft that took out all 16-bit support on x86-64: the hardware still supports 16-bit protected mode in long mode, just not v86.)

And, of course, there are virtual machines.

A look at Dart

rschroev — Tue, 18 Aug 2020 08:36:51 +0000

> It would be nice if I could run 16-bit Windows on top of 32-bit Windows on top of 64-bit Windows 10, so all my old applications would run. I've got a fair few Win95/8 (and even earlier) programs which it would be nice still to be able to run

I regularly run some old 16-bit software in a 32-bit Windows XP VM (VirtualBox) running on 64-bit Windows. It's not a perfect solution (not as seamless as native support would be, and it requires a copy of Windows XP) , but it works.

A look at Dart

Wol — Mon, 17 Aug 2020 22:02:59 +0000

> This means it's hard to replace Windows, because you need to handle all that legacy, but it's also hard for Microsoft to evolve the Windows platform, because that runs the risk of breaking legacy stuff.

Didn't IBM solve that problem 50 years ago? Or was MS's attempt at WoW (Windows on Windows) a failure?

As I understand it, IBM CICS runs on OS/360, which runs on OS/370, which runs on ...., which runs on the latest z900 hardware ...

It would be nice if I could run 16-bit Windows on top of 32-bit Windows on top of 64-bit Windows 10, so all my old applications would run. I've got a fair few Win95/8 (and even earlier) programs which it would be nice still to be able to run.

Cheers,
Wol

A look at Dart

Cyberax — Mon, 17 Aug 2020 17:49:19 +0000

UWP is kinda in a zombie state. It was not successful in moving existing applications off the Win32 API and for some unfathomable reason nobody wanted to create new applications targeting UWP.

Microsoft has shifted strategy last year, and they are pushing UWP across multiple platforms (including iOS and Android). But it's too little too late.

A look at Dart

jem — Mon, 17 Aug 2020 17:25:05 +0000

>It looks like they've finally succeeded in separating "legacy" from "modern" with Universal Windows Platform, and are now in a position to evolve UWP ignoring the legacy Windows side, but it's something they've been trying to do for a long, long time.

Or did they succeed? Googling for "UWP dead" gives 1.5 million hits. Apparently it wasn't that popular among developers. Sometimes I get the feeling Microsoft doesn't even care about Windows anymore. Look at YouTube videos from Microsoft's *own* events, where their *own* people are doing presentations using Macs. Even high-profile apps like Microsoft Teams are built using Electron, not .NET.

A look at Dart

farnz — Mon, 17 Aug 2020 12:26:22 +0000

Microsoft has a platform problem of its own; Windows is only the foremost platform because it's the one where all your legacy stuff will run. This means it's hard to replace Windows, because you need to handle all that legacy, but it's also hard for Microsoft to evolve the Windows platform, because that runs the risk of breaking legacy stuff.

Remember that the legacy platform has design decisions embedded into it that are now hard to change, dating all the way back to Windows 1.0 atop the 8086/8088 in 1985; they know that some of those decisions are now hurting, but they can't fix the legacy platform without breaking legacy apps, which gives them problems. .NET was one attempt to have a new platform for "modern" code, while letting the legacy work as-is, with the added bonus for Microsoft that it's easier to port .NET apps from x86 to IA64/ARM/other ISA. It looks like they've finally succeeded in separating "legacy" from "modern" with Universal Windows Platform, and are now in a position to evolve UWP ignoring the legacy Windows side, but it's something they've been trying to do for a long, long time.

A look at Dart

jem — Mon, 17 Aug 2020 10:58:01 +0000

Pot calling the kettle black? C# is the mother of all NIH languages.

I have always wondered why C# wasn't an AOT language from the start. MS copied the VM idea from Java, but why? Sun wanted to control the platform, but their Solaris was losing to Windows, so they created a platform on top of the existing operating systems. But Microsoft already controlled the platform (Windows).

A look at Dart

re:fi.64 — Thu, 13 Aug 2020 07:46:52 +0000

Worth noting that Dart's type system is strict and provably sound, with null-safe types in public preview.

Personally, I like it a lot because it has a lot of nice features without being incredibly complex or awkward. It's a bit hard to describe, but I personally see it as a "greater than the sum of its parts" scenario: stuff like having a sound type system, solid stdlib, sane package manager, incremental and reproducible build system with easy source generation, JIT for development, AOT for deployment, a graphical memory observer, ... These are all things other languages can do, but few can do them *all*. In other words, it's relatively unexciting at a glance, but is super easy to pick up and plain works well in practice.

Why Dart?

saadk — Mon, 03 Aug 2020 05:29:50 +0000

While I enjoyed seeing some examples and the overview of some of its features, the article falls short of explaining why readers should look at Dart and what makes it really stand out in the overcrowded programming language landscape. If you use Flutter, Dart is a must. But apart from this, how and why Dart is a better or interesting alternative for other languages?

I'm sure it has its niche

gus3 — Fri, 31 Jul 2020 02:13:46 +0000

The syntax is generally C-like, but it has Python-inspired things like iterators and scoped exceptions. To my un-informed eyes, it really looks like a mix of the best features of each language.

A look at Dart

koh — Fri, 31 Jul 2020 00:31:17 +0000

What does strong typing mean? Are the "primitive conversions" still allowed to be implicit, e.g. int <-> double? I read that at least strings need to be .parse()'d.

A look at Dart

Cyberax — Thu, 30 Jul 2020 18:20:23 +0000

How does it compare with TypeScript?

A look at Dart

pjbrooke — Thu, 30 Jul 2020 17:55:01 +0000

I've found it a useful language for web and mobile development. I particularly like the strong typing and the compiler messages on error. I'm far more productive in Dart than just writing plain JavaScript.

A look at Dart

evgeny — Thu, 30 Jul 2020 15:24:06 +0000

This would not be a general answer, but in my case, I learned Dart because of Flutter - which is among very few choices if you want to build an opensource app that works both in Android and iOS.

Admittedly, learning (or better say, getting familiarized with) Dart is only a small part of that route...

A look at Dart

kjp — Thu, 30 Jul 2020 13:51:16 +0000

Well, the article showed me that I'm never going to care about yet another Google NIH language. C#/mono can compile full AOT or partial AOT.

A look at Dart

ncm — Thu, 30 Jul 2020 09:55:41 +0000

Agreed, it is hard to understand where learning and using this language would benefit anyone.

A look at Dart

koh — Thu, 30 Jul 2020 00:11:09 +0000

Sorry to start with a negative comment; however, the article itself seems to rather onesidedly focus on promoting the language without indeed informing the reader about it. Sure, examples are nice and specific domains are nice, but is it bringing any benefit to the current landscape of programming languages? Are there features that make Dart stand out? Byte-code compilation is old, the non-executable "ahead-of-time" binary seems quite useless if there's byte-code / the requirement of a runtime, LLVM can compile everything it has a frontend for to JavaScript, it brings an own package manager (like quite a few languages before)...

What about downsides of Dart? Isn't runtime dependence and (seemingly, since the comparison with C came up quite often) non-strict typedness the combination of the worst features of the languages we currently have? Does it include features not found elsewhere or is it really about its standard library mix providing stuff "around the needs of user interface creation"?