Hacker News new | past | comments | ask | show | jobs | submit | hiteshk_msft's comments login

Microsoft (Chakra JavaScript Runtime team) | Seattle (Redmond) | Software Engineer | Full-time | Onsite | https://github.com/Microsoft/ChakraCore/

The Chakra JavaScript runtime team works on Chakra (the JavaScript runtime that powers Edge and other Microsoft properties), and ChakraCore (the Open Source heart of Chakra). We work primarily in the open, with standards bodies and the Node community, to help make JavaScript and the web better for developers everywhere.

We are looking for somebody with C++ performance engineering expertise to come join us on our mission to make JavaScript fast with Chakra on these platforms. You must be eligible to work in the US, have 5+ years of experience writing high-performance C++ code, have some background writing JavaScript (either for the web or Node), have expertise in low-level performance tooling and investigations and be interested in participating in technical discussions in the open with both internal partners and external communities. Compiler/Runtime experience is a plus, as is experience with API design. You will be required to pass Microsoft background checks prior to the start of employment and periodically thereafter. Further details regarding this process will be provided in follow up correspondence.

This is a unique opportunity to do work helping millions of users around the world, and to participate in open communities to shape the future of JavaScript. If you think that geeking out about language design, squeezing out that last bit of performance by hand-tuning assembly instructions, closely analyzing perf traces or working on the next generation developer tools, sounds like fun, send us a short intro + resume to chakracore (at) microsoft (dot) com.


Microsoft (Chakra JavaScript Runtime team) | Seattle (Redmond) | Software Engineer | Full-time | Onsite | https://github.com/Microsoft/ChakraCore/

The Chakra JavaScript runtime team works on Chakra (the JavaScript runtime that powers Edge and other Microsoft properties), and ChakraCore (the Open Source heart of Chakra). We work primarily in the open, with standards bodies and the Node community, to help make JavaScript and the web better for developers everywhere.

We are looking for somebody with deep Linux/macOS performance investigation expertise to come join us on our mission to make JavaScript fast with Chakra on these platforms. You must be eligible to work in the US, have 5+ years of experience writing high-performance C++ code, have some background writing JavaScript (either for the web or Node), have expertise in low-level performance tooling and investigations and be interested in participating in technical discussions in the open with both internal partners and external communities. Compiler/Runtime experience is a plus, as is experience with API design. You will be required to pass Microsoft background checks prior to the start of employment and periodically thereafter. Further details regarding this process will be provided in follow up correspondence.

This is a unique opportunity to do work helping millions of users around the world, and to participate in open communities to shape the future of JavaScript. If you think that geeking out about language design, squeezing out that last bit of performance by hand-tuning assembly instructions, closely analyzing perf traces or working on the next generation developer tools, sounds like fun, send us a short intro + resume to chakracore (at) microsoft (dot) com.


Microsoft (Chakra JavaScript Runtime team) | Software Engineer | Seattle (Redmond) | On-Site | Full-time

The Chakra JavaScript runtime team works on Chakra (the JavaScript runtime that powers Edge and other Microsoft properties), and ChakraCore (the Open Source heart of Chakra). We work primarily in the open, with standards bodies and the Node community, to help make JavaScript and the web better for developers everywhere.

We are looking for somebody with deep Linux/OS X performance investigation expertise to come join us on our mission to make JavaScript fast with Chakra on these platforms. You must be eligible to work in the US, have 5+ years of experience writing high-performance C++ code, have some background writing JavaScript (either for the web or Node), have expertise in low-level performance tooling and investigations and be interested in participating in technical discussions in the open with both internal partners and external communities. Compiler/Runtime experience is a plus, as is experience with API design. You will be required to pass Microsoft background checks prior to the start of employment and periodically thereafter. Further details regarding this process will be provided in follow up correspondence.

If you think you meet the requirements, and this sounds like fun, send us a short intro + resume to chakracore (at) microsoft (dot) com.


Even Microsoft can't sponsor visas nowadays?


Some of these suggestions are good but some caveats: - Lookup tables- while lookup tables are great, engines might sometimes convert switch statements to lookup tables too- Chakra does this when it's advantageous to do so - Try-catch- this seems like v8 specific advice. Chakra definitely does optimize functions with try-catch in it, and I think SpiderMonkey does too - Freeing memory- setting the reference to null does not necessarily free the memory- it just makes it likelier to get collected when the Garbage Collector runs

Disclaimer: MSFT employee, Engineer on Chakra


