But when it comes to automating my build process, doing continuous testing and deployment, setting up a environments in containers, or just where I'd rather spend most of my time operating- I'll take *nix and Java all day over IIS/Windows server. No thank you, the only Windows I have in my house is a VM for using Visual Studio and writing C# web apps on the occasion I need to for personal stuff.

I will be truly happy when I can write C# code and deploy to something like Tomcat. I will never again go back to Java when that day comes.

An example: I opened a case when IE9 was in developer preview with partner support. When they rewrote the download manager in IE for this release they changed how download prompting worked and removed a setting from the UI (and left it in the registry). This broke ClickOnce launches entirely for over 2000 users for us. Fast forward nearly 5 years and it's still broken, the case is still open and to get everything to work for the client we have to frig a registry setting on every workstation they roll out. That sucks for us and the client, badly.

This is a typical story for us. When you deal with VSTO, MSI packaging, managing large clusters of windows server machines, random bugs that just blow up in your face suddenly after working for years, signing code, trying to get repeatable builds out of a CLR solution and automating all of these things, forget it. PowerShell gets you 80% of the way there but the last 20% is a tar pit of pain and impossibility.

Now I've been in the Microsoft ecosystem for 20 years, certified and bought into it all. Perhaps I'm bitter and tired but I can't see past all this experience and have mixed memories of c#. All I see is hung instances of visual studio and working out which project file is buggered and all this is destroying the best language I ever used. I don't want to waste my life on giving them another chance.

There is literally none of the above on Unix platforms from experience. I've only encountered one bug in the last 15 years due to a CIFS kernel bug and RH fixed it within two days. I haven't had any automation friction at all.

I'm worn out and confused to be honest when I read back this post.

Have you worked in commercial UNIXes?

I have some HP-UX, Aix and Solaris war stories.

To be honest windows (NT series) operating systems were pretty trouble free in the NT4 era. The masses of fragmentation and numerous paradigm shifts were what broke it all for me.

I feel that people need to feel and experience both side end-to-end deep in the bowel to be able to judge Java/C# because it's more than just the language; it's everything! IDE, Tools, Libraries, Environments, etc.

so MS is aware that this process should be more light weight for many situations, and appears to head in the direction of node.js type hosting for times when you don't need all the IIS features.

MS makes some great technology and some terrible tech... but the problem is the terrible tech gets the same blessing as the great tech. An open-source community is the best way to develop best practices and properly replace their false-steps.

So if people won't pay for operating systems what will they pay for? Stuff that still costs them money, i.e. hardware infrastructure and attendant maintenance and administration. Hello cloud. Development shops are happily sending Amazon millions of dollars a month so they don't have to buy servers, set up server rooms, hire system administrators, and worry about things like air conditioning, big UPS systems and emergency power generators, etc.

Alongside Amazon, Microsoft is doing pretty well with Azure. And you can run free operating systems on Azure, and .NET is already well supported on Azure. So what will sell more Azure? Make .NET run on the free operating systems. Now all the developers who like the free OSs on their personal dev systems are suddenly able to develop stuff they can deploy on Azure. What about all the devs that like Macs? No problem, make .NET run on Mac OS X as well.

I think this is all about making Azure services more compelling and more able to compete with Amazon than it is wanting to do "nice things" for the open source community.

In the end I think this is overwhelmingly a net positive for both MSFT and developers.

A lot of good things happening in Redmond right now.

Now if they can somehow fix this upcoming Lync is now Skype Business business, I'll be really impressed.

However, I think they know that if they completely abandoned the .NET framework, there would be a community of very upset devs that have spent their entire careers investing in Microsoft. Instead, they're doing a slow withdrawal and "giving it to the community".

I think that in the long term, they're going to be focusing more on Sharepoint, SQL Server, and Azure; less on .NET. That's just IMHO.

To be fair, he probably wouldn't have been able to set it up initially by himself. But I've had really good luck getting family members on Linux lately. I can Ssh in and do updates or make changes and it's way easier than remotely administering windows.

Also, being open source means being open and transparent about release cycles and roadmaps, which takes a lot of effort and initiative. I do think Microsoft can do that if they build a solid team of technical community evangelists, but otherwise, they will be swimming against the stream.

And what makes it such a good language for you?

I have worked with prettier languages, for instance I have picked up Haskell recently, I have also worked with faster languages, C was my forte for many years and I have worked with languages in the GSD category like Ruby and Python.

C# is appealing not because of some feature that it has that other languages don't. But rather the long list of things they didn't fuck up. For instance by building concurrency and evented programming semantics into the core there isn't multiple competing event loops for instance. (unlike say Python or Ruby which have about 5 each, Java has more than I can count).

It's not so much there is one single thing that makes C# really nice, it's the whole package.

It opens an almost frictionless asynchronous pathway from your code all the way down to asynchronous capabilities of the underlying platform. Which was always the problem with leveraging async/overlapped IO: It was too complex and it turned your application logic inside-out because everything had to be performed in callbacks. async/await takes that on directly: You get everything executed in callbacks - only the callbacks are transparently created for you along with the necessary finite state machines so that your code still composes with exceptions, loops, branches working the way you expect - even across those "invisible" callbacks.

For server scalability as well as responsiveness on small devices (keeping number of thread low - even at one - while still serving the UI), that is really an advantage.

There is no "fakes" on the way - no extra threads being started just to wait for completion of an otherwise synchronous API. If the platform supports asynchronous IO/network/disk/database you can leverage that without any of the strange complexities of other languages.

