Better JavaScript Promises - <AUTHOR> http://frederic.vanderessen.com/better-javascript-promises/ <comment><USER2> I vehemently oppose this proposal. The syntax of the proposed JavaScript addition is confusing and misleading, and will break more programs than JavaScript's unfortunate `this`.

In particular, the following code snipped, copied from the blog post, goes against everything we've been taught by modern programming languages:

      var a = future;
      var b = a;
      console.log(a,b);   // will print 'hello' 'world'
      b = 'world';        // this does not resolves 'a'
      a = 'hello';

It breaks the concept of variables being references to objects. This is similar to Matlab's treatment of matrices, that none of it's successor languages (Python/NumPy, Julia) emulates.

Furthermore, it's confusing in the way that `a` could mean both (1) get value referenced by variable `a`, and (2) _wait_ until value referenced by `a` is available. I believe that a much better proposal would be to treat futures as a separate data type (`a = future()`), and implement getting and fulfilling the future as method calls (`a.set(1)` and `a.wait()`).

<comment><USER3> Your example illustrates the problem nicely. The code above is impossible to parse without knowing that "future" is a special value. Note that after you assign `a = future` you have no idea that a is special. Separate the code into three modules: the first contains lines 1 and 2, the second contains line 3 and the third contains lines 4 and 5. Now, looking at the second module you have no idea if the execution blocks on `console.log(a,b);` or not.

More importantly, even if all the code is written as nicely as the example above you still cannot reason about this like you could about every other goddamn language out there. You can't pick arbitrary lines of code from the listing and execute them in that order, and if you try to figure out how it works (even if it's written without deadlocks) you will break your brain.