> Try-catch- this seems like v8 specific advice. Chakra definitely does optimize functions with try-catch in it, and I think SpiderMonkey does too

http://gs.statcounter.com/ certainly suggests that specifically optimizing for Chrome/V8 will benefit the majority of users (58% not including mobile, 50% including mobile). As with all statistics, take with a grain of salt.


Also keep in mind that 50% of users as a whole may not equate to 50% of your users.


> Lookup tables

This one also seems a bit iffy to me, depending on the stage of compilation, how often this code runs, how much information the engine is able to collect, and the size of your table. The initial unoptimized property lookups will likely be slower than if/else statements, and the engine may end up optimizing them with inline caches, which are essentially a chain of if/else comparisons and jumps between dynamically generated code stubs.

> Try-catch

Yep, SpiderMonkey does optimize this case.


> Try-catch- this seems like v8 specific advice.

Carakan doesn't either. But given that nowadays affects some old TVs (but still newish, I doubt most people replace TVs that often…) and Opera Mini's limited JS support… Yeah, okay, that doesn't matter. :)


I vaguely remember firefox choking on try/finally but not try/catch, may have been fixed could have been a dream but in generally try can be tricky


Thanks for the suggestion, great idea! However, it's really early days for us still- as the blog post mentions, we are still working on implementing the JIT and concurrent GC which are quite important to awesome performance. When we complete that work, we'd definitely keep a close eye on current industry benchmarks


Heh, I didn't actually think an actual MS developer would respond to my comment.

As it stands, I can appreciate what MS is doing; you guys aren't probably going to compete with or replace V8 or SpiderMonkey on Linux overnight, hence why getting a working Node port is a good first step of presumably many.

Regardless, this is definitely an interesting step; it would be really trippy if I end up using an entire MS stack on my Linux desktop, but it appears that might be a legit possibility.


To clarify, this is why no graph has been published for Node.js on Linux and MacOS, or chakraCore on Linux and MacOS. But as a sibling post to the parent mentions, they have published performance statistics for Node.js on ChakraCore on Windows, where the JIT is implemented.


This sounds similar to kernel debugging- is that what you have in mind? Windows (the OS I'm most familiar with) has a couple different styles of kernel debugging, which allows you to introspect various levels of system state:

https://msdn.microsoft.com/en-us/library/windows/hardware/ff...

https://msdn.microsoft.com/en-us/library/windows/hardware/hh...


For now. The Linux branch of ChakraCore is under active development.

Disclaimer: working at Msft on ChakraCore


Check out the Linux branch :) we are actively working on a port.

Disclaimer: Msft employee on chakra


Is Mac support planned? Not really familiar with the internals, so I can't tell if the Linux branch is a generic (enough) branch for Unix and alike.


It's not on the short term roadmap because we've scoped it to clang 3.6 x64 Ubuntu while we stand up the branch but we're trying to keep our code changes for the port pretty generic.


From the Roadmap document - it seems like JIT on Linux is not a priority? That's surprising. Is it due to technical issues or the whole idea is to have NodeJS on Windows use Chakra and let the community do the Linux part with JIT?


The first step is to get the runtime and interpreter running. Next step is to bring the jit up. Chakra is the hybrid engine where we have the interpreter, simple jit and full jit. The interpreter is the one which does all the profile data collection. Profile data is required to get the quality jit code.

Declaimer: I work for Chakra team.


Hi! Thanks for explanation and another cool product!

One question that just came to my mind regarding this: Have you thought about a configurable/modular build where this interpreter/simple jit/full jit can be switched? Or is this perhaps already there?

I can think of some use cases where it would be interesting to build a modern and full featured JS engine in interpreter-only mode. E.g. to integrate it into platforms which don't allow JIT (iOS), to reduce the footprint or the attack surface. Or to be able to port it the other platforms without much effort - in the embedded domain there are still other processors than x86 and arm and other OSes than Windows, Linux and OSX floating around.


Great question. Yes, we have a way to disable jit. See the merged pull request by our super cool dev here: https://github.com/Microsoft/ChakraCore/pull/4. We have build configuration which produces daily builds without JIT as well: https://github.com/Microsoft/ChakraCore/pull/42.


That sounds better - you may want to consider updating the Roadmap document to clarify this.


Sure I will follow up.


This is more so that we have something that helps us break the problem into several steps to accomplish the goal. JIT will come after.


wow, this new Microsoft is something.


Why port rather than just writing it to be portable from the start? Seems like a lot of work?