Worth mentioning here is that Windows has an easier scalable and better designed completion oriented async model compared to the readiness oriented model of Linux - which is mostly limited to sockets anyway.

OS X has GCD - which is also a completion oriented model. I look forward to seeing how .NET with real global optimizing compilers from MS will do on OS X versus Linux versos Windows (on a Mac, obviously).

Also as of recently there is a standard library event loop package, and as far as I know Twisted was the defacto event loop on 2.x for most types of work.

From the usability standpoint I see that they are more or less similar. However since you state that async/await exploits the asynchronous capabilities of the underlying platform I'm really curious to know how is this different from the way the way Future is implemented in a JVM.

Async/await allows developers to write code that looks sequential, but is rewritten by the compiler into a sequence of coroutines built on top of TPL, while taking care error propagation happens correctly.

Edit: Sorry, messed it up a little bit. BlockingCollection will block your current thread for any other computation and does not allow to await on it.

But there seem to be alternatives: http://stackoverflow.com/questions/21225361/is-there-anythin... http://blog.stephencleary.com/2012/12/async-producer-consume...

Want to make a screenshot of the desktop? Got it. Want to post keystrokes to another application? No problem. Ohh I see you want to write a tcp server with asynchronous processing? Here's some generics you can just c&p.

I know other languages have these features too, but C# makes it so damn easy to use in the stdlib it's just not funny anymore.

They've realised recently this is having a negative effect on open source C# code as so much of the community waits for the "offical" version, but it has its positives too, almost anything you want to do is in the core libraries.

I mean, Entity Framework is great, WebAPI is slick, and MVC has its moments, but there are some real trainswrecks. I've used all three XML serializers in the .NET framework and they're all cringeworthy. ASP.Net WebForms could have been something spectacular with open development instead of the hideous monstrosity it was. And MSBuild would have been laughed out of the room and regarded as some kind of bizarre eccentricity like TempleOS or UrBit instead of a serious build system.

XmlSerializer, DataContractSerializer, and what is the third? I agree and was about to point out the same thing though; XML serializers in .NET are a joke but because they exist in the core libraries there is not really a compelling open source alternative.

That being said, it seems like the Asp.Net Web API is actually using Json.Net instead of the built-in serializer.

i never slept as much or as well than when i tried to work through the documentation.

People keep bringing up Scala, last time I tried Scala (~ year back) the compile times were pretty long and the IDE support was sluggish and I have a decent PC. Nowhere near to C#/VS development experience.

I'm happy .NET is going open source path but still think we need others to compete.

Fortunately Windows has implemented message-passing event loops for you for a couple of decades. And they're pleasant to work with as long as you don't mind everything being a WPARAM/LPARAM.

Server applications like a async socket server use IOCP, a kernel based type of event loop that is highly performant and scalable. And by the way, the .NET CLR already uses them at its core for sockets and other types of I/O.

Linq makes C# much better, especially compared to java. It's a whole different story in F# though.

I'm a Haskell enthusiast, but it's not so good at Windows support, or libraries. I've been thinking F# might be just the ticket.

Type providers http://fsharp.github.io/FSharp.Data/library/JsonProvider.htm... Code quotations http://msdn.microsoft.com/en-us/library/dd233212.aspx

Most importantly it has become a first class citizen of the ecosystem so the tooling is already great compared to a lot of similar languages.

http://fsharp.org/

http://blogs.msdn.com/b/fsharpteam/archive/2014/11/12/announ...

If you know Haskell then it's pretty easy to get into F#. The only thing you'll miss are higher-kinded types. Although they can be hacked in[3], it's not really worth the effort a lot of the time

[1] http://msdn.microsoft.com/en-GB/library/hh225374.aspx

[2] http://msdn.microsoft.com/en-us/library/dd233182.aspx

[3] https://code.google.com/p/fsharp-typeclasses/

I'm still trying to get my head around it; I thought I'd try to do so by implementing the core types and functions in Haskell's Pipes. So far I've managed to convince the F# compiler to take well over an hour to compile 70 lines of code!

The main argument against them has been lack of CLR support. But it seems that there's already the FsControl way, so I think some syntactic sugar would go a long way.

So yeah, until there's language support for type-classes I think it's probably not worth it.

[1] https://github.com/gmpl/FsControl

I'll have to go study FsControl now ;)

I worked at Microsoft for a couple years and I could already smell this brewing. The devs I respected the most were also the most unhappy with the platform tie-in. This is a desperately needed political shift for the organization, and I think it will actually boost morale as well.

But the JVM platform is great, and I'm just not going to get locked into a MS ecosystem. But if MS opens up to the rest of the world, well, that changes things considerably.

It has been since lambdas were introduced in Java 8. Groovy's original design by its creator James Strachan was about adding closures to the dynamic typing that Beanshell had at the time. The stuff added to Groovy since then (e.g. the MOP for Grails, DSL syntax, static typing in 2.0) are things Java already does better or things (if you ask me) it shouldn't do.

I can also testify as someone who uses Scala on a day to day basis and used C# at work as well - I completely understand your statement, although it's very subjective.

A), it was an uncalled-for digression into language wars, and

B), now that we're here anyways, a lot of us think the majority of features in scala and Haskell for that matter are fundamentally misguided. My goal is not to write elegant code, but to write the least complex code with the lowest cognitive overhead. TCO, 10x the man-hours in maintenance and all that. If the choice is between having to write null-checks or having to understand category theory to read my code, I'll take the null-checks.

