Hiring for Roslyn
A couple years ago I made a blog posting called "The Managed Languages Team Is Hiring" mere hours before our senior management announced that our hiring goals had been met and told me to please stop recruiting people. That was a little embarrassing. This time I have been assured that, really truly, we do have open positions on my team.
This gives me the opportunity to more clearly articulate what has hitherto been speculation and rumour. Yes, as many of you have deduced we have split the managed languages team into two teams. One is concentrating on the "async" feature that is now in CTP as well as researching and developing other possible new language features. The second team, code-named "Roslyn", is working on longer-lead tasks, namely a massive rearchitecture of the C# and VB compilers to support "compiler as a service" (CaaS) scenarios. The latter is the team I actually work on, along with a number of other developers and architects (like Neal Gafter, Matt Warren, Peter Golde and of course Anders Hejlsberg just to name a few.) We are looking less at specific language features and more at how to build a compiler architecture that is amenable to use as a foundation for modern tools.
When I joined the C# team during the effort to build C# 3 there were basically two "silos" of code on the C# team: the compiler team and the IDE team had each written their own custom semantic analyzer. (They shared a lexer and parser.) We realized that the semantic analysis burden imposed by LINQ was large, and that doing the same work twice was not a good idea. We made a major investment in enabling the IDE to consume the compiler's semantic analyzer so that we would have only one lexer, parser and analyzer suitable for both "batch compile" and "interactive" scenarios. That was a big success.
However, the interface to the C# 3 compiler's semantic analysis services is exceedingly complex and narrowly tuned to our specific IDE scenarios. And it is inconsistent with VB's similar system. And it is written in unmanaged C++, not in C# or VB, making it difficult to use it from managed code. There is a huge opportunity for the tools space if we can make a semantic analysis service that more than just our own IDE team can consume, with a consistent interface across the two premier .NET languages that is itself easily accessible from managed languages.
This is a enormous undertaking given the small size of our team; we have been working on it for some time now and we have plenty yet to do. The Roslyn team is somewhat understaffed right now; we are looking to hire someone at the "Developer 2" level. We will consider "fresh out of college" candidates but the ideal candidate we're looking for would have solid industry experience with both use of and creation of code analysis tools. We need someone who is crazy in love with compilers, who has thorough knowledge of C# and/or VB, and who wants to work with the awesome squad of senior architects and engineers we've already assembled.
The text of the job posting is below; if you are interested in this position please do not send your resume to me directly or post it here as a comment; use the mechanisms on the career site to make sure that your information gets entered into our database. If you want to mention in your application that you learned about this job here, that would be great, but not necessary.
Finally, why "Roslyn"? I was the one who came up with this silly name. Almost all Microsoft product code names are now city or town names. It's unlikely that the lovely and historic town of Roslyn, Washington is going to object to us using their name. But if we chose the name of a copyrighted character or fictional location from a book or movie then there might be a legal issue there, and obviously names already taken by other products are right out.
But more importantly my office has a northern exposure .
Ha ha ha ha ha ha!!! I crack myself up.
Job Category: Software Engineering: Development
Location: United States, WA, Redmond
Job ID: 734698 28776
Division: Server & Tools BusinessC# and VB are the flagship languages targeting the .NET platform. The overwhelming majority of code running on .NET is written in VB or C# using Visual Studio. The C# and VB team build both the language compilers and the Visual Studio editing experience around those languages, and the compiler team is looking for a new team member to help us deliver on a bold, new undertaking.
Until now, the VB and C# compilers have been used as black boxes. You put text in, and you get out a binary file. In our long-lead project, code name Roslyn, we’re changing that dynamic by building an API that exposes compilers’ analysis engines. Exposing parse trees and types, expression binding, and assembly production through an API enables a world of new scenarios including REPL, C# and VB as scripting languages, and more. In order to do this right, we’re re-examining the compilation pipeline at the most fundamental level and designing an immutable model written top to bottom in managed code.
Technical challenges on the Roslyn compiler team come in many forms. Ever noticed how fast the C# compiler is? It’s not an accident. What about lambda functions? How do those things work under the covers? If you were on the Roslyn compiler team, you’d be developing high performance implementations of C# and VB language features that developers use every day. How does Visual Studio produce such accurate and quick IntelliSense? It’s the compiler guts back there, and you could help build the foundation that enables scenarios like that.
As a developer on the Roslyn compiler team, you’ll work in an environment filled with smart, industry-recognized folks working on a next-generation product that directly affects the experience of thousands of developers like yourself every day. And if you’re seeking a more direct interaction with customers, on the Roslyn compiler team you will develop an in-demand expertise in the compiler implementation that allows you to speak as a domain expert in online forums and at conferences.
We’re looking for a developer who wants to be challenged, has sharp intellect, and possesses solid collaboration skills. The ideal candidate will have a strong architectural sense, a history of producing robust and maintainable solutions, and a passion for delivering genuine customer value. Knowledge of the .NET managed execution environment is a big plus and the ability to drive open issues to resolution is a must. We program in VB and C#.
Comments
Anonymous
December 15, 2010
Ahh...for the path not taken. My favorite class coming out of school was compilers, but my brain is rotted from too many years of application coding. Good luck with your search.Anonymous
December 16, 2010
At first I was surprised to see that you're designing an immutable model. Then I realized that English provides no good way to distinguish a model that's immutable from a model of an immutable-something (like, in C++, the difference between a const pointer and a pointer to a const object). I take it that you're designing a model of compiling with data structures that don't have mutators, rather than a model that itself cannot ever be changed?Anonymous
December 16, 2010
At Kevin ...that describes me to a T. I keep my brain from getting too dull by writing ever-more beautiful parsers for our simple internal searching language :) At Gabe: Looks like the job posting is a test of semantic analysis ability in and of itself!Anonymous
December 16, 2010
The comment has been removedAnonymous
December 16, 2010
Raymond Chen has an example about "immutable" today: "once the code ships, it's done. You're stuck with it. " blogs.msdn.com/.../10105888.aspxAnonymous
December 16, 2010
Simon Buchan: If the model was immutable, it wouldn't be possible to extend it for future advancements in compiler technology. If they created this compiler model 10 years ago, do you think it would be able to accomodate things like expression lambdas, type inference, and iterator rewriting? An extensible model is usually better than an immutable one because that means it won't have to be created anew every time something changes. You and Simon are both on the right track here. To clarify: when Roslyn builds up a data structure that represents the lexical, grammatical or semantic analysis of a particular hunk of code, the object it hands back to the caller is immutable, much as an expression tree is immutable in C# 3. The caller has no way of editing that thing. There are many reasons for that: immutable data structures are easy to make threadsafe, they support scenarios where old portions of the structure are cleverly re-used in future analysis, they make it cheap to keep historical data about what the analysis used to be around, they are easier to test, and so on. Internally we do use a fair number of mutable data structures for performance reasons but we try to hide this detail from the user. The kinds of things within that model will of course change and grow as the language changes and grows. -- EricAnonymous
December 17, 2010
Could this CaaS thing enable generation of JavaScript instead of MSIL? Kind of like projects.nikhilk.net/ScriptSharp but with the real parser?Anonymous
December 21, 2010
<quote>the two premier .NET languages</quote> Surely there are three: C#, F#, and C++/CLI. But we C++/CLI programmers are used to being ignored. Hey wait, you're not including F# either? Clearly there's something very wrong here.Anonymous
December 25, 2010
The comment has been removedAnonymous
December 25, 2010
Ben Voight: There used to be one premier language, but now VB is included. Java must have been the implict 0-th language supported, as Object should be clean while Java sported a few methods there. Managed C++ is on the fringe of normal application development, but have you yet found anything said that voilated C++ or F#? Eric is looking for a C++ reader and C# writer dev to translate a monolith compiler into a genuine API. Hey, you should apply!Anonymous
December 30, 2010
The comment has been removedAnonymous
January 06, 2011
What I wouldn't do for a PhD, or professional coding experience right now. Guess I'll have to enjoy being a hobbyist. I curse being in the middle of nowhere in a tough economy. Oh well, back to my own compiler framework.Anonymous
January 17, 2011
Actually, what do I have to lose?Anonymous
February 19, 2011
Eric, How does this new compiler infrastructure enable scenarios such as custom textual-DSLs? I am aware of the DSL toolkit team, but that is very focused on XML and the visual designer, and in my experience is both limiting and complex. I see meta programming as being the next big thing in productivity - so I can just define my models once (but not in C# because the syntax is not right for all purposes) then generate code to implement the various tiers (a bit like what LightSwitch or RIA services). There is a lot of 'cruft' that needs to be written in a multi-tier solution at the moment. If I could 'boil off' all of the excess code and just leave the essence I would say that I could describe it all in about 20% of the code or less. Thoughts? P.S. The small team makes me think Im not going to hold my breath for any of this technology in VS vNext :-(