26 ms·

Technology Change: .Net to Scala

116 points by SanderMak 13y ago

V-2 13y ago
Scala is not that distant from functional aspects of C# such as LINQ... certainly way more nice than Java itself, even including their latest LINQ me-too propositions... Having C# background, I only took a look at Scala and I liked it at first glance, I wouldn't mind learning it some day. See https://gist.github.com/samskivert/5278311 https://gist.github.com/samskivert/5278311 And although that's off-topic, while we're at it: http://www.digitalmars.com/d/archives/digitalmars/D/Java_streams_Vs_LINQ_Vs_D_193598.html http://www.digitalmars.com/d/archives/digitalmars/D/Java_str...
- balakk 13y ago
  As somebody who moved from F# to Scala for a project, my major gripes: - Lack of a yield statement equivalent(in c#/f#). I know, there are probably a dozen alternatives such as continuation passing etc, but none so convenient. - It's a massive language. Operator overloading seems to be highly encouraged, and library authors go to town with it. The Parser combinator stuff itself is enough to make one go dizzy, if you aren't familiar with it. - Tools: Idea is OK, but not a patch on VS and F#. Compilation times are practically instant for small/medium projects in VS land - here it's glacial, even on a recent MBA. SBT is great, when it works. On the + sides: - If you know f#, you practically know Scala - well, enough to be instantly productive. - Play 2 is very close to ASP.NET MVC. This was a welcome surprise, and a relief as well. - It's such a relief that whatever you build will run on anything with a JVM. Xamarin/Mono is awesome, but those guys are still a little obscure, and a tougher sell than a JVM-based language.
  - sandGorgon 13y ago
    I wish that sbt had the ability to work with exploded scala source dependencies, instead of insisting everything work in the JAR world. I am used to working with rubygems/pip and love the ability to go and screw around in the libraries. When I'm ready to package, I can run "sbt assembly" instead and it can take a little longer to build a packaged JAR. Clojure/leiningen has the same issue (although there are ways to get the source itself as well [1], but nowhere as clean as rubygems). [1] http://stackoverflow.com/questions/14395413/how-do-i-make-leiningen-download-the-source-of-a-required-library http://stackoverflow.com/questions/14395413/how-do-i-make-le...
    - eeperson 13y ago
      Why do you want this?
    - ssmoot 13y ago
      Could you elaborate what you mean by "insisting everything work in the JAR world"? SBT works with git submodules, git sources, other URI or File sources for dependencies. So you must mean something else, but I'm having trouble parsing.
      - sandGorgon 13y ago
        Rubygems and Python packages are source packages. When you used the package management tools in those languages, these packages are downloaded to somewhere in your path and used within the code you are writing. In fact in Rubygems, you can point to a Ruby git repository (like github) and have dependency management happen from there - no necessity for a centralized repository (like maven.org). This is how you share a ruby gem - http://guides.rubygems.org/publishing/#sharing_source_code http://guides.rubygems.org/publishing/#sharing_source_code . I can now specify in my Gemfile to pull a particular branch/tag/version of the gem directly from revision control. The same thing happens with SBT or leiningen, except that they are JARs. I believe this comes from using maven as the backend. Therefore, either you need to setup a local repository or publish to Sonatype or some other place. This is how you share your scala code - http://www.scala-sbt.org/0.13.1-SNAPSHOT/docs/Detailed-Topics/Publishing.html http://www.scala-sbt.org/0.13.1-SNAPSHOT/docs/Detailed-Topic... . Remember, publishing means packaging into a JAR. If you were too lazy to package your code into a jar and publish it ... well, then it's cumbersome to work directly from the repo. I really, really wish scala/clojure would enable the ability to work directly with source as packages - the big, big reason why it's not is the maven backend.
        edwinnathaniel 13y ago
        Seems easy to attach source and javadoc in Maven pom.xml: http://maven.apache.org/plugin-developers/cookbook/attach-source-javadoc-artifacts.html http://maven.apache.org/plugin-developers/cookbook/attach-so... Can't you use maven with your scala project? Most open source Java lib/framework that publish their JARs to the central Maven repository also publish their Source code and JavaDoc JARs as well. This is where I applaud the Java OSS community.
  - pkolaczk 13y ago
    The design approaches for Scala and F# are different though: F# is mostly FP with some OO tackled on - mainly influenced by OCaml. Scala unifies both OO and FP. > If you know f#, you practically know Scala - well, enough to be instantly productive. Sure, but actually you can say the same about knowing Java/C# and then moving to Scala. But in that case you're missing a whole lot of features that Scala offers that F# does not: typeclasses, traits, implicits, etc.
    - balakk 13y ago
      True. I was referring to similarities in things like higher-order functions, tail-recursion support, pattern matching, option types and so on. I feel the intersection of FP features between F# and Scala is much greater than C#/Java.
    - CmonDev 13y ago
      "F# is mostly FP with some OO tackled on - mainly influenced by OCaml. Scala unifies both OO and FP" So Scala is mostly OO with some FP tackled on?
      - tel 13y ago
        In my understanding, it's hard to say. It appears to have a base semantics that you can think through as OO-like message passing or FP-like lambda calculus reduction. I assume it's implemented OO-style on the JVM, but it's hard to say whether the core language biases one side or the other. I think that's interesting but also a big indicator of why you see such a big split-brain situation in Scala. FPers program FP-Scala, OOers program OO-Scala, but neither is dominating. As far as I can tell, Martin Odersky programs balanced OO-FP, but few others do.
      - andrewcooke 13y ago
        scala is the unholy child of everything from oo and everything from fp (well, almost). (but i found it hard enough to program in ocaml, which is similar to f#, because i was always torn between oo and fp parts, so maybe i am biased or just Too Dumb For Scala)
  - rjbwork 13y ago
    > It's such a relief that whatever you build will run on anything with a JVM. Xamarin/Mono is awesome, but those guys are still a little obscure, and a tougher sell than a JVM-based language. Yeah, and there are still some unsupported functions and properties in ASP.NET that keep you from being able to just drop an MVC project in. :(
  - lgieron 13y ago
    I haven't tried Idea for Scala recently (last time I tried it was much worse than Eclipse), but incremental compile in Eclipse is so fast that I basically do not notice it. Or were you talking about full compile times? These are rarely needed.
    - mjt0229 13y ago
      Scala support in IDEA is great right now. I think it's better than Eclipse at the moment, although my experience with Eclipse was observing over my coworkers' shoulders.
  - mjt0229 13y ago
    The problem with Xamarin is that it's expensive. Xamarin's docs don't really explain how big a project can get before you need to pay for expensive licenses, but I can't advocate at my company for a license that expensive when we're developing Scala pretty much for free.
  - pivo 13y ago
    > Operator overloading seems to be highly encouraged, and library authors go to town with it. This, the "every single library needs to provide some clever DSL", is my major complaint with Scala. It's not really Scala's fault either, Scala's core libraries don't have this problem. It's 3rd party developers with no restraint. So it doesn't have to be this way and I think (or hope, based on some comments about Scala on this site previously) that it's beginning to become a discouraged practice. Still, I have an immediate, visceral reaction to it after the years I spent trying to untangle heaps of overly clever C++ code with the same kinds of issues. I never want to be in that situation again. Code should be, above all, easy to read. If your code looks like a different language depending on which library you're using, that's a real negative. At least we now have pretty good IDEs that help out, but even then I think that it's probably not be a good sign if you kind of need to have a good IDE to understand the code.
  - MichaelGG 13y ago
    I've only given Scala cursory overviews and haven't written code in it. But when I inspect Scala code, it seems incredibly verbose. I was told that the type system is so powerful, type inference isn't possible in many situations, so you end up type annotating everything. That's one of the things I love about F# - code's far more compact without type annotations. Scala seems like it really wants to embrace Java's OOP completely.
- seglo 13y ago
  I've often said the same thing to .NET advocates at Empathica. In terms of language constructs, C# is closer to Scala than Java is to Scala. However, IMHO Scala still offers more than both combined. :)
PaulHoule 13y ago
That's going from the frying pan to the fire.
- woof 13y ago
  Faster and hotter?
DanielBMarkham 13y ago
Long article. Good stuff for those looking to make a similar change though. I remain a fan of F# on Mono. Love the FP paradigm, love all the easily accessible libraries, and love that it's all free. Scala would probably be a close second choice for a development shop, though. I personally would move towards pure FP with Haskell or Erlang, but staffing becomes too much of an issue to scale that out. I don't think they have that issue with Scala.
- dons 13y ago
  > pure FP with Haskell or Erlang, but staffing becomes too much of an issue to scale that out Does it? We've hired several dozen Haskell developers at this point, and we always get far more applicants than available positions.
  - DanielBMarkham 13y ago
    I'm still collecting data on this. Along with how dev practices scale out in a purely functional environment. I try to stay ahead of the game on these things. If I'm still collecting data, either I'm missing some major sources or the overall market isn't ripe for it yet.
jimbones 13y ago
The chart included and referenced is just of all the most obscure JVM languages. Look what happens when you add Java to that list [1]. [1] http://www.indeed.com/jobtrends?q=scala%2C+groovy%2C+clojure%2C+jruby%2C+jython%2C+java&l= http://www.indeed.com/jobtrends?q=scala%2C+groovy%2C+clojure...)
- josephcooney 13y ago
  Or C# http://www.indeed.com/jobtrends?q=scala%2C+groovy%2C+clojure%2C+jruby%2C+jython%2C+C%23&l= http://www.indeed.com/jobtrends?q=scala%2C+groovy%2C+clojure...
- yelnatz 13y ago
  Wait, what? http://www.indeed.com/jobtrends?q=scala%2C+groovy%2C+clojure%2C+jruby%2C+jython%2C+java%2C+go&l= http://www.indeed.com/jobtrends?q=scala%2C+groovy%2C+clojure...
  - arscan 13y ago
    apparently the matching algorithm isn't particularly smart... those are just the job postings that have the word "go" in it? http://www.indeed.com/jobanalytics/jobtrends?q=scala%2C+groovy%2C+clojure%2C+jruby%2C+jython%2C+java%2C+a&l= http://www.indeed.com/jobanalytics/jobtrends?q=scala%2C+groo... edit: yeah, it isn't intended to be programming specific: "Indeed.com searches millions of jobs from thousands of job sites. This job trends graph shows the percentage of jobs we find that contain your search terms."
  - route66 13y ago
    Indeed is unusable for the points made here. Under the graphics you have the links to the respective jobs. Just check for yourself what these "Go" jobs [1] and the "Scala" jobs [2] are. "Haskell" jobs are also interesting. And more: don't forget that currently even Php ads feature the infamous "experience with functional programming (Lisp, Clojure, Haskell) is a plus" line. [1] http://www.indeed.com/q-Go-jobs.html http://www.indeed.com/q-Go-jobs.html [2] http://www.indeed.com/q-Scala-jobs.html http://www.indeed.com/q-Scala-jobs.html
- 13y ago
Touche 13y ago
Some people just like complicated things.
- robmcm 13y ago
  It's only complicated if you don't understand it.
- trailfox 13y ago
  Fortunately they saw the light and moved off of the complexity of C# then...
  - Touche 13y ago
    From one complicated thing to another.
    - trailfox 13y ago
      Java is simpler than both C# and Scala, yet it is more disliked than both (see recent HN polls).
    - CmonDev 13y ago
      Well, at least they did not choose some dynamic garbage.
  - taude 13y ago
    And single vendor buy-in.
rodh257 13y ago
Really interesting article, thanks for writing it. I'd like to hear a bit more about the reasoning for the whole company swap, what problems you were having with C#/Microsoft stack. The impression I got was that you tried out something new for a small project, liked it and liked the idea of OSS in general and then started doing everything in that way, is that all there was to it? What other factors came into the decision on a whole?
- 300bps 13y ago
  I found the article very interesting as well but honestly it reads like a nightmare. Company heavily invested in X. New CTO comes on board, gives the technology stack a "hard look" which is often a euphemism of, "I wouldn't have chosen that technology, so you must change." Large portion of the existing developers leave, new developers (including OP) come in. New developers base technology decisions on what's best for their career, not necessarily what's in the best interests of the company. After all, in the Why Scala section they plainly state they knew little of Scala and there's a large section about what languages are hiring. And as you said, if there is time spent on what made them decide to switch away from the Microsoft stack, it is buried to the point I couldn't find it in two read-throughs of the very long article.
  - taude 13y ago
    I don't see having some of the old-school developers leaving the company and being replaced by potentially better talent as a bad thing. One signal for me is that I hire smart people because technology changes. It's a red flag for me when people stop learning or lose the desire to add to their tool belt. Some people can't adapt. But, hey, the world still needs Cobol programers, so...
    - 300bps 13y ago
      old-school developer With all due respect, you obviously know nothing about the Microsoft stack. These people were not using VB6. How do I know? From the article: new projects chose a base technology stack of C#, ASP.NET MVC ASP.NET MVC is not an "old-school" framework. It was first released in 2009!! That's four years newer than Ruby on Rails. It's ridiculously actively developed as well as being open source. It's currently in version 5 which was released October 17, 2013 which was... OMG 8 days ago. I continue to be shocked at how little most HN developers know about the Microsoft stack and how much innovative work has been done since they last looked at it in 1998.
taude 13y ago
It sounds like you might not have worked there yet, but it'd be great to hear how some of "convincing of management" went. Was it mostly the new CTOs vision who was able to convince business? (I speak as someone who moved some web apps off a .NET stack to OSS, but that was for a small company's single product)
- deleted 13y ago
  [deleted]