B) Precisely, unlike Haskell, Scala doesn't force you to write "elegant code", you can even use variables. Purists will flame you for that, but sometimes it's the best way to write a small piece of code and as soon as no state leaks outside of the function, it's not that bad. That said, I believe most of the features of Scala make maintenance easier, including the absence of null-checks as it moves errors from runtime to compile time and make major modifications without regressions easier.

The only difference worth mentioning is that they type system won't allow "leaks".

Me too. Luckily this is a false dichotomy.

def :+[B >: A, That](elem: B)(implicit bf: CanBuildFrom[Repr, B, That]): That

This is from the standard collections library.

In Java, I've got a List.add function. In case it's not clear from the name, 'add', I can click through to the implementation and it's pretty obvious what's happening.

In Scala, I've got +, ++, +:, :+, and a bunch of other nonsensical bullshit, and when I click through to the implementation? Even less sense. Whenever I use a standard scala collection, I have no idea what it's actually doing. Additionally, everything favors allocation-happy overly-clever immutable wrappers rather than a simple ArrayList which will smoke those immutable implementations in real-world performance.

The cure is far worse than the disease, here.

Scala's collections have some quirks, but not as many as .NET's collections and you're actually comparing apples to oranges, because you won't find the equivalent of an "add" that returns a new collection instead of modifying the old one in .NET.

This is what happens when you pass judgement unto things you don't understand. Working with immutable data-structures is really, really awesome and Scala's API for these collections is very friendly and very type-safe - as in, if you feel the need to use `isInstanceOf` / `asInstanceOf`, then you're probably doing something wrong ;-)

And I really wish that C# would grow up a little in this regard, as modern programming languages need immutable collections as well, with a nice API to go along with it. And btw - working with Option is super awesome, no category theory needed.

That said, as I was saying in another comment, I'm really excited about this announcement, because this is mostly about the runtime, not the language. You can run things built with Scala on top of .NET right now by means of IKVM. And the JVM finally has some credible competition.

http://msdn.microsoft.com/en-us/library/dn385366(v=vs.110).a...

I think it's kind of the point if the judgement is on the question "what is easier to understand". I think this is the sentiment many people staring to learn Scala are feeling - the barrier to entry, even if you are coming not from the blank slate but from the background of programming many years in many languages, is pretty high. It's not the judgement on "whether Scala and its collections are good/done right", which is entirely separate question from "whether it is easier for someone to understand how C# collections or Scala collections work".

>>> And btw - working with Option is super awesome, no category theory needed.

Well, if you want to do something like making a function that works on Option from a function that works on the underlying type, you pretty soon find yourself in that general area.

As far as not understanding how awesome immutable data structure are.. I'd take a step back before you make assumptions about what other people understand. Do you know anything about cache hierarchy and memory models on modern CPUs? Performance is important to some of us.

Yes I do. Worked 3 years on a soft real-time system with massive load, profiled the shit out of everything. There's an interesting discussion we could have about when immutable data-structures work best, when they've got problems and when it doesn't matter, especially given the extra benefits in dealing with accidental complexity. This isn't the right place though.

> Performance is important to some of us

Yes it is, but performance problems are fixed by means of profiling and optimizing the bottlenecks. Even in a system that has massive load, in many cases in doesn't matter and in some cases immutability increases performance by eliminating contention on reads. And seriously, most people invoking performance problems are not having those performance problems to begin with, therefore my assumption.

As I'm sure you know, when it comes to real-world situations, reducing inter-thread communication and isolating anything mutable is the key concern. That's why I find immutable wrappers that mock mutability to be a bit of a sideshow. You shouldn't have read contention with locking in the first place unless it's for a very good reason.

True, but you know how it is in practice :-)

For example I found that using persistent data-structures work best when you've got single producer, multiple consumers scenarios - so you mutate some state and you want to signal it over asynchronous boundaries to multiple consumers. With an immutable data-structure you just signal it, worry free and then you can keep on changing that state, completely non-blocking / wait-free and with good algorithmic complexity.

