LittleDan

LGTM! Smells like Redux (in a good way). But then ultimately at the root you probably want the event to update your “model”, and then that leads to an update of the “view”. This is the part where signals can be useful.

I think there is room for improvement in how we explain this. The problems aren’t really visible in this small sample and comes up more for bigger things. PRs welcome.

what do you do to retain talent? Wouldn't senior employees look elsewhere for better pay?

Giving everyone a true sense of co-ownership is great for retention. Plus interesting, meaningful work, good pay, etc. Why would you need to know that you make more than your coworkers?

It would be great to hear feedback from everyone on the Temporal survey: https://forms.gle/iL9iZg7Y9LvH41Nv8

pizlonator, Is ShadowChicken cheap enough to turn on all the time and make Error.stack work similarly to without PTC?

We wrote about this in detail in http://v8project.blogspot.com/2016/04/es6-es7-and-beyond.htm... under the heading "Proper Tail Calls".

tl;dr we implemented it, it works, but we are not shipping it because we believe it would hurt developers to lose some stack frames from Error.stack in existing sites, among other issues.

From the post:

"The V8 team is already working to bring upcoming features such as async / await keywords, Object.prototype.values() / Object.prototype.entries(), String.prototype.padStart() / String.prototype.padEnd() and RegExp lookbehind to the runtime. "

I'm working on async/await in V8, together with Caitlin Potter. Browser support is in progress for Firefox and Safari as well. It didn't make the cut for ES2016, but it is at Stage 3 at TC39. I'm optimistic that it'll get into the main draft specification at the next TC39 meeting after we have a second spec-compliant browser implementation, which doesn't seem very far off.

Sorry for the inaccurate shorthand; maybe that should read that SpiderMonkey supports it. Eric Faust of SpiderMonkey is a co-champion of the proposal, and spoke against implicit PTC at the March 2016 TC39 meeting. It's hard to get much stronger in support of a proposal than being a champion, and Eric works for Mozilla. From that discussion, it also sounded like there was support from the Mozilla devtools team as well.

I'm interested in getting everyone's point of view. We've been discussing pros and cons at https://github.com/tc39/proposal-ptc-syntax/issues and https://github.com/tc39/ecma262/issues/535 , and it'd be great to have your input, including the overturning-prior-consensus issues you raised in committee and anything else that comes to mind.

EDIT: How do you like the new wording "For these reasons, the V8 team strongly support denoting proper tail calls by special syntax. There is a pending TC39 proposal called syntactic tail calls to specify this behavior, co-championed by committee members from Mozilla and Microsoft." ?

And you can use that sort of library in ES6 because generators were standardized.

Not sure what you mean by virtual DOM. From the WebAssembly FAQ: "Is WebAssembly trying to replace JavaScript?

No! WebAssembly is designed to be a complement to, not replacement of, JavaScript (JS). While WebAssembly will, over time, allow many languages to be compiled to the Web, JS has an incredible amount of momentum and will remain the single, privileged (as described above) dynamic language of the Web. "

https://github.com/WebAssembly/design/blob/master/FAQ.md#is-...

The WebAssembly team is being incredibly thoughtful and open about their motivation and long-term plans, which is very refreshing.

ES2016 is proposed to be based on Ecmarkup, a more modern system which will let us collaborate on Github more easily, rather than a canonical MS Word document on the editor's computer.

What approval means here is that it was ratified by the ECMA General Assembly. The move by TC-39 to send ECMAScript 2015 to the GA was voted on at the last TC-39 meeting around a month ago.

The plan is to keep releasing them mid-year.

Hey, I was just going to mention how easy it was for me to move... to right next to your cube! (I'm in V8.)

Strong mode prohibits most (all?) implicit conversions https://developers.google.com/v8/experiments.

Brendan's talked about adding a macro system. I'm not sure if a macro system could really let you redefine everything that's built in though...

edit: Sounds like I'm behind the times; found out about sweet.js (http://sweetjs.org/).

For background on the user-defined operators and literals idea for ES7, see this: http://www.slideshare.net/BrendanEich/value-objects (it took me a little while to find; it hasn't been as prominent in recent discussions as the other items). I'm excited to see all the progress Javascript is making!

6% is nothing compared to the raises or stocks or other random bonuses that come with working for a big tech company for a while and doing well. It seems really short-sighted to compare details about initial offers at such a minute level. Plus, Google offers other nice ways of evading taxes, like a good 401k plan.

When I got out of school 4 years ago, people were already making the same arguments. While Google isn't perfect, I can't imagine a place I'd rather work, where I can really dig into technical details of things while having freedom to set my agenda in many ways, very smart coworkers and predictably high compensation. I don't think any of those things have changed in 4 years.

Talking about top CS schools/going to Stanford is really irrelevant. I went to Carleton College, which has a nice little CS department but not really well-known, and got a liberal arts education. Because I did some open-source work and maybe because of some academic projects, I was able to get lots of interviews and offers, all in the same range as people are discussing today. All Stanford does at a company like Google is get your foot in the door--small, poorly run startups may hire on that basis, but that's it.

My one piece of advice for people who want to get into the tech industry: Choose one open-source project and contribute to it over a long period of time (ideally starting in high school, but never too late). The short time span of college courses and lack of large projects (a semester is not long) means that you can't really develop the skills that you need to be effective by that alone. Large, open-source projects give you real experience in structuring code to be maintainable, working with others and receiving feedback, and understanding and changing existing code that other people wrote. It might also get you some nice internal references.

I agree, that's a great book to start with. When I started out programming the Linux kernel, I thought I had to understand everything and I hated the book for not going into detail on how things worked. But really, I just had to start changing code and running it, and I became a Linux kernel programmer. Now I see that I just needed to know the basic roadmap, and the rest comes from reading code and experimentation. It doesn't matter much if the book is a little outdated; the core concepts stay in place for a while. Another book I'd recommend starting with is The Linux Programming Interface. You can write programs for a while without getting to the kernel/userspace boundary, but this is essential to understand if you're going to write user-facing code (e.g., a driver).

It's just like the article said--just a big, annoying to debug C program. If you understand pointers, you can learn how to program the Linux kernel. Programming in the Linux kernel has been a really fun learning experience for me. It's nice, if intimidating, how you can just do everything--there are no hard abstraction boundaries, you can read all the source and call into any part of the kernel without going through hoops.

I've developed the Linux kernel with two machines, a development machine and a headless machine that I'm ssh'ing into (actually, a bunch of those--makes testing go faster). VMs aren't really an option for device drivers, but if you run your code on your development machine, you waste a lot of time.