[sebcat]

I'm from a Linux/FreeBSD background. I'm currently doing work on a Windows platform.

> Oh and VS support for git has been around for awhile. :) TFS also has really good git support, it has been improving with every version and it is now at a really good place.

Git in visual studio does not work well. I'm using the built-in stuff in VS2013. If you want to do anything except the standard stuff (add, commit, pull, push without fancy options), it's horrible. There's no UI support for anything, and no CLI. I find myself resorting to msysgit a lot, and it has it's own problems. And the other devs laugh at me for it ("You're running bash, on Windows? Huehuehue"), only to experience the same problems as I do.

The .NET "async" model is not good for I/O bound problems, which is what I work on. Want I/O multiplexing? Well, you can have IOCP, but most people end up with one thread per connection anyway because I/O multiplexing is not an option in most parts of the library eco-system. Want to make an HTTP request? Have it done in a worker thread, because your HTTP library is blocking. I know things are changing, and I know there's other ways to go about this, but the author's claim that the concurrency model offered by .NET is inferior to others is a very valid one. I've done work in Java previously and it's basically the same problem. I've also experienced problems with lock contention, corner-case deadlocks, &c. Now these are problems related to the codebase, not the language itself, but threads as a concurrency primitive tends to cause programmers to make mistakes more often than other concurrency models in my experience.

And no, make files and .sln files are just not the same. They're both a part of the build system, but that's about it. I'm not even going to argue a point here, because it just fills me with rage to think about that god-forsaken fragile, XML setup that is .sln.

[MichaelGG]

Perhaps you know less about the build system than you think. SLN is NOT XML, it's some strange line-based format, that essentially lists projects. From there the whateverproj files are XML and valid MSBuild files.

Git works fine in VS. Use Git Extensions.

[sebcat]

> Git works fine in VS. Use Git Extensions. I don't know, but I think Git Extensions is superseded by the built-in Git support in VS2013. And it's very limiting if you want to do anything except the basic add, commit, pull, push stuff.

[MichaelGG]

Superseded? How so? It's a third party plugin, just keep using it. The VS native stuff from MS is very immature but "ok" for simple TFS-like workflows.

[SideburnsOfDoom]

> Git in visual studio does not work well. I'm using the built-in stuff in VS2013. ... I find myself resorting to msysgit a lot

You can use the git cli if you like, you can use TortoiseGit or GitExtensions. They all interoperate really well. That's the strong point of a popular open-source system. I never saw the reason why the source control system has to be integrated into the IDE before it's usable. They all operate on files and file systems, not on compilers. Why is it hard to do the commit in a different window to the coding?

> want to make an HTTP request? Have it done in a worker thread, because your HTTP library is blocking.

I'm having great results with .Net 4.5 and "var response = await httpClient.GetAsync(url)" The HttpClient and async/await came out in August last year. Is that kind of code what you mean when you say "Have it done in a worker thread, because your HTTP library is blocking" or are you using a prior version?

[com2kid]

> And no, make files and .sln files are just not the same. They're both a part of the build system, but that's about it. I'm not even going to argue a point here, because it just fills me with rage to think about that god-forsaken fragile, XML setup that is .sln.

SLN files are not really part of the MSBuild system at all, nor are they XML. They seem to exist solely for the IDE's benefit!

Indeed I've used plenty of projects that use MSBuild but no SLN files.

[sebcat]

My mistake, I was confusing .vbproj/.csproj-files with .sln files.