Actually non-blocking logic becomes really easy, as you can always shove an immutable value into an atomic reference (note - I'm not saying "wait free", which still takes a lot of work :))

So really, persistent data-structures are great in a multi-threading context, as long as you don't have multiple producers pounding on the same reference holding such an immutable value - if you do that, things can get bad, when compared to specialized concurrent mutable data-structures - because a good concurrent data-structure is able to distribute the contention in multiple buckets instead of just one. But then again, having multiple producers pounding on the same resource is just asking for trouble and has to be avoided, because Amdahl's law.

Also, as you've hinted at, the problem with a normal linked List is the level of indirection. And in general, persistent data-structures imply the usage of trees, which also implies indirections. More advanced persistent data-structures are much better than the linked list is and this is an active area of research, but on the whole there's still much room for improvement.

On the other hand, in my opinion when speaking about performance, the first problem one has is to actually use the available CPUs (e.g. getting CPU usage over, say 70-80%). Which usually is hard to achieve if you have a combination of CPU-bound and I/O-bound tasks and your I/O stuff is not asynchronous. Only after that you can then move on to optimizing the memory access patterns for cache locality and for minimizing the stop-the-world freezes.

Speaking about GC, that's another topic - persistent data-structures have a tendency to generate junk that is neither short term or long term and that invalidates the assumptions that current GCs are making. The JVM at least has really good GCs, but without paying for a pauseless one (like that one from Azul Systems), you can still end up into trouble if you don't pay attention - but then you fire up YourKit's Profiler, find the source for those STWs, optimize and it works out well.

All in all I encourage everybody to find a good library that implements persistent data-structures and integrate them in their toolbox.

The one thing I disagree with, in many server applications, is using the available CPUs is pretty easy. You've got thread pools handling various tasks, just crank them up. In JVM-land, a very heavy 512kb stack per thread is still not really much penalty to pay as long as you re-use them. Aggregate application performance then becomes a matter of completing tasks faster while creating less garbage.

So it all comes down to what you consider a 'task' and how you handle the handoffs between them. The architecture decisions at this level dwarf the improvements from using an array vs list, as you implied, but they also make the usage of immutable types somewhat irrelevant IMO. Seal off mutable code within single-task boundaries and it doesn't matter how ugly it is, as long as you're passing immutable types (just plain javabeans with final members are fine) between boundaries.

Anyways, just my opinion. Great comment.

Why the atomic reference here? I know that provides CAS but if we're talking about a single writer aren't you okay to just replace things anyway?

Thanks!

Gotta test for any chinks in the armour.

Yes.

> Performance is important to some of us.

... and in those cases, you don't have to use data structures that model your problem domain poorly.

The problem isn't "immutable data structures" or "theoretically robust" languages. The problem is finding ways to express computations and their constraints in a way that can be efficiently modeled for your problem domain.

So what will probably happen is that once you see your performance problems, you can pray that it's only some hot spots that you can then replace with faster code - often it's not, so you have 100 places using around 1% of your time budget for example, which is when you can go and start over.

Admittedly not part of the core library, but installing a NuGet package is pretty darn easy.

>>This is what happens when you pass judgement unto things you don't understand ;)

[edit: Guess I should've refreshed the page to see the prior response before writing this. Apologies.]

You're rarely actually going to _see_ that signature (the docs actually simplify it for you), and in practice, it's completely meaningless to 99.9% of Scala you'll ever see.

You might as well consider it pixie-dust.

+ for one, ++ to add a collection, the others are generally going to apply to Cons-like. It takes all of a couple minutes to let these sink in.

Use a mutable.MutableList if that's what you want. Or just use ArrayList.

All this is about as pure FUD as I've ever seen...

Your typical Java developer is used to just look inside the code of whatever library they are using, and find a very straightforward implementation. Scala collections avoid a lot of boilerplate with canBuildFrom, SeqLike and suck, but simple and straightforward they are not. It takes quite a while before it stops reading like Japanese.

And IMO yes, a lot of symbolic methods in collections make relatively little sense. Don't forget that list also has ::, :::, +:, :+ and :\. There's more than a few, and there are no textual versions of them, for those that don't have them all memorized. They are a bit of a relic from the time Martin thought that /: was a good idea. It's fortunate that now only the scalaz people keep doing such things, because excessive use of symbolic operations hurt language adoption.

And he doesn't even get into other early confusion points, like how we have =>, <-, and ->, or how decomposing Seqs is not exactly pretty. Last week I had to help a guy that had been using Scala for 6 months to understand the 'punched in the face' operator :_*

So no, it's definitely not FUD. Are they issues that hurt my day to day Scala use? Not at all. Scala is my favorite language. Being able to use it instead of Java or Clojure is worth a good 15K a year for me.But that doesn't mean that I have forgotten some of the little things that made the learning curve tough at first. Thanks the heavens that I managed to end up finding a Scala job where I could learn from one Bill Venners.

That line alone drives home the point for me, you can read the rest of scala.collection.immutable if you need more convincing.

I'm interested in the Haskell part. What features do you think are fundamentally misguided ?

But, for example, https://www.haskell.org/tutorial/io.html.

At the end of the day, this is a huge inner-framework anti-pattern over the same procedural syscalls that every other language handles procedurally. I shouldn't have to care what a monad is, and side effects? The whole point of I/O is side effects. It could be a no-op, idle process or CPU-burning busy loop if I didn't care about side effects.

From that doc:

" So, in the end, has Haskell simply re-invented the imperative wheel?

In some sense, yes. The I/O monad constitutes a small imperative sub-language inside Haskell, and thus the I/O component of a program may appear similar to ordinary imperative code. But there is one important difference: There is no special semantics that the user needs to deal with. In particular, equational reasoning in Haskell is not compromised. The imperative feel of the monadic code in a program does not detract from the functional aspect of Haskell. An experienced functional programmer should be able to minimize the imperative component of the program, only using the I/O monad for a minimal amount of top-level sequencing. The monad cleanly separates the functional and imperative program components. In contrast, imperative languages with functional subsets do not generally have any well-defined barrier between the purely functional and imperative worlds."

So, basically, they acknowledge that their theoretical model has a huge impedance mismatch with what we write programs to do (I/O, eventually, somewhere). And that's fine, they can knock themselves out and I hope it's fulfilling for them. It's not for me.

Separation of pure and unpure components greatly simplifies the reasoning about the problem domain. Traditional imperative programs are often full of subtle bugs because calling a procedure can have arbitrary effect on your system. For example calling function with the same arguments can return different values based on arbitrary hard-to-track reasons (such as your OS's scheduler). It's just too much details to keep in your head.

But in Haskell pure functions are guaranteed to have same result with same input. It enables the programmer to create logically isolated blocks without messy interdependencies.

It's especially helpful for concurrent programming by freeing you from all the non-deterministic spaghetti.

Haskell has a steep learning curve, but it'll make you a better programmer in the long run.

Sure it does, and composes well under it.

There's no theoretical stuff here, it's just making sure that the caller knows about callees having side effects.

No, you have a tiny, very simple type that allows for type safe IO. It also happens to make haskell a more powerful imperative language than most imperative languages, as IO actions are first class and can be passed around and manipulated like anything else.

>So, basically, they acknowledge that their theoretical model has a huge impedance mismatch with what we write programs to do (I/O, eventually, somewhere)

No, they acknowledge that doing IO is so important that it should be done correctly. You are going to some pretty extreme mental gymnastics to misrepresent a language you want to hate.

The I/O monad modifies the Universe that contains the set of all functions that comprise your program (if I even understand the concept correctly).

That sounds rather complicated. My way of thinking of it is simpler than that. a -> IO b is just a function from a to b that can do some I/O. Nothing more complicated than that.

The right half is usually empty, except when you use the `>>=` operator (or flatMap) on an existing action, e.g.

let c = a >>= f

That operator chains the function `f` can take the value produced by the first IO action and produce another IO action. After we apply that operator, the result `c` is a cons cell where the left part is the original action `a` and the right part is the function f which takes the value produced by a and produces the next action. Its sort of like a cons cell in regular lists, except the next value is provided by a function. A lazy cons cell, perhaps :)

The final result is a lazy chain of I/O cons cells (called "main", of course :P). Its passed to the Haskell runtime, which executes that chain as a recipe, alternating between doing I/O actions and evaluating the function to decide what to do next.

So what does this buy us? Mostly just referential transparency. What does referential transparency buy us? Easy refactoring. We can replace any expression with its value, even stuff like `putStrLn "test"`. We can say `let writeTest = putStrLn "test"` at the top of the file then write `do writeTest; writeTest` in main.

Another neat thing is that do syntax isn't limited to just IO, but works with anything that implements `flatMap` (and `unit`, which I forgot to mention). That means we can build our own imperative DSLs that produce IO-like monads which are then interpreted by our own interpreter, and the users of those DSLs can use the same do syntax. Which is pretty awesome. Here is a simple example: https://gist.github.com/tonymorris/b5dba9d7d877051d0164 and a much more complex one http://augustss.blogspot.com/2009/02/more-basic-not-that-any... :)

You can handle every single error explicitly (as in Go) using pattern matching

  eitherResultOrError = operation1 arg

  case eitherResultOrError of
    Left error -> handle error
    Right result -> handle' result

  let eitherResultOrError = do
    x <- operation1 arg
    y <- operation2 x + 1
    z <- operation3 x y

  case eitherResultOrError of
    Left error -> handle error
    Right result -> handle' result

For IO operations and other monadic actions, its best to use EitherT, ErrorT or MaybeT, which are monads that can add error handling to any other monad. To understand how these work, its probably best to implement MaybeT. Basically, they add another wrapper to other monads to redefine what the bind operator (`>>=`) does

One doesn't have to learn category theory to realize that Options are great, especially when accompanied by a little bit of help from pattern matching, map, flatten and getOrElse.

The fact that many Scala lead figures that come from a Haskell background are bringing with them a holier than thou attitude doesn't mean that there aren't some functional concepts that are very useful even if your code is mostly imperative, and Option is arguably the least controversial of the lot. It's so uncontroversial it's in Java 8, although suffering from the fact that it is lacking some of the great Scala goodies.

To make Haskell a serious advantage and not just a minor benefit (compared to, say, SML), you probably also need to understand kinds. Let's bear in mind that the vast majority of practicing programmers can't reasonably define an algebraic data type, and that it's not their fault, because the ROI for learning such things is often negative.

I do think there is a reactionary "don't-wanna-learn anything" vibe against Haskell among certain groups. But I think we should be clear that, to get the power that Haskell promises, you do need to learn many new things. Those things, while not exactly category theory in a narrow sense, are closer to category theory than they are to conventional programming knowledge.

    data Bool = True | False

There are a few reasons for this that get dismissed by the day to day practitioners. First, there is the cognitive rewiring required to think of everything as an inert expression. In Haskell there are no actions, just descriptions of actions that the runtime manages. I'm specifically talking about I/O and its monadic implementation. Second, learning about monads is not enough. When effects are encapsulated as monads you need to understand monad transformers to fruitfully combine effectful computations. This is by no means the best way to do things because there are also implementations of effectful computations with row types and extensible effects, e.g. PureScript, that requires a lot less cognitive overhead and is less error prone. Third, many of the high-powered libraries in the Haskell ecosystem are so heavily reliant on categorical constructs, e.g. free (co)monads, functors, applicatives, monoids, bifunctors, Kleisli categories, etc. that getting through all that thicket to be truly productive with the libraries instead of just copying and pasting requires a time investment that is of dubious value to many programmers and you're better off learning about security practices on OWASP because you are more likely to encounter a SQL injection than you are to encounter a Kleisli category of a monad.

I'm not saying knowing these things is not useful or won't make you a better programmer but to just demonstrate that there is indeed a cognitive overhead that might not be worth it. I like category theory as much as the next mathematician but programming with categorical constructs is not necessarily the most optimal way to do things when all I need is a screen scraper for an XML feed.

As the language is considered holistically with tooling, the error messages are always good and they don't make dubious decisions (getting rid of semi colons) that are theoretically sound but screw up tooling.

There is a very good reason they will never eliminate semi colons from C#, the visual studio team would never let them...C# is developed in a completely different style from Scala.

I'm sure you are right: scala today is probably a much more simple language with great IDE support...7 years ago, it was a bunch of advanced features and building a decent IDE for it was a struggle.

That said, people are missing the forest from the trees. This isn't about the language, but rather about the runtime and the standard library. That's the true value of the JVM, that's the true value in .NET.

There wouldn't be any problem for porting Scala to .NET. Sure, it would be difficult as .NET's reified generics are maybe too limited for Scala's type-system, but I'm sure somebody could make it work, at least partially.

And there was a Scala for .NET, but it lacked interest so it died. But hey, you can still run stuff built in Scala on top of .NET by means of IKVM ;-) Has poor performance compared to a JVM, but then again, people are willing to build stuff in Scala for Android. Also Clojure.NET is doing pretty good from what I've heard.

As a Scala developer that loves Scala and the JVM, I personally find this announcement very exciting. As finally, the JVM has true competition ;-)