Why design the engine first released in 2011 under a completely closed culture to be portable for its eventual open-source release five years later? I understand the appeal of the thoughts behind what you said, but you shouldn't burn time on things you don't foresee being an issue.


Chakra was originally written for Internet Explorer 9. "Linux compatibility" was not exactly a huge priority at Microsoft at the time.


Engineer on Chakra here- are these the docs you're looking for? https://msdn.microsoft.com/en-us/library/dn249552(v=vs.94).a...


I know it's off-topic, but since you're a Microsoft employee: haven't the MSDN guys ever heard about friendly URLs? Compare: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Sp...

(I'm guessing this would be at least the milionth time they hear about it :) )


MSDN does support friendly names: https://msdn.microsoft.com/library/system.string (works for any .net class)

I think the person who wrote this particular page simply didn't specify a friendly name, which is why it's falling back to the canonical name.


Yep! Especially the reference.

Will have a look and compare with the spidermonkey bindings when I get time.

Thanks!


Engineer on the Chakra team here. As the blog post says, we are definitely interested in going cross-platform. Which platforms would you be interested in seeing first?


I would be very insteresting to see a Chakra-based Node.js project for server side apps, so Linux would be my first vote :)


Microsoft is already working on Node, and it's actually already possible to run Node on Chakra. See https://blogs.windows.com/buildingapps/2015/05/12/bringing-n... and https://ms-iot.github.io/content/en-US/win10/samples/Nodejs....


It's just very rare to use a Windows VM in a cloud service environment to deploy services.

This may change with the Docker support we are seeing promised. Powershell is definitely a workable remote shell. But it's not the case that this is sufficient today.


Azure is the second biggest cloud provider in the world (after amazon) - and we (TipRanks) deploy VMs to Azure.

It's a lot less common but I wouldn't call it `very rare`


A lot of Azure use is with Linux VMs.


Azure provides a massive number of Linux boxes. It's actually their preferred target, if you hear them tell it at Connect2015.

I had a friend go there, came back talking about hallway discussions of Posh on Redhat.


That's cool but only run on Windows 10 which limit its usage and hence the community. A widely used non-V8 Node.js would be a great project in my opinion.


Give it time. When Node was new it didn't work on Windows, which limited its usage and hence the community.

Now, Node is probably the most reliable cross platform language host. Write something for node, nearly anything, and if it works on your OS it'll probably work elsewhere too.

There's no reason something similar couldn't happen with Chakra, especially now that it's open source



Linux/FreeBSD


Yes, please! Here's another vote in support of Linux and FreeBSD!


Just to clarify, you're taking about Chakra going cross-platform, not Edge itself? I think a few of these replies might be looking at whatever_dude's comment and getting the wrong idea.


That's correct, this announcement is only about ChakraCore being open sourced. I have no knowledge and can't comment on what the Edge teams plans are.


OS X. I don't use it but I think it'd have great value. I often hear engineers talk about how they don't want to work with IE because they have to boot up a VM to use it. So...they don't even test it, they know nothing about it except for how IE used to be 10 years ago when they still used Windows machines.

That'd be the coolest thing since it'd encourage developers that shy away from MS technology to dive into it.


They're open sourcing the JavaScript engine, not the browser. A port to OSX would mean you can run there server side programs before deploying them to Windows servers. I believe there are more Linux servers out there. Still a port to OSX would be useful because there are many developers with Macs that deploy to Linux.


I don't see how it'd help deploying server-side programs. Maybe that makes sense with IoT. And as a Node alternative/enhancement.

BUT, once you have the JS engine over, I could see them porting over the rest. But anyways, you could still run headless browser (or just Chakra) and run tests against it.


Have you heard of www.browserstack.com ? Easy way to test different platforms without VMs.


yeah but it's paid, needs internet access, and requires some sort of setup. Plus, most OS X devs would do this ONLY for IE. Which is a barrier of entry.

Downloading and installing IE browser on OSX is a much better solution. And this way, you have a browser that people can use casually as well. Since it has awesome ES6 support, that makes it even better for JS Devs.


Linux, and then Android would be interesting, for non java android apps.


A little love for Haiku sure would be nice....

In all seriousness I'm pretty sure everyone would say POSIX-y systems.


Nodejs-Webkit or Electron should support Chakra engine as well.



This is just for Windows 10 isn't it?


All! Mac OS X + Linux!


No love for the BSDs or Redox or TempleOS


Linux, because of servers.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: