Bare Metal Assembly Raspberry Pi Starfox Tribute - <AUTHOR> https://www.youtube.com/watch?v=-5n9IxSQH1M <comment><USER2> Great work, it's always nice to see more Asm projects!

"Bare Metal" \- does this mean the RPi can run blob-free?

A possible improvement I suggest is to gfx_draw_line in gfx.s - using a fixed- point algorithm could be simpler and faster: [http://hbfs.wordpress.com/2009/07/28/faster-than- bresenhams-...](http://hbfs.wordpress.com/2009/07/28/faster-than-bresenhams- algorithm/)

<comment><USER3> Thanks for the feedback!

Even though the game does not need an operating system, it still requires bootcode.bin and start.elf.

The fixed point version of Bresenham's algorithm looks really nice on x86, but it uses integer division, so implementing it on an ARMv6 (no div instruction) would be quite painful.

<comment><USER4> That reminds me of good old days of 6502 assembly and implementing bitshift based multiplication and division yourself.

<comment><USER5> Absolutely. I'm surprised that having to work around no 'div' is seen as painful compared to writing the rest of the game using 3D in assembly !

Learning on 6502/Z80 meant most everything was from first principles, and although I'd hate to regress so far today (head would hurt) it really was a great way to start.

</comment></comment></comment></comment><comment><USER6> This is extremely impressive - well done all!

There is a bare metal chess game [0] for the Pi that was presumably another teams entry for the same assignment (they are both from Imperial).

[0] [https://github.com/xu-ji/assembly_chess/](https://github.com/xu- ji/assembly_chess/)

<comment><USER7> Yes, it looks like it - they would have completed the assignment last year.

</comment></comment><comment><AUTHOR> Github: [https://github.com/ICTeam28/PiFox](https://github.com/ICTeam28/PiFox)

</comment><comment><USER8> I'm impressed first year students can write such clean assembly. Also that they can write both driver code and a higher level rasterizer.

<comment><USER9> Why so? I was already looking at Assembly listing at the age of 12.

When I was 16, I enjoyed using higher level languages but the real fun was doing Assembly.

Kids these days real need to get some of this exploratory desire back.

<comment><USER10> Fully agree - children have amazing capacity to learn complex things. It's one reason why I'm nervous about code clubs using Scratch; the children can cope with more, so why limit them?

</comment></comment></comment><comment><USER11> Wow that brings back memories of building games on a TRS-80 Model I in z80 assembly!

Good show, I've often felt low level was a dying art, perhaps I'm wrong and stuff like this will push people to learn what a register is and what "flags" are.. :-)

</comment><comment><USER12> Very impressive. How things have changed - we did nothing quite so fun and practical in first year computing at Imperial back in 1995! Plus, now I feel old :)

</comment><comment><USER13> A welcome return to the Acorn/RISC OS days where "100% ARM assembler" was a back-of-the-box boast for many games and applications (Sibelius).

<comment><USER9> Not only Acorn/RISC OS, but all 8 and 16 bit home systems.

The main issue is of course portability, but I had lots of fun with Assembly during that timeframe.

Do you know how RISC OS fares in the Raspberry PI?

<comment><USER13> I haven't used it yet, but it seems to be faring okay.

[http://riscpi.co.uk/sales- riscospi/?doing_wp_cron=1403977657...](http://riscpi.co.uk/sales- riscospi/?doing_wp_cron=1403977657.5454409122467041015625)

You can also download RiscPC or Archimedes emulators, e.g.

[http://www.marutan.net/rpcemu/](http://www.marutan.net/rpcemu/)

</comment></comment></comment><comment> slipstream- Oh wow. This is awesome.

And here I am sitting here, with little x86 asm and z80 asm knowledge, reversing windows binaries and messing with Pokémon arbitrary code execution exploits. (optimizing my payloads for the 8F/"ws m" exploit is fun though!)

Been meaning to learn ARM asm for some time, but haven't got around to it.

</comment><comment><USER14> Looks like there's a tiny little emulator for this, too.

[https://github.com/ICTeam28/PiEmu](https://github.com/ICTeam28/PiEmu)

I've got as far as installing the SDL headers (you're looking for SDL.h from SDL 1.2) and running cmake . but not much further.

<comment><USER15> Hey, I'm part of the team who wrote this. What platform are you running on? and what errors are you getting?

<comment><USER14> Hey, congrats on this project.

Mainly I was waiting to reboot into Linux to try to build this.

You may want to add some instructions for building the game/emulator.

For the emulator, I'd never used cmake before (sort of) so I didn't know to run cmake .

Then the error about SDL (needed libsdl-dev package or similar)

For the game, I'm currently downloading a Linaro ARM toolchain on a slow connection but I don't anticipate any further issues.

<comment><USER15> Thanks! It currently only works on Linux, so depending on your distro, you need to install the SDL package. If you're using Debian or Ubuntu (or derivatives), it will be sufficient to install the libsdl-dev and cmake packages using apt-get. Then create a build directory and use CMake to generate makefiles then build the emulator with make.

To set up the build environment, follow these instructions:

       cd /dir/to/PiEmu/
       mkdir build
       cd build
       cmake ..
       make

These instructions are also on the README.md for PiEmu in-case anyone else is wondering how to get it building.

<comment><USER14> To add to this, the latest "official" Raspberry Pi toolchain is at [https://github.com/raspberrypi/tools](https://github.com/raspberrypi/tools). You probably want the one _without_ hf in the name.

serialvelocity - am I correct in assuming you're building for softfp?

</comment></comment></comment></comment></comment><comment><USER7> I have to say, this assignment in general has been my favourite part of first year (my group extended our assembler to look enough like GNU as that we could assemble the output of GCC, so we could compile CSUD).

Nice work - love it (might play it at some point to see if I'm any good).

</comment><comment><USER14> Looking at this project, I feel very very very dumb. I've been using computers for 2 decades and programming for 1 and I can't even imagine doing something like this!

<comment><USER16> Reading this comment made me very very sad. I've been programming computers for over 3 decades, and this is how we _started off_ in my day. The "MyComputerification" of IT education during the 90's has a lot to answer for...

<comment><USER14> Don't worry, I'm currently writing a FAT32 reader from scratch and slowly making my way through a Peter Norton assembly tutorial from the 80s...

My day job, on the other hand is nearly all web dev and admin work.

</comment></comment></comment><comment><USER17> Nicely done! I remember getting the original game for Christmas one year as a kid, and it was lots of fun. This brings back memories. Kudos!

</comment><comment><USER18> This is amazing! -Shea</comment>


James Fallows on the vulnerabilities of the cloud after wife's Gmail is hacked - <AUTHOR> http://www.theatlantic.com/magazine/archive/2011/11/hacked/8673/2/?single_page=true

<comment><USER2> From the article: "if you use Gmail, please use Google's new "two-step verification" system. .... This is not an airtight solution, but it can thwart nearly all of the remote attacks that affect Gmail thousands of times a day."

Here's more information: [http://www.google.com/support/accounts/bin/static.py?page=gu...](http://www.google.com/support/accounts/bin/static.py?page=guide.cs&guide=1056283&topic=1056284)

This additional protection will radically improve the security of your account against hijacking.

<comment><USER3> What happens if i change my phone number? Whats the process when i do that?

<comment><USER4> I only use the SMS option very, very rarely. Usually I use the authenticator Android/iPhone app.

</comment></comment></comment><comment><USER5> 1\. Backup your emails with Thunderbird and put them on an external hard drive encrypted and/or encrypted on an online backup service, like Dropbox or ADrive.

2\. Backup some of your other Google data with Takeout: <https://www.google.com/takeout/> Use 2-step authentication as well.

3\. Passwords? Use Keepass/KeepassX or LastPass. Generate new random passwords using the generate password feature. You could technically reuse passwords for accounts that aren't sensitive, but with those password managers you don't really need to, especially since they both support search. Backup them up like you did with emails (external hard drive encrypted and/or encrypted on an online backup service, like Dropbox or ADrive.)

4\. Master password? Try passphrases (<http://xkcd.com/936/>) or (for a slightly weaker option) use the initials of the words of part of a song, phrase, or something you can remember that isn't too common. It should be at least 10 characters long. Add memorable symbols or numbers for bonus credit.

5\. On Windows? No Anti-virus software? GET SOME.

6\. Don't enter your passwords on public computers. In fact, I wouldn't even access any private data on a public computer.

7\. Don't tell your friends/family what your passwords are. Should be obvious, but not always so.

8\. For Pete's sake, DON'T WRITE YOUR PASSWORDS DOWN ON POST-IT NOTES! and don't store them in unencrypted files. Really, this is a bad idea.

Even if you follow all the above, you still need to use common sense online when it comes to security.

<comment><USER6> Number 8 is overrated, it requires physical access to the password and is less viable than any pure online attack. See [http://www.schneier.com/blog/archives/2005/06/write_down_you...](http://www.schneier.com/blog/archives/2005/06/write_down_your.html)

</comment></comment><comment><USER7> I've said this before, and I will say this again.

 _Email is a service worth paying for._ It is quite possibly _the_ primary method of official communications between you and anyone else these days, far surpassing the volume of paper correspondences you have.

So why are we using free services that offer no guarantees, no SLAs, and no support - for anything other than throwaways accounts?

I run my own server, but this is hardly necessary for the majority of the world. What you _do_ want is a server that backs you up constantly, and can respond to _precisely_ issues like these.

<comment><USER8> Okay. So who is offering a service that can match Google's offering? In particular, they need to offer a good (ie, at least as good as Google's) webmail client and spam filtering.

<comment><USER9> I use www.fastmail.fm (owned by Opera) and can't recommend them highly enough. For a family or small business it's great as you can have shared folders/address books, use your own domain(s), and more.

The web mail doesn't include tagging or inline conversations but otherwise it's pretty good with not too much wastage. Of course you also have IMAP/POP access if that's your flavour.

<comment><USER10> Another happy fastmail user here, of about 9 years. Agreed, it's worth paying for.

</comment></comment></comment></comment><comment><USER11> Repeat of this thread

<http://news.ycombinator.com/item?id=3122798>

</comment><comment><USER12> _"For reasons too complex to explain here, even some systems, like Gmail's, that don't allow intruders to make millions of random guesses at a password can still be vulnerable to brute-force attacks."_

Anyone care to explain?

<comment><USER13> I don't know what he means here, but one possible way to brute force would be to iterate the username and not the password. It depends on what you're trying to do, but if you just want accounts you pick the top X number of passwords used then get a list of usernames and a healthy collection of proxies. As long as your list of usernames and proxies are long enough you should be able to brute force your way into a lot of accounts.

</comment></comment><comment><USER14> Anyone else have a few issues with this story?

1\. Thinking that Google owed them a higher level of customer service for a free account. They're already offering a much better email system than almost anywhere else, for free!

2\. Letting the backup email address expire.

3\. Not backing up important messages. You can't leave backup to other people regardless of who they are.

4\. Not using two factor security for an email account with so much important data.

5\. Sending important personal data over email?? "At some point over the past six years, our correspondence would certainly have included every number or code that was important to us" WTF? E-mail, regardless of the provider, is not secure! Why would you send these things plaintext across the Internet??

6\. He alludes to the fact that his wife's info may have been on the Gawker release. . . and they were just hacked now??

Granted. . . maybe we cannot expect a nontechnical consumer to know these things. So how do we get them up to par? (edited for formatting)</comment>


For modern development Javascript indeed is a shit language - <AUTHOR> http://live.julik.nl/2013/05/javascript-is-shit <comment><USER2> Despite most of the points in this post being debatable — there's one bit that caught my eye:

        "Being nice will not help it, and CoffeeScript is not radical enough."

As the guy who started CoffeeScript, I agree. It's an intentionally very conservative approach. But there's more than one good way to skin the JavaScript cat. I think it would be fun to take another run at the same problem — attempt to find a minimal, readable, and easier-to-learn language that fits in the same role as JavaScript — but to do so with a _much_ more radical design. Whereas previously such a thing would have been unusable in practice, having good sourcemap support in most browsers these days makes it viable, perhaps. I've been playing around with it a bit...

<comment><USER3> CoffeeScript was obviously inspired by Ruby. While CS is great, I've never gotten over the usage of "->" or "=>" to signify a function. To me, Ruby's "def" or "do" reads so much better. Especially with "end", to signify a barrier, as opposed to whitespace. Have you considered porting Ruby directly to JavaScript?

By the way, thanks for your work on _ & Backbone!

<comment><USER2>
        > Have you considered porting Ruby directly to JavaScript?

No. It's been attempted before, and it doesn't turn out to be terribly useful in the end, because of the _vast_ semantic mismatch between the two languages. See: [https://github.com/jashkenas/coffee-script/wiki/List-of- lang...](https://github.com/jashkenas/coffee-script/wiki/List-of-languages- that-compile-to-JS#ruby)

        > I've never gotten over the usage of "->" or "=>" to signify a function.

Give it a try, perhaps. It's _critical_ not to use "def" and "do" when your functions are first-class values that can be passed as arguments, or assigned to variables. It's for this reason that Ruby 1.9 has a new lambda syntax that looks a great deal similar to CoffeeScript's. For example:

        request(url, def callback(response) do
          ...
        end)

... that kinda thing is no good.

The reason it's an arrow is because in any decent function, the input determines the output, eg. input points to output. And therefore, the CoffeeScript syntax: (input) -> output

<comment><USER3> >> it doesn't turn out to be terribly useful in the end

True, I'd chose CoffeeScript over Opal.

>> Give it a try, perhaps.

Oh, I dig it, especially the fat arrow.

>> It's critical not to use "def" and "do" when your functions are first-class values that can be passed as arguments, or assigned to variables.

Still, I find "def" to be more `readable` than arrow symbols. I'm not sure how JavaScript's first class status for functions would deter a keyword containing letters. Considering JavaScript itself uses _function_ as its.

>> The reason it's an arrow is because in any decent function, the input determines the output, eg. input points to output. And therefore, the CoffeeScript syntax: (input) -> output

That definitely makes logical sense. Still, I feel the readability might be increased by using words, which the mind is more attuned to quickly applying meaning to.

Edit: Great job, on CoffeeScript, regardless!

</comment></comment></comment></comment><comment><USER4> Sadly I agree, you can just start with this:

        > [1,10,5,-15,-2,4].sort();
          [-15,-2,1,10,4,5]

And yes saying "oh but it is because it has weak types" doesn't excuse it, it is broken and that's that. Naming the brokeness with a label or showing why historically it is there, doesn't fix it.

On the other hand they do have nice closure support, I do like some of that. But in large, the language makes me angry every time I have to use it.

Someone mentioned Dart, I am hopeful for that. But who knows how long till dartvm is embedded in Chrome. For now dart.js and source maps might help.

There is a bit more palatable Coffeescript. But it only puts some band-aids over JS's brokenness.

Also agree with callback hell. It is funny people extol is at the next big thing -- whoo, asynchronous calls! You can callback in your callback while you callback. No, no, no. That is a horrible way to handle large concurrency problems! (Good for quick one page examples though!). Async and friends help. But why the heck do I need to stick a callback in the middle of my logic if all I need to do is make a request to the database or another GET request?

The only sane way I know how to best handle concurrency is using a language with support of goroutines/isolates/tasks or even threads and queues. Even deferreds are just sugar on top of callbacks. We all know how Python's Twisted has taken over the world, right? Oh wait, it hasn't. Calling them Futures or Tulips or whatever doesn't fix the underlying problem.

> I can understand that some people wanted to escape the MRI infrastructure by > going Node, because - you know - learning Japanese is hard.

Granted node is fast. (And according to its author scales linearly across CPU cores, sorry couldn't resist the mandatory jab at that). Ok it doesn't really scale across cores and it will block everything if you do a for loop in the middle of your logic. But it is really fast, amazingly so. And that is like crack. It gets people hooked.

EDIT: JS has weak types not just dynamic, one can have dynamic and strong types for example, like Python ( [https://en.wikipedia.org/wiki/Weak_typing](https://en.wikipedia.org/wiki/Weak_typing) ). Thanks makslinn.

<comment><USER5> > And yes saying "oh but it is because it has dynamic types" doesn't excuse it

It has _nothing_ to do with dynamic types[0]. It has to do with

> If compareFunction is not supplied, elements are sorted by converting them > to strings and comparing strings in lexicographic[0]

period end of the story. You might argue it's a shitty default, but please argue against reality, not what you (wrongly) believe it is.

[0] this is the MDN translation, the exact specification is steps 14 to 18 of the SortCompare abstract operation, defined in ECMA-262 5.1 22.214.171.124 "Array.prototype.sort (comparefn)":

        13. If the argument comparefn is not undefined, then
            a. If IsCallable(comparefn) is false, throw a TypeError exception.
            b. Return the result of calling the [[Call]] internal method of comparefn passing undefined as the this value and with arguments x and y.
        14. Let xString be ToString(x).
        15. Let yString be ToString(y).
        16. If xString < yString, return -1.
        17. If xString > yString, return 1.
        18. Return +0.

[0] your edition to "weak types" is just as wrong as the previous version I quoted was.

<comment><USER4> The correct answer is it has to do with weak types.

> `If compareFunction is not supplied, elements are sorted by converting them > to strings and comparing strings in lexicographic` period end of the story.

As I said explaining the historical context or labeling the brokennes with something like "weak typing" doesn't excuse. It still stays broken.

> You might argue it's a shitty default, but please argue against reality, not > what you (wrongly) believe it is.

Surprise, I know it is possible to eventually sort things in JS. I too have seen sorted tables in JS done entirely in JS. That's not the point. The point is, it is has fundamentally broken type system.

<comment><USER5> > The correct answer is it has to do with weak types.

No, it does not. You could define the exact same default function in Java, Haskell (requiring that the sorted type be a Show instance) or Python (hell, getting the exact same behavior in Python could hardly be simpler: `ar.sort(key=str)`. There, I broke it. That is near literally how the ECMAScript spec _very explicitly_ defines the default comparison function. The behavior of the sort function is _not_ a consequence of weak typing).

> As I said explaining the historical context or labeling the brokennes with > something like "weak typing" doesn't excuse.

Which you'd know is not what I'm doing, if you could be arsed to read instead of trying to substitute your imagination for objective reality.

> The point is, it is has fundamentally broken type system.

That might well be, but the default sort comparison function is not a demonstration of it. As opposed to the comparison table of 0 and null for instance:

        > 0 < null
        false
        > 0 <= null
        true
        > 0 == null
        false
        > 0 >= null
        true
        > 0 > null
        false

<comment><USER6> > No, it does not. You could define the exact same default function in Java, > Haskell (requiring that the sorted type be a Show instance) or Python (hell, > getting the exact same behavior in Python could hardly be simpler: > `ar.sort(key=str)`

I don't use JavaScript but to me this looks like a really broken implementation over weak typing. Of course, this isn't a trait of the typing system per se as it is a trait of the "interface", if you will, that it offers to the programmer.

What OP was probably annoyed by was the typical excuse the JS community offers for this behaviour: "it's weakly-typed so you can treat the arguments as anything you want". This misses the point of having a weak typing system: instead of using it to infer the type of the arguments and get a sane default comparison function, avoiding the verbosity typical of strongly-typed languages (where you have to specify the comparison function with the correct type signature), you have to specify the comparison function for anything that isn't a string. Bummer :-(.

I hope I haven't missed anything here; as I said, I'm not quite fluent in JavaScript.

<comment><USER5> > this looks like a really broken implementation over weak typing

No dammit, javascript does not coerce numbers to strings when comparing them, a "weak typing" implementation would behave exactly as he wants.

> What OP was probably annoyed by was the typical excuse the JS community > offers for this behaviour: "it's weakly-typed so you can treat the arguments > as anything you want".

That makes OP fractally wrong instead of merely broadly wrong.

> avoiding the verbosity typical of strongly-typed languages (where you have > to specify the comparison function with the correct type signature)

Which you don't, not every language is Java and some actually have defaults. Which work. In fact, even in Java bloody java you don't have to provide a comparator to sort a list, as long as the list's items implement Comparable (that is, they can be compared to one another)

<comment><USER6> > No dammit, javascript does not coerce numbers to strings when comparing > them, a "weak typing" implementation would behave exactly as he wants.

Please note that I wrote it's a broken implementation _over_ weak typing, not _of_ weak typing. The typing system is fine, at least as far as this matter is concerned, but the standard library is badly applied over it.

<comment><USER5> > Please note that I wrote it's a broken implementation over weak typing, not > of weak typing.

But weak typing is a complete red herring, as I noted previously the behaviour of the default sort function is independent from the typing system, you could have a default sort function doing more or less the same thing in a very strict statically typed system.

Haskell's `sort` is defined (more or less) as

        sort :: Ord a => [a] -> [a]
        sort = sortBy compare

it could be (uselessly) defined as

        sort :: Show a => [a] -> [a]
        sort = sortBy (comparing show)

resulting in the same behaviour you see in javascript.

<comment><USER6> Yes, of course it is a red herring! OP's rage was against the JS community taking it as an excuse for shity implementation, that's all I was trying to clarify...

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> Personally, I disagree. I find JavaScript to be the most "write-able" language, and switching to Node + frontend JS as my main language (I've done Python, Ruby, PHP, Java and C++ as jobs) has been the best thing I've done in a long time. Express and Angular are amazing.

Sure, it has a bunch of quirks. Sure, it's not good for everything (I do mostly relatively simple CRUD apps). Sure, in the browser, it gets slow when the DOM is involved. Sure, this is hardly a rebuttal of the points in the original article.

But, still, I love JavaScript.

I think the problem is that the author is writing JavaScript as though it's Ruby. A JS developer switching to Ruby would have similar problems.

<comment><USER8> I see this all the time. JS is slow because of the dom. No. JS is slow because JS is slow. Yes, I know V8 makes it faster than it used to be. Yes I know it is neck and neck for computation, but because of the way memory is handled it is slow for loading large dictionaries.

But I could forgive all of that.

JavaScript is not well designed for work in a team environment, nor is it well designed for Large Code Bases.

But I could forgive all of that.

All the best languages have a group of scientists that have chosen that language to be their defacto language. That is why we see Python, LISP, Fortran (yes still), MatLab, all living on long beyond the "trendy" languages.

JS only picked up steam because Flash died. Not because it was a great language. If it were a great language people would have started optimizing it 5 years ago. It isn't. So they didn't. The new optimizations are out of necessity. And because it lets front end pretend to be backend. That may sound snobby, and it is, but JS for backend is like writing in Visual Basic. These days you can do anything in it, it will be fast, but that doesn't make it the right choice.

<comment><USER9> >> _JS only picked up steam because Flash died. Not because it was a great language. If it were a great language people would have started optimizing it 5 years ago. It isn 't. So they didn't. The new optimizations are out of necessity. And because it lets front end pretend to be backend. That may sound snobby, and it is, but JS for backend is like writing in Visual Basic. These days you can do anything in it, it will be fast, but that doesn't make it the right choice._

Very much ^this.

I never cease to be amazed by the defensive attitude and excuses coming from JavaScript developers. Usually the premise is "I can get shit done in it, so it must be good", which isn't a particularly strong argument.

If you would make up 20 completely different metrics to rank programming languages on, and score every popular language using each of them, JavaScript would be near the bottom of almost all of them, and near the top of none. It's not terrible in _every_ way imaginable (it would score reasonably well on 'productivity' for example), but it's not great in _any_ of them either, which frankly makes it a shit language that only exists as a historical accident.

<comment><USER10> I wanted to switch to other languages rather often, but most of them are getting strange quite early in the learning process.

</comment></comment></comment></comment><comment><USER11> I'm so tired of hearing how bad JS is as a language - guess what, it doesn't metter. The ecosystem and community is absolutely amazing and that's something you just can't beat - all the well documented, polished and maintaned libraries, frameworks etc, the amount of books, guides, conferences and so on, the ability to use JS everywhere, tools, services, cloud based solutions and much, much more. That's why people create all the amazing stuff and all of this results in one of the most important things - development speed. Sure, JS has a lot of quirks you need to be aware of and it's easy to write bad JS, but with some experience, you can rapidly write a maintainable, easy to read, flexible and modular code.

<comment><USER12> Yeah, same here. I have no difficulty writing large scale apps in JS because I play to its strengths and manage its weaknesses. These shit-for-brains "experts" can't, and somehow it's all the language's fault.

Here's a clue folks: you're the programmer, it's your job to work out how to programme for your target platform, and if you can't then fuck off and leave it to the professionals.

<comment><AUTHOR> "it's your job to work out how to programme for your target platform" \- exactly, but there is an active effort to try and put the JS garbage on each and every target platform!

</comment></comment></comment><comment><USER13> > a function is not an object, not a datastructure that can carry data

Wait, what? That's the definition of a closure.

Most of this seems to boil down to the author saying "my programming brain was hardwired by Ruby, and I'm annoyed JavaScript is different." OK, I feel your frustration. As a reader, though, I'd far rather see a post from someone who has spent the time to become proficient in both ecosystems and can offer more considered pro/cons.

On one point, I'll agree: I wish Javascript had an easy way to say "referencing an undefined property of this object should throw an error."

</comment><comment><USER14> I have always wondered why so many people like dynamically types languages... I mean, if I have a variable I ALWAYS know what kind of data I expect in it. If I try to use different kinds of data in the same variable then something is clearly wrong - either with me (for wanting that) or with the way I use the variable (and I would appreciate some warning about it).

The problem is that you hardly have a choice nowadays. Python, JS and PHP are dynamic, Java is a great language but crappy concept (don't tell me it isn't slooo... <wait for GC... ok, done> ...ow). Ironically, the ugliest language I have ever coded in (ObjectiveC) has the best design decisions (IMHO). ARC instead of manual memory management or GC, strongly typed but still allows generic object pointer (id),...

<comment><USER15> _I have always wondered why so many people like dynamically types languages_

Because you don't have to write a lot of boilerplate to tell the language things that it should be able to figure out for itself.

 _I mean, if I have a variable I ALWAYS know what kind of data I expect in it._

But that data might not always be of the same type. For example, in Python, I might want a variable to hold strings but also None, so that I can differentiate between, say, "the user explicitly entered an empty string" and "the user hasn't entered any string at all yet".

Yes, there are ways to do this in statically typed languages (for example, Haskell's Maybe), but it's still extra code that I have to write.

<comment><USER14> > Because you don't have to write a lot of boilerplate to tell the language > things that it should be able to figure out for itself.

This is exactly my point; compiler can't figure out what kind of data I want, at least not in general. A good example is jQuery $.data() which tries to guess what kind of data you have in your HTML tag attribute. Guess what happens if you have a MongoDB ObjectId (as string), for instance "52259986890d6f24e9000000"? Exactly - it is a floating number. Believe me, it leads to some interesting debugging sessions... :)

I agree with you however that it is beneficial to have a way to set the var to None/null/..., indicating "not initialized". Win some, lose some I guess.

<comment><USER15> _Guess what happens if you have a MongoDB ObjectId (as string)_

But that's a matter of semantics, not static typing. You're going to have to do type conversion on the string regardless, because "MongoDB Objectid" isn't a native type for the compiler. But with static typing, you need to tell the compiler the type of the variable _in addition_ to telling it how to do the type conversion: for example, in C++, you might have to say...

        var MongoObjectid id = new MongoObjectid("somestring");

..whereas in Python, for example, you could just say...

        id = MongoObjectid("somestring")

<comment><USER14> > You're going to have to do type conversion on the string regardless, because > "MongoDB Objectid" isn't a native type for the compiler

My point was that jQuery .data() tries to guess how to handle strings and misses in some cases, because the strings are too similar to numbers. The fact that this particular string was a MongoID is actually not relevant to the problem, it just illustrates that this is a real-world problem.

</comment></comment></comment></comment></comment><comment><USER16> It's interesting to see so many people say "JS is great and we used it to build X" on one side and people who hate JS on the other side.

Obviously Node (and JS) has some things that it is strong in. People use it to build those things. Good developers won't use a tool in their box which is inferior to another tool they can use effectively. In between, there is a lot of room for "good enough" where tools overlap.

I think some developers are able to largely stick with a certain tool because development goes in waves. I can spend multiple months on a certain profile of work and then get hit with the same type of project a couple more times. Maybe by then I become an expert with that thing and I just keep doing those sorts of projects. You might think I'm crazy because I'm a "Node developer" but you probably don't know the nature of the work that I do.

Eventually I get hit with a different project and everything falls apart if I try to keep using the same tools as I had been using. So, I curse myself for being stupid and wasting time and start over with the tool I should have been using in the first place.

Some developers might have such a limited set of tools that they can't (or won't even try) to switch.

"So, I landed a big gig for the government. It's a healthcare site. I'm going to build it in Wordpress."

Following this thread further, look at some of the selling points of Node.

* It's great because as a front-end developer, you probably already know JS. With Node you can use JS on the back-end also!

* Because the front-end and the back-end are both in JS, I can use one programming language and re-use libraries for each side.

Great, let's encourage people who only know one programming language and a limited range of tools to just stay in that box.

There are things that X tool does well. There are things that X tool is horrible at. Perhaps rather than ragging on Node, the author should write an article explaining that developers should be expanding their tool-set so they have flexibility in handling different types of problems.

<comment><USER17> >Obviously Node (and JS) has some things that it is strong in. People use it to build those things. Good developers won't use a tool in their box which is inferior to another tool they can use effectively. In between, there is a lot of room for "good enough" where tools overlap.

People use JavaScript not because it's good but because it's the only option to develop in a browser. Having the same language on the client and the server is a very strong point, that's why they use NodeJS.

<comment><USER18> > Having the same language on the client and the server is a very strong point

Only if you're so incredibly strapped for cash that you can't hire real devs that can pick up another language in a day or two.

Almost every language used commonly on the serverside is vastly preferable to js.

This whole "well, it's THE SAME" benefit simply isn't. It's a red herring.

I'm convinced the whole ecosystem has sprung up because of hordes of terrible copy-paste browserside devs that don't actually fully understand what they're doing in js, who resultantly would be incapable of building anything serverside in another language at all because their overall comprehension of programming is marginal at best.

Anyone not stupid or insane just learns ruby or python or scala or go or even php or .NET.

PS: cue replies from all dozen people on the whole internet who know pointer math and still like coding webapps in js, who don't realize that I'm not talking about the 12 of them but the 12,000 who are doing the js/node problems on codeacademy this instant.

<comment><USER19> > Anyone not stupid or insane just learns ruby or python or scala or go or > even php or .NET.

I _started_ with PHP and C#/VB.NET, before learning JS. I know Python, Scheme, Java, I've played a bit with Clojure and Ruby[0]. After all that, JavaScript (admittedly, usually through CoffeeScript) is my favorite language. It provides everything you need to build almost anything you want, wrt tooling.

I understand and agree that it has warts, as does every language. But to call its use "stupid or insane" is ridiculous.

[0] I have yet to understand the concept of blocks, as they seem to be just a half-assed implementation of first-class anonymous functions. If someone can show how they improve on them, that would be much appreciated.

<comment><USER18> ....aaaaand scene. Cut!

<comment><USER19> I have literally no idea what you meant by this.

<comment><USER18> You didn't miss your cue, and delivered your lines perfectly. We're done for the day, we're not bringing in Eevee[1] and Dziuba[2] to shoot the "every language has warts hahaha what are you, a noob?" scene until tomorrow.

You did great, thanks again. Don't call us, we'll call you.

[1] [http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad- de...](http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/)

[2] [http://pages.citebite.com/b2x0j8q1megb](http://pages.citebite.com/b2x0j8q1megb)

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> > They are not solvable by making a new ECMA spec.

As it turns out, many of the issues outlined are not only very much solvable by making a new ECMA spec but either already solved in ES5 or solved in ES6.

> JS has callable attributes

> This is a shitty design decision

I strongly recommend not following the provided link, which is basically inane, uses the term "slots" in a rather disturbing manner and makes completely incorrect assertions e.g.

> Self [is] slot-based. This gives one substantial advantage: not having to > specify that you want to move a block of code as a value explicitly. So you > can do, for example in JS

          // boom! we transplanted a method
          someVar.smartMethod = another.otherMethod;

to my knowledge, you most definitely can not do that in such a manner in Self. Slots manipulation in Self can only be done through primitive messages (e.g. `_AddSlots:`, which takes an object whose slots should be copied into the receiver).

> Hobjects are unusable for stable keys

> The mixup between objects and hashes is also a very bad idea, because it > defies the premise that objects can have metadata on them - which alllow you > to establish a rudimentary type system or at least any kind of > introspection.

Magnificent baseless assertions. Javascript allows for object metadata through the prototype, or through properties (Object.defineProperty/Object.defineProperties) which — amongst others — allow setting non-enumerable properties. ES6 also introduces the concept of names. I'm not saying maps-as-objects is great, but I am saying these assertions are 1. wrong and 2. nonsensical.

> Fobjects are unusable for type systems since an object does not carry any > type information.

> This one is a biggie. Even in the Ruby world, where everything is happily > quacking like a duck, we often use the Object#class to get information about > an object.

In ES5, the exact same behavior is provided by Object.getPrototypeOf providing access to the internal [[Prototype]]. Most implementations also provide direct access via the __proto__ property, which IIRC ES6 standardizes. And of course the `instanceof` operator has been there since ES3, but that's only ~13 years ago.

> Nothing will happen. Since ojects are hashes[...], our constant with the > wrong key will be undefined, and will happily bleed into the callee. This > makes stack traces huge.

'Nothing will happen' (and the related "What is the error that you will get if MyApp.Views.WidgetView is not defined yet? undefined is not a function of course! [...] And why? Simply because everything is a hash and the language is incapable of doing any kind of introspection." later) and 'objects are hashes' have nothing to do with one another. Hashmaps does not actually require unmapped keys to return nil or undefined. Javascript does because it is shit. Same for Ruby or Java. Python does not have that issue, accessing an empty key will raise a KeyError.

> and the language provides zero facilities for constants

All runtimes but MSIE (unless they've added it in IE11) already implement `const`, and it's standardized in ES6.

> Callback hell

> [...] In a normal situation this would have been fixed simply by adding a > wait primitive to the language which would schedule the events when the > result is still being fetched.

You mean, something like ES6's yield?

> Terrible exception handling

No objection there, javascript may well have a worse exception handling than Go, a language whose users try very hard to make others believe doesn't have exceptions in the first place. At least runtimes are finally trying to generate callbacks worth reading.

Not that this help when mixing with async, as your final traceback will lack 90% of the necessary context.

<comment><AUTHOR> ES6 has not been finished yet as far as I know.

<comment><USER5> It is not[0], but when TFA asserts

> They are not solvable by making a new ECMA spec.

I consider using the upcoming ("new") ECMA spec more than fair game to refute his assertions.

[0] although a number of its features are shimable, precede it by a few years, are already (possibly partially) implemented in some runtimes or are available through ES6 -> ES5 compilation via Traceur. See [http://kangax.github.io/es5-compat- table/es6/](http://kangax.github.io/es5-compat-table/es6/)

</comment></comment></comment><comment><USER20> Aren't all these rants about programming languages as sterile as debating whether Spanish language sucks because it is not as regular as Italian language ? I really don't get it, people keep attacking issues of javascript or php. Fact is: 1) people use the languages of their choice to make programs. 2) Programs work, no matter as shitty the program is reputed to be 3) why look further ?

My view is: instead of ranting about languages (think about the meaning of that word), why not instead dissect what we do with them: programs, and find ways to improve them ?

<comment><USER21> > why not instead dissect what we do with them: programs, and find ways to > improve them ?

The way to improve a lot of programs is to write them in a different language.

<comment><USER20> Another way is to fix/tune the algorithm

<comment><USER21> That may hit an upper bound, above which you have to rewrite in a different language. That upper bound may be quite low.

</comment></comment></comment></comment><comment><USER22> I'm very glad JavaScript is the language of the web. It has a combination of things I like that I don't find in many other languages:

* lexical scope

* first-class functions

* prototypal inheritance

<comment><USER23> Not many languages have prototypal inheritance, but most modern languages have first class functions these days. And what sane language uses dynamic scoping?

<comment><USER24> Do you mean lexical scope? Scheme has it and it is awesome. If you think it is not a good feature you should grab a SICP and see the magical stuff you can do with it.

<comment><USER25> He is asking what other sane language does _not_ have lexical scope, as that was listed as one of JavaScript's advantages.

<comment><USER24> Oops you are right... I read it backwards, I can't edit it anymore :(

</comment></comment></comment></comment></comment><comment><USER26> This article reads like this comic: [http://imgs.xkcd.com/comics/rock_band.png](http://imgs.xkcd.com/comics/rock_band.png)

 _goes back to happily writing JavaScript_

</comment><comment><USER27> You are holding it wrong.

No seriously, you might be trying to use a fast glue/prototyping/event processing and browser deployed language to do something that should be done in a different environment. If your core logic task is algorithmic, consider C or Go and call that from your event framework. If it's data integrity/type- safety related, consider using your sql dialect.

(not a flamebait, but nosql is just a big distraction, please seriously consider postgres, it rocks, esp with json and plpgsql stored procedures that can be used to enforce data integrity braces and as independent unit testing for your data structures)

AngularJS, Express, node, and postgres is the most potent combination I've used in a long time.

Cheers,and good luck! F

</comment><comment><USER28> Yes, JavaScript is terrible. But JavaScript is not the end of programming languages, it is a step for the next big language.

I think everybody agree that different languages for frontend / backend development are the not the best solution, so JavaScript is a big step forward.

But i think soon it is necessary for a complete rebuild for a new language, with all the things included that we learned and invented from the "old" languages.

Dart, TypeScript, Coffescript, and the 1.000 other language Modifications / frameworks try all to fix a little part of the problem. Thats nice but annoying too.

</comment><comment><USER10> Is Dart an alternative for those problems?

Edit: I mean stuff like "callback hell", does it allow me to programm normally and still avoid blocking the loop?

<comment><USER29> If you're doing frontend dev, then you must use Javascript or a language which compiles to Javascript. I believe Dart currently has a mostly functional tool to compile Dart code to Javascript.

As for callback hell, Dart has "Futures" which are basically Promises. If you like Promises, you could use Dart...or one of the many excellent Promise libraries for Javascript; the syntax is almost identical.

(The linked article savages Promises for no obvious reason. I happen to like the syntax. In any case, Dart uses the same syntax, so if you buy the articles criticisms, Dart is no panacea.)

<comment><USER30> The "syntax" of promises in JS and Dart isn't really a syntax. They are library features in the form of fluent method chaining. This is merely a library pattern, it is not a syntax.

A syntax would be something like the async/await support in C#. Or the async and let!, do! etc along with pipelines in F#.

<comment><USER29> A valid point; that just seemed like the easiest way of phrasing it to me.

Anyhow, what I was trying to say is that the linked article trashes Promises, and Dart has Promises, so Dart is at least in that respect not a solution.

<comment><USER10> And this aspect is one of the biggest problems I got with JavaScript.

The only big things, which Dart seems to solve, is modularization and the many tiny JavaScript quirks, for which IDEs or a strong understanding of the language is needed.

</comment></comment></comment></comment></comment><comment><USER31> As someone who maintains old 1000+ KLOC projects I have to agree. Have look at some large old Perl projects to see how JS code will look&feel in 10 years.

But on other side I see JS bytecode as great alternative to Java and JVM. Modern languages usually include JS as compilation back-end.

<comment><USER32> >But on other side I see JS bytecode as great alternative to Java and JVM.

Exactly how is javascript a better byte code than JVM byte code?

<comment><USER31> Obviously install base is huge.

</comment></comment></comment><comment><USER33> For modern development of _what_?

Then don't use Javascript.

I'm not sure I can really appreciate another rant about how one language, framework, pre–compiler, VM, etc is terrible and everyone should stop using it.

Javascript's popularity has emerged organically. Its not because it has the best design. Its because it can get the job done and is browser based–and now server-side too. The browser is the next OS, the ultimate VM, if you will.

If you just stop picking at it and appreciate it for what it is...it is f'ing awesome.

<comment><USER30> It's operating a defacto monopoly on a layer of the modern development stack. This does not make it "f'ing awesome".

People rant about JS not because it's shit, per se. Everybody knows that. They rant because they long for better languages that are available across all web browsers.

I would like to see a standardised CLR-style VM that allows language modules to be loaded as requested by a particular web page. Otherwise we'll just be replacing JS with what will probably be another old fashioned imperative language (see: Rust). We don't want that. We want freedom to use whatever language we want.

</comment></comment><comment><USER34> The webpage is difficult to view in the Android Browser (though not Opera Mini) due to the overlay at the bottom.

[http://m.imgur.com/9eOKqJZ](http://m.imgur.com/9eOKqJZ)

On that note, at what resolution, if any, do embedded code snippets from GitHub and the like stop getting get cut off on the mobile? At 800x480 they get cut off even in landscape mode.

<comment><USER24> The same happened on a windows phone

</comment></comment><comment><USER35> I don't get the "Fobjects are unusable for type systems since an object does not carry any type information."

You can just do

       if(myObjectToTest instanceof typeOfObjectIExpect)

</comment><comment><USER36> I don't understand how the author thinks simply calling every little annoyance "shit", without further explanation, is very constructive.

</comment><comment><USER37> Here we go again. Let's enumerate the technologies which are shit: HTML is horrible CSS is an abomination HTTP is wasteful, slow and old C++ is a horrible language (Linus Trovalds) C is dangerous Java sucks ..

I'll stop there and let you expand the list if you want.

Turns out the whole computing world is built on top of this terrible tech which many people hate, yet somehow it's moving forward.

<comment><USER38> All I know after years of being in the tech industry, every programming language ever invented has pissed off enough people that no one should ever use each language. I'm quite sure that languages not yet invented has already pissed enough people already that they'll be hated the day they are released.

Personally, I find such people childish in a way.

It's a tool in a toolbox. I've never seen a mechanic rant about the substandard design of a standard screwdriver because he pulled it first despite actually needing a phillips screwdriver.

</comment></comment><comment><USER39> "JS has callable attributes, Hobjects are unusable for stable keys...object does not carry any type information, Null everywhere, since ojects are hashes"

I find most of the problems listed are related with dynamic type system of JS. These all can be solved most easily by a statically typed language.

Therefore the debate mostly is between static vs dynamic typing.

<comment><USER40> I would also argue that expecting an object to carry type information is an unfair expectation of a non-object-orientated language.

<comment><USER41> JavaScript is an objected oriented language.

<comment><USER42> Not really, from what I gather it's closer to a functional language that lets you implement objects with private data by using closures.

<comment><USER41> Yes really. It's an OO language based on Self's prototypical OO model rather than a class based OO model. Prototypical OO is still OO, unless you're claiming Self isn't OO, but the Smalltalker's who invented Self would very much disagree. Prototypes are objects, no closures or classes required.

<comment><USER42> Ah, I stand corrected, thanks. Makes sense; I think I had something about private vars in JavaScript and closures running through my head and confused it with 'JavaScript does OO with closures' :)

<comment><USER41> No problem.

People who don't like or get prototypes have certainly reimplemented classes with closures, but classes are not a requirement to be OO, objects are; classes are just one way to do it, prototypes are another. Objects don't require classes, though many a JavaScript programmer thinks so.

</comment></comment></comment></comment></comment></comment></comment><comment><USER43> No matter if I agree with this or not; why the stab at Java there? I'm not sure what the resemblance, besides the name, is here? Or does OP just dislike Java (for some completely different reason) and could it just have as well been Perl or PHP or whatever a lot of people don't like?

<comment><USER44> Date API (old, not the new one that is arriving) was taken from Java. And Date library in Java is frankly... horrible.

</comment></comment><comment><USER45> Google Closure Compiler + @struct = new property definition outside of constructor is forbidden.

Or DEBUG_ON && Object.seal(this); at the end of every constructor.

Here, I've fixed "Hobjects" for you.

JavaScript _allows_ you to write shitty code, but whether you do it or not is just a matter of skills and tools.

</comment><comment><USER46> \- Unfortunatly you can complain all you want you'll have to write some javascript if you do front-end development. And today there are quite a lot of tools (transpilers,linters,etc...) that can help you with that.

Fortunalty you can chose the language you want on the server.

</comment><comment><USER47> Is it impossible to write an article like this without liberal use of swearing? Many of the points in the article are quite reasonable, but with the foul language used in it I cannot bring myself to read it all.

Foul English is far, far worse in my eyes at least than JavaScript.

</comment><comment><USER48> Another rant by a programmer who clearly doesn't understand JS... It does have its drawbacks (what language doens't?) but if you have some coding discipline you can code pretty big application without headbanging.

</comment><comment><USER49> Every time I read an article of someone blaming a language, that is not the language they love, I feel like I am reading an airplane pilot, driving a bus and screaming: BUT THIS THING DOESN'T FLY!!!

</comment><comment><USER50> While I agree JS is a shitty language overall, and worst when writer larger apps.

Having someone who wrote this on a website that spend 30% of the screen estate for page footer isn't very convincing.

</comment><comment><USER51> I've been meaning to pick up Dart for a new app, but there aren't any great frameworks for Dart apps yet. It seems Angular is being ported though.

<comment><USER52> Dart doesn't really need "frameworks" in the way that JavaScript does. The core libraries are very rich:

      * dart:async give you Futures (Promises in JS, no need for Q) and Streams
      * dart:core and dart:collections give you real data structures like List, Map, Set, Queue, LinkedList, LinkedHashMap, etc. Much more comprehensive than underscore.js
      * dart:html is much improved over JS's DOM, and have most of jQuery's functionality (see ElementList).
      * New and upcoming standards like Shadow DOM, custom elements and template binding let you declaratively define your HTML template in HTML with data-binding, which is the foundation of frameworks like Ember, Angular, Knockout, etc.
      * Polymer is a JS and Dart library for helping you write custom elements.

Also, the package system in Dart, pub, is very similar to npm and encourages smaller, focused packages rather than sprawling frameworks.

Check it out, it's a very nice language and environment. But I'm on the Dart team, so I'm obviously biased.

</comment></comment><comment><USER53> Well, this will probably just be ignored or downvoted, but as far as I can tell, ToffeeScript (a derivative of CoffeeScript which is a derivative of JavaScript) is the best language to be programming in today.

Of course "best" is subjective, but I believe that the combination of Node.js's superior module system and the available packages, the clarity of the language (which actually surpasses Python) combined with the asynchronous single-threaded event-based model, and ToffeeScript syntax which makes asynchronous code read like synchronous code, makes this a superior platform.

I do think that Go is a wonderful evolution of C, but the module system or at least ecosystem is inferior to Node's, and the language syntax and concurrency approach (although very useful and better than Node's in many circumstances) is old-fashioned.

Many people don't trust, don't learn, and ultimately cannot objectively evaluate JavaScript, simply because it is too easy to use. [sarcasm] And everyone knows that real programmers don't use easy languages. Those are for beginners.[/sarcasm] That's the real explanation for most of the JS hate. The other part of it is the people who did try to learn it, found out there were problems, and then for whatever illogical reason decided that they couldn't use CoffeeScript or any other similar language to compensate for those problems.

</comment><comment><USER54> > In a normal situation this would have been fixed simply by adding a wait > primitive to the language which would schedule the events when the result is > still being fetched... 80 percent of the programming is about doing one > motherfucking thing with another motherfucking thing and you need both of > them to complete the action.

I love JavaScript, but I totally agree with this.

</comment><comment><USER55> Agree. JS = gavno. It's faster than Ruby only because Ruby is slow like gavno as well.

The fact that many are eating gavno and are feeling happy about it does not make it healthy or tasty. The problem is when there are no other food to choose (browsers).

That's why I love backend development. I can choose a decent, compiled, strongly typed language and well-supported framework.

</comment><comment><USER56> I thought I'd write up a response to this, pointing out how Javascripters get around these issues right now, and how they will come ES6: [http://sidekicksrc.com/post/for-modern-development- javascrip...](http://sidekicksrc.com/post/for-modern-development-javascript- is-just-something-you-need-to-learn/)

</comment><comment><USER57> Hey folks, thanks for all the constructive criticism and death wishes. Will do my best to respond in detail - but for now I've removed the fixed footer. Deployment from the train FTW.

</comment><comment><USER58> Looks like learning rage.

When faced with a new thing to learn, point out all the mistakes and flaws that give you reasons to not learn this shitty thing in the first place.

Or it could be the 3rd stage of grief :)

</comment><comment><USER59> Most of the comments in the article are about the horrible footer. Gosh, is indeed an awful footer.

Oh by the way I agree with half of what he said (just half) but I still enjoy javascript.

</comment><comment><USER60> To me it seems the author is expressing his own inability to code in the language, why discuss someone's opinion?

</comment><comment><USER61> Coffee Script makes it a bit sweeter.

</comment><comment><USER62> yay ruby!</comment>


Ask HN: How do you find new products? - <AUTHOR> Hi,
I and co are currently at the start of our YC journey but have a couple of questions that will help us going forward.
How do you find new products? We are interested in the process you go through to discover new products.
What I mean by _new_ products is anything that has been released recently. It could be literally anything based on your needs, preferences, hobbies or lifestyle.
Thanks,
M <comment><USER2> Typically network effects (people discussing them on the internet) lead me to an interest in something which I then go and download. Did you want something more specific?

</comment><comment><USER3> I don't understand the question. I buy new products in stores or online... Are you looking for a specific purchase I made and how I came to select the product?

</comment><comment><AUTHOR> eli,

Apologies for causing confusion. We are interested in how you search for new products. Let's use in store and online as examples, what is the process that you go through? Less so on product selection and more on discovery. If that makes sense.

Thanks

</comment><comment><USER4> www.producthunt.com</comment>


Ask HN: How often do you get rejected for "lack of passion"? - <AUTHOR> So I've been interviewing with some companies lately (London) for software development position. All I managed so far is get rejected from a bunch of places. I'm not a "rockstar dev", but I've got ~5 years under my belt and have never been fired, so I think of myself as average I guess. Most companies either ghost you after the interview or give some bullshit feedback. 2 out of 3 latest ones however stated something along the lines of me "having lack of passion", "enthusiasm" for their product. These companies were not exactly startups either.<p>Now I worked in a bunch of boring industries such as web agency, insurance company and lately finance. I have no passion whatsoever for either of these and yet I manage to do my job just fine. Is "lack of passion" just a code word for "you don't seem too eager to bust your ass and do unpaid overtime for us"? <comment><USER2> Frankly, no, it's not a codeword for unpaid overtime, it means "you will likely just make everyone depressed with your attitude."

You don't need to be passionate about insurance, but you need to be able to show some enthusiasm about building software for insurance, which likely has a lot of exciting challenges (in addition to 90% boring work, as does almost any job). You don't need to be passionate about web agencies, but you need to at least understand what's cool about working at an agency (in addition to what's not). Finance is "boring" to you? There are tons of interesting tech challenges in finance. If you describe every job as boring then the problem might be you.

Nobody is going to hire you just because you can code if you have a negative attitude about what everyone there spends their days doing. Why would they?

<comment><USER3> You make it seem like not being excited equals having a negative attitude that brings everyone down. There are many shades of grey between those two.

I've worked on boring stuff that I wasn't excited about, but I didn't have a negative attitude at work. Every day I just came in, did what had to be done, went home. AFAIK my past co-workers and managers all appreciated my work.

I can empathize with what OP is saying. I've never been rejected myself for "lack of passion", but I know people who have interviewed perfectly fine candidates in terms of logic reasoning and technical aptitude and rejected them for this bullshit reason.

I don't understand this current expectation that you can't just do a good job at what you do, no, you have to be all starry eyed about it and thinking of it even in your dreams. There's more to life than work.

<comment><USER4> There's a QI (UK show) clip about this topic. Although the discussion is geared towards customer service, I think it still fits here. It's 45 seconds long.

[https://www.youtube.com/watch?v=_LiDTKEF1ek](https://www.youtube.com/watch?v=_LiDTKEF1ek)

<comment> J-dawg Here's more David Mitchell on the subject of passion. I think the OP will probably agree!

[https://www.youtube.com/watch?v=Bz2-49q6DOI](https://www.youtube.com/watch?v=Bz2-49q6DOI)

</comment></comment></comment></comment><comment><USER5> I think you're right, it's just as bullshit as they come.

I'm working for an ISP that also sells IPTV, both to end-users (along with settopboxes) and to other ISPs (as a service they sell to their users). I couldn't care less about the television in general and IP-based one in particular. I don't watch TV, I don't even have a TV set and the closest thing to one that I have is the screen of my laptop. Yet I take pride in how our infrastructure for providing TV channels works, especially when compared to how it looked like when I got hired.

In other words, it can be perfectly healthy if you don't care about the product itself, as long as you care about the quality of the product and craftsmanship used to build it.

</comment><comment><USER6> On the one hand, pretty bullshit ([https://www.google.com/#q=at+*+we+are+passionate+about+](https://www.google.com/#q=at+*+we+are+passionate+about+) is a fun search). And often code word for "unpaid overtime".

On the other hand, companies do legitimately want people who will care about their work. So maybe next time:

1\. Spend a bit more time reading about companies' business and then ask more questions at interviews. Even if you're not passionate you do want to make sure they're not going to have redundancies in 6 months, and it will give better impression :)

2\. Emphasize your pride in work you do, so even if it's not "HEART EYES INSURANCE I LOVE INSUARNCE" at least it's "I will do good work."

3\. Try to get better sense of company culture (e.g. unpaid overtime), so you can better calibrate rejections and so you can get better sense of if you want to work there. Ideally if they say "not enough passion" you should already know whether this is code for unpaid overtime based on what you learned in interview.

4\. This is another reason getting jobs through someone you know is better, you can get better sense of company culture in advance.

Some ideas on filtering out companies that suck: [https://codewithoutrules.com/2016/10/14/job-you-dont- hate/](https://codewithoutrules.com/2016/10/14/job-you-dont-hate/)

Some resources I wrote up on finding jobs with a sane workweek: [https://codewithoutrules.com/saneworkweek/](https://codewithoutrules.com/saneworkweek/)

</comment><comment> J-dawg I think this is slowly becoming one of the last acceptable forms of discrimination.

We know that terms like "Cultural Fit" can be used a proxy to cover up for all kinds of discrimination which is illegal / socially unacceptable.

I think "Passion" has become of those terms. It allows you to exclude a whole raft of people without admitting the real reason.

Socially awkward? Not passionate. Bad at public speaking? Not passionate. Suffer from depression or anxiety? Not passionate. Find it hard to show emotion in front of people you just met? Not passionate.

Here's a revolutionary idea: interviewers could just evaluate candidates based on their technical aptitude, skills and experience.

</comment><comment><USER7> Sorry you're having a hard time.

I think software development is murky. In my experience, fixing a customer problem with software can take 10 hours if you're excited about it and interested enough to come up with a creative solution or 40 hours if you're bored and just robotically building to a spec.

Likewise, I haven't met a programmer who was very good at something they hated. I'm guessing you actually enjoy some parts of your work -- maybe steer the conversations to that.

</comment><comment><USER8> Yes, but there are tons of "passionate" people out there, so they are looking for them. Here in my country (Brazil), we are nearing a ridiculous situation. Most startups set stupid hiring metrics managed by people ignorant about technology and most of them (if not barely all) fail badly. And then the CXO's all blame their "passionate" programmers and leave with the pockets full of money.

<comment><USER9> > Yes, but there are tons of "passionate" people out there, so they are > looking for them.

Are there really be people passionate about building boring business software or is it just a case of rewarding the liars?

<comment><USER8> I don't think anybody is passionate working for others in the long term. And mostly young and inexperienced people are passionate until they get the full picture.

</comment></comment></comment><comment><USER10> Be passionate about the problem space the job and code exists in.

</comment><comment><USER11> Look at it as they are filtering themselves out for you.

</comment><comment><USER12> I'd imagine that's _exactly_ what they're looking for. And if they can somehow find someone so passionate, they can only benefit. So why not look for that (from their perspective)?</comment>


Free Software Awards 2019: Nominate those who inspire you by November 6th - <AUTHOR> https://www.fsf.org/blogs/community/free-software-awards-nominate-those-who-inspire-you-by-november-6th <comment><USER2> Fun fact #1: fsf staff and current board members cannot be nominated.

Fun fact #2: RMS is neither staff nor a board member.</comment>


Windows 10 on ARM - <AUTHOR> https://channel9.msdn.com/Events/Build/2017/P4171 <comment><USER3> Microsoft are seriously _killing it_ in emulation these days.

First I was amazed with them getting Xbox 360 (PPC) games running _at full speed or better_ on the Xbox One (x86) and now we have x86 on ARM.

They have some wizards working on this stuff.

Edit: I wonder if Dave Cutler is involved in this x86 on ARM stuff? I think he was with the Xbox 360/Xbox One.

<comment><USER4> As far as I know, they don't emulate Xbox 360 games on Xbox One, they port and compile it for the new console, creating entirely new binaries. Not much emulation going on there. Correct me if I'm wrong.

EDIT: [https://en.wikipedia.org/wiki/List_of_Xbox_360_games_compati...](https://en.wikipedia.org/wiki/List_of_Xbox_360_games_compatible_with_Xbox_One) "Unlike the emulation of original Xbox games on the Xbox 360, the Xbox One does not require game modification, since it emulates an exact replica of its predecessor's environment – both hardware and software operating systems."

I stand corrected.

<comment><USER3> It uses emulation. While it is true the user needs to download a 'game image' rather than play the game directly from disc this is because that image is a virtual hard disk that contains the game and a customised Xbox 360 virtual machine that has tweaks for the game. It is similar to PC console emulators that have specific configs for certain games.

<comment><USER5> I thought they do a static recompilation too, from the original binary, but I can't look it up now.

<comment><USER6> That's actually probably the case. Xbox 360 banned making arbitrary pages executable (not even the Kernel could do it, the Hypervisor call to mark a page as executable had to come with the signatures signed by Microsoft's private key).

So they probably can get away with static recompilation.

</comment></comment></comment></comment></comment><comment><USER7> This excites me. I work with a lot of geospatial industry tools, many mobile tools are still based on old window CE/pocket PC/windows mobile platforms; I hope to see these snapdragon devices overtake this area.

Mobile data collection tools on iOS and android devices are rather poor (at least open source ones), hopefully this will help solve this problem—we'll just be able to use windows applications that work and are better developed. The windows ecosystem still seems easier to me than iOS / Android, perhaps that's just my bias or that I see more development options.

This could be a huge turning point for Microsoft's mobile divisions.

x86 drivers are still something I'm curious about here...

[edit: I should also mention, the reason why geospatial tools comes into play here is because the snapdragon CPUs have integrated GSM and GNSS (GPS) on the die. Currently, x86 based tablets have to use a separate component, and many don't come with it or even provide GNSS as an option]

<comment><USER8> It's not your bias. The Windows ecosystem has always been pretty good for developers. If it weren't for the ten-year Ballmer purgatory, MS would have been all over this space, where little iOS and Android toys still haven't hit puberty. Reinventing the wheel has been an overall giant waste of time for the industry.

</comment></comment><comment><USER9> I am seriously impressed with Microsoft. I haven't used windows in years but they are releasing tons of useful things. VSCode is great on Ubuntu and every version of OS X I have run it on. Plus tons of other cool things like bash on win; etc.

Also, I have a bizspark Azure subscription and it's not a perfect UX; but man does it beat AWS

<comment><USER10> I agree, what Microsoft shows us today is a real evolution of a software- engineering empire done (mostly) right. The sad fact is that this open-source love + tons of goodies for developers comes after decades of pain and suffering, which were not really "killing" Microsoft, but they were risking a lot. Now they're flying, leaving Apple far behind (Apple completely lacks a multi-tier engineering vision), but if they get a monopoly again... pain and suffering will be back. That's the free market.

<comment><USER11> What is a "multi-tier" engineering vision?

</comment></comment></comment><comment><USER12> For any Microsoft insiders with knowledge about this, a few questions:

1\. In the talk they claim that they get "near native" speed from the translation. Can we have some real number of what can be expected? What about warm up time?

2\. Is the x86 translation layer only available in user space, or can x86 drivers be loaded for hardware that doesn't have arm drivers yet (or the manufacturer doesn't care about making them)

3\. Are there any plans in the future for supporting x64 code as well in the translation layer?

Edit: One more:

4\. Are there any plans on supporting Arm v7 in the future, e.g. with Surface/Surface 2 support?

<comment><USER13> 5\. How do they solve the problem that x86 has a much stronger memory model than ARM, which makes emulation of multithreaded x86 code pretty hard without introducing a huge performance disadvantage?

<comment><USER14> Since there are no publicly available details, I would guess this is solved in hardware. The Qualcomm processor can be made to support stronger memory model for translated instructions similar to how the Power processors support strong-access ordering for efficient x86 emulation[1].

[1] [https://www.google.com/patents/WO2012101538A1?cl=en](https://www.google.com/patents/WO2012101538A1?cl=en)

<comment><USER15> Previous ARM generations had a "strongly ordered" memory type. ARMv8 doesn't have this for cacheable memory (normal) but device memory has a R(erorder) attribute to control access ordering. Of course device memory isn't cached either. Beyond that the non reordering attribute only applies within an implementation defined block size and its behavior with respect to normal accesses (or outside the block) isn't defined either. Making it mostly useless except for the most restrictive of cases.

</comment></comment></comment></comment><comment><USER16> Man, that League of Legends desktop icon on the test machine is such a tease. I would love to know what the status of x86 gaming on ARM devices would be, especially for something competitive that runs on most anything like LoL

<comment><USER17> They already shown LoL and Photoshop running on ARM a few months ago in a demo video. Google it :)

<comment><USER18> I have seen the photoshop video, but not League of Legends - got a link?

</comment></comment></comment><comment><USER19> Does this emulation work for x86-64 executables too?

EDIT: no [1].

[1] [https://www.theverge.com/2016/12/7/13866936/microsoft- window...](https://www.theverge.com/2016/12/7/13866936/microsoft- windows-10-arm-desktop-apps-support-qualcomm)

</comment><comment><USER20> Odd thought: the existence of an ARM Windows, makes it much simpler for _Apple_ to ship ARM PCs.

The macOS development stack has been re-tooled to output LLVM bitcode within its "fat" binaries for a good while now. It'd be very simple for Apple to throw the switch on a compile farm ala the one Google has for Android APKs, and suddenly have ARM downloads for everything on the Mac App Store (without requiring any re-submissions.) Which means it wouldn't be hard at all for Apple to ship a "functional" ARM macOS computer... just, until now, such a machine wouldn't have had a very good Windows story. No Boot Camp, no cheap virtualization, etc.

Suddenly, that story is a solved problem.

<comment><USER21> This idea keeps popping up. LLVM bitcode is way too architecture specific to allow that to happen. Chris Lattner has stated it himself.

<comment><USER20> "x86 bitcode" can be _transpiled into_ "ARM bitcode."

Yes, you could do the same thing with a plain x86-ISA binary, but such a binary might have sections that are very hard to transpile efficiently/effectively—because e.g. they exist as the result of compiling hand-optimized x86 ASM source modules. Targeting bitcode constrains the inputs a bit more, such that the input to the transpiler won't be using extremely- microarchitecture-specific instructions.

And yes, the results wouldn't be 100% efficient. But it would be efficient _enough_ —like Rosetta—to serve as an effective stop-gap to allow ecosystem consumers to continue to consume their purchased apps on new devices, until ecosystem developers upload explicitly re-optimized apps. (And it would—like Rosetta—at least let apps from "dead" development studios run, rather than killing them off entirely.)

</comment></comment></comment><comment><USER22> I'm surprised that nobody has mentioned FX!32. That was the binary translation layer that Windows NT on DEC Alpha used back in 1996 or so to run x86 Windows binaries. There is an old Digital Technical Journal article about it here: [http://www.hpl.hp.com/hpjournal/dtj/vol9num1/vol9num1art1.pd...](http://www.hpl.hp.com/hpjournal/dtj/vol9num1/vol9num1art1.pdf)

Everything old is new again!

<comment><USER23> Ah, DEC Alpha! I had one that ran NT 4.0 and pre-release copies of Windows 2000 (amongst other things) and the day Microsoft decided not to release Windows 2000 for it was one of the saddest of my life (until then).

</comment></comment><comment><USER24> HN is probably not the right target for this type of device. Either way we need Windows 10 on ARM to succeed for Intel to have more competition. I also do think it will be successful if it works at least as well as Intel's Atom- based Celeron and Pentium laptop chips, especially in emerging markets.

Intel shot itself in the foot by replacing the Core architecture in mobile Celerons and Pentiums with Atom, and also by starting to rename lower performance Core M chips to Core i3 and Core i5. This will make it easier for ARM and AMD to "catch-up" and even beat Intel at these levels, because Intel got greedy and tried to trick the market with lower-performing chips at the same price points as for previous (and more powerful) generations.

<comment><USER25> > Intel shot itself in the foot by replacing the Core architecture in mobile > Celerons and Pentiums with Atom

Core mobile Celeron and Pentium are still available, for example Celeron 3865U [1], it's just Intel got tired of having names with useful information in them. That processor should probably have a name like Core v7 2C-2T 1.8Ghz-15W which has most of the useful information, but 3865U is what we got, so you have to filter out the atom chips yourself.

[1] [https://ark.intel.com/products/96507/Intel-Celeron- Processor...](https://ark.intel.com/products/96507/Intel-Celeron- Processor-3865U-2M-Cache-1_80-GHz)

</comment></comment><comment><USER26> There have been rumors of a 'surface phone' that runs Win 10 (not mobile) for a couple years now. Most expected some kind of future Intel chip to enable that, but ARM support certainly opens up the possibility. Just what Windows phones need - another OS change!

<comment><USER27> I'd be very interested in a Windows 10 phone if it has automatic updates that do not depend on the carrier, to avoid the Android situation where only certain phones get updates on a timely basis.

<comment><USER28> Windows 10 Mobile gets OS updates directly from Microsoft. Verizon does not support Windows 10 Mobile _at all_ , but my four year old Verizon Lumia Icon got Windows 10 version 14393.1198, which released yesterday, yesterday.

Microsoft has chosen to drop a lot of older models from the Creator's Update, but is still providing cumulative/security updates to the Anniversary Update right now, which is supported on all phones which run Windows 10 Mobile.

At least, at present, if you have a Windows 10 Mobile device, you have recent security updates, regardless of make or model.

<comment><USER17> One thing Microsoft does well is Long term support and backwards compatibility. I guess this applies to their mobile OS as well.

<comment><USER25> Unless your mobile OS is Windows Phone 8.1, or Windows Phone 7, or Windows Mobile 6, etc which got very little in the way of updates once a new major release was made; and many phones are not upgradable from one major release to the next (or the upgrade wasn't pushed to users without intervention, which is effectively the same thing).

I would say, Microsoft has a reputation for long term support and backwards compatibility, but it seems like it's something they're trying to get away from.

<comment><USER28> I would more characterize it as failures in their mobile space. Microsoft has rebooted it's mobile product line a bunch of times. But, as noted, my Lumia Icon was a Windows Phone 8.x device, and it runs yesterday's release of Windows 10 Mobile. A pretty large number of 8.x devices are capable of 10.

The manual intervention to upgrade to 10 is because, as noted, the big change is that Windows 10 Mobile upgrades are handled by Microsoft, so the update servers had to be changed. Prior versions to 10 had the same carrier-based update issues Android had.

I'd argue that change alone points to the fact that Microsoft is getting better at long term support, not worse.

</comment></comment></comment></comment></comment></comment><comment><USER29> Interesting - something they should have done rather than the orphan WindowsRT, in my opinion.

I wonder if this ends up being the inheritor of Windows CE for embedded ARM- flavoured devices. I also wonder if this means that the Win10 ARM kernel has the full Windows API - so if you built an ARM PE executable that could run natively. I suspect 95% of the pieces are in place for that but it's not yet been productised.

<comment><USER30> I feel like this is in response to the pushback against Windows RT honestly. They put the cart before the horse on that one, trying to get everyone to use an app store with no apps, and quickly realizing that the base Windows experience wasn't enough for the vast majority of their users.

Killing Windows RT was the right choice, because it was never designed to do something like this. It had a weak translation layer for Win32's API built right in, and they would have needed to do some wizardry to have the two live side by side. No, I think RT was a useful but failed experiment, and I'm excited to see them take this approach with Win32 emulation on ARM. If it works as well as these demos suggest it does, it could finally provide a good path for ARM into consumer laptops and even desktops, to spark some great competition in the space. I'm excited to see where this goes.

</comment></comment><comment><USER31> Please correct me If I am wrong. But I think with WSL and this, Microsoft proved they are much much more superior than Google and Apple when it comes to serious system software development (they have to be, they have developed one of the most complex Kernel of the all times and maintained and improved it for decades. Yes I am linux guy too. But Widnows Kernel is extremely complex and well architectured piece of software ever written). Yes, Google does have very good applications, apple does have too.

But when it comes to hardcore system software development stuff. They are unbeatable. Emulating entire x86 on ARM? This is mind blowing.

They have pulled good emulation before too (one I think was inside XBOX).

But this is going to be serious. I would say very serious.

Extremely good battery life would give Microsoft, very good edge over Apple.

1) Qualcomm will be the winner. and so other ARM CPU manufacturer. and Intel is the biggest loser here.

2) Microsoft will hit market with this. After this they will have extremely good position to release good phone, and here we stand, I see successful future for Windows Phone.

3) From Computer Architecture perspective, the bottleneck is not memory or CPU speed. It is IO and energy. I don't know how this will impact on IO. But I am almost sure this is unbeatable from energy efficiency, and when I (and almost all people I know) buying a laptop. battery life is almost the most important aspect of it.

<comment><USER32> I voted you up as it's rare a Linux man would show any kind of respect to the - actually very very good - NT kernel. Good post also.

</comment></comment><comment><USER33> They are doing this because they want the benefits of great ARM battery life. But they are emulating x86 on ARM. So they believe that emulated x86 on ARM will have a better battery life than native x86. The only way I think this could be possible is if they measure battery life of an idle device. Maybe someone can disabuse me of this belief.

<comment><USER34> Keep in mind, if you're just using a web browser, Skype and office, these are likely to all be ARM native. It's only when you boot up an x86 program it even comes into play - for a lot of users that will be very rare.

</comment></comment><comment><USER35> Really interesting.

I can see a potential milestone Windows 10 S on an Arm V8 based laptop with all day battery+. Sort of a Surface RT but without any excuses.

If Apple follows suit and creates a light weight, network centric laptop experience around iOS, then you'll have three contenders for the 'appliance' environment, ChromeOS, Windows 10 S, and iOS. Each with their own 'laptop' design ethic, Pixel, Surface, MacBook.

<comment><USER36> I think I might take this line of reasoning a bit further and have Apple actually come out with an ARM (A11?) powered computer. Given that you could put multiple ARM chips in a MBP I could see a whole lot of power for very little money. Another thought would be switching the Mac Mini to ARM.

Consequently, all this ARM talk has got to be making Intel nervous. I don't think now would be the best time to buy any INTC stock. :/

</comment></comment><comment><USER37> If that runs great on phones, and has virtualization support for e.g. running ARM Linux guests, I would change both my Android phone and my Ubuntu laptop for one phone (e.g. Snapdragon 835 or better + 8-12GB RAM + 256GB flash + USB 3.0 OTG), using a dummy screen + keyboard as laptop replacement.

<comment><USER38> A desktop/mobile convergence phone is my dream. I'd buy one in a heartbeat.

<comment><USER9> I think I get it; but could you expand a bit on what you mean?

<comment><USER38> A phone form factor device that can run a full desktop OS, or something close to it. Canonical was getting close with Ubuntu Touch but that's essentially dead now. I don't want a gimped version of Windows like I'd get with Continuum, I don't want a "desktop-like" version of Android like Samsung is doing, I want a full version of Linux or Windows that can run desktop applications.

<comment><USER9> Ah ok; I actually want something similar; a tablet that can act like a phone but _only_ on WiFi so I don't have a phone bill. Basically; an iPad but w/ real integration & iMessages etc via a free or cheap VoIP number w/o data

<comment><USER39> You might want to look into Google Voice. Free number for texting, calls over data. I receive and send texts and calls from a browser too.

</comment></comment></comment></comment></comment></comment><comment><USER40> Microsoft is one of the few companies that really grok Systems Software right now.

<comment><USER41> They always did, but FOSS people always downplay the work that Microsoft Systems Research does, as if having a clone of an existing OS and UIs was some kind of innovation.

</comment></comment><comment><USER42> Does the x86/x64 cpu emulation work for JIT code or other self-modifying code? (Copy protected games, for example?) In the linked presentation they just briefly mention doing a load time(?) transpile of x86 to arm64 and caching the result on disk. What about exe packers that map memory rw then rx after unpacking, such as UPX?

<comment><USER12> They say that it's a dynamic translation layer, so presumably it doesn't make a distinction about where the code came for (except maybe you'll lose some performance optimization if they are caching translated code)

<comment><USER43> Most dynamic emulators don't do instruction by instruction emulation - <USER2> take in a whole block of instructions and translate that block, caching chunks that may be used without any inference (eg. branching). Once you hit a similar instruction block you don't have to do any translation; just execute from the cache. This is why you have a load time for reading from an x86 image.

</comment></comment></comment><comment><USER44> Windows 10 on ARM would allow Apple Bootcamp on ARM-based MacBooks. There have been rumors about Apple moving to ARM and potentially bringing processors in- house. I wonder if that influenced Microsoft's thinking.

<comment><USER45> You think that this actual shipping product that Microsoft developed might have been influenced by these "rumors" that are never actually sourced to anyone in Apple?

</comment></comment><comment><USER46> This is how Windows RT should have been in the first place.

</comment><comment><USER13> Does this mean that Windows 10 (not Windows 10 IoT Core) will also come to Raspberry Pi 3?

<comment><USER47> Good question. How much memory on RPi3 and how much required to run Windows10?

<comment><USER13> RPi3 has 1 GiB of RAM. The system requirements of Windows 10 (cf. [https://www.microsoft.com/en- us/windows/windows-10-specifica...](https://www.microsoft.com/en- us/windows/windows-10-specifications)) are 1 GiB for 32 bit and 2 GiB for 64 bit (both on x86). So I think if Microsoft is willing to, it should work, in particular if they slim down the fictional RPi3 version of Windows 10 (which I would strongly recommend).

I personally see the much larger performance regression for Windows 10 on RPi3 in the fact that at least on Windows 10 IoT Core there was no hardware acceleration of graphics on RPi3 when I last tested it (about a year ago), which caused it to feel rather sluggish.

</comment></comment></comment><comment><USER48> Strategically interesting because, up to now, the Dalvik bytecode runtime and the subsequent pre-compiling ART runtimes were the best way to do ISA- independent application environments. Apple's fat binaries got in early enough in their (smaller) developer community for Apple to avoid being tied to an ISA. Microsoft was handcuffed to an x86 legacy boat anchor. But now they have escaped, and those other approaches are less of an advantage.

</comment><comment><USER49> Wow, This is brilliant. Microsoft is making leaps and bounds improvement to keep their consumer base happy. Almost ten years after switching to Linux, I think I might gladly use a windows machine as a second PC.

</comment><comment><USER50> I hope that recompiled desktop apps will be allowed in addition to emulation.

</comment><comment><USER51> Can someone explain how they are achieving high execution speed? I would have expected the speeds (or at least the start-up times, if we have dynamic recompilation) for x86 on ARM to be outright abysmal.

<comment> mark-r There's a reason their demo apps were pre-installed. The initial recompilation is cached so that running it the second time will be much quicker than the first.

</comment></comment><comment><USER51> Anybody know when we can expect a phone out that can emulate x86 Windows 10? End of 2017 is the first estimate I heard but I'm not sure how realistic that is.

</comment><comment><USER52> I dont know much about where to find these chip or what I am looking for but...

[http://i.imgur.com/mRdk6ZD.jpg](http://i.imgur.com/mRdk6ZD.jpg)

This is an ancient chip, however I also found MediaTek ones for ~ $10, which had 4 cores and were 1.6ghz SoC.

Sounds to me like we could seriously see $100 laptops that actually function soon.

</comment><comment><USER53> That company could do so much impact if only they had laser focus and distribution execution. Still so much talent with them.

</comment><comment><USER54> That's a Microsoft Intellimouse Explorer Mouse and a Belkin USB 2.0 hub. They're like 10 years old.

<comment><USER55> Fitting when doing a video on backwards compatibility.

</comment></comment><comment><USER56> If they're supporting x86 emulation to run desktop apps will they support compiling native desktop ARM apps?

They're essentially supporting the end result, I would hope they don't force developers to go through emulation to try to encourage them to write a universal windows app

</comment><comment><USER57> Props to D.M. for the pivotal work. You know who you are :-)

\-- ST boot sector guy

<comment><USER58> Not the first time I've seen a reference to D.M. and pivotal work.[0] Is giving a shout out to D.M. some sort of Microsoft meme?

[0] [https://github.com/netmf/llilum](https://github.com/netmf/llilum)

</comment></comment><comment><USER59> Great potential for a Win10 phablet I can develop on that also lets me make phonecalls. Not for big projects, but an anywhere device. Does Win10 support non VoIP calls?

<comment><USER60> I think it does since MS did a big overhall on their windows architecture, phone, xbox, and desktop all run the same base services just with different GUI's. Technically an XBOX could make phone calls but has no GUI or hardware for it.

</comment></comment><comment><USER61> Emulation should be a last resort. They should ship an SDK with all the proper import libs and a cl.exe etc. that can target proper Win32 on ARM.

<comment><USER62> Microsoft appears to have apps that are native to ARM, but the real value of the Windows ecosystem is all the Win32 apps that have been built over the last 2 decades. The emulation layer addresses that so that "it just works" with old apps.

I assume they will be releasing a build configuration for native ARM software deployment on Windows.

<comment><USER61> I would not assume such. They actively seem to hate this scenario.

<comment><USER24> Microsoft also has this project, and UWP apps should work on ARM as well:

[https://developer.microsoft.com/en- us/windows/bridges/deskto...](https://developer.microsoft.com/en- us/windows/bridges/desktop)

<comment><USER61> Neither of those are what I am talking about.

</comment></comment></comment></comment></comment><comment><USER63> I hope they drop this on the surface 2. It would save it from being a paper weight.

<comment><USER64> Was the SurfaceRT an ARM device? I have one collecting dust, would be nice if it got an update

<comment><USER65> Yes. The RT devices ran ARM, which was one of the reasons for the locked down software policy (nothing else would run anyway).

<comment><USER66> Except that you were also denied much of the existing API and can only install software if you have a developer key from MS. I use my RT device for media playback in the car, but the windows-RT version of VLC hasn't been updated in years, and is somewhat buggy.

<comment><USER67> It also took VLC more than 2 years to develop and release the RT version. By the time it was released the market had already declared RT dead.

</comment></comment></comment></comment></comment><comment><USER68> I'm out of the loop on ARM. Can somebody explain the significance of it?

<comment><USER69> It's the processor architecture that in the past was used primarily on servers. Now it's almost universally used in mobile devices, too. It's ubiquity has caused a much larger technological demand for cross-platform development, which is one of the reasons why technologies like JavaScript and Rust have become so popular. Additionally, it's lower power and lower heat compared to it's x86 cousins.

<comment><USER70> > in the past was used primarily on servers

Embedded devices, yes, but ARM on servers is more like ARM's perpetual future.

</comment></comment></comment><comment><USER71> Any word on actual devices that can run this for sale. Configurations ?

</comment><comment><USER72> Ha-ha, Microsoft will do it again. For Windows on all devices!

<comment><USER24> Not really. This is more about allowing ARM to enter the PC market. ARM couldn't break into the PC market without Microsoft's help and by being fully supported by Windows. The only other alternative were Chromebooks, and even Google didn't bother to make a big push for ARM in Chromebooks.

</comment></comment><comment><USER47> What about .Net on ARM?

<comment><USER73> I believe there was a mention in the Day 1 BUILD keynote somewhere that Samsung's work on .NET on ARM (built for Tizen specifically, but I would imagine generically useful) was going to be open sourced to the .NET Core project at some point.

<comment><USER47> So, as of today, Windows 10 on ARM support x86 win32 or UWP, but not a .Net?

<comment><USER73> Oh, UWP .NET has always supported ARM (since Windows 8). I assumed the question was about .NET needs outside of the UWP.

<comment><USER73> Also, the Win32 x86 emulation I would imagine would support most/all .NET Win32 applications, to whatever extent the Win32 .NET Framework gets added to emulation image.</comment></comment></comment></comment></comment>


Modern procrastination - <AUTHOR> http://sethgodin.typepad.com/seths_blog/2010/02/modern-procrastination.html <comment><USER2> When short-cycle tasks (like sales contacts) compete with long-cycle tasks (writing specs and programming) the short cycle tasks win because they interrupt the long-cycle ones.

Got to set aside a time to check emails, lock the door, and never deviate.

I just wish I could queue HN the same as email and check it later and see everything I missed that day.</comment>