Interestingly, C# can model type classes much more straightforwardly (using implicit conversions), and this is one of the reasons I continue to use it along side F#.

[1]http://stackoverflow.com/questions/9868327/f-type-constraint...

Other than the fact that .NET reified generics and Scala's type system don't play well together, which was one of the big challenges facing Scala.NET.

Just as Go is fine without generics, F# is fine without HKTs.

It's a sad realization for those coming from a language that does support HKTs. Still a great language.

In the sense of lacking higher-kinded types and typeclasses?

I love the simplicity behind the language and it makes simple things actually simple - which isn't as trivial as it sounds. But once you start dealing with complex things in Clojure the language doesn't do much for you, if you can't fit your problem in to it's provided toolkit the code written will actually be horrible - for example go look at core.async [1] implementation - just reading that code gives me a headache - I understand it's complicated stuff with buffering and all but having type annotations on protocols and variables used would be extremely helpful when trying to parse that code. Types help me think more abstractly when I'm reading the code as I can take them as compiler enforced contracts and think of them in abstract terms, in dynamically typed languages complexity and the amount of things you need to be aware of is just too overwhelming IMO.

[1] https://github.com/clojure/core.async/blob/master/src/main/c...

You can activate validation for everything in development and then in productive only activate validation on your api endpoints. In a future version, you will probebly be able to generate core.typed stuff directly from schema.

