> This will have to be very good to be better than Visual Studio on Windows.
Really? I feel MS has really dropped the ball with VS. VS2013 was OK, but not great. A lot of random lock-ups in really annoying situations where you can't even fathom why (like opening a text file). VS 2015 is actually awful - it wasn't until Update 1 that typing this (below) in C# would pop-up an on screen exception dialog:
class Foo : Bar
{
public Foo()
:
Pressing enter after the colon would throw the exception consistently. How on earth was that missed in testing? This is such a common C# pattern for invoking the base or this constructor.
I often find myself staring at the screen, saying in my head 'What the hell are you doing now!'. The new DNX project system is unusably slow (compiling) and the tooling for it is non-existent. And for me it still crashes all of the time. Other devs on my team are having similar problems.
TFS and TFS explorer is a total joke. The 'offline mode' is slower than online mode, and also causes crashes. If I lose my VPN connection then I have to shutdown VS and restart before TFS will reconnect again (this has been an issue for every version of VS I've used). Luckily we're moving away from that travesty of a system to git very soon (the VS git integration is actually pretty good).
I used to feel that VS was a really solid piece of tooling, and I agreed with your sentiment that I quoted. I don't any more. I will check this out, and if it works then I'll happily drop VS, two years ago I couldn't ever imagine myself saying that.
I've been rather pleasantly surprised at how much support MS are giving git and github - they offer git hosting on Visual Studio Online and the Azure documentation is in github.
This has been the case for C++ for a while now. Every version of VS has gotten worse since, IDK, 2006 or something (and that's ignoring how long it takes them to finish new versions of the language). I had a suspicion that they had moved their A team over to work on C#, but hearing this... maybe they're just getting worse.
For C# at least every version is at least better than the previous. 2015 was the big Roslyn makeover so I suppose I can accept a few more regressions than usual. But feature-wise, each version has had at least one killer feature that made the previous seem dated on day 1. Examples: edit-and-continue, or lambdas in watches.
I hate to say this, but a lot of your issues might also be coming from the TFS integration. I know I used to have a bear of a time with random crashes and issues. Since switching to git & resharper I have had a much, much easier time.
With 1 notable exception of 1 huge project.
On large, 40+ project, solutions it seems like Visual Studio just falls on its face. Our new team is redirecting toward microservice approaches in light of some of these frustrations.
Not that your arch should be dictated by your editor, but quality of life is what it is.
> I hate to say this, but a lot of your issues might also be coming from the TFS integration.
I suspect some of the problems are, for sure - our big internal project is a multi-million line app, maybe 70-80 csprojs. VS2013 dealt with it OK, but had its occasional problems (the TFS issues weren't occasional though), VS2015 is much worse in general. It's very unstable.
My open-source project LanguageExt [1] uses git and isn't that large. I still get crashes and lock-ups. It was the first project I migrated to DNX also. It takes an age to build (where the sln/csproj system doesn't), and nails the CPU (99% usage). Something is very wrong, and very unfinished.
I can see where MS is going with this new open-source tools approach, but at the moment the whole thing seems to be a mess, and VS just can't deal with it. The one ray of light is the git integration. That works for the most common scenarios. I only occasionally have to drop back to the cmd line.
It seems like every time there's a new project format the first version is just really awful. I think they really only test it on small almost toy-level projects thoroughly but fully conjecture.
That's a very cool project though - what got you going on that? If I could convince my coworkers to not kill me for doing so, I would try to introduce using that at work :-) I've definitely gotten them on to the immutability by default train of thought tho - a lot of people very happy with that mindset considering how much of work has become parallel processing. It's amazing how much faster you can do things like build invoices of thousands of items when you can process the whole thing in parallel :-D
My pref has always been command line tbh - getting away from TFS was the best thing that ever happened for me.
I'm a CTO of a healthcare software house in London, we've been developing a very large web-app in C# over the past 10 years. Over the years it has evolved as any project does, but I started noticing more and more that OO was really not the right tool for the job of managing large inter-dependant systems (well, the Java/C# brand of OO anyway). The promise of re-use, decoupling, composition, ... all seemed to be lies. On top of that I started to get a sense of the common bugs that were coming through: null-reference errors being by far the biggest. The in-your-face bugs like null-ref errors are relatively easy to spot though, what becomes more problematic over time is shared mutable state logic errors. They can remain buried for some time.
I'd already had an interest in functional programming piqued by LINQ and Erik Meijer's talks on Haskell. I spent some time learning Haskell and F#, and came to the understanding that the stability and reliability of a system could be massively improved if null didn't exist, if objects were immutable by default, and if functions were pure/referentially transparent. Expression oriented programming became my order-of-the-day, but C# kept getting in the way. Unfortunately I couldn't just drop it and move to F# because our code-base is huge and written in C#.
So that's when I started writing csharp-monad [1], it was my first attempt at bringing functional concepts into C#. It had a couple of problems though, and they were:
* The types were classes, and therefore if a function returned Option<T> then it could still be null
* It followed the '.NET BCL way' of having functions like GetValueOrDefault() - again breaking the safety net that an Option type (for example) is supposed to give.
It had benefits though, primarily that I could make composable computations with the various monads (using LINQ). The problem with that approach was that it quickly bumped up against the rest of the BCL. And, in my case, the rest of our multi-million line C# OO app.
So I mothballed that project to an extent. I'd use it now and again where I had control over a process end-to-end. But it got me thinking, that the main issues I had were:
1. Non-expression based C# constructs (if/else, switch, etc.)
2. OO-heavy core types, like List<T>, Dictionary<K,V>, etc.
3. Whenever I brought in 3rd party libraries that 'did functional', they wouldn't work with my Option type in csharp-monad, or any of my functional types - and they never could because there's no baseline for functional (other than LINQ) in C#.
4. The lack of more expressive LINQ grammar makes it less useful and sometimes more cumbersome than Haskell's 'do' notation or F#'s computation expressions.
1-3 cries out for an equivalent of a BCL for functional constructs. I was under no illusion how big a job that would be, but I could see real value in it: a unified set of types for Option, Either, Try as well as collections Lst, Map, etc.
"A functional prelude for C#"
And once I saw that C# 6 allowed 'using static' I saw that as an opportunity to really create a 'functional BCL' that actually looks like a functional language. A chance to take C# in a more Scala-like direction (which if you think about it, is where it's going, it just doesn't have the libraries to support it). So that's when language-ext [2] was born.
Item 4 was more problematic. I couldn't create more LINQ grammar. So I started thinking about it in a different way. Mostly I wanted to create expression oriented code. It was just safer. But with C# OO you always hit that expression boundary. So I thought about how I could control the boundary. Some of that was to build 'matching' constructs into the core types, but that wouldn't deal with all boundary issues. That's where the actor system comes in (LanguageExt.Process [3] ). I'd looked at Akka.net and its very Java-like API horrified me - it looked like C# 1.0. So I took the idea that a LanguageExt Process (an actor) is a fold over a stream. That suddenly created a very powerful idea that I could create packets of pure computation and wrap them with their state, and each message would evolve that state. In one fell swoop it created a better and more controlled OO that can interact with pure functions - and all fully integrated with the functional BCL I'd developed. It also allowed us to start breaking up our monolithic app in a much more controlled way.
So yeah, that's the back story! Sorry if it turned into War & Peace.
Btw, I am in the market for two developers at the moment. So if none of what you just read horrified you, please drop me an email with your CV to plouth AT gmail :)
TBH, I've been using VS2013 since release day, and I can count on 1 hand the amount of times it has crashed on me when running natively on a workhorse computer.
I had tons of problems with it when I was running it in a VM on a MacBook Pro though...
Really? I feel MS has really dropped the ball with VS. VS2013 was OK, but not great. A lot of random lock-ups in really annoying situations where you can't even fathom why (like opening a text file). VS 2015 is actually awful - it wasn't until Update 1 that typing this (below) in C# would pop-up an on screen exception dialog:
Pressing enter after the colon would throw the exception consistently. How on earth was that missed in testing? This is such a common C# pattern for invoking the base or this constructor.I often find myself staring at the screen, saying in my head 'What the hell are you doing now!'. The new DNX project system is unusably slow (compiling) and the tooling for it is non-existent. And for me it still crashes all of the time. Other devs on my team are having similar problems.
TFS and TFS explorer is a total joke. The 'offline mode' is slower than online mode, and also causes crashes. If I lose my VPN connection then I have to shutdown VS and restart before TFS will reconnect again (this has been an issue for every version of VS I've used). Luckily we're moving away from that travesty of a system to git very soon (the VS git integration is actually pretty good).
I used to feel that VS was a really solid piece of tooling, and I agreed with your sentiment that I quoted. I don't any more. I will check this out, and if it works then I'll happily drop VS, two years ago I couldn't ever imagine myself saying that.
Competition can only be a good thing here.