No VB yet, but that's just because I haven't had time to do it yet -- VB is trivial to add support for.

In fact, the package I used for the compiler binaries contains the csc + vbc compilers, so it's literally just shoveling some command line arguments down the pipe.

It's definitely on my to-do list. :)

I hope you don't mind me replying here. I figure if you're working on the tools you might appreciate some feedback...

Annoyingly it seems to work differently to how DNX builds. With my project [1] I have spent what felt like an age setting up a .NET Core supported project.json that builds with 'dnx build'; the result is horror slow compilation and maxed out CPU usage whenever I build in VS2015, even if nothing has changed - actually borderline unusable. I have rebuilt all of the csproj files and the sln that I originally deleted to make way for the project.json and xproj files. So I now have:

  * project.json per folder
  * <project name>.project.json per folder
  * <project name>.csproj per folder
  * <project name>.xproj per folder
  * <project name>.sln per folder

The per xproj sln is tedious just so I can tick a box saying 'Produce output', like I'd ever not want to produce output. Total mess.

So I thought I'd give this (dotnet CLI) a go. I can't run from the root because there's not a project.json there. If I go into the Core project then it compiles OK (on OSX with no issues), but builds in the <project>/bin folder like MSBuild. That means the other projects in the repo can't find their references like they can with the DNX artifact system. It seems to me that it should support the same DNX project.json/global.json dependency system.

Whilst I support the general direction MS is taking with DNX and 'dotnet'. The whole system is a buggy inconsistent mess and has recently lost me weeks of time trying to figure out the magic combination of settings that are needed to support cross-platform builds (actually most of the time has been spent waiting for builds, waiting for VS2015 to stop locking up, or giving VS2015 enough 'lock up time' before killing it from the Task Manager and starting again).

I'm also not sure MS has quite prepared itself for the public evolution of their tools and source. It has lead to a trail of misinformation throughout the web - and I for one have found the process incredibly difficult to follow. Trying to piece together what is going-on through github issues on the aspnet/dnx/fsprojects repos is tedious. I still don't really know if I'm doing it right and the 'official' help is light on details at best.

[1] https://github.com/louthy/language-ext

Totally understandable -- a lot of this stuff is really new, so we've fallen a bit behind on documentation, partially because we're not exactly sure how some stuff should work, so we don't want to mislead people.

The dotnet-cli stuff is super new so a lot of the tooling is incompatible right now. As things start to settle out more in the next few weeks a plan to write a series of blog posts about how things work, general development approaches, and where you can expect to hit rough edges.

Thanks for the feedback, though! We're definitely a bit new to this style of development.

This looks like it includes C#, VB.NET, F#, and any other language that targets the CLR (Common Language Runtime, i.e., Microsoft's JVM). edit: Apparently not. Mea culpa!

Also, I don't know how long ago you tried Mono + VB, but especially since MS started collaborating with Mono and offering upstream first-party support (~2 years), support for the IL has been almost production quality. (Now it is production quality - I'm running some of my customer ASP.NET applications which was built around the NHibernate rather than EF/MS SQL on full Linux infrastructure).

Satya is making a ton of bold moves that are basically antithetical compared to the Ballmer-era MS. Visual Studio Code (yet-another-electron-based-editor) and Community, along with the ridiculous amount of open stuff on Github has effectively eliminated the vendor-lock-in stronghold that Microsoft previously had. Residual Office renewals and upgrades on the MS SQL stack will only get them so far. They're going full Docker[1] support on the new Windows Server stack, as well as full .NET support off the Windows stack, which is interesting to say the least. I wonder if we'll start seeing them buying out companies that are traditionally aligned with more-open-sourcey.

A bold move they could make would be buying out Cognitect. Datomic could be a perfect fit for them. Integrate Visual Studio support (e.g. as good as IntelliJ/Cursive) and give CLJS first-party support (let Nolen take a lead spot on the TypeScript team) in VS and it could be a steal at even a few hundred million dollars. The talent (Hickey+Nolen) the developers who they bring over + the perception shift within the dev community + the Datomic itself is likely worth a half a billion to MS.

[1] http://www.hanselman.com/blog/BrainstormingDevelopmentWorkfl...

F# support is in progress, next beta i think. pull requests got merged last week

TypeScript(and even C#) is a huge step backwards compared to Clojure and ClojureScript. Immutability is a clumsy thing in TypeScript whereas it's concise and natural in Clojure and ClojureScript.

I doubt a bright person such as David Nolen would like to work with TypeScript as it is right now.

IMHO of course.

I'm pretty sure a few tens of millions (lets say Nolen has 5% equity? I think give or take a few points, that's about right) for 4 years (generally the buy-out terms for a pair of golden-handcuffs) and the freedom to choose the direction in which TS goes (notice I did say "Lead" -- his role would have to be essentially Anders or Meijer's level for it to go through I'm sure) would be equally amenable for all parties involved. (I don't think you understand the freedom engineers at that level in MS get, especially post-Ballmer). Immutability sucks in TS? Oh well, here David, take 5-10 SDEs and do whatever you want.

MS gets the Clojure (and maybe more importantly the CLJS userbase), Cognitect gets massive reach (CLJS is subsidized solely by the licensing of Datomic by strict revenue), MS' corporate customers get Datomic. Just going by the direction MS has been in lately ("embrace & extend") under the new anti-Ballmer role, floating an offer of 300-500 million would be beneficial to everyone involved. Let's say there are conservatively 100k Clj(s) users out there right now using Clojure + Sun's JVM. At 300 million that's 3k per active developer acquired right off the bat. You'll lose maybe 10% of the users who live-by-their-Macbook-and-die-by-their-iPhone. Even at 600 million, that's still a cheap price to pay.

I'd say immutability is just about the only thing that's concise in Clojure/Script and everything else about it is a huge step backwards - especially the lisp syntax. Yuck! (Also IMHO.)

It was maybe 2 or 3 years ago I poked around in it and failed to get much to run.