Instead, let's something like $q [1], or even just the smaller/simpler AngularJS implementation of it [2]. While requiring callbacks, it's still very workable and does simplify things. Adding chained callbacks is very nice:

        var resp = $.get('/my/url');
        showLoadingScreen();

        resp.then(function(data) {
            return JSON.parse(data);
        }

        resp.then(function(data) {
            alert('data.username = ' + data.username);
        }

        resp.catch(function(err) {
            alert('Error: ' + err);
        })

        resp.finally(function() {
            hideLoadingScreen();
        })

[1] [https://github.com/kriskowal/q/wiki/API- Reference](https://github.com/kriskowal/q/wiki/API-Reference)

[2] [https://docs.angularjs.org/api/ng/service/$q](https://docs.angularjs.org/api/ng/service/$q)

<comment><USER2> The point is, extending JS to support such constructs _without_ requiring callbacks would be worthwhile, IMO [1]. However, making it obvious with a better API would be necessary.

[1] Note, however, that it would turn JS's threading model completely on its head. Right now, the philosophy of JS is "single-process" threading model, with WebWorkers supporting a "multi-processing" concurrency model by isolating different threads of control. Allowing futures without callbacks would bring JS closer to Golang's concurrency model.

</comment></comment></comment><comment><USER4> Ugh. There are (at least) two fundamental problems here:

First, depsite the ugliness that asynchronous code entails, it does have one very important feature: it never blocks, which makes reasoning about it much easier. This proposal would make it possible for Javascript code to block, which enables a whole class of bugs that were impossible before.

      var a = future;
      var b = future;

      setTimeout(function() {
        a = b+1;
      },0);

      setTimeout(function() {
        b = a+1;
      },0);

      console.log(a, b);

Hello deadlocks!

Second, futures aren't first-class values. The proposal specifies that assigning a future to a variable doesn't create a second reference to the future, it creates a child future that would be resolve by the resolution of the parent future.

Thus, a future must be resolved in the scope in which it's created, or the resolution won't be propagated to all its children. With promises, you dont' have to worry about the side effects of assignment or function calls. Take this common pattern for wrapping an asynchronous call with a promise:

      function promiseMeSomething() {
        var d = defer();
        doSomethingAsyncronous(function(err, value) {
          d.resolve(value);
        });
        return d.promise;
      }

We could do the same with futures:

      function futureMeSomething() {
        var f = future;
        doSomethingAsyncronous(function(err, value) {
          f = value;
        });
        return f;
      }

But that callback function is repetitive, so we'll refactor:

      function makeCallback(d) {
        return function(err, value) {
          d.resolve(value);
        }
      }

      function promiseMeSomething() {
        var d = defer();
        doSomethingAsyncronous(makeCallback(d));
        return d.promise;
      }

But consider the same refactoring with futures:

      function makeCallback(g) {
        return function(err, value) {
          g = value;
        }
      }

      function futureMeSomething() {
        var f = future;
        doSomethingAsyncronous(makeCallback(f));
        return f;
      }

Whoops. This won't work, because g is a child future of f and resolving it won't resolve f.

<comment><USER5> As well, Javascript's single-threaded execution means blocking execution halts your whole program. IMO, the way to tackle complex asynchronous callback code is with smarter code structure and frameworks — just as you should avoid shoe- horning inheritance OOP into JS, you should write async callback code with readability and flexibility in mind (without complaining you "have to" write bad code)

</comment></comment><comment><USER6> The main reason why writing concurrent code in JavaScript is not completely insane (just moderately so) is because of the single-threaded sequential execution model (also known as cooperative threading).

Asynchronous effects need to remain explicit.

Consider a simple example:

        function binary(stack,combine) {
          var a = stack.pop();
          var b = stack.pop();
          stack.push(combine(a,b));
        }

In today's JavaScript, this code executes as an atomic sequence. It turns [..,a,b] into [..,combine(a,b)] and there is no way for another piece of code to step on this function's toes and break this invariant.

What if "combine()" suddenly became asynchronous ? Either because its operation itself is asynchronous, or the evaluation of "a" or "b" involved an asynchronous operation. This would cause the call to "binary()" to pause in the middle of the function, which would give time to another part of your code to call "binary()" in turn. And now [a,b,c,d] has turned into [a + b, c + d] instead of [a, b + c + d], and you'll have a jolly good old time debugging tht.

Make asynchronous context switches implicit and you start needing locking primitives. Everywhere, including third party libraries that "used to work". Because every single line of code(except plain assignment) could be a ticking async-bomb that will pause the current function and let other functions wreak havoc on your invariants.

Scary.

Callbacks are ugly, and promises are hardly better, but asynchronous operations NEED to stay explicit. And explicit asynchronous operations are contagious. That's just what they are.

Just make the syntax less right-pyramidal: C#'s async/await syntax is a good candidate, and 'await' is a good way to mark a possible context switch.

</comment><comment><USER7> ES7 has `async function(){}` and `await call();` syntax proposal that adds the promise/generator trick to the language.

[http://wiki.ecmascript.org/doku.php?id=strawman:async_functi...](http://wiki.ecmascript.org/doku.php?id=strawman:async_functions)

<comment><USER8> This syntax has been borrowed from other languages and is tried and true.

I feel that the author intuited that something like this would be nice, but wasn't aware of async/await and so proposed something that only kind of vaguely points in the right direction. I don't think he's wrong that something like this would be nice, but async/await is a much more robust way of dealing with this!

</comment></comment><comment><USER9> > Unfortunately, using yield based solution will require third party > libraries, which means increased payload and incompatibilities among > frameworks.

Check out co ([https://github.com/visionmedia/co/blob/master/index.js](https://github.com/visionmedia/co/blob/master/index.js)). For all its features it's tiny. Increased payload and incompatibility is a blanket statement; that could apply to any library or framework.

> And I am also quite disappointed that the solution to one of JavaScripts > biggest flaws requires hacking a language feature that was designed for an > entirely different use-case, which will surely bring lots of confusion.

There should be a really high bar for adding keywords to a language. If something can be solved with features we already have, we needn't add another. ES6 generators solves the callback problem for now. There are of course other (perhaps more flexible) solutions, like Scala's futures and for-comprehensions [1], or F# computation expressions [2]. But generators are simpler and they work well enough.

[1] [http://docs.scala- lang.org/overviews/core/futures.html](http://docs.scala- lang.org/overviews/core/futures.html) [2] [http://fsharpforfunandprofit.com/series/computation- expressi...](http://fsharpforfunandprofit.com/series/computation- expressions.html)

<comment><USER10> ES6 adds function* which is basically a new keyword. This is ugly by the way. fortunatly on the server I can use node-fibers.on the client,async libs and promises are good enough,as people ususally dont have to write 10 async operations on a row.

</comment></comment><comment><USER11> Reminds me of call/cc, which amuses me since that's the only (major) feature of Scheme I hadn't yet seen anyone calling for in Javascript (eg. there are plenty, including me, who want tail-call optimisation; I've seen pre-compilers implementing hygenic macros, libraries implementing numeric towers, etc.).

<comment><USER12> I'd like to see TCO in Javascript, but before that I'd like to see some less headache-inducing method of dealing with lots of asynchrony.

I'm not at all sure the method described in the linked article would work as well as said article makes it sound, but I'm definitely in favor of seeing people much smarter than I am argue this one to a finish and then implement the last proposal standing.

</comment></comment><comment><USER13> I don't like this. Even the author's own example shows how this gets very confusing even with simple code:

      var a = future;
      console.log(a);     // will print 'hello'
      a = 'Hello'
      a += ' World!'
      console.log(a);     // will print 'Hello World!'

Deferreds/promises are good exactly because they explicitly state what they are through their type, and they behave the "same" whether they are resolved or not.

This proposal breaks the notion of what a variable is, and it behaves very differently whether the future has been replaced by a value or not. This will become confusing very fast and a great source of race conditions.

</comment><comment><USER14> There is a bug in the author's first example:

var a = future; setTimeout(function(){ a = 'Hello World'; },1000); console.log(a);

If evaluating 'future' returns control to the scheduler, the setTimeout never gets called.

On a higher level, these "flow control" libraries do not, despite their name, control the flow of logic. The underlying asynchrony remains exactly the same. They just make it easier to avoid an indentation avalanche, or callback spaghetti. If and only if spaghetti makes it difficult for you to reason about code will these "flow controls" make it easier to reason about asynchronous Javascript.

<comment><USER11> As far as I understand it, when the "future" keyword is hit it woudn't return control to the scheduler; it would introduce a special deferred value. Control would only return to the scheduler when something attempts to 'force' that deferred value.

You can think of these deferred values as being a getter and setter pair, sharing a reference:

        var future = function() {
            var x;
            return {'getter': function () {
                while (typeof(x) === 'undefined') wait;
                return x;
            },
            'setter': function(val) {
                x = val;
            }};
        };

In the article, future is a keyword rather than a function, and the getter and setter are called implicitly. The idea is that we can pass around references (the {'getter', 'setter'} pair) however we like without triggering any action; however, once the getter is called it will enter a loop, polling and 'waiting' (switching execution back to the scheduler) as long as the setter's not been called.

The radical part here is the 'wait', which I've made up to illustrate the point, and is the crux of the whole thing. It's basically a cooperative multithreading mechanism. This would let an asynchronous API be turned into a synchronous one, since we just need to wait for the result with a polling loop like my example above.

Whether that's a good idea or not is debatable. Personally I think it's a bad idea; shared mutable state is the cause of _all_ concurrency problems (race conditions, locks, deadlock, livelock, etc.) so it absolutely should _not_ be default or implicit. The idea that 'concurrent' == 'multithreaded' needs to die; multithreading is a dangerous anti-feature which uses a little syntax to hide a whole new language semantics, breaking all intuitions about our code and throwing safety properties out of the window.

Thankfully Javascript hasn't fallen into this trap yet; eg. WebWorkers uses message-passing instead.

</comment></comment><comment><USER15> I was thinking the whole way through, "wait, don't generators fix this?" so it was good to see that acknowledged at the end. I'm confused by this, though:

>Unfortunately, using yield based solution will require third party libraries, which means increased payload and incompatibilities among frameworks.

Do you mean that translating to yield requires wrapping things that aren't expecting it? That's true of moving to any non-callback solution. Or do you mean that you want to see the native Node APIs implemented with generators rather than callbacks? I hope the solution to that will simply be patience.

<comment><AUTHOR> I mean the yield by itself is not a good API, it has to be wrapped in third party Deferreds libraries to be useful - there's an (excellent) linked article which explores this approach : [http://jlongster.com/A-Study-on-Solving- Callbacks-with-JavaS...](http://jlongster.com/A-Study-on-Solving-Callbacks- with-JavaScript-Generators)

</comment></comment><comment><USER16> I think what you are looking for is done, to some extent, in angular.js with their resource library. The future object is returned from the resource and can be put directly into a template, which then re-renders when the response comes from the server. The problem I have found is that it does not clean up your javascript code as much as you would think. For example, error handling is still complicated.

I have had good luck using javascript promise objects to clean up complicated async calls.

for example, making multiple calls and waiting for all responses looks something like this:

promise = YourFavoriteAsyncLib.all([new Promise('/restaurants'), new Promise('/shops')]) promise.then(function(res) { // res[0] === restaurants // res[1] === shops });

...or we can wait for one to finish and then make a couple more calls...

promise = new Promise('/restaurant/1');

promise.then(function(r) { return YourFavoriteLibAgain.all([ new Promise('/restaurant/' \+ r.id + '/patrons'), new Promise('/restaurant/' \+ r.id + '/menu') ]); }) .then(function(res) { // do more fun things synchronously });

The details change, and some libraries act a little differently, but once you break they async calls into steps it becomes easy to read.

I think the point of all of these responses is that async cannot look like regular statements because they do not act like regular statements.

</comment><comment><USER17> Genereally speaking async is one of those things that the JS community hasn't quite figured out yet. (Nor has anyone else, really.)

Personally, what I'd really like to see is an M:1 thread model, i.e. a model where you program as if you have M threads of control, but only one of them is actually executing at any one time. Any calls which are currently async would behave as if blocking and would yield control to any other runnable "thread". So you would have concurrency but _not_ parallelism -- which is effectively what you have to reason about anyway when you have async.

It may very well just be me, but I find that reasoning about normal "blocking" flow control is vastly easier in general than reasoning about async flow control even if it involves multiple threads. It gets even easier if you limit all inter-thread communication to some form of queueing/message passing.

EDIT: Reading it back this looks overly convoluted, basically what I'd like in JS is "user-space threads".

</comment><comment><USER18> I would much prefer to see native provision for "channels" and "channelized blocks", _à la_ the core.async library for Clojure/Script:

[https://github.com/clojure/core.async/blob/master/examples/w...](https://github.com/clojure/core.async/blob/master/examples/walkthrough.clj)

</comment><comment><USER19> This is tangential to the discussion, here, but if you want to make 3 simultaneous async requests, it's super easy with promises. Here's an example using bluebird ([https://github.com/petkaantonov/bluebird](https://github.com/petkaantonov/bluebird)):

      Promise.all([async1, async2, async3]).then(function(results) {
        console.log('async1:', results[0]);
        console.log('async2:', results[1]);
        console.log('async3:', results[2]);
      });

or:

      Promise.all([async1, async2, async3]).spread(function(res1, res2, res3) {
        console.log('async1:', res1);
        console.log('async2:', res2);
        console.log('async3:', res3);
      });

With the co library ([https://github.com/visionmedia/co](https://github.com/visionmedia/co)), it'd look like this:

      co(function*() {
        var results = yield [async1, async2, async3];
        console.log('async1:', results[0]);
        console.log('async2:', results[1]);
        console.log('async3:', results[2]);
      })();

Until ES6 is available everywhere, the existing promises libraries are so mature and easy-to-use that I don't really see a problem with them. Bluebird will even promisify an entire module for you with `promisifyAll`, so mixing it with callback-based modules is typically trivial.

I think that even though it relies on the use of third-party libraries like co, the generators solution is much easier to reason about than the proposed solution here.

I can't find the source, unfortunately, but I remember reading somewhere that generators were actually designed with this use case in mind, so the claim that using them for async "requires hacking a language feature that was designed for an entirely different use-case" is false, if I'm remembering correctly.

<comment><USER20> PromisifyAll is awesome... until you realize some code you are using is doing some seriously crazy stuff.

For example, Mongoose takes all of methods on the prototype during object creation and replaces them with ones that run middleware. This means that if you try to use one of the promisified methods, none of the middleware gets called.

<comment><USER21> I made a fix for a mongoose issue that sounds like what you describe and landed it in 1.2.3[1]. Can you verify? And if what you describe is a different issue can you make a github issue? (or is mongoose doing something so crazy that it cannot be helped at all? :P)

[1] [https://github.com/petkaantonov/bluebird/commit/70f90c33dd94...](https://github.com/petkaantonov/bluebird/commit/70f90c33dd944a54d2995ed41f08860cc414f824)

</comment></comment></comment><comment><USER22> Originally I had milder "this could be a problem" objections, but now on my Nth edit I've fallen into "are you _trying_ to drive us all insane" territory.

So here's the (shorter) list of issues, which I'll support later on with code samples:

1\. The new behavior is invisible to most readings of the source code. It's just magic, and unless you've obsessively tracked the magic as it flows, you never know where it might be.

2\. The magic can strike in any place, at any time, and can _throw an exception_ when it happens. Even `a=b+c` is no longer safe.

3\. Even when it doesn't throw an exception, the magic can cause anywhere/anytime pauses and delays. Good luck with that smooth animation function.

4\. The assignment semantics mean that even the equals sign is not safe, and can fuck up my code.

5\. Infinite loops?

6\. Indefinite resolution?

______________

#1:

Should be self-evident. There's no way to know, reading code, whether a variable is a future, unless you backtrack it _alllll_ the way. There are no annotations or markings as it flows.

That would be par-for-the-course in JS and fine _except_ that we're not just talking about another scalar type, this is a whole new beast.

#2:

        future function getCount(){
            raise "OH GOD THE NETWORK IS DOWN";
        }
        var b = 7;
        var c = getCount();

        var a = b + c; // How was I supposed to expect an exception here!?

#3:

        var congratulationAnimation = function(msg){
            // Spend 1 second fading in different UI elements

            var escaped = escapeForHtml(msg);
            // Spend 1 second fading in message

            // Spend 1 second fading in remainder of UI elements

        };
        var msg = getMessage(); // Secretly a future from somewhere
        congratulationAnimation(msg);

        // WTF, why is my animation pausing halfway!?!?

#4:

        var msg = future;
        alert(msg);

        // [...elsewhere...]

        // Store heroic status update
        msg = "Today I beat up a baby";
        msg += " godzilla which was terrorizing a local school";

        // OH GOD THEY THINK I'M A VILLAIN NOW

#5:

        // I have no clue what this'll do.
        var a = future;
        a = 1 + a;

#6:

        // What does this do, break console output forever?
        var f = function(){
            var a = future;
            console.log(a);
        }
        f();

</comment><comment><USER23> I've been actively programming in JS since it was in beta and this proposal seems really confusing to me. I can only imagine what a new programmer would think when they encountered `var a = future`.

And I know this seems petty, and for that I apologize, but... "excape"?

</comment><comment><USER24> If synchronous looking code is switching on demand when IO gets blocked, then isn't this just how other language schedulers work (e.g. python, green threads in Java)?

A few years ago it's what everyone liked about node ...

</comment><comment><USER6> A few years ago, I came up with a similar proposal, though more specifically aimed at making callbacks easier to manage. It was a simple syntax extension, as opposed to new semantics for the language.

You would write this:

        var! x = expression;
        statement;
        statement;

And JavaScript would parse it as:

        return expression.then(function(x) {
          statement;
          statement;
        });

This is obviously shamelessly pilfered from monadic syntax 'let!' in F#, and my own 'let!' extension in OCaml.

</comment><comment><USER25> I have been using Jquery promises with good enough success. And the chaining makes the code synchronous to read.

Improve them slightly add error handling like maybe monad. Yield has done wonders for the delegate allergic people in C# for ages.

We probably should abstain for a while to change the JS language - it is quite messy as it is. Undescore is awesome example how you can extend the language with small amounts of code.

</comment><comment><USER26> Not too sure if I agree with this. I'm glad the author noted that he wrote this prior to knowing about es6 generators.

</comment><comment><USER27> This would be wonderful, especially for people learning JavaScript. When and how to use call backs and wrangling asynchronous code propagation is a major frustration coming to JavaScript from languages that default to synchronous behavior.

<comment><USER15> I'm of two minds on this front. On the one hand, managing asynchronous code in JS is hard. On the other hand, managing asynchronous code _in general_ is hard, and the only difference is that JS makes you think about what it is you're actually doing. I feel like having to make such behaviors explicit in JS has made me a better programmer in other languages because of having had to think through the timing and sequencing issues. It's just like memory management in, e.g., Java - it's not that pointers aren't there, it's just that they're mostly managed for you, and knowing how they work is beneficial to forming a better mental model.

</comment></comment><comment><USER28> I use Q and its asynchronous promises for JavaScript works as promised :) [https://github.com/kriskowal/q](https://github.com/kriskowal/q)

</comment><comment><USER29> > If you ever had to port localStorage based code to IndexedDB you have been > confronted to Javascript's biggest flaw; its asynchronous system is leaky. > Once you have an asynchronous method, every other method that calls it must > be asynchronous as well.

If I was writing localStorage I would use setTimeout or something and make it async from the beginning. You should always assume async when any type of I/O is happening.

<comment><AUTHOR> Yes In deed, but I think it is very unfortunate that JavaScript forces you to make your code more complex than it needs to just because the API might change in the future :/

</comment></comment><comment><USER30> I guess I don't understand the significant advantage this would provide. You can accomplish some of the same functionality with other control flow libraries. Also, I could see the future declaration, with potentially cascading effects, causing as much confusion in the code as callbacks.

The point of Node is that it is asynchronous.

<comment><USER31> The idea of continuations (which promises are) is to make an asynchronous control flow _look_ like it is synchronous, but not _become_ synchronous. More than anything, it is about readability and having a logical flow in the code.

</comment></comment><comment><USER32> ToffeeScript</comment>


Public Flashing: Open Screen Project - <AUTHOR> http://www.adobe.com/openscreenproject/

<comment><AUTHOR> Basically:

"Specifically, this work will include:

* Removing restrictions on use of the SWF and FLV/F4V specifications

* Publishing the device porting layer APIs for Adobe Flash Player

* Publishing the Adobe Flash® Cast™ protocol and the AMF protocol for robust data services

* Removing licensing fees – making next major releases of Adobe Flash Player and Adobe AIR for devices free."</comment>


Announcing Open Source of WPF, Windows Forms, and WinUI - <AUTHOR> https://blogs.windows.com/buildingapps/2018/12/04/announcing-open-source-of-wpf-windows-forms-and-winui-at-microsoft-connect-2018/ <comment><USER2> I hated to see this advice to contributors:

"We will typically not accept contributions that implement support for an OS- specific technolology on another operating system. . . We also do not intend to accept contributions that provide cross-platform implementations for Windows Forms or WPF."

[https://github.com/dotnet/wpf/blob/master/Documentation/cont...](https://github.com/dotnet/wpf/blob/master/Documentation/contributing.md)

Microsoft seems to be actually refusing to accept contributions that could make WPF cross-platform - it's a bit beyond "no official plans for cross platform".

<comment><USER3> Neither Windows.Forms or WPF can easily be made portable, the code is really a thin layer on top of existing Windows services.

I know, because I did this before with Mono, and the changes would be highly disruptive to the codebase.

<comment><USER4> Use Python QT, it is portable. No need to invest time and effort in non- portable GUIs.

And their whole .Net is full of patents.

<comment><USER5> PyQT can be considered a reasonable (and in many ways superior) alternative to WinForms but what about WPF? Is there a modern cross-platform non-browser declarative 2-way-binding MVVM desktop GUI toolkit? I use PyQT mysef but I really wish I could use binding instead of just handling events manually.

</comment></comment></comment></comment><comment><USER6> in Microsoft/microsoft-ui-xaml - Data/Telemetry

 _This project collects usage data and sends it to Microsoft to help improve our products and services. Read Microsoft 's privacy statement to learn more._

 _For more information on telemetry implementation see the developer guide._

[https://privacy.microsoft.com/en- US/privacystatement](https://privacy.microsoft.com/en-US/privacystatement)

[https://github.com/Microsoft/microsoft-ui- xaml/blob/master/d...](https://github.com/Microsoft/microsoft-ui- xaml/blob/master/docs/developer_guide.md#Telemetry)

Looks really easy to disable, but probably something some folks need to be aware of. Love the license and effort Microsoft put into this.

<comment><USER7> Am I the only one who always accepts these kind of "help improve the product" things? I want to help improve the product.

<comment><USER8> So you're why all my products suck!

I do the same.

<comment><USER9> No, that's because companies prioritize short term at every turn ;-)

</comment></comment></comment></comment><comment><USER10> See also Scott Hanselman's (emotional!) post on this: [https://www.hanselman.com/blog/AnnouncingWPFWinFormsAndWinUI...](https://www.hanselman.com/blog/AnnouncingWPFWinFormsAndWinUIAreGoingOpenSource.aspx)

<comment><USER11> > _That means your (or my!) WPF /WinForms/WinUI apps can all use the same > controls if you like, using XAML Islands. I could take the now 10 year old > BabySmash WPF app and add support for pens, improved touch, or whatever > makes me happy!_

that's not interesting. the interesting question is: will there be a SQL Server Management Studio for GNU/Linux?

<comment><USER12> There is Azure Data Studio for GNU/Linux.

<comment><USER13> Yes and there are commercial alternatives as well, e.g. JetBrains DataGrip.

</comment></comment></comment></comment><comment><USER14> This commit is so funny: [https://github.com/dotnet/winforms/commit/a534dd2ebff6792c31...](https://github.com/dotnet/winforms/commit/a534dd2ebff6792c31642348b41b491397ecdfaa#diff-2d4df8d222478e1799aa9928c5069779L426)

<comment><USER15> When lawyers gain access to your source code.

</comment></comment><comment><USER16> While unlikely, I hope one day that the entire Windows operating system will be made open source — I'm not sure how Microsoft would make the revenue work out, but I bet it could be done. And the world would be better for it.

<comment><USER17> Even if Windows is open sourced (which would be pretty cool just to peak in there), there's no way on Earth you'd be able to compile it. I heard a full build takes over 18 hours on insane hardware, talkin 64+ cores.

<comment><USER18> I compiled GCC from source recently - it took several hours on an 8-core Xeon with 64GB of RAM.

Lots of projects take a long time to build, so it's not a show-stopper by any means. I imagine you could also mix precompiled parts with parts you compiled from source too.

<comment><USER19> Normally, it takes a few minutes on 4-core 6 year old i5 ivy bridge to build a cross-compiler for C/C++.

Just not to scare someone off, from building gcc. :] It's fun.

</comment></comment></comment></comment><comment><USER20> Hope Apple is listening, it would nice if I could develop iOS apps without owning, leasing, or remotely connecting to a Mac.

<comment><USER21> You can run osx within vmware: [https://github.com/DrDonk/unlocker](https://github.com/DrDonk/unlocker)

<comment><USER22> Where do I get a macOS license that allows me to run it in VMWare?

<comment><USER23> You gotta buy a Mac...

</comment></comment></comment></comment><comment><USER24> The crossplatform issue already opened, discussed and closed: [https://github.com/dotnet/wpf/issues/48](https://github.com/dotnet/wpf/issues/48)

<comment><USER25> A more realistic approach for a cross-platform WPF might be to start with Mono's Moonlight (as Silverlight and WPF have a lot in common) - this could now be speed up by using parts of WPF.

However in 10 years no one has cared enough to start a project to do this, so I'm not too optimistic.

<comment><USER26> [https://github.com/AvaloniaUI/Avalonia](https://github.com/AvaloniaUI/Avalonia)

</comment></comment></comment><comment><USER27> Very excited to see WinForms and WPF especially hit open source. WinForms is still IMHO the hands-down most convenient way to quickly assemble a GUI for an app, and while Microsoft hasn't given it much love over the years, it's huge userbase will hopefully take advantage of the ability to iterate on it via GitHub.

<comment><USER28> I'm not entirely sure we're referring to the same WinForms but I distinctly remember loving C# in 2009 or so, just when WPF was coming out. But I refused to use WPF for my apps because back then you'd have to force the user to install the latest .net which I thought was too much of a bother.

So I tried using the old GUI framework and boy was it a nightmare to customize _anything_. I remember having to override the default Button class and add like 50 lines of code just so I could get a custom background. This and the fact that C# back then couldn't do high scalability servers were what forced me to learn C++ and in my opinion QT is a much easier library to use than the old WinForms was.

<comment><USER29> > I remember having to override the default Button class and add like 50 lines > of code just so I could get a custom background.

That's mostly because you're not supposed to be doing that sort of thing in the first place. Customizing widgets = inconsistent look and feel. Custom widgets = Inconsistent LAF, inconsistent interaction, no accessibility etc.

The idea of Win32 UI, WinForms etc. is that you have a look and feel dictated by the system, not by individual app developers, with the ultimate goal being not just a consistent look and feel of the whole system (including applications) but consistently applied patterns of interaction. This in turn makes computers easier to use.

Of course, modern UI frameworks, whether in the browser (JS) or outside the browser (QML, UWP, JS, ...) run completely counter to that.

<comment><USER28> That's all well and good but in certain niches you need custom graphics. A good example is gaming, have you seen how beautiful the blizzard client is? Steam is nice too. Users of these apps don't care about a unified experience with the rest of the win32 ecosystem, in some ways these apps are a different ecosystem unto themselves.

I was trying to write a poker client so same thing, using normal buttons just wouldn't have made any sense. It would've been ugly as hell.

Modern UIs stray from a standard because standards are boring and if your app is boring then your not so boring competitor will snatch your users.

<comment><USER30> Your "boring" is a blind persons "basically usable". Standards exist for a reason.

I actively judge apps with non-platform-standard UIs as worse than an equivalent with a standard UI.

<comment><USER31> While I appreciate inclusivity, software isn't just utilitarian, it's also aesthetic. when it comes to aesthetics, slavish adherence to the lowest common denominator is a cancer... By analogy, would you like it if all books were written for a fourth grade reading level because some people can't handle more complexity? Or if the plots of all movies and television shows were simple enough for an idiot to follow?

<comment><USER26> Complexity is not an issue here, though, and in general the "boring" UIs tend to be the more complex ones, in terms of exposing more features etc. It's the custom-made ones that often trend towards fourth grade reading level...

<comment><USER31> Ironically, you got lost in the analogy. I'm not talking about interface complexity, but any intentional deviation from maximal accessibility (at least when it serves an aesthetic purpose).

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER32> So does this mean WPF is alive? Is it sane to develop something new in WPF again?

<comment><USER33> Depends if you subscribe to the idea that open-sourcing something is equivalent to putting it out to pasture.

MS' problem is that Visual Studio is the only "real" software they produce that uses WPF - which also happens to be a flagship product. They need WPF to stay up-to-date but they can't afford to invest their own FTE resources into it either when other products are more important as far as the C-levels are concerned.

I'm curious what this means for UWP XAML - as it has its origins in WPF. Can Microsoft use open contributed WPF code in UWP?

<comment><USER34> OneNote was a flagship WPF software as well. OneNote has announced it's all in on UWP moving forward.

WinUI included in the announcement above is the UWP XAML controls and their "XAML Islands" wrappers, so Microsoft is directly taking UWP open source contributions now, too.

<comment><USER35> OneNote never used WPF AFAIK, Win32 OneNote used the same internal UI framework other Office Win32 apps used (and still use)

<comment><USER34> So far as I'm aware, Microsoft's Ink controls have never had Win32 versions. For a few years they were System.Windows.Forms-only, for many more years they were WPF-only, and now the latest versions are UWP-only. That's a pretty core component part of OneNote. I don't think OneNote was WPF for all of its history, but there was certainly a time where a large percentage of it was WPF, from what I've heard. Which is also why I've heard OneNote led the vanguard to UWP and has been the Fluent Design 2.0 test bed for where Office's Fluent Design is moving, because it was the easiest to integrate UWP controls into the fastest.

<comment><USER35> My understanding is that most everything ink-related in OneNote is custom on top of the lowest-level APIs available. That tends to be Office's MO in general.

</comment></comment></comment></comment></comment></comment><comment><USER36> I expect that WPF and WinForms are still windows-only, correct?

<comment><USER37> Hypothetically, if 10 developers decided to make a WPF fork/patch that would work on linux, would it be a worthwhile project?

<comment><USER38> Would have to wait until like mid-2019, as they didn't open-source everything yet :( Currently only has System.Xaml

[https://github.com/dotnet/wpf/blob/master/roadmap.md](https://github.com/dotnet/wpf/blob/master/roadmap.md)

</comment></comment></comment><comment><USER39> Wouldn't it be better to license them under Apache instead of MIT considering that --presumably-- Microsoft might have some patented stuff in there?

<comment><USER40> Apache has a clear patent grant, but it's also transitive. Folks redistributing a modified library have to grant their own patents. Some customer might care about the distinction.

Also MS's lawyers may not be 100% clear about whether these libraries already include patented technology from other patent holders that MS may have licensed years ago.

MIT punts on the whole issue, so may seem "safer" to a lawyer when used with a giant existing code base. Apache is clearly the right choice for new development (for those who don't like GPLv3, anyway -- let's not get into that argument).

</comment></comment><comment> c-smile Seems like "to Open Source" is another form of saying "to sunset the project" ...

<comment><USER41> It's wrong in general case. Look at Zeit team with their OSS stuffs.

</comment></comment><comment><USER42> Real question: why is WPF worth contributing to, if it can't be made cross- platform?

I've used WPF for about a day, and I never went back to using it. Not 'hating' on it, I just want to understand WPF and the incentives to open source it (I get it for .NET though).

<comment><USER43> many people use windows, and therefore it is useful even if it is not cross- platform

</comment></comment><comment><USER41> Now i understand why MS bought Github. They need to collaborate on their own stuff in a private way by owning it.

<comment><USER44> Why would a company the size of MS host their private repos on GitHub? And open source is open so they don't need to own GitHub for that.

<comment><USER41> Because their private repos are at MS size.

</comment></comment></comment><comment><USER45> I'm not sure if it's applicable, however;

I'd be interested in any association that can be made against previous versions of such libraries, and the newly released open source libraries. Are the 'releases' between the old closed source and that of the newly open source significantly different?

If so, and either way; I'd be interested in knowing what kind of changes were applied in direct action of the source being released. Was it just cleaning/linting of the code? Were there features that were otherwise inappropriate (security? quality?) that needed attention before release.

Things like alignment with child dependency license agreements, or overall quality (in code, testing, and deployment) are things I find extremely interesting. Was there some interesting 'inappropriate' language in the source from developers long gone. Could this have effectively been the opposite spectrum of what happened with event-stream [https://github.com/dominictarr/event- stream/issues/116](https://github.com/dominictarr/event-stream/issues/116)

I'm not explicitly saying it's any of my business. I can imagine a multitude of reasons that this history would never be provided. But... as above.. I can consider reasons, perhaps; it should..?

I don't mean to discourage release. I really appreciate it. Just some thoughts..

Edit: Minor readability

</comment><comment><USER46> I hope this means Paint.NET can now be ported to Linux. Pinta just doesn't cut it as a substitute.

IIRC, while Paint.NET was under the MIT license at that time, porting to Mono was not possible because of the lack of WinForms. Not sure where I read that, maybe here: [http://www.osnews.com/story/22843/Introducing_Pinta_a_Gtk_Cl...](http://www.osnews.com/story/22843/Introducing_Pinta_a_Gtk_Clone_of_Paint_NET)

<comment><USER47> First of all, just being open-source doesn't make Windows Forms or WPF cross- platform and in fact, that's specifically not the goal or focus here.

Secondly, Paint.NET includes quite a bit of non-WinForms/WPF code by now, talking directly to DirectWrite and Direct2D in places and probably other things as well. It's very much a Windows-only application and porting it would require rewriting a lot of important core code of the application.

</comment></comment><comment><USER48> It's nice that they removed all the hacks: [https://github.com/dotnet/winforms/pull/144/files#diff-2d4df...](https://github.com/dotnet/winforms/pull/144/files#diff-2d4df8d222478e1799aa9928c5069779L426)

It reminds me of when the Windows 2000 source code was leaked and it showed how vulgar a lot of the comments were.

</comment><comment><USER49> If, as people here have suggested, that WPF is dead, I now wonder if desktop apps in general are being killed. I liked qt widgets quite a lot but I think that's mostly in maintenance mode. How do these companies expect the end user to interact with the next version of excel, autocad, solidworks, photoshop, etc?

<comment><USER50> Either using a browser, or if wild speculation is to be believed, using a MS fork of Electron (much like VS code).

</comment></comment><comment><USER51> Wow. What's next? Windows itself? What if the next iteration of Windows was based on Intel's Clear Linux?

<comment><USER52> There were rumors of a Winux project at Microsoft that put the Windows GUI on top of Xenix. I don't think it was true. But the idea of moving the OS to a Unix OS goes back to MacOSX. Microsoft could do worse than putting Windows on top of Linux.

<comment><USER53> > Microsoft could do worse than putting Windows on top of Linux.

Start a new OS, along side Windows, based on Linux/Unix.

Make it as stable as Windows for the every-day user, because let's be realistic, even Ubuntu can't manage it.

Ship all new laptops/PCs with this new OS.

Continue supporting Windows/Server for the enterprise.

That would be so awesome.

<comment><USER54> Or better create a new OS with modern technologies, great new ideas and open source it. Linux is nice, but we need some architectural innovation here.

<comment><USER51> There was a research project years ago that wrote an OS in C#. It wanted to be super stable, modern and no cruft. I forget the codename but was hoping it would see light of day.

<comment><USER55> I believe it was the MS Research project Singularity which grew into Midori.

<comment><USER51> That's it! Thanks for the research it was bugging me. Tip of the tongue sort of situation.

</comment></comment></comment></comment></comment></comment></comment><comment><USER56> I think Microsoft is aggressively trying to attract developers to use their products and this is yet another action in that direction. I think it's a good move but I'm far from a conversion. My next OS will be a GNU/Linux

</comment><comment><USER57> This is a pretty minor thing, but with the open sourcing of WinUI, I wonder if there's enough open-sourced that people could try and figure out how to support Dark Mode themes in non-UWP applications?

<comment> c-smile You mean something like this: [https://sciter.com/sciter-4-2-support-of- acrylic-theming/](https://sciter.com/sciter-4-2-support-of-acrylic-theming/) ? (Note, that is not a UWP application)

As of automatic detection check my question on SO: [https://stackoverflow.com/questions/51334674/how-to- detect-w...](https://stackoverflow.com/questions/51334674/how-to-detect- windows-10-light-dark-mode-in-win32-application)

</comment></comment><comment><USER58> Does this mean that WPF apps can be build on Linux and run on Windows?

<comment><USER59> No. It means anyone can now try to port it.

</comment></comment><comment><USER60> Open-sourcing pieces of .NET code --- which is "open source enough" with a decompiler, after all... they didn't bother to obfuscate it and the ExtremelyVerboseButMostlyQuiteUsefullyDescriptive names still remain in the binaries --- seems almost a natural consequence of how the platform works.

But as a long-time Windows programmer, I would liked to see parts of Win32 open-sourced, because it's the _far_ more interesting (and efficient) part of what makes Windows... Windows.

<comment><USER61> ReactOS and WINE both need people to examine the guts of Windows in clean room dissassembly.

</comment></comment><comment> Const-me > are ready for your contributions on GitHub: WPF

Currently, the linked WPF repository is almost empty. Very little code, and not a single .cpp file. WPF's native layer is huge, wpfgfx_v0400.dll, PresentationNative_v0400.dll, etc., lots of complexity between .NET and Direct3D 9.0c.

</comment><comment><USER62> This year does not end surprising me. I have quite positive experience with development in WPF, but I noticed except the SourceTree I can't find any application which looks nice. Do you know any neat-looking application which uses WPF?

<comment><USER63> Visual Studio is written in WPF.

</comment></comment><comment><USER64> Well, let's hope they open source Silverlight next so I can finally upgrade to Visual Studio 2017 when maintaining my apps (that are still in daily use by happy customers).

</comment><comment><USER65> I wonder how hard it would be to write a WPF to Gtk+ adaptor?

<comment><USER66> WPF is really, _really_ declarative, extensible and composable in a way I haven't seen in any other desktop UI framework. And certainly not in Gtk.

I'm not going to say it can't be done, but I will venture a guess that it's going to be difficult and probably a lot of effort.

More effort than simply forking and porting to be X11/Wayland native? Not sure, but I wouldn't dare to exclude the possibility.

<comment><USER67> WPF is built on DirectX, you would probably want to port it to something like Skia.

</comment></comment></comment><comment><USER68> I'm guessing this will be a blessing for Wine

</comment><comment><USER69> It seems they want to get out of WPF and others. UWP probably won't get open sourced.

<comment><USER70> They can't open-source UWP because it's basically a Windows thing.

It's based on WinRT, which is based on COM.

<comment><USER69> You can open source Windows only code. Why not? WPF won't be cross platform either when open sourced.

</comment></comment></comment><comment><USER71> I hope they open source WCF the same way.

</comment><comment><USER72> Sounds like news for Hololens dev since desktop dev is all but dead.

</comment><comment><USER73> This strikes me as ten years too late.

<comment><USER74> It's never too late to do the right thing.

<comment><USER75> It can be. It's useless to apologize to someone who's dead.

</comment></comment></comment><comment><USER76> nice job!

</comment><comment><USER77> WPF is dead. Microsoft is rewriting some of it's apps which used to be native in Electron - OneDrive, Visual Studio Installer,...

</comment><comment><USER78> Why is this important?

<comment><USER67> Because lots of WinForms and WPF developers have been frustrated at the lack of activity on these frameworks. It holds out the promise that even if Microsoft can't be bothered to maintain them then perhaps the community will.

Personally I think it's too little and too late, Desktop development has had its day.</comment></comment>


How generics were added to .NET - <AUTHOR> http://www.mattwarren.org/2018/03/02/How-generics-were-added-to-.NET/ <comment><USER2> I started looking at the source diffs and it triggers a panic attack. That's a ton of work.

All the more reason to admire and appreciate MS Research and the development of C# generics. Really amazing accomplishment.

And Linq is one of the single greatest inventions in modern day programming.

<comment><USER3> Regarding LINQ: I really like certain parts of it, dislike others (mainly inline Select-statements and the EntityFramework built on top of it), but I'd be hard-pressed to call it the greatest invention of any time. PEP 255 laid the ground work for similar language features in 2001, and I doubt that the python guys "invented" all of that out of thin air (cf. Reference #4 in the PEP).

What you can argue is that LINQ made this stuff available to more developers (with useful syntax and in a statically typed language, which also must have taken a lot of work), but filter/map/reduce have been around for quite a while.

That obviously doesn't make it less useful or the underlying tech less impressive though.

<comment><USER4> The magic behind LINQ is that it's a query layer on top of a backing data store. When it first came out, you'd see data providers written against twitter, file system and everything like that. Then entity framework & nhibernate linq provider came out. It was great, hid a lot of details from user, brought static type checking to otherwise very hard to "verify" sql. You'd now think in terms of objects, and not tables.

Linq compiler compiled the whole query into a AST, which you could then convert to a backing query your data store could understand.

To date, I still think Linq was great. I was indifferent to the "sqlized linq", but i liked the lambda quite a lot. It was a nice abstraction and a pretty good language to write queries on.

Disclaimer: I worked on NHibernate Linq integration ~10 years ago.

<comment><USER5> What is your opinion on the state of NHibernate ?

I've started using it in 2009. I am still using it in my projects, but I am still not sure if NHibernate is functional complete or if the project is nearly dead.

It works fine for me (if it is not worth the effort I am using Dapper.net), but it doesn't seem that there is much active development going on.

<comment><USER4> To my surprise, it seems fairly active: [https://github.com/nhibernate/nhibernate- core](https://github.com/nhibernate/nhibernate-core)

I stopped working on nhibernate around 2010-2011, when i started masters. I did only keep in touch with one friend - i am not very sociable person. So I guess short answer is, i am not sure to be honest.

Back in 2008ish, I was thinking it was going to die because Entity framework provided a great support for linq, and it had a great hype. A bunch of enterprises moved away from NHibernate (we also had a lot of legacy from XML configuration - a bunch of internal data structures were referencing xml), so it was clunky. Fabio, Oren (Ayende) did a bunch of improvements, I worked a bunch of shortening initialization times and so on. I think Ayende did a very good job with Linq initially, but there were plenty of edge cases that i remember having to fix :) It was my first opensource project as a core member (second and last was castle project) - so it has a very special place for me :)

<comment><USER5> Okay - it really seems to be quite active right now. Thank you for your insight.

I've used the Linq queries in one of my projects, but I like the QueryOver statements more (a little bit too much black magic in the Linq queries).

But I believe that it was a great effort - so let me thank you for that !

<comment><USER6> In my expereince you shouldn't even touch the black magic stuff unless you're a small org or it's a throwaway app.

Linq with the EF is great for simple queries and updates, anything else and you're in for serious performance problems as soon as the app scales. Better to drop to normal SQL for complicated data loading.

Even MS can't write decent LINQ queries, their ASP.Net identity provider is now the most 'expensive' bit of our app now because they used expensive LINQ queries instead of using raw SQL queries. Admittedly our use-case is abnormal as the specific problem we have is that because of the way users are added their password gets reset almost immediately, as they're invited by an organiser. It also means new users are constantly being added. When the password reset is saved it completely unnecessarily "verifies" the update by making sure the username and email are unique, which means two UPPER()s and CONTAINS()s on string fields. Unlike the old provider there's no usernamelowered field already in the db to avoid this.

We can fix it by over-riding these queries, but it's annoying that the ASP.Net team took a core framework piece that was very performant with fast performing SQL and made it substandard. At least I can look at the code now ;).

<comment><USER7> I've never thought of LINQ as black magic and have scaled some astoundingly complex LINQ queries in a past life. I've even done some things in LINQ optimization that you couldn't do in just "normal" SQL (clever joins of databases on different servers without linked servers; complex client-side caching and statistics work).

I think LINQ gets a lot of flak it doesn't necessarily deserve in complex queries due to people stopping at the black box and assuming black magic. It's a very functional programming paradigm embedded in an otherwise procedural world, and so the skills to debug complex LINQ should be unsurprisingly just a bit different than debugging most else in C#. I don't blame people for stopping at the black box. I just think more people should know that you _can_ do more than stop at the black box.

(Also, it amuses me that your example from ASP.NET identity's changes have nothing to with that it should be using raw SQL queries versus LINQ, and everything to do with denormalization versus the query execution engine. It shouldn't be a huge surprise that Microsoft might trust SQL Server to be able to UPPER() and CONTAINS() fast enough, and the queries rare enough that it isn't necessary to denormalize that information.)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> This surprised me:

> It was only through the total dedication of Microsoft Research, Cambridge > during 1998-2004, to doing a complete, high quality implementation in both > the CLR (including NGEN, debugging, JIT, AppDomains, concurrent loading and > many other aspects), and the C# compiler, that the project proceeded.

I didn't realize that it was less a "must-have" and more of a "research and if-possible" task. I wonder how the .NET framework/languages would have changed if they went with type erasure. Would we even still talking about .NET today?

<comment><USER9> We're still talking about Java, which does type erasure. Oracle has really been phoning it in for many years, and despite that the platform is still going strong. Killing large, entrenched platforms is not easy.

Windows remains 800lb gorilla on the desktop, and C# is Microsoft's recommended environment on it. It's hardly surprising that .NET remains relevant.

<comment><USER10> On large platforms, I am going to piss off people but I'll do it anyway. It's not because a language is widely used that it is a well designed language. Javascript, VBA and php immediatly come to my mind. There are many other reasons for a language to be a heavy weight other than its own merit.

<comment><USER11> This reminds me of Peter Lynch's comment about the stock market: "a voting machine in the short term, but a weighing machine in the long term".

In the short-term, languages with good developer outreach and other factors win. But you don't get things like generics or the .NET TPL without some serious long-term vision. I really do believe well-designed languages win over a long enough timescale.

</comment></comment></comment></comment><comment><USER12> Is already at the beginning of the article, but should be more visibible how MS Research and Don Syme seen the opportunity to add generics (neeeded for F#) and added that. With design already supporting later addition like variance.

Not just the design, the real implementation too in the existing already complex CLR codebase. And that include lot of areas like NGEN, AppDomains, etc, so is no small feat at all, for a production ready framework already used by lot of developers.

I am programming in .NET Framework from v1.0, the v2.0 (with generics) was a clear cut, so is not something you can add too late because it become pervasive in the framework who leverage it in the design (generics in v2.0, LINQ in v3.0, TPL and Async v4.0) As a note, .NET continue to support non generic collections for backward compatibility, but usage is deprecated.

Really interesting piece of .NET history in [https://blogs.msdn.microsoft.com/dsyme/2011/03/15/netc- gener...](https://blogs.msdn.microsoft.com/dsyme/2011/03/15/netc-generics- history-some-photos-from-feb-1999/)

<comment><AUTHOR> > Is already at the beginning of the article, but should be more visibible how > MS Research and Don Syme seen the opportunity to add generics (neeeded for > F#) and added that. With design already supporting later addition like > variance.

I definitely agree, that's why I put it right at the start of the post :-)

</comment></comment><comment><USER13> > Ultimately, an erasure model of generics would have been adopted, as for > Java, since the CLR team would never have pursued a in-the-VM generics > design without external help.

Can someone explain why "in-the-VM" generics design is better than the erasure model of Java?

<comment><USER4> 2 main things:

\- Boxing/unboxing would not be an issue anymore, so you gain performance.

\- Runtime types are enforced: List myList = new List<String>(); myList.add(new Object());

In JAVA, this is ok. In c#, it throws.

<comment><USER14> Testing this, it doesn't throw in C#, it just doesn't compile because you can't declare a variable to be a List without declaring the type with it. If you specify myList as List<String> then it still doesn't compile.

<comment><USER4> For c#, try compiling with IList instead of list.

IList myList = new List<String>(); myList.add(new Object());

</comment></comment></comment></comment><comment><USER15> Does anybody remember the article about their generics implementation in assembly ? How they basically were able to reduce the cost of generics by observing they needed only 3 implementations, by writing specialized versions, one for 8-64 bit values (just one version), and then one for 64 bit pointers, and one for structs (struct passed in by having length and value).

<comment><AUTHOR> > Does anybody remember the article about their generics implementation in > assembly ?

Do you mean [http://joeduffyblog.com/2011/10/23/on-generics-and-some- of-t...](http://joeduffyblog.com/2011/10/23/on-generics-and-some-of-the- associated-overheads/) or [https://blogs.msdn.microsoft.com/joelpob/2004/11/17/clr- gene...](https://blogs.msdn.microsoft.com/joelpob/2004/11/17/clr-generics-and- code-sharing/)

They're 2 articles I came across that covered the low-level details of the generic impl.

</comment></comment><comment><USER16> Did they really have to split the library into generic/non generic? I think Java handled that much better.

It's been more than a decade since I last used C#, so excuse me if I recall incorrectly.

<comment><USER17> I disagree. I think that C# generics are way better. The C# generics are supported at the virtual machine level, whereas Java just pretends to do generics. Java generic types are unknown to the virtual machine since the compiler just compiles a List<Foo> to a list of objects, leaving the VM ignorant of what it really is.

I thought the Java implementation was almost a workaround to avoid the hard work of a true generics implementation.

The fact that C# generics are understood by all parts of the .NET ecosystem makes it so much better and boosts the language to a much higher level than Java.

C# and Java always seemed to be roughly the same to me until C# got generics, and that boosted C# to a much better plane of existence, which was followed by a great deal of innovation such as LINQ, async-await, lambdas, etc, all of which benefit from C# generics.

<comment><USER18> To answer the parent's question: Yes, it was necessary. Doing it the way they did allowed source compatibility with pre-generic or non-generic-aware code. Passing a List<string> to something that expects an IEnumerable works just fine and effectively gives you the Java solution (at a source level) when talking to older APIs! This is why interface IEnumerable<T>: IEnumerable.

>I disagree. I think that C# generics are way better. The C# generics are supported at the virtual machine level, whereas Java just pretends to do generics. Java generic types are unknown to the virtual machine since the compiler just compiles a List<Foo> to a list of objects, leaving the VM ignorant of what it really is.

It is worse than that. Java generics don't work with value types at all thanks to this. A C# List<int> is much closer to a zero-overhead abstraction. It does not box the primitive int values. If Java ever adopts primitive generic types it will break compatibility or introduce massive performance overhead, as touching any non-generic API forces a boxing conversion. Either it negates the reason for type-erasing originally or it eliminates the main benefit of non- boxing value type support (performance).

(I should clarify that Java doesn't have first-class value type support either so this really only applies to primitives)

>I thought the Java implementation was almost a workaround to avoid the hard work of a true generics implementation.

It was a deliberate design decision to retain compatibility between pre- generic and post-generic Java code.

Personally I think that was the wrong tradeoff; there is never a better time to make a breaking change than _right now_. The cost only ever increases with time. It was also clear back then that Java would exist for far longer with generics than without and that far more code would be written in Java post- generics than pre-generics. The result is everyone who uses Java is stuck with limitations and negative performance impacts forever, rather than accepting some short-term pain.

It is also my personal opinion that source compatibility is what developers actually cared about and Sun should have told the stodgy risk-averse big Java houses to suck it up and get ready for JVM v2. It would have been a good opportunity to fix a few other things in the JVM.

C# had the benefit of hindsight in some ways. I'm not sure if Java demonstrates how open delivers inferior results, how bad leadership can impact a project, or just what happens if you pay attention to what "enterprise" customers claim they want.

<comment><USER19> > Personally I think that was the wrong tradeoff; there is never a better time > to make a breaking change than right now. The cost only ever increases with > time.

Yes, but from a marketing perspective breaking with the past is usually not desired. Especially if your product is currently being adopted and is already partially adopted in both hardware and software (which might have been the case when they implemented generics?).

</comment></comment></comment></comment><comment><USER20> If it took 6 years to get generics into .NET, we can't fault the Golang guys for taking their time too.

<comment><USER21> It took them 6 years to do it properly on top of an existing framework with the aim to maintain a crazy level of compatibility.

They did so because they knew the advantages to be massive. And so does everyone else at this point.

That golang decided to forego that wisdom when they started from scratch (and thus create a complex compatibility-story if they were to add it later) is entirely their own fault.

<comment><USER20> So the Golang guys are in the same situation now, aren't they? Isn't it a bit unfair to fault them for not including generics from the beginning?

<comment><USER21> > Isn't it a bit unfair to fault them for not including generics from the > beginning?

No. Because that would be much easier and was the only obvious answer.

They took a shortcut, hoped nobody noticed and later when people started complaining about this obvious omission in a modern language, tried to weasel their way out of with some "complexity" bullshit and how "people wouldn't understand".

So I can fault them for both not including it and then later being disenginious about why.

For this glaring omission the golang designers deserve nothing but ridicule.</comment></comment></comment></comment>


Ask HN: When a VC-backed company folds, who gets paid back first? - <AUTHOR> Sad situation but I have recently resigned from a startup I helped turnaround and bring to profitability.  Unbeknownst to me, there were payables I was unaware of and it was too much to surmount, even with good cash flow.  Aside from being wrecked emotionally (I thought "we did it!"), I am now reckoning what will be the outcome. They currently owe me multiple 6 figures of cash, and I thought I was the only one "accruing", but there are/were plenty of others.
In any case, at the time of a liquidation (due to IP, I think there is a good chance of acquisition) who gets paid back first- Vendors or investors?
Edit to add that I am not an employee but a contractor with invoices for my time. <comment><USER2> It will all depend on your contract and how they raised money. If they raised using debt instruments the investors will have lots of leverage.

In almost all cases (bankruptcy or acquired) your time will be discounted as "insider" (you were helping the turn around) time and you might get some back but it won't be nearly what you have invoiced, unless the company is acquired for a sum greater than the debts. In that case you will be made whole. There are exceptions to what I just said though, and most of that will depend on your contract and how they raised money.

Been on this train myself, it is an interesting situation. Best thing to do is get an attorney early and make sure the appropriate paperwork is in place to secure your spot at the table.

<comment><AUTHOR> very useful, thank you

</comment></comment><comment><USER3> In the US, the company would go through bankruptcy court. It's a court and it _might_ be worth talking to an attorney. But if there's no money, then nobody gets paid and even if there is money, the best likely outcome is some people get a little. Who gets paid first and what is determined by bankruptcy law and there's a priority list that probably starts with the taxman and then secured loans (e.g. the IP pledged as collateral). It's also worth keeping in mind that the people who didn't pay you also had time to engage in other financial engineering...like pledging the IP as collateral for a loan from themselves to the failing company.

Good luck.

</comment><comment><USER4> I've had this happen. You'll get a lot of empty promises. Ultimately, you'll get pennies on the dollar, if anything at all.</comment>


Boeing CEO Vows to Beat Musk to Mars - <AUTHOR> https://www.bloomberg.com/news/articles/2016-10-04/boeing-ceo-vows-to-beat-musk-to-mars-as-new-space-race-beckons <comment><USER3> All competition and politics aside, isn't this what Musk was ultimately trying to achieve? Turning this into a race to be the first one to put humans on Mars ultimately means we're jumpstarting the idea of a multi planetary species, even if it's done for the sake of competition.

<comment><USER4> Exactly my thoughts. The headline "Boeing vows to beat Musk to Mars" literally translates to "Elon Musk wins". His whole goal in founding SpaceX was to foster competition in the stagnant space vehicle industry, just like the Tesla's purpose was to get other auto manufacturers to work on electric vehicles (and to convince consumers that EV doesn't mean it has to suck).

<comment><USER5> Where my cynics at?

Are we really so naive that we're just parroting whatever Musk's PR team says? Musk isn't doing this to further the human race, he's doing it to make money.

<comment><USER6> I don't deny he has done well but I there are a few factors to consider

1\. I would much rather Musk become rich by furthering humanity than someone making the next cat picture app

2\. The companies are tackling some of the hardest problems and I think purely to make money he would have picked other easier problems to solve.

3\. It is shortsighted to not embrace anyone pushing and striving for the important goals for humanity. Energy, transportation, space travel.

<comment><USER5> > 1\. I would much rather Musk become rich by furthering humanity than someone > making the next cat picture app

Agreed.

> 2\. The companies are tackling some of the hardest problems and I think > purely to make money he would have picked other easier problems to solve.

That's not necessarily true. Remember that Musk started with $165 million from sale of shares of PayPal when it was bought by eBay, so he could afford to wait a while for his companies to take off. When you have a large amount of money to invest and you're young, it makes sense to invest in things with a high up-front cost and long wait before you get a payoff--most companies aren't willing to take a risk on that kind of investment, and once it pays off, you own something with little competition and a long head start on your competitors.

And, incidentally, it puts Musk in the position of Silicon Valley's golden boy --which has numerous business advantages.

> 3\. It is shortsighted to not embrace anyone pushing and striving for the > important goals for humanity. Energy, transportation, space travel.

I agree, but we shouldn't do that naively. If we see Musk as being inherently good instead of as who he is, someone trying to make money, we'll be more likely to compromise our ethics because we view him as good.

Imagine a future where SpaceX sets up mines on the moon. This creates a situation where SpaceX has unprecedented control over a subset of its employees--they literally will die without the company's resources, because there aren't other options on the moon. If we naively trust Musk's intentions, we might let this happen without regulation and only add regulation after abuses for profit are discovered--which may be decades too late for the victims of the abuse. But if we realize that Musk is not ethically different from any other CEO, we will have the wisdom to preempt these kinds of problems with oversight.

</comment></comment></comment></comment></comment><comment><USER7> Sure, they could beat Musk to Mars if they succeed in lobbying congress to enact laws forcing SpaceX' accidents to be investigated by the FAA. ULA is railing over losing their exclusive USAF launch contracts and shouting down SpaceX whenever they can, it seems. How about they put their (considerable, federal) money where their mouth is and get us to Mars.

<comment><USER8> What I'm interested to know, is what's in it for both companies - <USER2> notoriety?

It's going to cost billions to reach Mars, and more billions to develop things to a "good enough" point to actually make the round trip feasible - and so far, at least to my knowledge, we've found nothing of enough value to make trips there economically viable for a for-profit corporation.

Sure, they'll get government contracts, but that doesn't pay for the first trip there (which appears will be entirely on their own/investors dime).

There aren't massive gold or platinum deposits we've found - and even if there were, surely it would be difficult to extract and recover due to mass.

I firmly believe Musk is totally willing to bankrupt his company (and himself) to achieve his goal of landing on Mars, but are his investors? What about Boeing and Lockheed Martin (ULA)?

At least with a government landing on Mars, you can expect science to be conducted. What does a for-profit company do there, when there's not much to make a profit from?

What's the end-game here? We land and say "we did it!"... then what?

<comment><USER9> After they have conclusively proven the success of their large launcher with countless launches to get all the equipment and supplies in orbit and the SpaceX mission leaves for Mars what is SpaceX going to do? Sit on it's laurels and wait for the mission to reach Mars? Or maybe allow anyone to launch massive payloads into space on a very well proven platform.

If SpaceX can show they are have a very capable platform for heavy lifting before anyone else they can retain that position for a long time. Moon bases, Hubble replacements, long term space stations all need heavy launch capabilities. SpaceX wants to sell them their premier service.

<comment><USER8> That's an interesting angle I hadn't considered.

Although, wouldn't building a moon base first make more sense? Walk before you can run, sort of thing? Or even Venus, since it's closer.

<comment><USER9> You'd have to convince Elon Musk. Me, I'd go large geosynchronous space station first.

<comment><USER10> Go get a massive asteroid and build a facility out at L1 Lagrange point.

<comment><USER11> L1,L2,L3 are unstable. Better build it at L4 or L5, which are stable.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> I was at the event, and this 'vow' didn't really come off as a vow to beat Musk.

We all know about Musk, but Muildenburg is someone worth checking out. His story is about as classic Americana as it gets. Raised in the midwest. Parents and grandparents were farmers. Trained as an engineer and then went to work for Boeing right out of school... I think he said what he said because he was just trying to share the room's enthusiasm to do big things with our future. Besides, he just might be right, so it might be worth taking a look at him.

</comment><comment><USER13> Competition is a wonderful thing.

<comment><USER14> How can you say that? Cooperation is a wonderful thing. Why is it a good thing that two separate entities, with the exact same goal, are keeping secrets from each other and inhibit the development towards that goal with the only reason being ownership and the ability to withold these technologies from the public? I mean, I get that regular zombies would say that competition is good - but a programmer? Haven't you heard about open source? Geez..

<comment><USER15> Competition keeps corporations consumer-centric due to the need to be the best available option. Competition creates different perspectives and solutions due to the need to innovate to survive. Competition drives people to do their best, due to human nature.

<comment><USER14> Oh, yeah. Corporations are so consumer-centric. Especially Boeing who's been grinding down our atmosphere for decades.

Competition creates one sole perspective: make more money than the others. This gives companies no swinging room to be 'good' instead of profitable. Also, corporations are completely void of democracy and shouldn't be legal.

</comment></comment></comment></comment><comment><USER16> Sounds like he's just saying SpaceX will fail, and NASA will go on the SLS. Bloomberg is trying to manufacture a story that isn't there.

<comment><USER17> My worry is that they are going to make sure SpaceX fails.

<comment><USER18> Who is "they" and how will they "make" SpaceX fail? Boeing has been in the space business for a long time. Why is the news only interesting when it involves an SV darling?

Oh, the conspiracies....

</comment></comment></comment><comment><USER19> Seems like this is a side-effect Musk intended for. Competition of this kind is always positive.

<comment><USER20> Musk is a savvy businessman before anything else. He would prefer to not have competition.

<comment><USER21> Not true as exemplified by his Tesla company releasing the patents to their technology.

He knows he can't do it alone. He's elevating the bar for everybody.

</comment></comment></comment><comment><USER22> Lets hope that it is a promise for innovation and not a threat of dirty tricks. people should not be declaring it as some kind of "Musk victory". These guys do not play fair and have deep pockets.

You can beat Musk to Mars one of two ways:

1) You innovate better/faster than SpaceX and get there sooner

2) You slow down SpaceX by legal/ political/other means until your company can get a lead.

Given all the dirty tricks[1],[2] & possibly [3] that ULA (50-50 partnership Boeing & Lockheed) has played in the past, I would not put it past them to do #2.

[1] [https://defensesystems.com/articles/2014/04/28/spacex- protes...](https://defensesystems.com/articles/2014/04/28/spacex-protest-air- force-ula-contract.aspx)

[2] [http://spacenews.com/ula-vp-resigns-following-remarks-on- com...](http://spacenews.com/ula-vp-resigns-following-remarks-on-companys- competitive-position-strategy/)

[3] [https://www.washingtonpost.com/business/economy/implication-...](https://www.washingtonpost.com/business/economy/implication- of-sabotage-adds-intrigue-to-spacex- investigation/2016/09/30/5bb60514-874c-11e6-a3ef-f35afb41797f_story.html)

</comment><comment><USER23> Boeing has been feeding on the teat of the American taxpayer too long. They've gotten fat and lazy.

This isn't going to happen.

<comment><USER24> Agreed. They don't stand a chance really.

</comment></comment><comment><USER25> Am I the only one who did a double take and Googled it when Boeing was described as "Chicago-based?" Maybe it's just because my parents grew up in Seattle, but I'll always associate Boeing with the Northwest.

<comment><USER26> Boeing corporate HQ is in Chicago. [https://en.wikipedia.org/wiki/Boeing_International_Headquart...](https://en.wikipedia.org/wiki/Boeing_International_Headquarters)

</comment></comment><comment><USER10> To me this is just ridiculous. ULA is so far behind SpaceX. The whole Vulcan engine recovery thing just seems so likely to fail and they have to wait for the BE-3 and who knows how far out that will be.

</comment><comment><USER27> First Mercedes decided they'll be the leader in EVs, then Boeing decides they'll be first to Mars. How will Elon Musk's companies cope with so much imaginary competition? On that note, I've decided I'm going to be a billionaire. I don't know why more people don't choose that.

</comment><comment><USER28> Musk started a competition. Before Space X we would not have see this type of statement from Boeing. I hope other companies get on board. LET THE RACE BEGIN! Yea!! Love it.

</comment><comment><USER29> I see that everyone is realizing the value in this particular PR line, "Mars Ho!". Given the degree of extreme hope I see in the world of intelligent and educated people regarding this issue, I suspect it might work for a while too. At some point though, it's going to become clear that no current group has any real intentions, not to mention clear ideas, to make a Mars colony work.

<comment><USER30> Please, explain to me why your so certain these are empty statements. Im genuinely curious.

If I recall correctly, the first stage of the "moon race" was more generalized, especially to the press. Also Musk himself has a pretty strong history of not sharing much of the meat of a plan till it happens.

<comment><USER29> We knew how to keep people alive on the way to the Moon, alive on the Moon, and had a reliable way back. We didn't start off the race by declaring our intention to colonize the Moon.

So I look at the issues which made Mars 'hard' a while ago, and whether or not they're solved or if Musk is on the way to solving them. Micrometeorite shielding. _Not solved_ Radiation shielding. _Not solved_ Long term microgravity health effects. _Not solved_ Sufficient understanding of the human microbiome to keep it thriving off-world. _Not even addressed_

</comment></comment></comment><comment><USER31> I've noticed articles I regularly submit never get traction then the same article, same link, same title hits the front page. Is this something the Mods are doing? Just wondering.

Case in point I submitted this article roughly 12 hours ago: [https://news.ycombinator.com/item?id=12641840](https://news.ycombinator.com/item?id=12641840)

<comment><USER32> Just timing. For a new story to hit the front page it has to be seen on "new"

<comment><USER31> Except the links are 100% identical, which is why I was asking.

</comment></comment></comment><comment><USER33> I cant help but think that rather than a race against each other, Boeing should be focused on just making this happens. A coalition of support across these companies (and others like Airbus) is surly better for the human race than pure capitalism, in this case.

<comment><USER34> For some reason us humans (speaking generally) get extra motivation out of competition. See: the previous race to the moon.

<comment><USER33> And peace is boring too, so when we're not actually shooting at each other we use the economy as a weapon. This is no different, if only we could evolve to a point where we were better at working together instead of destroying each- others work, we would achieve a lot more in the short time we're on this planet. I get that this isn't reality (today), but when people make statements like that of Boeing's CEO...it just feels like we're not even trying (which i think is rather pathetic).

tl;dr; Jean Luc Picard wouldn't endorse this line of reason.

<comment><USER34> Competing to see who can build a better rocket first isn't destroying each others work (i.e., not even close to the same as war). It seems on the surface that working together instead of competing would be more productive, but have you ever tried to work on a mega huge engineering team? It's generally not more effective than a smaller team. So why not have several relatively smaller teams working on the same thing in parallel, egging (or even cheering) each other on as they go?

</comment></comment></comment></comment><comment><USER35> Space Race!!! Space Race!!!

</comment><comment><USER36> how about beat them but not duplicate the work, let's say send a few living quarters there.

<comment><USER37> I support this plan. If we truly want to establish a colony, we should probably start by picking a suitable location on Mars and sending as many supplies there as possible. There is no such thing as too much food and water.

</comment></comment><comment><USER38> l-o-l

<comment><USER39> Tie fighters on Mars?</comment></comment>


Payday Loans: New laws aimed at payday lenders will end up hurting the poor - <AUTHOR> http://reason.com/archives/2009/09/25/payday-of-reckoning

<comment><USER2> Compared to bank charges, payday loans are cheap... Bounced checks involve no loan and you still get the high fee. And of course, these fees add up very fast. It really sucks to pay $35 on a $2 check that bounces.

Many poor people don't have bank accounts at all. So credit cards aren't really an option.

Further, the federal government has paased so called consumer protection laws that limit peoples power tobdispute credit report errors... Which means more people have bad credit, especially poorer people who are probably less likely to challenge their reports. Many organizations that do not extend credit get to report on credit reports, and a disputed debt that goes tobcollections can show up on a report a half dozen times from different agencies as if they were separate debts!

If government wanted to fight payday loans, a more effective solution would be to make credit reporting companies liable as they used to be, if they report information that they know is wrong.</comment>


Dave Cutler's five-decade-long quest for quality (2016) - <AUTHOR> https://news.microsoft.com/features/the-engineers-engineer-computer-industry-luminaries-salute-dave-cutlers-five-decade-long-quest-for-quality/ <comment><USER4> For anyone interested in the history behind the NT kernel I recommend a book called "Show Stopper!: The Breakneck Race to Create Windows NT and the Next Generation at Microsoft" by G. Pascal Zachary - really enjoyed it.

I think the Windows NT kernel is a very underrated piece of technology - <USER3> reason it was unstable in the beginning is due to a corporate top-down decision: the hardware of the time was limited so they included GDI stuff in the kernel (crappy code not written by Cutler's team).

<comment><USER5> >I think the Windows NT kernel is a very underrated piece of technology - <USER3> reason it was unstable in the beginning is due to a corporate top-down decision: the hardware of the time was limited so they included GDI stuff in the kernel (crappy code not written by Cutler's team).

Err, no. The reason it was unstable in the beginning were choices like having a "MUST SUCCEED" kernel memory pool which caused a bugcheck if the system could not allocate from that pool. Random kernel components allocated from this pool and if you opened too many handles (sockets for example), you'd get a bluescreen because an unrelated driver was trying to allocate memory for some other activity.

There were probably other similar choices that I don't remember now. It _has_ been 25+ years.

And let's talk about the NT Driver I/O model. The most highly complex, over- designed POS I have ever seen. _And_ this design was "polluted" for performance out of the gate (Fast I/O path, for example). It took Microsoft _years_ to reliably and safely cancel pending I/O in the kernel. Remember the days when a random peripheral driver could hold on to an IRP and cause bluescreens all over the place because the process it was doing I/O for exited ? It was hard for internal Microsoft people to write good drivers, let alone OEMs in the wild with a fraction of the learning resources at their disposal.

NT was based on the microkernels that were fashionable in those days (e.g, Mach from Rick Rashid et. al). As with most academic ideas, when microkernels met the real world they had to be adapted.

Win32K came about because GDI performance in NT was crap. There were other things that were similarly pushed into the kernel already. I believe a classic microkernel would also have networking modules in user mode, for example. DirectX in the kernel (hated by the purists back in the day) is inarguably responsible for NT being able to supplant Win9x in the consumer PC market.

The NT kernel evolved over the years to be something that actually met the needs of Microsoft's customers. I would argue that's the real achievement, and not all of that can be laid at the feet of "Cutler's team".

I second the recommendation for "Show Stopper" :-)

<comment><USER6> I can't really comment about mentions on the I/O model or the early instability.

We should give credit to the early architectural decisions made by Cutler which allow for niceties like the Windows Subsystem for Linux (WSL) that came about recently.

I third the recommendation for "Show Stopper" as well. :-)

<comment><USER7> >We should give credit to the early architectural decisions made by Cutler which allow for niceties like the Windows Subsystem for Linux (WSL) that came about recently.

i think most - 99.999% - credit here goes to Linus :) Given the modern power of Linux the WSL would have happened anyway - independently of whether early NT architectural decisions help it or preclude it.

<comment><USER8> For the Linux subsystem, sure.

For the POSIX, Win32, and OS/2 subsystems that existed at the birth of NT, the kernel capability was all Cutler, and Linux was in no position to contribute.

Showstopers explains the NT kernel personalities.

<comment><USER9> I really enjoyed ShowStopper when I read the original release in 1994.

In particular, I really admire the people who worked on that project, because they had a lot of field-tested reasons for the things they were doing.

But the whole subsystems concept basically cleaved the logical domains in a way that was obviously, even at the time when I read it, not going to extend well in the future. While the POSIX and OS/2 stuff can be seen as a kind of hubristic base-covering (the one kernel to end all kernels), it should not have made the cut in a disciplined engineering organization.

</comment></comment></comment></comment></comment></comment><comment><USER10> Three hours of interviews with Cutler for the Computer History Museum:

Part 1: [https://youtu.be/29RkHH-psrY](https://youtu.be/29RkHH-psrY)

Part 2: [https://youtu.be/SVgSLud50ss](https://youtu.be/SVgSLud50ss)

</comment><comment><USER11> When I used to work at Microsoft, my manager (pretty high level person, not a middle-manager) used to tell me: Dave Cutler is one of the biggest assholes in the company and most people don't like him but the company has to put up with him because the cost of losing him to another competitor (like Google) would be too much from competition standpoint.

Given the fact that Dave Cutler would basically be peers with Jeff Dean and Sanjay Ghemawat who had key contributions to multiple fields in the computer science, this makes sense.

Instead of hearing a story by a random Microsoft press corp reporter, or his management (like Steve Ballmer), I actually would like to hear stories about Dave Cutler from his subordinates.

<comment><USER12> What could possible be the purpose for you to tell us that your former boss thinks Dave Cutler is "asshole". There is zero people in the world that need that information.

<comment><USER8> Cutler is famous in his derision of early UNIX.

[https://en.wikipedia.org/wiki/Dave_Cutler#Attitude_towards_U...](https://en.wikipedia.org/wiki/Dave_Cutler#Attitude_towards_Unix)

The quote most often heard is that "UNIX is a junk OS designed by a committee of Ph.D.s."

Showstoppers goes into some detail about his career goal "to get UNIX."

Whether this is is purposeful or not is likely subjective. It is, in my opinion, informative.

<comment><USER12> Are you saying that his attitude towards unix is the same as "being asshole"?

</comment></comment></comment></comment><comment><USER13> Great article about a very significant accomplishment. Few of us get a chance to write an operating system--Dave wrote three. VMS was about as solid as you can imagine.

At the time, I wondered if there weren't too many features in VMS and now NT. But that is always the tension, isn't it?

One interesting fact that the article doesn't cover is that MS had to pay Compaq, interitor of DEC, something like $60 million as the result of hiring Cutler. There are very significant similarities in NT with VMS. All in all, it was certainly worth it.

<comment><USER14> As in, WNT = VMS + 1

<comment><USER13> As in VMS = RSTS + 1

<comment><USER15> You sure you got the joke? V + 1 = W, M + 1 = N, S + 1 = T

<comment><USER13> Ach! I did not.

</comment></comment></comment></comment></comment><comment><USER9> As an aside, since it's getting on time for me to move on from my current employer, are there any companies doing these kinds of hardcore engineering projects any more outside of the defense industry?

I have spent most of my life (until recently) doing systems work (sometimes but not always big-iron embedded) and I kind of wish companies were still investing in ~30 person teams for big engineering projects. I've always wanted to work on a Windows NT ... but no more routers.

</comment><comment><USER16> I find the persimitic locking model of NT handles to a fundamental design flaw in NT. is this something that came from VMS.

Sure the unix model of 'user must handle errors' is a pain, but it leads to more flexibility in the long run.

<comment><USER17> It didn't. I was admin on a VAX 11/780 back around 1980. One day I noticed two directories contained the same files and assumed they were duplicate do I deleted one copy to open up some disk space (we were using RM80 disks). Then I noticed that the files had disappeared from both folders, because they were hard linked.

I was like "oh shit" because they were system files. I called support and they helped restore the files from tape and then I rebooted. So I can honestly say that VMS is very similar to Unix in that respect.

<comment><USER12> Having hard links in the file system has nothing to do with whether handles can be shared.

</comment></comment></comment><comment><USER18> Nitpick, reading this published in 2016:

> At the time, some questioned why Microsoft developed a 64-bit system; today > most computers are 64-bit systems and even our phones will soon have a > 64-bit operating system.

I've had to refresh my memory: the first 64-bit iPhone was released on September 20, 2013. It was "we have 64-bit since almost 3 years ago" for Apple in 2016.

</comment><comment><USER19> (2016)

<comment><USER20> Thanks—added above.

Discussed at the time: [https://news.ycombinator.com/item?id=11504102](https://news.ycombinator.com/item?id=11504102).

</comment></comment><comment><USER21> Dave Cutler is a better OS engineer than Linus Torvalds. Fact.

<comment><USER22> Could you please try to increase the quality of your comments? We're here to learn something substantive, and one-liners don't deliver.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

<comment><USER21> Eh? It was a worthwhile comment written in a tongue in cheek style. Just look at the conversations it spawned.

</comment></comment></comment><comment><USER23> Shame NT is so buried under 12 layers of crap that people write it off and demand that we just go entirely for a Linux monoculture.

</comment><comment><USER24> NT was a huge disappointment. To wit, they've never had a shell that even approximates Unix sh from years ago.

<comment><USER25> Are you kidding? Check out WSL - they've got the full bash working just like it does on Linux.

<comment><USER16> With lots of caveats and gotchas.

See comment from Microsoft guy linked here. [https://news.ycombinator.com/item?id=18783525](https://news.ycombinator.com/item?id=18783525)</comment></comment></comment>