- CmonDev 13y ago
  ".NET stack to OSS" This does not make any sense whatsoever since e.g. ASP.NET MVC is OSS. Why don't you say ".NET stack to JVM stack"? Because it doesn't make your choice sound intrinsically better?
  - taude 13y ago
    You don't run your ASP.NET MVC on Linux boxes, though. On non-IIS web servers, and likely you use SQL Server and the LINQ libraries....unless you'r using Mono (which has a lot of hurt involved to do so, especially once you start getting in with external libraries that your application might depend on). in general, when people mention ".NET STACK", they're talking about the whole-shebang, not a single library that might happen to be OSS when the other 100 libraries you're dependent on aren't.
  - dragonwriter 13y ago
    > This does not make any sense whatsoever since e.g. ASP.NET MVC is OSS. ASP.NET MVC is an open source framework, sure, but the .NET platform, as such, is not OSS. (Some parts of the MS .NET ecosystem are open source, and there are open source alternative implementations for some parts, but that doesn't make the platform OSS.)
pkmishra 13y ago
Thanks for Sharing. I also learned scala after working on .net stack for more than 7 years and I am not disappointed. I really like C# but if I have to learn JVM based language I would definitely go for scala.
cygwin98 13y ago
And one year later, a blog post titled "Why we moved to Java from Scala" or "Why we moved back to .NET" appeared on HN and havested hundreds of votes. Just kidding.
- CmonDev 13y ago
  It actually makes a lot of sense, because the change to Scala was triggered by "Simon". Another Simon will come and bring Python or something even worth.
  - seglo 13y ago
    That's incorrect. The technology change was bottom-up, by developers. Simon didn't intervene with his technical direction until we already had a couple of Scala projects under our belts.
    - _random_ 13y ago
      I you saying you had a vote and some developers (C#) disagreed and there was a minority of them?
      - seglo 13y ago
        There wasn't really a vote, but we did have a group forum where objections could be raised. People who weren't onboard with Scala were in the minority and most of the arguments raised didn't hold much water.
MrDosu 13y ago
Why couldn't they have written "Web Application" in the first paragraph...
cygwin98 13y ago
I was being snarky in my another comment and was downvoted as hell. Oh well, I am OK with that. However, I can't help thinking of the failure of Scala at Yammer, which caused a big buzz two years ago [1] and [2]. From the blog posts I've read about Scala and Yammer, they planed the transition to Scala carefully and with passion, and they switched away from Scala in merely one year. Has the situation changed totally? I don't know. Maybe Scala has improved significantly since then and all the pain points back then have been addressed nowadays. I'd like to be enlightened on these factors. [1] https://news.ycombinator.com/item?id=3297750 https://news.ycombinator.com/item?id=3297750 [2] https://news.ycombinator.com/item?id=3292555 https://news.ycombinator.com/item?id=3292555
- jimbones 13y ago
  Things haven't changed, using Scala doesn't offer significant benefits over Java and it is just a noisy minority that pontificate over Scala and its supposed (largely academic) benefits. This is the thing I find most annoying regarding Scala use, and people advocating its use, it just doesn't do anything that Java can't do - plus the tooling for Java is wayyy better, there is a smaller learning curve, you can hire people to work with it and you don't spend your days endlessly debating what obscure language feature that may lead to tighter code in release 2.11.B.3.48d.M1.
  - trailfox 13y ago
    > "Scala and its supposed (largely academic) benefits" Perhaps you would like to discuss the "academic" benefits with the likes of Twitter and Foursquare? > "it just doesn't do anything that Java can't do" It's a more expressive language. You could argue that Go and Python can't do anything that C or assembler can't do. That doesn't make Python irrelevant. > "plus the tooling for Java is wayyy better" In terms of the JVM the tooling is exactly the same. In terms of coding I use IntelliJ for both Scala and Java development, without noticing much difference in quality between the support for either language. In terms of libraries Scala has access to all the libraries that java has as well as additional libraries designed specifically for Scala. Most (actually all) Java developers that I know grumble when having to code in Java after they are exposed to Scala.
flipchart 13y ago
I'm more and more confused by everyone that bashes the MS stack because it doesn't have the OSS community that the other stacks do. I'd really love to hear what OSS projects there are for the Python/Ruby/JVM/etc languages which don't have equivalents for .Net. Maybe I'm doing something wrong, but my experience on .Net has always been such that I can find a project to meet my needs. Sure my target OS is Windows, so the OS interop is not an issue for me, but for my day to day needs, there is always a solution to be found in the .Net OSS community.
- pnathan 13y ago
  Weka is one that I ran into personally a few weeks ago.
- subsection1h 13y ago
  What are the .NET equivalents of The Ruby Toolbox[1] and pluginGeek[2]? Also, there are more than 11 times as many Ruby projects at GitHub as there are C# projects[3] (even though .NET developers vastly outnumber Ruby developers). [1] https://www.ruby-toolbox.com/ https://www.ruby-toolbox.com/ [2] http://www.plugingeek.com/ruby http://www.plugingeek.com/ruby [3] https://github.com/search?q=stars%3A%3E0 https://github.com/search?q=stars%3A%3E0
  - _random_ 13y ago
    And 7 out of those 11 are some sort of 10-line "gems" or whatever they are called. Also GitHub is not the only code sharing web site, just biggest and hypiest. For any of those tools/plugins there is a .NET equivalent, but I don't know a up-to-date page that combines them all as an overview.
  - flipchart 13y ago
    To be fair, those appear to be pages which list existing packages, which is not what I was commenting on in my OP. However, I would suggest one of the closest equivalents would be nuget[1]. I think that the history of the languages should be mentioned: Ruby 1.0 was released in 1996[2], while the beta of .Net was only released in 2000, and 1.0 only in 2002[3]. Thus one could perhaps say (maybe unfairly, but nevertheless) that Ruby has had more time for OSS projects to develop. I"m not saying that that is the reason for the abundance of Ruby projects on Github, but I don't believe that the relative lack of .Net projects on Github implies that the needs of a .Net developer is not met by the current OSS offerings. [1]: http://www.nuget.org/ http://www.nuget.org/ [2]: http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 [3]: http://en.wikipedia.org/wiki/.NET_Framework http://en.wikipedia.org/wiki/.NET_Framework
mwexler 13y ago
Besides an interesting read, I laughed all over again at the video on the bottom. Worth a reminder if you didn't catch it the first time or haven't "Java 4-Ever" before...
- seglo 13y ago
  Definitely a nugget of Java humour worth preserving and sharing. Glad you liked the post :)
karterk 13y ago
I'm part of a team who moved from Java to Scala recently (C# is a nicer language than Java these days). Apart from me, nobody else had real-world Scala experience but were generally good programmers and were able to pick up the functional aspects of Scala fairly quickly. The move was a big success, and a frequent comment I hear is "I can't imagine moving back to Java". One of the reasons why the migration worked for us was that one can (with a bit of discipline) get into idiomatic Scala slowly. You can definitely start off writing Java-ish Scala and still gain a lot from the decreased verbosity and nicer APIs. You can safely stay away from over-using implicits, functional programming etc. till you get a good grasp of the language. With excellent Java interoperability, you don't have to convert your entire stack to Scala overnight, but slowly replace old code with Scala. With respect to performance, if you insist on writing idiomatic Scala, there is definitely a performance overhead, because the JVM is not suited for large amounts of small allocations, as is often the case with an immutable style of programming. However, we run a pretty large scale data crunching system, and depending on what your code does, CPU bound performance hit pales in comparison to the network and I/O waits, so for us, it was not a big deal. When we absolutely needed to optimize a tight loop or something, we wrote C-like Scala, using while loops and mutable data structures. Addendum: The greatest win for us was the readability of the code base. Scala allows you to largely keep your data structures immutable, so it's much easier to reason about. With parallel collections, Actors and Futures, concurrency support is excellent as well. You definitely need to pick up a few new concepts, but the time is well spent as once you get a hang of those things, your productivity will be 10x - you don't have to wrangle with primitive concurrency constructs.
- flipchart 13y ago
  Why is it so hard to keep your data structures immutable in C# or Java? C# (my primary language) has parallel collections as of .Net 4.0 and with .Net 4.5 you have the async keyword support on top of the TPL. Could you elaborate on the differences between Scala and C# which make Sala more preferable for you? I'm not trying to start a war on C# vs Scala, I'm genuinely interested in the differences (I enjoy learning new languages, but for the right reasons)
  - 13y ago
powertower 13y ago
Reading this thing it just gets worse and worse as you go down. All they've done was get rid of smart people, create complexity, and embraced a culture of buzzwords. A complete disaster in the making. And for what?
- seglo 13y ago
  I'm sorry you interpreted it that way. It wasn't a disaster and internally the general consensus was that it was a great success. I've made some amendments to my post to provide some more context to our initial process change. Thanks for the feedback.
  - powertower 13y ago
    I might have read too fast, and might have some serious bias here because I actually prefer C# and .NET over anything else (and like leaving performance issues to be dealt with caching / rather than introducing complexities) - but it seems like you went from using a familiar, predictable, and very popular stack to embracing a dozen different smaller and lesser known technologies all full of interoperability issues, idiosyncrasies, and each requiring very specific domain knowledge.... All because a single person at the top is ideological about OSS instead of practical about solutions. Though maybe that's what was required to get a buyout or merger, in which case that's what you needed to do due to the environment/culture of the other party... http://www.empathica.com/press-release/mindshare-technologies-acquires-empathica/ http://www.empathica.com/press-release/mindshare-technologie...
    - seglo 13y ago
      The process change was top down, yes, I think that's the only way it could have succeeded IMO. However, the Scala change was bottom up and by developers. The Mindshare acquisition is a recent event that postdates our technology change (Sept 19).
      - _random_ 13y ago
        How did those "developers" choose that change if a lot of them disagreed and left later on? There had to be 1-2 leaders who happened to be Scala-fans.
programminggeek 13y ago
Scala is awesome, but I wish it had a faster compiler. The web dev experience of 2-5 second code refreshes is painful IMO. If they got it to less than a second Scala might be my ideal language.
jroseattle 13y ago
I always find the most interesting aspect of "we changed from X to Y" to be about why change is happening, how it is managed, etc. Context is everything, but the process described by the OP sounds like standard, top-down decision making. The OP certainly gets to it by the end of the article. I've gone through this process (tech stack shift), both as a recipient-of-change as well as a catalyst-agent-of-change. Remarking on the email that the OP's CTO sent to everyone, these statements stick out: "...A technology choice will be made appropriately for the needs as we see them..." "...no hard decision has been made about our future languages or technologies..." "...Less C#/.Net, more Scala/Java/Open Source..." The CTO likely has very good intentions, but this is an implied technical decision that's already been made. He references "we" in the email to imply group participation in decision-making, but it is very much a you-are-with-us-or-you-are-against-us definition. To wit, those who didn't buy in were shown the door. Having been the guy in that chair, this is not an easy thing to do. Being handcuffed by prior technology decisions is not only difficult, it's often untenable. Usually, the people hired into those leadership roles often have to resolve the decision making issues that got the company to that point. That said, here's what I've learned in terms of how to go about these types of long-term changes: - As the CTO, take full responsibility for introducing change. This is not taking credit, but instead being the owner of the decision and ensuring it succeeds. Support the team, and encourage them to openly question the decision, so that those questions can be addressed. The CTO's email above makes a change decision requisite, but it's up to everyone else to make it work. To anyone who's worked in a potentially charged environment, that's a typical setup for scapegoating. As the lead dog, don't put your team in that position. If your decision comes off as playing-the-executive card, you have failed. - As a team member, embrace change but make it completely objective. Be open to change, but only as it helps to reach a goal. Evaluate technologies after using them, comparing them, and finding what's good and what's not-so-good. Make your personal productivity the least-influential point of analysis. If you can't find a way to assess something honestly because of your preference for operation, you're doing yourself a disservice. Be productively critical of technical decisions -- your own, and others.
- seglo 13y ago
  OP here. Thanks for your feedback. The Technical Strategy email was sent out about midway through our adoption of Scala. I didn't explain the dynamics of our larger development department much in my post, but at that time we were essentially two teams in two different physical locations. The location I was at had already seen success with a few projects in Scala (BeetleJuice and the beginning of our API). Our CTO thought it was time to set a clear direction for the future of development department after an analysis of our current situation and discussion with members of the wider team. Nobody was shown with the door. I'll admit there was some resentment, but nothing a well adjusted developer couldn't get over. As I mentioned at the end of the post, one thing I would do differently in the future is make a stronger effort around consensus building about the decision. However, the Scala change started off as something small and organically grew into a legitimate alternative to the Microsoft stack. Going into our first project (BeetleJuice) we didn't anticipate the impact it would ultimately have on the organization.
kylequest 13y ago
This statement is pretty funny given the focus on intentional transition to Scala: "So, no hard decision has been made about our future languages or technologies, and there are no rules that all new development must happen in Scala."
petermartin 13y ago
I really liked this article. I am just now starting to learn Scala. Great post.

116 points by SanderMak 13y ago

V-2 13y ago

Scala is not that distant from functional aspects of C# such as LINQ... certainly way more nice than Java itself, even including their latest LINQ me-too propositions... Having C# background, I only took a look at Scala and I liked it at first glance, I wouldn't mind learning it some day. See https://gist.github.com/samskivert/5278311 https://gist.github.com/samskivert/5278311 And although that's off-topic, while we're at it: http://www.digitalmars.com/d/archives/digitalmars/D/Java_streams_Vs_LINQ_Vs_D_193598.html http://www.digitalmars.com/d/archives/digitalmars/D/Java_str...

balakk 13y ago
As somebody who moved from F# to Scala for a project, my major gripes: - Lack of a yield statement equivalent(in c#/f#). I know, there are probably a dozen alternatives such as continuation passing etc, but none so convenient. - It's a massive language. Operator overloading seems to be highly encouraged, and library authors go to town with it. The Parser combinator stuff itself is enough to make one go dizzy, if you aren't familiar with it. - Tools: Idea is OK, but not a patch on VS and F#. Compilation times are practically instant for small/medium projects in VS land - here it's glacial, even on a recent MBA. SBT is great, when it works. On the + sides: - If you know f#, you practically know Scala - well, enough to be instantly productive. - Play 2 is very close to ASP.NET MVC. This was a welcome surprise, and a relief as well. - It's such a relief that whatever you build will run on anything with a JVM. Xamarin/Mono is awesome, but those guys are still a little obscure, and a tougher sell than a JVM-based language.
- sandGorgon 13y ago
  I wish that sbt had the ability to work with exploded scala source dependencies, instead of insisting everything work in the JAR world. I am used to working with rubygems/pip and love the ability to go and screw around in the libraries. When I'm ready to package, I can run "sbt assembly" instead and it can take a little longer to build a packaged JAR. Clojure/leiningen has the same issue (although there are ways to get the source itself as well [1], but nowhere as clean as rubygems). [1] http://stackoverflow.com/questions/14395413/how-do-i-make-leiningen-download-the-source-of-a-required-library http://stackoverflow.com/questions/14395413/how-do-i-make-le...
  - eeperson 13y ago
    Why do you want this?
  - ssmoot 13y ago
    Could you elaborate what you mean by "insisting everything work in the JAR world"? SBT works with git submodules, git sources, other URI or File sources for dependencies. So you must mean something else, but I'm having trouble parsing.
    - sandGorgon 13y ago
      Rubygems and Python packages are source packages. When you used the package management tools in those languages, these packages are downloaded to somewhere in your path and used within the code you are writing. In fact in Rubygems, you can point to a Ruby git repository (like github) and have dependency management happen from there - no necessity for a centralized repository (like maven.org). This is how you share a ruby gem - http://guides.rubygems.org/publishing/#sharing_source_code http://guides.rubygems.org/publishing/#sharing_source_code . I can now specify in my Gemfile to pull a particular branch/tag/version of the gem directly from revision control. The same thing happens with SBT or leiningen, except that they are JARs. I believe this comes from using maven as the backend. Therefore, either you need to setup a local repository or publish to Sonatype or some other place. This is how you share your scala code - http://www.scala-sbt.org/0.13.1-SNAPSHOT/docs/Detailed-Topics/Publishing.html http://www.scala-sbt.org/0.13.1-SNAPSHOT/docs/Detailed-Topic... . Remember, publishing means packaging into a JAR. If you were too lazy to package your code into a jar and publish it ... well, then it's cumbersome to work directly from the repo. I really, really wish scala/clojure would enable the ability to work directly with source as packages - the big, big reason why it's not is the maven backend.
      - edwinnathaniel 13y ago
        Seems easy to attach source and javadoc in Maven pom.xml: http://maven.apache.org/plugin-developers/cookbook/attach-source-javadoc-artifacts.html http://maven.apache.org/plugin-developers/cookbook/attach-so... Can't you use maven with your scala project? Most open source Java lib/framework that publish their JARs to the central Maven repository also publish their Source code and JavaDoc JARs as well. This is where I applaud the Java OSS community.
- pkolaczk 13y ago
  The design approaches for Scala and F# are different though: F# is mostly FP with some OO tackled on - mainly influenced by OCaml. Scala unifies both OO and FP. > If you know f#, you practically know Scala - well, enough to be instantly productive. Sure, but actually you can say the same about knowing Java/C# and then moving to Scala. But in that case you're missing a whole lot of features that Scala offers that F# does not: typeclasses, traits, implicits, etc.
  - balakk 13y ago
    True. I was referring to similarities in things like higher-order functions, tail-recursion support, pattern matching, option types and so on. I feel the intersection of FP features between F# and Scala is much greater than C#/Java.
  - CmonDev 13y ago
    "F# is mostly FP with some OO tackled on - mainly influenced by OCaml. Scala unifies both OO and FP" So Scala is mostly OO with some FP tackled on?
    - tel 13y ago
      In my understanding, it's hard to say. It appears to have a base semantics that you can think through as OO-like message passing or FP-like lambda calculus reduction. I assume it's implemented OO-style on the JVM, but it's hard to say whether the core language biases one side or the other. I think that's interesting but also a big indicator of why you see such a big split-brain situation in Scala. FPers program FP-Scala, OOers program OO-Scala, but neither is dominating. As far as I can tell, Martin Odersky programs balanced OO-FP, but few others do.
    - andrewcooke 13y ago
      scala is the unholy child of everything from oo and everything from fp (well, almost). (but i found it hard enough to program in ocaml, which is similar to f#, because i was always torn between oo and fp parts, so maybe i am biased or just Too Dumb For Scala)
- rjbwork 13y ago
  > It's such a relief that whatever you build will run on anything with a JVM. Xamarin/Mono is awesome, but those guys are still a little obscure, and a tougher sell than a JVM-based language. Yeah, and there are still some unsupported functions and properties in ASP.NET that keep you from being able to just drop an MVC project in. :(
- lgieron 13y ago
  I haven't tried Idea for Scala recently (last time I tried it was much worse than Eclipse), but incremental compile in Eclipse is so fast that I basically do not notice it. Or were you talking about full compile times? These are rarely needed.
  - mjt0229 13y ago
    Scala support in IDEA is great right now. I think it's better than Eclipse at the moment, although my experience with Eclipse was observing over my coworkers' shoulders.
- mjt0229 13y ago
  The problem with Xamarin is that it's expensive. Xamarin's docs don't really explain how big a project can get before you need to pay for expensive licenses, but I can't advocate at my company for a license that expensive when we're developing Scala pretty much for free.
- pivo 13y ago
  > Operator overloading seems to be highly encouraged, and library authors go to town with it. This, the "every single library needs to provide some clever DSL", is my major complaint with Scala. It's not really Scala's fault either, Scala's core libraries don't have this problem. It's 3rd party developers with no restraint. So it doesn't have to be this way and I think (or hope, based on some comments about Scala on this site previously) that it's beginning to become a discouraged practice. Still, I have an immediate, visceral reaction to it after the years I spent trying to untangle heaps of overly clever C++ code with the same kinds of issues. I never want to be in that situation again. Code should be, above all, easy to read. If your code looks like a different language depending on which library you're using, that's a real negative. At least we now have pretty good IDEs that help out, but even then I think that it's probably not be a good sign if you kind of need to have a good IDE to understand the code.
- MichaelGG 13y ago
  I've only given Scala cursory overviews and haven't written code in it. But when I inspect Scala code, it seems incredibly verbose. I was told that the type system is so powerful, type inference isn't possible in many situations, so you end up type annotating everything. That's one of the things I love about F# - code's far more compact without type annotations. Scala seems like it really wants to embrace Java's OOP completely.
seglo 13y ago
I've often said the same thing to .NET advocates at Empathica. In terms of language constructs, C# is closer to Scala than Java is to Scala. However, IMHO Scala still offers more than both combined. :)

PaulHoule 13y ago

That's going from the frying pan to the fire.

woof 13y ago
Faster and hotter?

DanielBMarkham 13y ago

Long article. Good stuff for those looking to make a similar change though. I remain a fan of F# on Mono. Love the FP paradigm, love all the easily accessible libraries, and love that it's all free. Scala would probably be a close second choice for a development shop, though. I personally would move towards pure FP with Haskell or Erlang, but staffing becomes too much of an issue to scale that out. I don't think they have that issue with Scala.

dons 13y ago
> pure FP with Haskell or Erlang, but staffing becomes too much of an issue to scale that out Does it? We've hired several dozen Haskell developers at this point, and we always get far more applicants than available positions.
- DanielBMarkham 13y ago
  I'm still collecting data on this. Along with how dev practices scale out in a purely functional environment. I try to stay ahead of the game on these things. If I'm still collecting data, either I'm missing some major sources or the overall market isn't ripe for it yet.

jimbones 13y ago

The chart included and referenced is just of all the most obscure JVM languages. Look what happens when you add Java to that list [1]. [1] http://www.indeed.com/jobtrends?q=scala%2C+groovy%2C+clojure%2C+jruby%2C+jython%2C+java&l= http://www.indeed.com/jobtrends?q=scala%2C+groovy%2C+clojure...)

josephcooney 13y ago
Or C# http://www.indeed.com/jobtrends?q=scala%2C+groovy%2C+clojure%2C+jruby%2C+jython%2C+C%23&l= http://www.indeed.com/jobtrends?q=scala%2C+groovy%2C+clojure...
yelnatz 13y ago
Wait, what? http://www.indeed.com/jobtrends?q=scala%2C+groovy%2C+clojure%2C+jruby%2C+jython%2C+java%2C+go&l= http://www.indeed.com/jobtrends?q=scala%2C+groovy%2C+clojure...
- arscan 13y ago
  apparently the matching algorithm isn't particularly smart... those are just the job postings that have the word "go" in it? http://www.indeed.com/jobanalytics/jobtrends?q=scala%2C+groovy%2C+clojure%2C+jruby%2C+jython%2C+java%2C+a&l= http://www.indeed.com/jobanalytics/jobtrends?q=scala%2C+groo... edit: yeah, it isn't intended to be programming specific: "Indeed.com searches millions of jobs from thousands of job sites. This job trends graph shows the percentage of jobs we find that contain your search terms."
- route66 13y ago
  Indeed is unusable for the points made here. Under the graphics you have the links to the respective jobs. Just check for yourself what these "Go" jobs [1] and the "Scala" jobs [2] are. "Haskell" jobs are also interesting. And more: don't forget that currently even Php ads feature the infamous "experience with functional programming (Lisp, Clojure, Haskell) is a plus" line. [1] http://www.indeed.com/q-Go-jobs.html http://www.indeed.com/q-Go-jobs.html [2] http://www.indeed.com/q-Scala-jobs.html http://www.indeed.com/q-Scala-jobs.html
13y ago

Touche 13y ago

Some people just like complicated things.

robmcm 13y ago
It's only complicated if you don't understand it.
trailfox 13y ago
Fortunately they saw the light and moved off of the complexity of C# then...
- Touche 13y ago
  From one complicated thing to another.
  - trailfox 13y ago
    Java is simpler than both C# and Scala, yet it is more disliked than both (see recent HN polls).
  - CmonDev 13y ago
    Well, at least they did not choose some dynamic garbage.
- taude 13y ago
  And single vendor buy-in.

rodh257 13y ago

Really interesting article, thanks for writing it. I'd like to hear a bit more about the reasoning for the whole company swap, what problems you were having with C#/Microsoft stack. The impression I got was that you tried out something new for a small project, liked it and liked the idea of OSS in general and then started doing everything in that way, is that all there was to it? What other factors came into the decision on a whole?

300bps 13y ago
I found the article very interesting as well but honestly it reads like a nightmare. Company heavily invested in X. New CTO comes on board, gives the technology stack a "hard look" which is often a euphemism of, "I wouldn't have chosen that technology, so you must change." Large portion of the existing developers leave, new developers (including OP) come in. New developers base technology decisions on what's best for their career, not necessarily what's in the best interests of the company. After all, in the Why Scala section they plainly state they knew little of Scala and there's a large section about what languages are hiring. And as you said, if there is time spent on what made them decide to switch away from the Microsoft stack, it is buried to the point I couldn't find it in two read-throughs of the very long article.
- taude 13y ago
  I don't see having some of the old-school developers leaving the company and being replaced by potentially better talent as a bad thing. One signal for me is that I hire smart people because technology changes. It's a red flag for me when people stop learning or lose the desire to add to their tool belt. Some people can't adapt. But, hey, the world still needs Cobol programers, so...
  - 300bps 13y ago
    old-school developer With all due respect, you obviously know nothing about the Microsoft stack. These people were not using VB6. How do I know? From the article: new projects chose a base technology stack of C#, ASP.NET MVC ASP.NET MVC is not an "old-school" framework. It was first released in 2009!! That's four years newer than Ruby on Rails. It's ridiculously actively developed as well as being open source. It's currently in version 5 which was released October 17, 2013 which was... OMG 8 days ago. I continue to be shocked at how little most HN developers know about the Microsoft stack and how much innovative work has been done since they last looked at it in 1998.

taude 13y ago

It sounds like you might not have worked there yet, but it'd be great to hear how some of "convincing of management" went. Was it mostly the new CTOs vision who was able to convince business? (I speak as someone who moved some web apps off a .NET stack to OSS, but that was for a small company's single product)

deleted 13y ago
[deleted]
CmonDev 13y ago
".NET stack to OSS" This does not make any sense whatsoever since e.g. ASP.NET MVC is OSS. Why don't you say ".NET stack to JVM stack"? Because it doesn't make your choice sound intrinsically better?
- taude 13y ago
  You don't run your ASP.NET MVC on Linux boxes, though. On non-IIS web servers, and likely you use SQL Server and the LINQ libraries....unless you'r using Mono (which has a lot of hurt involved to do so, especially once you start getting in with external libraries that your application might depend on). in general, when people mention ".NET STACK", they're talking about the whole-shebang, not a single library that might happen to be OSS when the other 100 libraries you're dependent on aren't.
- dragonwriter 13y ago
  > This does not make any sense whatsoever since e.g. ASP.NET MVC is OSS. ASP.NET MVC is an open source framework, sure, but the .NET platform, as such, is not OSS. (Some parts of the MS .NET ecosystem are open source, and there are open source alternative implementations for some parts, but that doesn't make the platform OSS.)

pkmishra 13y ago

Thanks for Sharing. I also learned scala after working on .net stack for more than 7 years and I am not disappointed. I really like C# but if I have to learn JVM based language I would definitely go for scala.

cygwin98 13y ago

And one year later, a blog post titled "Why we moved to Java from Scala" or "Why we moved back to .NET" appeared on HN and havested hundreds of votes. Just kidding.

CmonDev 13y ago
It actually makes a lot of sense, because the change to Scala was triggered by "Simon". Another Simon will come and bring Python or something even worth.
- seglo 13y ago
  That's incorrect. The technology change was bottom-up, by developers. Simon didn't intervene with his technical direction until we already had a couple of Scala projects under our belts.
  - _random_ 13y ago
    I you saying you had a vote and some developers (C#) disagreed and there was a minority of them?
    - seglo 13y ago
      There wasn't really a vote, but we did have a group forum where objections could be raised. People who weren't onboard with Scala were in the minority and most of the arguments raised didn't hold much water.

MrDosu 13y ago

Why couldn't they have written "Web Application" in the first paragraph...

cygwin98 13y ago

I was being snarky in my another comment and was downvoted as hell. Oh well, I am OK with that. However, I can't help thinking of the failure of Scala at Yammer, which caused a big buzz two years ago [1] and [2]. From the blog posts I've read about Scala and Yammer, they planed the transition to Scala carefully and with passion, and they switched away from Scala in merely one year. Has the situation changed totally? I don't know. Maybe Scala has improved significantly since then and all the pain points back then have been addressed nowadays. I'd like to be enlightened on these factors. [1] https://news.ycombinator.com/item?id=3297750 https://news.ycombinator.com/item?id=3297750 [2] https://news.ycombinator.com/item?id=3292555 https://news.ycombinator.com/item?id=3292555

jimbones 13y ago
Things haven't changed, using Scala doesn't offer significant benefits over Java and it is just a noisy minority that pontificate over Scala and its supposed (largely academic) benefits. This is the thing I find most annoying regarding Scala use, and people advocating its use, it just doesn't do anything that Java can't do - plus the tooling for Java is wayyy better, there is a smaller learning curve, you can hire people to work with it and you don't spend your days endlessly debating what obscure language feature that may lead to tighter code in release 2.11.B.3.48d.M1.
- trailfox 13y ago
  > "Scala and its supposed (largely academic) benefits" Perhaps you would like to discuss the "academic" benefits with the likes of Twitter and Foursquare? > "it just doesn't do anything that Java can't do" It's a more expressive language. You could argue that Go and Python can't do anything that C or assembler can't do. That doesn't make Python irrelevant. > "plus the tooling for Java is wayyy better" In terms of the JVM the tooling is exactly the same. In terms of coding I use IntelliJ for both Scala and Java development, without noticing much difference in quality between the support for either language. In terms of libraries Scala has access to all the libraries that java has as well as additional libraries designed specifically for Scala. Most (actually all) Java developers that I know grumble when having to code in Java after they are exposed to Scala.

flipchart 13y ago

I'm more and more confused by everyone that bashes the MS stack because it doesn't have the OSS community that the other stacks do. I'd really love to hear what OSS projects there are for the Python/Ruby/JVM/etc languages which don't have equivalents for .Net. Maybe I'm doing something wrong, but my experience on .Net has always been such that I can find a project to meet my needs. Sure my target OS is Windows, so the OS interop is not an issue for me, but for my day to day needs, there is always a solution to be found in the .Net OSS community.

pnathan 13y ago
Weka is one that I ran into personally a few weeks ago.
subsection1h 13y ago
What are the .NET equivalents of The Ruby Toolbox[1] and pluginGeek[2]? Also, there are more than 11 times as many Ruby projects at GitHub as there are C# projects[3] (even though .NET developers vastly outnumber Ruby developers). [1] https://www.ruby-toolbox.com/ https://www.ruby-toolbox.com/ [2] http://www.plugingeek.com/ruby http://www.plugingeek.com/ruby [3] https://github.com/search?q=stars%3A%3E0 https://github.com/search?q=stars%3A%3E0
- _random_ 13y ago
  And 7 out of those 11 are some sort of 10-line "gems" or whatever they are called. Also GitHub is not the only code sharing web site, just biggest and hypiest. For any of those tools/plugins there is a .NET equivalent, but I don't know a up-to-date page that combines them all as an overview.
- flipchart 13y ago
  To be fair, those appear to be pages which list existing packages, which is not what I was commenting on in my OP. However, I would suggest one of the closest equivalents would be nuget[1]. I think that the history of the languages should be mentioned: Ruby 1.0 was released in 1996[2], while the beta of .Net was only released in 2000, and 1.0 only in 2002[3]. Thus one could perhaps say (maybe unfairly, but nevertheless) that Ruby has had more time for OSS projects to develop. I"m not saying that that is the reason for the abundance of Ruby projects on Github, but I don't believe that the relative lack of .Net projects on Github implies that the needs of a .Net developer is not met by the current OSS offerings. [1]: http://www.nuget.org/ http://www.nuget.org/ [2]: http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 [3]: http://en.wikipedia.org/wiki/.NET_Framework http://en.wikipedia.org/wiki/.NET_Framework

mwexler 13y ago

Besides an interesting read, I laughed all over again at the video on the bottom. Worth a reminder if you didn't catch it the first time or haven't "Java 4-Ever" before...

seglo 13y ago
Definitely a nugget of Java humour worth preserving and sharing. Glad you liked the post :)

karterk 13y ago

I'm part of a team who moved from Java to Scala recently (C# is a nicer language than Java these days). Apart from me, nobody else had real-world Scala experience but were generally good programmers and were able to pick up the functional aspects of Scala fairly quickly. The move was a big success, and a frequent comment I hear is "I can't imagine moving back to Java". One of the reasons why the migration worked for us was that one can (with a bit of discipline) get into idiomatic Scala slowly. You can definitely start off writing Java-ish Scala and still gain a lot from the decreased verbosity and nicer APIs. You can safely stay away from over-using implicits, functional programming etc. till you get a good grasp of the language. With excellent Java interoperability, you don't have to convert your entire stack to Scala overnight, but slowly replace old code with Scala. With respect to performance, if you insist on writing idiomatic Scala, there is definitely a performance overhead, because the JVM is not suited for large amounts of small allocations, as is often the case with an immutable style of programming. However, we run a pretty large scale data crunching system, and depending on what your code does, CPU bound performance hit pales in comparison to the network and I/O waits, so for us, it was not a big deal. When we absolutely needed to optimize a tight loop or something, we wrote C-like Scala, using while loops and mutable data structures. Addendum: The greatest win for us was the readability of the code base. Scala allows you to largely keep your data structures immutable, so it's much easier to reason about. With parallel collections, Actors and Futures, concurrency support is excellent as well. You definitely need to pick up a few new concepts, but the time is well spent as once you get a hang of those things, your productivity will be 10x - you don't have to wrangle with primitive concurrency constructs.

flipchart 13y ago
Why is it so hard to keep your data structures immutable in C# or Java? C# (my primary language) has parallel collections as of .Net 4.0 and with .Net 4.5 you have the async keyword support on top of the TPL. Could you elaborate on the differences between Scala and C# which make Sala more preferable for you? I'm not trying to start a war on C# vs Scala, I'm genuinely interested in the differences (I enjoy learning new languages, but for the right reasons)
- 13y ago

powertower 13y ago

Reading this thing it just gets worse and worse as you go down. All they've done was get rid of smart people, create complexity, and embraced a culture of buzzwords. A complete disaster in the making. And for what?

seglo 13y ago
I'm sorry you interpreted it that way. It wasn't a disaster and internally the general consensus was that it was a great success. I've made some amendments to my post to provide some more context to our initial process change. Thanks for the feedback.
- powertower 13y ago
  I might have read too fast, and might have some serious bias here because I actually prefer C# and .NET over anything else (and like leaving performance issues to be dealt with caching / rather than introducing complexities) - but it seems like you went from using a familiar, predictable, and very popular stack to embracing a dozen different smaller and lesser known technologies all full of interoperability issues, idiosyncrasies, and each requiring very specific domain knowledge.... All because a single person at the top is ideological about OSS instead of practical about solutions. Though maybe that's what was required to get a buyout or merger, in which case that's what you needed to do due to the environment/culture of the other party... http://www.empathica.com/press-release/mindshare-technologies-acquires-empathica/ http://www.empathica.com/press-release/mindshare-technologie...
  - seglo 13y ago
    The process change was top down, yes, I think that's the only way it could have succeeded IMO. However, the Scala change was bottom up and by developers. The Mindshare acquisition is a recent event that postdates our technology change (Sept 19).
    - _random_ 13y ago
      How did those "developers" choose that change if a lot of them disagreed and left later on? There had to be 1-2 leaders who happened to be Scala-fans.

programminggeek 13y ago

Scala is awesome, but I wish it had a faster compiler. The web dev experience of 2-5 second code refreshes is painful IMO. If they got it to less than a second Scala might be my ideal language.

jroseattle 13y ago

I always find the most interesting aspect of "we changed from X to Y" to be about why change is happening, how it is managed, etc. Context is everything, but the process described by the OP sounds like standard, top-down decision making. The OP certainly gets to it by the end of the article. I've gone through this process (tech stack shift), both as a recipient-of-change as well as a catalyst-agent-of-change. Remarking on the email that the OP's CTO sent to everyone, these statements stick out: "...A technology choice will be made appropriately for the needs as we see them..." "...no hard decision has been made about our future languages or technologies..." "...Less C#/.Net, more Scala/Java/Open Source..." The CTO likely has very good intentions, but this is an implied technical decision that's already been made. He references "we" in the email to imply group participation in decision-making, but it is very much a you-are-with-us-or-you-are-against-us definition. To wit, those who didn't buy in were shown the door. Having been the guy in that chair, this is not an easy thing to do. Being handcuffed by prior technology decisions is not only difficult, it's often untenable. Usually, the people hired into those leadership roles often have to resolve the decision making issues that got the company to that point. That said, here's what I've learned in terms of how to go about these types of long-term changes: - As the CTO, take full responsibility for introducing change. This is not taking credit, but instead being the owner of the decision and ensuring it succeeds. Support the team, and encourage them to openly question the decision, so that those questions can be addressed. The CTO's email above makes a change decision requisite, but it's up to everyone else to make it work. To anyone who's worked in a potentially charged environment, that's a typical setup for scapegoating. As the lead dog, don't put your team in that position. If your decision comes off as playing-the-executive card, you have failed. - As a team member, embrace change but make it completely objective. Be open to change, but only as it helps to reach a goal. Evaluate technologies after using them, comparing them, and finding what's good and what's not-so-good. Make your personal productivity the least-influential point of analysis. If you can't find a way to assess something honestly because of your preference for operation, you're doing yourself a disservice. Be productively critical of technical decisions -- your own, and others.

seglo 13y ago
OP here. Thanks for your feedback. The Technical Strategy email was sent out about midway through our adoption of Scala. I didn't explain the dynamics of our larger development department much in my post, but at that time we were essentially two teams in two different physical locations. The location I was at had already seen success with a few projects in Scala (BeetleJuice and the beginning of our API). Our CTO thought it was time to set a clear direction for the future of development department after an analysis of our current situation and discussion with members of the wider team. Nobody was shown with the door. I'll admit there was some resentment, but nothing a well adjusted developer couldn't get over. As I mentioned at the end of the post, one thing I would do differently in the future is make a stronger effort around consensus building about the decision. However, the Scala change started off as something small and organically grew into a legitimate alternative to the Microsoft stack. Going into our first project (BeetleJuice) we didn't anticipate the impact it would ultimately have on the organization.

kylequest 13y ago

This statement is pretty funny given the focus on intentional transition to Scala: "So, no hard decision has been made about our future languages or technologies, and there are no rules that all new development must happen in Scala."

petermartin 13y ago

I really liked this article. I am just now starting to learn Scala. Great post.