Other then that, I think extreamly high performace code a la core.async is not the norm, there the types are not used for the programmer, but rather for the VM. I have used type hints in the last couple of years maybe, one or twice.

I've tried core.typed, it's amazing in theory but in practice it's unusable (at least for me) and nobody annotates their code anyway. If core.typed becomes more widespread in Clojure community I might actually give it a second chance, in the mean time I'm just going to use Kotlin for JVM, it has transparent Java interop and reduces the Java noise, and the tools (IDEA) is infinitely better than anything I've seen in Clojure land.

trait SeqLike[+A, +Repr] extends Any with IterableLike[A, Repr] with GenSeqLike[A, Repr] with Parallelizable[A, ParSeq[A]] { self =>

or

def :+[B >: A, That](elem: B)(implicit bf: CanBuildFrom[Repr, B, That]): That

Outside of some pretty extreme examples (scalaz maybe), I don't think I've actually ever seen someone else's source that implemented a custom collection.

And you're purposefully trying to confuse people by digging into what might as well be "internal" signatures.

What do the actual, official docs say about SeqLike :+ ?

  > def :+(elem: A): Seq[A]
  > [use case] A copy of this sequence with an element appended.

Can you dig down further and find the CBF signature? Yes. Do you need to for anything outside of spreading FUD? Nope. Is it a bad thing that it shows how the sausage is made underneath the covers? I don't think so.

If the collections API is purposely trying to confuse people, blame the Scala team, not me.

Akka? Spray? ScalaUtils? Do they take effort to learn? Yes. Are they anything like scala.collections? No.

Why didn't you pick scala.concurrent? Or scala.util? Or any number of other packages? Why didn't you use the signatures in the official docs as-presented?

The Scala team goes out of their way to present something simple and easily digestible to most programmers, even the ones unfamiliar with Type Classes.

I mean, you basically just use a Seq like an immutable version of Ruby's Array and it just does what you want 99.999% of the time.

How often do you see people go on to propose that because much of Ruby's Array implementation would be incomprehensible to 90% of Ruby programmers that that makes Ruby a bad language? It's an entirely ridiculous metric.

Both languages can be difficult to decipher. I do find that Scala's syntax is much more flexible, which can lead to more stumbling when trying to read code.

[SerializableAttribute] [ComVisibleAttribute(false)] public class Dictionary<TKey, TValue> : IDictionary<TKey, TValue>, ICollection<KeyValuePair<TKey, TValue>>, IDictionary, ICollection, IReadOnlyDictionary<TKey, TValue>, IReadOnlyCollection<KeyValuePair<TKey, TValue>>, IEnumerable<KeyValuePair<TKey, TValue>>, IEnumerable, ISerializable, IDeserializationCallback { ... }

And this is of course ignoring the fact you copied that from the documentation witch shows all interfaces the class implements. IDictionary also implements ICollection & IEnumerable so you wouldn't need to include them. So to actually implement this class it would more likely be

[SerializableAttribute] [ComVisibleAttribute(false)] public class Dictionary<TKey, TValue> : IDictionary<TKey, TValue>, IDictionary, IReadOnlyDictionary<TKey, TValue>, ISerializable, IDeserializationCallback { ... }

maybe less

A talented C# dev will need to know co/contravariance as well as implicits considering they also exist in C#.

In Scala, being familiar with these concepts is practically a necessity, though.

True for co/contravariance. For implicits, that depends on which implicits you are talking about.

Scala has:

* implicit conversion operators (these have existed in C# for some time, under the same name)

* implicit parameters (C# doesn't have an analog to these that I can think of)

* implicit classes (C# has an analog in classes providing extension methods, though the classes themselves are distinguished by a keywords as they are in Scala; in Scala, these are essentially syntactic sugar for creating a normal class and an implicit conversion from the extended class.)

C# allows default values for parameters, but it's not quite the same.

Example of C# default value for parameter:

  static void Addition(int a, int b = 42)  
  {  
    Console.WriteLine(a + b);  
  }

  Addition(4); // Prints 46  
  Addition(4, 5); // Prints 9

Like C#, implicit parameters must come after non-implicit parameters (if any).

Unlike C#, the implicit value does not need to be defined in the signature. Also unlike C#, if you provide the value for one implicit parameter, you must provide the value for all implicit parameters.

Right. Scala has C#-style default parameters as well, implicit parameters are a different (though very loosely related) thing.

  using System;
  
  public class Program
  {
  
  public class Person
  {
    private string _name;
    private int _age;
    
    public Person(string name, int age)
    {
      _name = name;
      _age = age;
    }
		
    public static implicit operator int(Person p)
    {
      return 42;
    }
  }
	
  public static void Main()
  {
    var person = new Person("Jim", 51);
    var number = 100;
    AdditionPrinter(person, number); // Prints 142
  }
	
  public static void AdditionPrinter(int a, int b)
  {
    Console.WriteLine(a + b);
  }
  
  }

Though implicits I feel are so much simpler than many people fear.

From a Ruby perspective: Just think of them as operating similarly to Refinements, except not completely insane because there is no global scope at compilation. You only have to worry about your own package, imports and inheritance.

Tracking down an implicit generally takes all of 10 seconds, and never more than a few minutes. Even moderately brain-bendy ones like akka.patterns.ask (where does the implicit "?" come from? "ask" is actually an implicit conversion to a class that defines it: https://github.com/akka/akka/blob/master/akka-actor/src/main...).

Annoyingly F# brought them along for the ride too, although you rarely have to explicitly write them.

I wrote a library of monads for C# [1], and implementing the SelectMany method is a good example of how messy it can be:

    public static RWS<R, W, S, V> SelectMany<R, W, S, T, U, V>( this RWS<R, W, S, T> self, Func<T, RWS<R, W, S, U>> bind, Func<T, U, V> project)
    {
    }

    Option<int>

    int option

    public static SelectMany R W S T U V ( this self : RWS R W S T, bind : Func T (RWS R W S U), project : Func T U V) : RWS R W S V
    {
    }

    class Thing int
    {
    }

    class Thing T : BaseThing T
    {
    }

[1] https://github.com/louthy/csharp-monad

A Scala dev will look at the Scala type signature and shrug.

A C# dev will look at the C# type signature and shrug.

As usual, unfamiliar things are difficult and familiar things are easy.

I've seen C# that is almost as hard to read as bad Perl -- also, not surprisingly, from contractors who weren't going to be maintaining the code.

I don't think this says anything about C# or Scala, I think what it says is something about the natural result of the economic incentives of people being paid to throw code over the wall before they leave for greener pastures.

The documentation for Scala is actually pretty outstanding IMO. I had a much easier time compared to Ruby. Daniel Westheide's introduction series "The Neophyte's Guide to Scala" is the single best language intro I've ever seen, for any language. It even goes into enough of Akka to get a basic chat application going. And while Akka works nicely with Scala, it's conventions are so different it might as well be a different language. In idiomatic Scala you probably don't run into mapTo or vars too often for example, but that's going to be a pretty common sight working with Akka.

At least the documentation on PlayFramework.com is mostly current, and doesn't gloss over important detail. Unlike rubyonrails.org, where even five years ago the basics were horribly dated, inaccurate, and skip important background.

Programming languages you don't know are harder to read than programming languages you do know.

Unlike "bad perl", you have types that tell you exactly what something does.

> ... and simple tutorials which don't go into the depths we need to know (like how do you create a Manifest from Java to call into Scala code that needs it?

Calling Scala from Java is not beginner level material that winds up in a tutorial, and it's a bad idea to begin with; you're stuck speaking a pidgin Scala using Java-only constructs just to maintain Java interop.

I will definitely agree with you there. It would help our team significantly if we had a Scala expert we could consult but there's not enough in the budget (monetary or political) to hire one. We are pretty much left to fend for ourselves with Google, Stack Overflow and a couple reference books. This project also contains a C++ component that would probably have been just as impenetrable to my teammates (who have C but no C++ experience) if I hadn't already been fairly familiar with the language.

> Unlike "bad perl", you have types that tell you exactly what something does.

Static typing doesn't help always when you actively try to subvert it. There are casts to and from Any all over this codebase. Reflection is used everywhere even when it's not necessary. There are even places where they convert between types by serializing an instance of one type and deserializing it as an instance of another (with similar fields but not actually related in the type system). They also loved Option[] types which might not be so bad if they weren't also storing Some(null) into them in just enough places you forget to check for it but it still blows up in your face at least a once a month. Basically, the original authors of this code tried their best to destroy the usefulness of the Scala type system and succeeded fairly well.

> Calling Scala from Java is not beginner level material that winds up in a tutorial, and it's a bad idea to begin with; you're stuck speaking a pidgin Scala using Java-only constructs just to maintain Java interop.

By mandate of our management we are not allowed to write any new Scala code except where absolutely necessary. The contractors went behind our management's back to write it in the first place (we told them they could use Java 8 which they interpreted to mean they could use anything that would run on a Java 8 JVM). After that was found out (about a 1/3 of the way through the contract and too late to rewrite everything without blowing our contractual deadline with our customer) new Scala code was banned and they had to (and we have to) use Java as much as possible after that point. This is also not helped by the fact that at the time they handed the code over it was barely half-baked and performing at less than 25% of the needed throughput and we're left trying to finish and fix it.

Of course, when it can take three or four developers (with a combined background in Java, C#, C, C++, Python, Javascript, and an academic familiarity with OCaml-family functional languages) a half hour or more to figure out what a some of the methods in this codebase even do (at both a syntatic and conceptual level) I am going to put (a small) part of the blame on Scala for allowing such impenetrable code to be written in the first place. I'm certainly not placing all or even a significant amount of the blame for this project's problems on Scala but it is certainly not helping.

Thanks for letting me vent.

That being said, when you understand the nuances of type annotations, that code is quite readable in the mathematical notation sense. It is concise and takes more time per byte to understand, but it tells me enough about the code that I rarely have to read the actual implementation to know exactly what it does.

It is in fact representative of the vast majority of code you use.

The fact that it wasn't immediately clear to you that a lot of your code DOES use this code is probably the strongest argument I could make.

C++ is the poster child for this. No one argues that C++ is a bad language just because the standard library is full of magic.

Scala's STDlib might be more powerful, more honest and more consistent, and also might be striving to be DRY for the implementors.

Personally, I feel that Scala's Collections goes overboard in hitting the above goals, and the resulting signatures are too verbose. And this increases the cognitive load for the subset of people that need to bother about it (performance tuners, architects, etc). But that's not a fault of the language per se.

Personally, I make it a habit to always read (or try to read, in this case) standard library source code that I'm depending on to be correct.

To get the "ugly" signature you have to look at the actual source, or example the method definition in the official docs.

They go out of their way to make sure to present an easy-to-understand version for actual users.

Which is why every actual Scala developer rolls their eyes at someone bringing up CBF. You have to go out of your way to try to be confused about it. And if that digging stops at finding the method signature, well, probably serves you right for being confused. ;-)

Is CBF amazing? Probably not. Is it some sort of confusing eternal battle for most Scala developers? Absolutely not.

I mean just look at the official docs, find out where he got these weird examples from, and then tell me this is a well reasoned argument.

I rewrote 100klines at least from C#1 to C#2 when generics came in 2.0. It was compatible in that the non generic code still worked, but I don't really see what difference that made. If we didn't want to upgrade the cod me then we wouldn't have updated the compiler!

Obviously if you don't want the benefits of Py3 then you don't have to pay the upgrade cost either.

Plus, for this question, the size of the user base doesn't matter: If a developer has to adapt his code to a new language version, he/she doesn't care whether ten or ten-thousand other people have to do the same.

Scala's smaller user base means there are a lot of less people to get mad.

> Scala has been throwing out bad features in pretty much every single release for the last 5 years.

You cannot throw out features in a language with the community size C# has, otherwise you just get another Python 3.0.

  a) Microsoft is in an excellent position to make such 
     changes, unlike Python, because Microsoft shops will 
     largely do whatever Microsoft tells them.

     Just have a look at how often they have incompatibly 
     changed the standard library used by C#.

  b) Not every language has to botch the transition as badly
     as Python designers did.

I haven't looked into F# or Scala too much, but I bet F# comes out looking far better, because it was so deeply inspired by Haskell (but made practical).

Eh what? Scala is a lot closer to Haskell than F#/OCaml, and can express roughly the same things, while F# is a lot less expressive.

It takes a while for your code to get big enough for the last part to matter, but it's huge when it does - you can handle any kind of "context" in a generic way, e.g. async calls, error handling, audit logging, software transactional memory, or custom things for e.g. database access. F# has a number of these specific implementations but they're kind of "hard-coded" in the language rather than fully extensible. So I guess the pitch is: imagine C# async/await could be "just a library", and other contexts that you wanted to handle similarly could also be a library, and the resulting functions are first-class citizens in the type system (no awkward choices of whether a particular function is async or not, you can handle that generically).

That's true in F# -- async is just a library in a computation expression.

That's not true. You can extend the language yourself with "computation expressions" (and that's in fact how the 'async', 'let!' et al keywords are implemented).

However Scala is not a first class citzen in the JVM, but C# is the systems language of the CLR, already a huge difference.

A lot of interesting aspects of Scala are possible only because of immutability.

And a lot of smaller things: * Typeclasses. In Scala you can implement them with implicit parameters, I have no idea how you would do it * Case classes. Again in C# you can implement something that kinda looks one with readonly and just a getter, but it's not as good as you won't get stuff like equality and copy, you'll have to write the boilerplate * Pattern matching, in particular with case classes * Option. You can create your own, or use the Option from FSharp, but all the lib you will use will be returning null all the time. * And more...

Additionally there are aspects that are more of a personal preference, like how the "map" function is called "Select" and "filter" is called "Where", and so on. All functional languages use the same names, the SQL-like naming for manipulating collections is just confusing for me.

At the end of the day, Microsoft tried to build a better Java when they designed C#. And it is indeed better than Java, especially because they moved fast in their versions while Sun/Oracle was terribly slow (why did we have to wait that much for lambdas??). But C# mostly sticks with the same concepts as Java (OOP) while Scala truly embraces both FP and OOP.