Like early OneDrive and Windows 8, I really hope a couple people got fired over this debacle. But like today's OneDrive, Windows 10 and .NET Core, I'm glad it's finally moving forward. I know HN has an anti-Microsoft bias from pg on down, but this is serious, proven tech that's moving in the right direction. Say what you want about MS, but their R&D budget is larger and more focused on developers than any other company, decade after decade.
Maybe my C# dev bias is showing, but I have to second SHanselman's question: what debacle? They've been working on it solidly for a couple of years now with good progress and transparency in the Github repositories. Hell, MS is even putting their C# language design meeting notes online - you'd have never seen something like that 10 years ago.
If you're talking about the tooling not being ready, I think this is a far better outcome than just holding off release until all the tooling is ready. I'll personally be sticking with ASP.NET 4.6 for a while, but once we've got a stable VS integration, probably move at some point.
You've been working with .NET core for a couple of years? And found it solid? It was announced 17 months ago and it's been a frustrating clusterfuck to follow, with the product and the core tools themselves renamed at least twice.
C# guy here! Love .NET! And found the open development wankery around .NET core (or whatever they finally call it) incredibly frustrating.
EDIT: Putting strategy documents online, documentation online, and then throwing it away isn't helpful. Maybe you dig the churn. Maybe that's why you're sticking with .NET 4.6. If you're in the trenches trying to build stuff against these bits (especially after they were called RC), you may have a different opinion on the impact of the way this was handled.
And Scott, don't forget to give F# some love here, especially being as it is not on Roslyn and it's important its project system stay current with whatever son of MSBUILD becomes.
When .NET Core really starts to take hold outside of the Windows environment, and it will, there are people in those environments looking for a better functional-first programming solution than what they have, and it will be F#.
Totally honest question: in the world of Javascript, Python, Ruby, etc. is Visual Basic still relevant? I understand the desire to have it around to drag VB devs to .NET, but is there a market anymore? Wouldn't it be better to just throw it overboard and focus on C# / F# and maybe Typescript as a JS superset?
There's one pretty cool feature that VB.Net has that C#/F# don't and that's an XML literal syntax... I wrote a service interface to a Flex client a few years ago (also having an XML literal syntax) and it was pretty nice going. Of course E4X didn't take hold and the syntax didn't make it into C#, but it was nice at the time.
These days I'd lean towards JSON.Net before anything XML based if I can avoid it. WCF could use a little love too.
Thank you for what you do for the .NET community! Especially for what you guys are doing with https://live.asp.net. I really enjoy all the discussions and banter between you, Jon, and Damian. It brings a much needed human-element to these big framework changes. I do feel like there have been many surprises along the way but you guys handled them just fine.
Not really sure exactly where OP is coming from, but kudos to you guys for all the hard work. Just worked on a MVC6 app recently and I really like the new DI and front-end tooling features. Thanks!
Scott, love what you guys are doing, keep it up! I did C# for 7 years and recently switched to Python but with the latest, thinking about switching back.
Couple of questions:
1) will non-Windows platforms be fully supported and performant in RC2 and RTM?
2) is there a good place to follow along the non-Windows work?
I owe you a long, private email (I'm a fan of your work.. and an ex Microsoft dev manager) but the way this was handled was not good. A RC that wasn't, public fumbling, throwing away schedules, and you can't even come up with a sane name for the damn thing. Too early, too weird, and poorly managed. For such an amazing, important technology that's such a massive leap forward in size and interoperability!
It smelled like OneDrive. And I'll provide this quote to demonstrate the type of insanity that leaks out of my beloved Redmond on occasion...
"Prior to Windows 8.1, we had two sync experiences. One used on Windows 7/8/Mac to connect to the consumer service, and a second sync engine to connect to the commercial service (OneDrive for Business). In Windows 8.1 we introduced a third sync engine..."
Current beef is the BashOnWindows alpha. Why was this pushed out so early? Quite literally nothing works on it. The forward progress even in the past few weeks is impressive but... it's bad. Ubuntu Trusty was a weird release to begin with and now it's in a weird time in its lifecycle where it's very difficult to get modern versions of gcc, clang, python 3.5 or even ffmpeg. Not that you could run cmake anyway. But meanwhile you shipped bits where "apt-get update" itself failed right out of the box. I don't get it.
EDIT: HN is limiting my ability to reply to you Scott but my frustration with Bash on Windows is both. The quality of the early bits is poor and I find the timing weird. Likewise Trusty itself is at a maximally frustrating stage of its lifecycle for anyone new jumping in (Stack Overflow is already filling up with newbie Bash/Ubuntu questions that are often tied to Windows bugs. And geeze, just let the insanity of that sentence sink in.) From a technical perspective I don't love the alpha. From a dev/engineering/coder perspective I don't love Trusty. From a strategic perspective, just like .NET Core, I'm wondering WTF is going on, thus the rant.
Maybe we'll have to agree to disagree. The public asked for open and we gave them Open with a pretty capital O. When this project started we didn't know we were buying Xamarin, so that required a pivot. Yes it looked messy because it was messy. It's hard to be Open AND Organized. Node is a mess, remember io.js? Software Development is messy and this was a peek into the kitchen.
I can't speak to OneDrive, but it's clearly a problem. Unfortunately, I work in DevDiv, not Windows.
As far as Bash is concerned, I think "literally nothing works" is not fair. I helped with this release. I presented on it for 90 minutes this morning and installed and brought in build-essentials, worked on redis-server, g++, ruby, and it worked fine. Yes there's rough areas, but we can update it often with WU. Also, you're complaining about Trusty in the same breath as Bash on Windows. You'll be able to update to 16.04 later so that might help. And, you're certainly able to Hyper-V any Linux and SSH in as well.
Keep up the good work, I love being able to see and play with the beta or alpha code. Things may not work perfectly, but that is why it's no production code.
I'll give a polite tip of the hat but warn that cutesy redis demos are starting to wear thin. The C++ support in the tools you get after installing build-essentials on Trusty smells like Visual Studio 2010.
As for .NET core, you'll get plenty of warm fuzzy "just happy to be part of the journey" crap here but don't forget that for every unemployed enthusiast chatting in an issues thread on github there are 100 professionals working their asses off trying to ship solutions. That's why you exist. Don't lose that.
"Things may not work perfectly, but that is why it's no production code." Ugh. They called it a Release Candidate! And it was... crap.
Tools support isn't like horseshoes, almost doesn't count. Likewise you need breadth and depth with your Linux support or this is going to be a total friggin' debacle for devs.
I'm in the bracket of the "100 professionals working their asses off trying to ship solutions" as my day job. What has the "unemployed enthusiast"s chatting on a thread go to do with me shipping solutions? Let the children boogie and i'll join in my free time :)
Something hip like one of the neural toolkits? I guess that would be hard to do since you can't install CUDA, R packages or the JDK at the moment. Maybe run Docker? Nope. Heck, I'd settle for being able to run tar or rar. Those don't work either. Cmake? Nope, broken. Valgrind? nope. Mono? nope.
He's welcome to run the same redis demo he does every tradeshow and pretend everything's hot and ready for action, but it's misleading at best.
We're focusing on mainstream developer scenarios to start with (esp. Ruby, Java, Python, etc); we'll get to more advanced, esoteric, and exotic technologies later.
FWIW, many core Linux tools (e.g. tar, gzip/gunzip) work* well, and tools like gcc/g++, Mono and CMake work* well in current insiders builds.
* By "work", we mean, they work in our scenario testing. If you find issues, please log bugs at https://aka.ms/winbashgithub.
I'm running the latest insider build. The bugs reported are based on personal experience and I verified they were currently open on GitHub as well before I posted. Tar hangs, cmake can't find a compiler, Valgrind goes nuts, and mono doesn't run. This is right at the top of the current issue list on GitHub with Microsoft annotations confirming the bugs.
I do what I can to report issues but frankly I do pretty basic development and hit an immediate brick wall with this stuff. I can't believe I'm celebrating Cygwin both for stability and breadth of packages. It's nuts.
I don't expect you guys to demo tensorflow. I'm simply saying that getting Redis limping borders on false prophecy.
"He's welcome to run the same redis demo he does every tradeshow and pretend everything's hot and ready for action, but it's misleading at best."
Here, I just built TensorFlow on my Surface while sitting here in an airport. Here's a screenshot: http://i.imgur.com/WlNNuVt.png
I'll try some more complex TensorFlow examples on the plane.
I'm sorry you're having (or had) issues with the build on your machine, but your negativity is kind of a bummer. We're happy to help chase down filed bugs.
I did a "make dist" and then tried to untar. It hung two builds ago. This build it hangs -- or worse, the files are corrupted. It's sort of ridiculous.
EDIT: Maybe it's bug #313? Anyway the Microsoft I used to know wouldn't release stuff like this. Step 1 fire all the testers. Step 2 "let the community vote." Step 3 is not profit.
When I am presented with a tool, a ship date, and a release candidate -- I set my timing and expectations accordingly.
When those expectations are not met, you're correct -- I don't use it. I also provide what the Redmond boys call "feedback." Having worked there it's easy for me to spot the knucklehead behaviors they tend to fall into. Inability to name or ship a product plus goofy tech decisions (like shoving everything they can't quite figure out into this "middleware" hole) usually means developer pain ahead.
PM for Bash on Windows here. In answer to some of your questions:
"Current beef is the BashOnWindows alpha. Why was this pushed out so early?"
We released this feature early because we wanted to get it into the hands of the community in order to learn how they'd use it, what tools they'd run on it, how it would stand-up to real-world use, etc. And the community has been AWESOME, filing lots of bugs (https://aka.ms/winbashgithub) and engaging in an overwhelmingly positive and supportive manner. Thanks to all of you that have provided your feedback.
"Quite literally nothing works on it."
This is just not accurate. There are a large number of things that do work surprisingly well on Bash/WSL, even in this early stage in its development. While Scott and I were on Skype, prepping for //Build, I curl'ed the Redis source tarball, unzipped it, apt-get install build-essential, built, and ran Redis, within minutes, without any modifications.
Are there many things that don't work? Yes. Absolutely. We've been very, VERY transparent about this and, in fact, state explicitly in our intro video (https://aka.ms/winbashav) and our announcement (https://aka.ms/winbashann) that there will be many gaps and that lots of things won't work.
But let's be fair here, we're talking about an early beta feature in early builds of a beta OS that you choose to download for free. If you don't know that you're going to experience issues, you should not be running Insiders builds.
"Ubuntu Trusty was a weird release to begin with"
No, it's not.
That you don't like it is merely a reality of the Linux ecosystem: Ask 100 Linux dev's which distro to use and you'll get perhaps 20 suggestions - Ubuntu, Debian, Arch, Fedora, CentOs, RedHat, Suse, Gentoo, etc.
WSL is designed to be distro agnostic, but we had to start somewhere, so we chose a stable, supported distro's that is very popular with developers - Ubuntu 14.04. We plan on supporting other distro as we expand and improve our implementation of WSL.
"it's very difficult to get modern versions of gcc, clang, python 3.5 or even ffmpeg"
Really? You're suggesting you don't build everything from source??? ;)
Realistically, we're aiming to benefit the most developers possible with this first release - there are far more developers using 14.04 right now than newer versions. And there's FAR more existing code targetting 14.04 era toolsets than the latest and greatest.
We'll get there, but you'll have to be just a little patient while we improve the breadth and depth of WSL's implementation.
They will get this stuff working, and it will be great. Because Microsoft. But whatever they're doing now is just stupid. I worked with some pretty chaotic teams at MS in high pressure situations and development was never approached like this nor was it this "messy." They're pretending this is how the sausage is made. This is not sausage.
First of all: software development 101. Is WSL even remotely feature-complete? So let's not call it a beta.
I'm not sure why you guys have such a hard-on for Redis, but... whatever. It is clean code that compiles on old toolsets. Much other code does not. Keep rocking those Redis demos, setting and getting values is fascinating. :)
Debating distros is pointless but I have noticed that Ruby (and oddly, Microsoft folk) tend to land on Ubuntu. Fine, no big deal. But Trusty was a weird release for them -- and the Canonical packages sort of suck. It's mid-2016. How much C++14 support would you expect to get from installing build-essentials? Shouldn't it compile code I'm writing in Visual Studio 2013? Would you expect to have Python 3.5 available? Would you expect to be able to type "apt-get install ffmpeg"? For various reasons these basic things do not work on Trusty. And then you made it worse by shipping bits that didn't even handle apt-get properly.
I'm not anti-Ubuntu other than to point out every bag o' bits reaches a point in its lifecycle where it's a total pain in the ass to set up a modern development environment. Trusty is past that point. It's an unfortunate thing to launch with. Not being able to move forward is also unfortunate. Don't punt on that, trust me. If WSL actually worked, people would be screaming about that instead of all these noise bugs. You'll see.
If you want to triage this, get Canonical to offer some more modern packages. Again, I'm not sure why Microsoft hopped into bed with Canonical (especially on the Azure/container side)... but ok. Now get them to ease some pain. I shouldn't have to install a half-dozen shady PPAs to try the stuff that hits the HN homepage every day.
And I truly despise this "let's see what the community wants" fake project management technique. You know damn well what features you need to implement. You knew damn well what C99 stuff was needed 10 years ago. "Send us a note if it doesn't work" is lazy, shortsighted and damaging to all parties. It's community management, not engineering. Project Management via squeaky wheel is just stupid in 2016. It didn't work prioritizing C99 features and it's a particularly stupid way to implement a shim library for Linux userspace. This is Open development done wrong.
