Scala in 2018: SF Scala panel with Rod Johnson

Scala in 2018: SF Scala panel with Rod Johnson

Recording: Scala in 2018: SF Scala panel with Rod Johnson

[Music] yep cool so if each panelist go in from hor here can just say their name quickly my name is hor here itties I am Paul snle R Johnson James Douglas it co Brian McKenna fantastic we got test James microphone all right cool yep so can you can you see anything here so see when the sound goes this little bar just jumps okay cool all right so we're going to start um welcome everybody this is uh a special San Francisco Scola Meetup I think one of the most special events we've done through mostly 3 years of our existence so welcome everybody uh we're in Kabam and Michael Morana director of engineering here is really uh the person who pushed for us to be here this is our first meet up here this is a fantastic venue this is an old Twitter office and I was actually working here when she was at Twitter uh it's c located it's uh beautiful views company they're enthusiastic about Scala a bunch of their team members are here so we really are grateful and happy to be here um and uh a few words how this whole thing uh came about uh in uh in June they had the schol days conference it's a typ save yearly conference which quickly became a flagship conference was Scala and uh essentially all the people from San Francisco flew to New York to meet there uh and uh and Rod uh gave a keynote uh which uh start a lot of debate and cost a lot of thinking which is a sign of a a great keynote uh and essentially uh if I can sort of paraphrase the meaning is a Scala increases uh we should be careful with various complex issues uh if I may say so and essentially be mindful of of various techniques uh in widespread usage today uh and that basically cause a lot of responses from The Scholar Community but they not necessarily were all in a kind of a productive fashion that there were a lot of tweets and kind of uh sarks but uh we never had a conversation about this right we actually never had a forum where we can collectively think of the future of Scala and uh I think we should all thank R for stating the the title of his K the original can out you know looking a few years ahead and I think it's really useful for all of us to do that so basically we called this panel the same the same uh title to really focus on on where what is the goal of all of this right because in in five years the world will change uh a lot of new companies will be born we already see from uh San Francisco startup scene a lot of them are so it's inevitable that huge companies will be born like Twitter and grow very quickly which you know happen to the time frame of 5 years right and scull will be underneath and thousands of developers will be working in them a lot of them will learn Scola in the years to come so it's it's all very uh relevant questions and this forum is meant as a discussion where we can actually uh come together to the sculla community and talk with Rod about about the future and he has a lot of very relevant experience and basically he took a lot of this industry to to new heights and uh definitely his addition to the types of award is very valuable and we can all learn basically from from from that uh so at the same time uh there was a lot of controversy uh and uh disagreement on on on a lot of specifics and people have run opinion so basically we have we'll have a format to to discuss all of that so that's the preliminary uh the plan for the evening is Mike is going to tell us about Kabam and tell you a bit more about the facilities right it's a huge audience so you should know about all the amenities available and after that we'll jump straight m thank you very much so I'm Michael Morano uh thank you so much to Alexi and Jason for organizing the Meetup uh I know Alexi put a lot of work into like the Scola uh the Silicon Valley schola Symposium which was fantastic I think we've got a really great Community here so Kabam is most well known for our mobile and social games um I work on the distribution engineering team a team of about 20 Engineers uh working on the core web services for our account systems and our mobile sdks uh we've got existing apis which we've been using we've been using Java we've been using Ruby and over the last two months we've started to build up our web services on Scala and play um so we're definitely new to the space we're excited to be involved and we're always looking for people to help us out so if you're interested in working at cabam come talk to camers we've got a whole ton of people here for us our recruiters here but that's the end of the plug um uh tactics for the evening so piles of pizza please eat all the pizza beer is over there feel free to drain the kegs if you don't drink beer there's refrigerators over there with other drinks restrooms are out in the lobby around the corner if you guys need anything come grab any anybody from cabam tonight thanks a ton all right all right thanks Mike so the uh structure of this panel uh will be be pretty fixed in the beginning and then we'll uh uh Len up a little bit and play by ear so first Rod is going to recap essentially his keynote for for those of us who didn't get a chance to to see in its entirety uh and uh then each of the panelists will basically State their response and state their vision for Scola in view of these questions uh so we know basically where everybody uh stands and but and I'll ask you guys to introduce yourselves I think everybody's uh pretty known in scull and Java Community but you know if you can just sort of introduce yourself again and recap a little bit uh uh your scull of biography it will be great and then uh formulate response uh so that will be the first part uh So based on this and the set of questions which we collected on the uh Meetup uh website uh I will ask each of you uh a question uh to clarify your positions right and and all of this will be Ed so Rod has up to 10 minutes every other panelist has up to three minutes uh the questions uh because we'll be asking all asking R so we need to know you know his uh his uh position in in a lot of detail uh so when the second part each of the panelists will ask Rod a question we'll have up to 30 seconds for the question and up to 2 minutes for R's response right so uh and the the panelist do not have to use all this time we'll have the timer going uh but it it's an upper limit uh and short questions are fine and short answers are fine uh and uh and basically after that we'll have the segment for the audience questions so I encourage everybody to uh either prepare the question and think it through when we go around with the mic or and or uh tweet with the hasht Scala 2018 which is here on the screen and I'll be picking this up and Jason our amazing organizer who is a referee he is the time asra he will be managing the time and he has various Tools in his Arsenal to enforce this uh and uh he and Mike will help me with the questions uh from the audience and uh in the end we'll have a free form discussion uh among the panelists so that's that's the plan so Jason please ring in the pel I think you to it like this let's do it again all right there you go so R uh now the floor is yours please uh tell us uh uh the uh summary of your um message uh which you uh gave at colay thanks uh Alexi actually before I start I have a question at what point do we have the Cong Congressional vote and are we going to go to the UN Security Council I think that depends on the proceedings okay okay so well thank you very much um for coming tonight I do hope that you know some of you aren't waiting with baseball bats outside I sometimes sometimes wonder from Twitter but you know seriously I think it is fantastic for you know as a sign of the health of the Scala community that people are so passionate about Scala and so many people want to talk about Scola I mean it kind of sucks for the people who couldn't come along tonight because the event was full um but you know it's great to see so many people here so you know there has been an interesting reaction I think it's fair to say to my talk and you know maybe I should have spoken about something less contentious like chemical weapons in Syria or gun oh um because there may have been a little bit less passion um but seriously you know I'd like to start by saying that I think in terms of the big picture I would hope that everyone on the panel and everyone in the audience is on the same side I passionately want Skyla to succeed I really really love programming in skolar as I mentioned in my talk in New York I get more joy out of programming in schola than I have out of programming in any language since c c is not a language that I would choose to write code in every day because frankly we have evolved in terms of levels of abstraction and paradigms but you know with writing code in C I just always thought that it was perfectly elegant if you wanted to write procedural code C gave you a beautifully elegant way of doing just that and know Java and C++ I I write quite a bit of java um I like Java but I I never felt exactly that you know it was an objectoriented language Java was okay but you know no one would seriously argue that it was the most perfect or elegant expression you could have of those Concepts whereas with scalar I think that it truly is beautiful if you look at the way it mixes the paradigms if you look a lot at a lot of the little details in the language it's you know I think it's truly truly beautiful I would also say that um I think in distinction to um some people um in the community and frankly in distinction to some people I highly respect I am very much a practical kind of guy and I make you know I don't apologize for that I mean essentially I think that software engineering is fundamentally about people rather than uh programming languages and you know I think it is a valid matter of debate whether that's correct um but you know that is definitely the Viewpoint that I'm coming from so some of the major points I don't want to recap the entire talk but some of the major points that I made was that I think that scolar is on the brink of becoming a really mainstream language I think Scala really is breaking away from what you might call the second tier languages and I think it's a really really exciting moment for Scala as a programming language and therefore for those of us in the Scala community so that actually reflects one of my biases that I think it would be really good if Scola becomes mainstream I think it'd be really really good if lots and lots and lots of people use scholar and there is actually a valid argument that that is not the way that Scala should go that Scala should be something that you know is frankly more of a niche but you know perhaps U maybe what some people would consider a more elegant niche so you know I I think that is a debatable point but I'm coming pretty pretty uh strongly from the Viewpoint that it is really good for things to be used very very widely for a number of reasons one reason is that if something is good you really want people to benefit from it so if you think something is truly fantastic I think it is great to take that to as many people who can benefit from it as possible secondly I think that things that do not expand to a large community and potentially a very large community eventually do die everything dies in the end but the things that live longest are the things that really have gotten to mainstream acceptance so if you love something but there really aren't an enormous number of people using it it's more likely to go away uh and that you know is definitely one of my motivations some of my more controversial points were my assessment of what I believe to be some of the issues holding Scola back from that kind of mainstream acceptance and also some of my observations about Java so you know I started by talking about a few more or less randomly chose chosen reasons of why Java sucks and you know that obviously went down goes down pretty well in in in the community but then I actually talked about some of the reasons that Java has become very popular and why frankly there are things about Java that really really don't suck so for example there is the fact that Java has exceptional and exceptionally good story on backward compatibility we don't and that actually in that it's been intriguing that in terms of the reaction or rather the more negative end of the spectrum of re reaction to my talk that has not been discussed at all and certainly both in my opinion and from a lot of people that I speak to uh that seems to be a major issue another thing that I think Java doesn't suck at is tooling support Scala tooling is getting there java tooling is truly awesome and it's not you know it is not a question of like I believe someone commented about the event about well of course J needs toing because of all the XML files I'm not going to mention spring tonight besides the fact that really heavy use of XML hasn't been recommended in spring for about four years I I do think that I should break that um but but you know the fact is it's not just a work around to the deficiencies of java Java at the end of the day is a language that you can build tooling for is it has a strong model It's relatively typ safe scolar is a language you could build even better tooling for because it's got a stronger model and it's a matter of time and it's also possibly a matter of slowing down the moving Target that is scolar so the tooling can catch up one of the more contentious that I mentioned was so I think there's two parts to this the first part is the question of whether it's good for code to be easily readable so for example if some someone can't read your code if that's your fault or it's their fault I frankly think that if someone finds it hard to read your code that often is the fault of the person who wrote the code there is a second very legitimate debate about what constitutes readable code and I certainly would not claim to have a monopoly of wisdom on that in fact I would not claim to be anywhere near the wisest person in this room on that but I think it's a very very important debate and my personal observation is that because of the proliferation of different possibilities and different styles that exist in Scala uh there does tend to be more of an issue and I mean this is this is not something that I plucked out of the air this is something that I've heard from a number of companies that I'm personally associated with and it's something that I've heard from a lot of people more broadly that they worry about the mix of styles and the fact that there isn't always so a priority on um readable code another perhaps content well definitely contentious point was that I don't think object orientation is bad in fact I think that Scala has been described by its creator as a modern object-oriented language that has first class support for functional programming and I do think that there is a bit of a current in the some elements of the community about viewing objectoriented programming as a second class Citizen and I I think that personally does not reflect uh what scalar is this definitely shouldn't be taken to mean that I dislike functional programming I think functional programming is very valuable I think there are fine languages purely devoted to functional programming but I think scholar is essentially a hybrid so you know I definitely um do not mean to give the impression that I dislike functional programming some of the other points I made were essentially about the community that I feel that there is an assumption that the skaret community knows best and that you know if you look for example in particular at the Java community that the great unwatched Java folk basically don't know very much it's not my personal observation and I do think that when we look at other communities and particularly the Java most of our future recruits are going to come from we actually should take a slightly more respectful and I do believe that the point that's been made that perhaps I was not sufficiently respectful of what's been done in the Skyla Community that's a very very fair point and it is something that you know frankly I should have made clearer in the um in the talk that I am actually respectful of a lot of that has been accomplished in um the Scola community so essentially what I was trying to do is open a debate on how Scala can get to being a mainstream language that's extremely widely used and is going to live frankly um for decades and I I think that is the most important debate in Scala right now thank you Rod it's perfect timing uh we have the timers going here uh they are basically guides for the panelists we you know prefer that to keep inside the bals but if you make a very important Point don't you know don't be afraid to run over a bit so uh now uh we'll just go uh left to right uh starting hor uh so please introduce yourself and uh and then uh formulate your response to to Rod's uh keynote and and today's recap of that uh we have for all the panelists they are uh Twitter handles and GitHub accounts on The Meta page I think uh folks know most of the panelists very well uh but it will still be useful to hear you know your little story from from yourself uh so my name is J Ortiz I'm a software engineer at for square uh I've been at for square for about three years uh for square has been using Scala extensively for that entire time uh when I started we had like five Engineers writing Scala full-time now we have like 80 Engineers writing scholar full time uh so we've definitely like sort of seen the team grow and the codebase grow uh the vast majority of the engineers that we've hired have had no prior experience whatsoever with schola uh so so we've gotten a pretty good sense of like you know how do you take programmers that have never been exposed to scholar before and like dump them into a very large uh scholar code base we have I last time I counted I think we had like 600,000 lines of Scala uh in our code base uh dumped them into a very large Scala code base and like you know do they can they work well how do they find the language what are their stumbling blocks um before where I worked at LinkedIn uh LinkedIn at the time was like a 95% Java shop uh with you know a few hundred Engineers uh and they were they were sort of slowly adopting Scala for like you know a handful of teams were looking at Scala for you know a handful of projects uh I think now LinkedIn has sort of like jumped you know pretty pretty deeply into Scala and they've a lot of their core infrastructure is based on Scala uh a lot of their web web stuff is being Rewritten in Scala um so that was that was a different perspective of like a large Java organization sort of like transitioning to uh to Scala uh so I think I've gotten like and before LinkedIn I was sort of like using Scola for my own projects not necessarily at a large company uh and so I feel like I've gotten like a a good sense of like you know using Scala as a hobbyist using Scala in an organization that went from you know massive Java code base to like being pretty uh pretty big on Scola adoption to an organization ation that started off as 100% schola uh and and and grew very large um and so my my reaction to to Rod's uh talk um I think there are some areas in which we like we very much agree I think there are uh some areas in which we have like very different assumptions about you know what's going on uh and I think there's some areas where we like fundamentally disagree and I want to go through through each of those uh so areas where I think we we very much agree um compile time I think he he mentioned in his schola days talk that you know the Scola compiler needs to be faster uh and that is the number one biggest problem that we have run into at for square is when you have you know 80 Engineers recompiling 600,000 lines of Scala all day long uh it it takes a very very long time to compile uh and you know there's we've we've spent a lot of effort sort of like mitigating the the problems of scholar compile times uh but it is you know orders of magnitude slower than the Java compiler than the go compiler than a lot of other compilers uh so that's definitely like one of the one of the biggest areas I think that that scholar could improve in uh another thing that I think I agree with rodon is that uh tooling support to get better the IDS need to be better there needs to be buggers uh refactoring tools stock enforcement tools uh sort of like f bug software I think there's there's all sorts of things where uh Java tooling is far ahead of where uh Scala tooling is and and these are sort of like important for for companies that uh that run on on Scala um I also agree with Rod that that Scola sort of uh lets you lets you code in a variety of Styles um you can treat it as like Java with you know fewer type annotations you can treat it as hasal with more type annotations you can treat it as like you know Ruby you can treat it as like anywhere in like this you know multidimens space of Styles um and and I think different uh different organizations and different open source projects have converged on sort of like different areas of this style space uh and there's uh there isn't a lot of agreement as to what constitutes good scholar style um and and I think sort of being able to um being able to like codify uh maybe not like one style guide for everyone to agree on but but at least sort of like a small number of them for for different communities to agree on I think that would be very useful um uh I also agree very much with him about not Reinventing wheels that have uh sort of like if there's a good Java library that does something and it does it well and it has you know 10 years of experience in production and you know it's fixed a lot of bugs and addressed a lot of issues uh there's no there's no need to reinvent that in schola uh and I think sort of like one of the places in which the the sort of the Scala open source community has done very poorly here is with Json libraries there's like six different scholar Json libraries uh all of them are buggy in different particular ways uh and and it's just like they don't interoperate with each other they don't uh they're not very none of them are very performant uh the situation in Java land isn't that much better but but there are sort of like you know solid Java libraries that at least do like Json pressing very very quickly and very very well uh and you know everyone in scholas seems to want to reinvent their own parser for Json and that's you know probably totally unnecessary um and and I also agree that the jvm is scola's greatest strength I think uh to the extent that Java that Scola has been successful it is because it has uh integrated very well with the jvm which has sort of you know thousands and thousands of manur of uh of you know engineering effort P into it to make it like a great solid VM it's like much better than than basically any other any other virtual machine for any other programming language out there um and so that's the that's the stuff where I think we I I agree with you uh the things where I think we have like very different assumptions about about uh about things is um uh I think you know you your your stance very much assumes that the popularity is good that the more people use schola the better that is um and I think I don't know if I agree or I disagree but I think that I I don't sort of automatically assume that um I think uh Java has been extremely popular and that is a source of a lot of its success but I also think that the vast majority of java programmers are not people that I would want to work with um and so in sort of like a very selfish way I want Scola to be this like this niche of people that are that are really really good at what they do um and and if I'm hiring for a scholar position then I don't have to worry that I'm going to get flooded with a bunch of rums of you know people that can string Enterprise of be together but have no idea how a computer works um and and maybe that's a little snobbish uh and it probably is uh but but I like that aspect of schola um I think another assumption is that Enterprise uh another assump another assumption you make is that Enterprise is good um and and I think there's a lot of room for debate there um I think uh you know Google is a huge user of of Java for you know for a bunch of their back-end software um and they have totally rejected all of the you know j2e all of spring all of like all of the like Enterprise Java things um and they've you know basically settled on you know the core of j2c they've even like ignored a lot of the libraries they've built their own standard library for Java um and and they've taken that and you know then they're they really love Java I think you know Google is very very committed to to working with Java um but uh but they very much rejected all the Enterprise site of java uh and I and I think you know there's something to that where uh a lot of the Enterprise stuff that has gone into Java is not great um and um and the the core of the Java language is is really beautiful and elegant in some ways like it it uh it's a the jvm is like a very you know clear programming model it has a has a memory model which is like you know first of its kind kind of thing um and uh and and Java sort of like Maps very much like one to one onto the jvm uh and so it's very elegant in some ways but I think a lot of the ecosystem that evolved around Enterprise Java was not very great um and I think that another one of the assumptions that that you make in your talk is that uh the the visible parts of the community or the majority of the community uh and I think that's not the case at all I think that uh the people that you like the the stuff that you see in blog posts and on the mailing list and on the IRC Channel represent like a very small percentage of the actual schola code that's getting written uh and if you talk to people that are using schola at work you're going to see a much wider perspective um than than what is like sort of evident uh in um in sort of like the the very vocal Community um and I think I'm out of time but I'm going to say one more thing um and and that is I think that what I fundament fundamentally disagree with you about uh about the talk that you gave is that it sounded very prescriptive it sounded very much like uh The Scholar Community should do this or the scholar Community should do that um and we need to like you know work towards a common style and we need to uh do all these things um and I think I think that approach of telling other people how to write their scholar code uh is just going to be very unpopular uh and I think the right way to approach the the problem of like if you want schola to be popular in the Enterprise or you want schola to be popular among this like community that has not yet adopted schola uh I think the right way to do that is is not by prescribing current schola users on how they should use schola uh but by Leading The Way right sort of like publishing a style guide uh sort of you know uh setting like setting best practices sort of uh you know publishing libraries that uh that you know use the the the Java libraries that you think shouldn't you know are solid and aren't re and and aren't Reinventing the wheel right so like leading the way for people that uh that want to use Scala in the way that you Invision people using Scala uh and I think that is that is uh a better and a probably more fruitful approach than than trying to to sort of like you know hurt all the cats that are currently using Scala and make them go in the direction that you want to go because I think that's it's kind of not really going to happen um and that's more than I have time for thanks for uh now uh on to Paul well um Rod has has made the job of debating him extraordinarily difficult uh with his synopsis which I suppose is only fair after he's made it so much easier to be a Java developer uh for the last uh you know over a decade right so the first thing I'd like to do is thank rod for spring actually um you know made my job so much easier as a Java developer for many many many years um I really don't don't have a lot to offer by way of debate um so let me just if I can make a couple of of observations uh offer a couple of opinions of my own um one is that what it means to be Enterprise application I think is different today uh than it has been at uh any time in the past decade plus I think um okay Chris sorry we're just adjusting your levels Paul hello maybe we should use the hand mic I've got the hand mic here why don't we just go to that okay okay let's try this okay thank you um to to be an Enterprise application now has has challenges around the the quantity and quality of data um I think that you have to deal with that have evolved over time Rod is over here nodding his head uh so um most people are going to be exposed to the need for some form of machine learning um as they proceed developing applications for even the most mainstream of uh Enterprises uh I think at this point uh I think everybody understands now that blocking IO uh shared State concurrency um you know the these kinds of things are are part of the problem set not part of the solution set no matter what language uh you happen to be working in so one of my propositions is that um it takes new languages and new Frameworks to address new requirements even in the mainstream Enterprise uh and then a second observation or opinion that I would offer is I'm not convinced that having a bifurcated or more fragmented Community using a language is necessarily a bad thing um for example the C++ Community is pretty firmly divided into the SE with classes camp and the Boost Camp uh and that doesn't seem to have damaged uh the C++ Community uh all that much and I would suggest that for the Scola Community to have similar subcultural divisions if you will uh is not necessarily harmful um to The Scholar Community as well you can just sit it down and uh hold it for next time uh and now thanks Pa uh James we'll see if my mic lasts yeah uh so uh I'm James Douglas and first of all I want to say that this is super awesome to be up here with all you guys I feel like uh I'm in your shadow um and I'm just honored to be in this panel with everyone here um so I think I like like many of the people here and many of the people uh at schola days who saw uh your keynote Rod uh got into Scala as uh something of a Java refugee uh so I started my career you know as a Java programmer and then I moved into sort of the Enterprise um Java space uh building ejbs at first on things like Oracle websphere or IBM web spere or whatever um and then uh I read both your books and and moved away from ejbs which was wonderful and and got to adopt spring uh and ended up using that for SE uh several years um at multiple companies Consulting and um and so forth uh and so I've seen it work really well um especially with big teams of uh beginning Engineers uh and then in the last few years I've discovered Scala and that's kind of opened up this entire new world to me so I you know my my history was very much in this o kind of procedural shaped um uh world and and now uh you know not having a math background uh I'm learning about things like functional programming and category Theory and so forth um and I'm finding that it's really affecting the way that uh I think about Computing and and that I write code um and such that at any given point in time if I look back at code that I've written just a few months ago I think like wow I'm not going back to that way like no way um so it seems like for me uh Scala has been uh uh because it has this sort of O functional uh hybrid model uh it's going to be very difficult um you one of the things you talked about was um uh kind of coming up with uh idiomatic uh or or style guide prescriptions as jge put it uh that we want to sort of steer the community toward and uh you mentioned that most of the people uh currently using Scala make up very much the minority that you expect to see uh in the next five years so um so I can I can kind of see how uh having sort of a standardized um best practices or or sort of style guide would be you know handy for bringing people in and Scala is and how to write code in Scala but uh based on my own experience it seems like the things that brought me into Scola are completely different from the things that are keeping me there so it's kind of nice uh that there is such a wide range of styles that are possible in Scola and I think that's um one of the things that has made it successful so far and uh I think gives it a lot of value um that's also going to uh make it very difficult um you know to come up with any kind of single standardized style to prescribe to people and I think um Jorge was mentioning uh the uh proliferation of Jason parsers and uh you know they're all buggy and you don't want to use any one of them in particular um how uh you know each one of them different style and so it's it's kind of interesting to look at uh where I am in my own uh progression through you know my learning of Scala and and watching my uh approach to programming change uh these different libr will actually appeal to me at different times and so I can see the inherent complexity in this especially when you have a team of people who are learning schola or maybe have more there there will be a tendency just move in kind of different stylistic direction uh it sort of seems like uh the debate lot and it keeps uh the the room for improvement and the room for uh discovering new things um you know very wide open uh the other thing that that uh I I wanted to mention was uh you know we're talking about um Scala in 2018 becoming a mainstream language uh and you mentioned that your love for Scala is part of what motivates that you want it to you don't want to see it die and you want to see it uh have the same sort of adoption um or some subset of the adoption that Java saw even if it can't quite get to where Java got uh just so that it can live on and we can program in this um uh very robust language um but actually I I wonder if that's actually necessary uh for scala's Success uh as it is I find Scala um you know very useful for the the code that I write at at at my company um and I think a lot of people find uh the same thing to be true um and furthermore the the pattern that I followed um sort of entering Scala with a very Java oriented uh mind frame uh and kind of graduating to functional programming not not that one is necessarily uh uh objectively better than the other but that's sort of the path that I've taken and that's where my preferences are um I think that's available right now to to any engineer who wants to make that Journey so I sort of I wonder if uh I guess I sort of agree that I I would like to see Scala become mainstream but maybe for a slightly different reason I think the things that Scala has opened up for for me uh I want every engineer to have that same kind of opportunity uh and you know if Scala becomes more popular fine I don't I you know I'm sort of indifferent um from the languages uh for the sake of the language but I think that's a wonderful thing for engineers to have access to um but but as I said I think it's already kind of in place it has a strong enough Community uh already that that we're kind of there uh so I think uh I still have plenty of time but that that's uh most of my thoughts that that that I'd open with Thanks James I think Jason is putting way too much time I think it should be just three minutes per panelist so uh so uh now on to it hi everyone um it I'm an engineer at uh Twitter I work on the trends team at Twitter um basically my team is um responsible for the architecture implementation and the product of trending topics at Twitter and um been working on Scala for the last couple of years and before that I was a purely Java programmer so I've seen the switch as it happened um and I've delved into functional programming before um um during my school days uh so when I started at Twitter um I came from a purely Java background so it was interesting to see a paradigm shift that you almost make when you go from imperative style of coding to more functional style of coding and uh just going back to thoughts that I think are resonating here as well um that it is very easy to especially in a language like Scala to code like Java because it lets you do that um so it's quite important I think um from what we've been talking about here to um also tell people how would you what's the right way what's the best way to do it it's not that you're trying to put constraints on what they're developing and what they're implementing but it's good to see um what how can I improve in what I'm doing um I think Twitter Rec early and we have scholar school at Twitter uh this is open to all proam that they come from Ruby background Java C++ um and it's a way for them to see or um work in a language that they don't um generally work in um when when I did that when I started um programming in schola I found I became a better Java programmer there were Concepts that I could take from schola and Implement them in Java and realize wow there is uh so much better way of doing this um than I could have imagined so um the way I look at languages or um new langues that you would pick up it's um more to do with opening your horizons um if Scala is providing your new way of thinking you bring that back to a language which had not those constructs uh available to it or you didn't think that you could do things that way um so and having a community around that does give you that support um why do SCH have scholar school when do you think that a programming language has made it to mainstream do you have to have it offered in universities as classes um do you think that a tooling support around languages is is what makes it um a mainstream L mainstream language or uh do you think that more and more open source projects are what makes a language mainstream so there are all these things that I think we uh put languages on a pedestal with um is it offered in the community is it does it have tooling support um does it have open- Source support um all of these things if as a community um we make an effort to bring people on board and say this is not scary it's uh it will make you better as a programmer it will only improve the language going forward improve the community going forward um yep than that's my thoughts and now Brian uh hi everyone I'm Brian McKenna I'm the third Australian on the panel so um Cy so I actually come to Scala from high school um I'm one of the many people that come from high school and um I started working at a company called precog where we did a lot of purely functional scholar um we recently got acquired about 2 months ago by uh company called Rich relevance so now I'm writing a lot of java and trying to integrate scholar into coase and can believe it I'm writing a lot of uh purely functional J I have to do it so um I I have to confess that I only watched Rod's keynote a couple of days ago um I actually tried watching it about a month ago but I couldn't bring myself to watch the whole thing um I got to about halfway and I couldn't finish it off um basically my problem was that it seemed like a big wine um you were just kind of winging about the skolar community and how it is at the moment um and I'm for winging I I do it all the time check my Twitter um but I I didn't feel that it was very constructive also I didn't see I didn't feel that it was very cohesive it seemed really so um firstly I just want to point out that I don't think that Scarlet becoming a mainstream language is important important to me I couldn't care less if it was mainstream or not all I care about from a language is if I can write a program that does what I intend that's it um if if if people take ay writing a program is a useful thing then um then they can come in and join in but having a goal as becoming a mainstream language is not useful to me personally so um if I if I really wanted a popular language I'd just go use JavaScript you only live once um so secondly um the content of the keynote was that um that um that rod says that um The Scholar Community uh needs to be more welcoming and I did not get that from from Rod's keynote um rod says that uh functional programmers need to go somewhere else that that doesn't make me feel welcome at all um and going back say need be more welcoming and then saying that then goinging out people in the community that have been doing good things and saying look this person is very naive because of this thing that he said that's not very welcoming either um but also you said that code The Scholar code is usually too clever and I don't I don't see how we can be naive and also too clever at the same time um you know if we need to stop writing clever code we need to think about what the implications is by by saying saying that we can't write clever code does that mean we have to write ignorant code and I I can't write ignorant code sorry um when we see code that we think might be too clever maybe we should think about it and say well maybe this code has been written like this for a reason um maybe there's actually some benefits from understanding that this code is is is is is doing something that I don't understand and that I actually have some learning to do I might have to accept that I haven't stopped learning and that I need to learn some more but that's what that's what we should probably try and do right so I I mean I next time that you find some code that you think is too clever maybe just try and figure out why it's written like that maybe try and figure out the implications of why it's written like that maybe um you might find that intellectual Purity isn't actually a thing that there's actually benefits coming from writing code in a purely functional style um you might find that writing elegant algorithms might actually help solve real world problems um and maybe you'll even come to the same conclusion that I have which is that functional programming is the most pragmatic way to to write Scala thank you than Brian so here we have uh all the panelist positions and and Rod so thank you for that uh and now uh basically the next segment uh each panelist will ask Rod a question so Rod I've seen you make a not so you that's also your time to respond to every individual uh panelist if that works for you I I would like to respond to some of the points now sure um sure how long do I get that works fine that works fine let's do that so basically uh if you'd like to respond uh on mass so let's give you a segment of time just for that and then go go to the individual questions I think I'm I'm going to respond in two parts um I'm going to respond to everyone else and then I'm going to respond to Brian awesome uh so I I know Australian's awesome I mean seriously we say what we think I think it's it's pretty awesome uh where are you from uh grew up in Brisbane oh Sydney so um I lived in Sydney for two years didn't like it um okay so to the some of the other comments well in fact this is this is actually a point that really comes out in actually what um several people said which is doesn't matter whether something's mainstream and I mean Brian put it more strongly um and also with possibly an added little fris on of maybe it's cool if it's not mainstream because if it's not mainstream then you know essentially you don't get the people that write code you don't like coming into it I I think that actually the question of Google issue of Google was brought up I think it's a really interesting issue Google use Java but they do use it in a way that certainly is not typical of so-called Enterprise usage but on the other hand nor are Google's problems typ of the kind of problems that most Enterprise class uh companies have one of the reasons that Google uses Java is obviously that Google grew up at the time when Java was utterly dominant so you know it's partly a generational thing that at that point if you're going to write a Google you're going to write it in Java secondly they use Java because Java performs incredibly well why does Java perform incredibly well you know what maybe the fact that Java is so mainstream is exactly why the jvm is such an awesome piece of code you know in fact it's the fact that there are a whole lot of people using the parts of java that say Google doesn't really care about um and using various parts of the Java ecosystem that Google doesn't care about that enables Google to be Google and I think that's a pretty good example of even if you are atypical of a very large group of people that use a particular technology you know what you benefit from the fact that they they use them I mean you know Google um essentially gets almost a free ride on the fact that um you know oracle for example considered Java important enough to put billions of dollars into it uh well obviously Oracle lawyers would argue that Google had got more of a free ride than that that then such litigation is evil so we will not discuss it uh so you know that is a fundamental fundamental difference of opinion uh that the idea that it doesn't matter if something's mainstream and I am perfectly Frank about the fact that I'm coming partly from a business perspective here as well as a technology perspective I don't think that frankly awesome as a Scala adoption today is I don't think scala's got to that point of critical mass where it's not going to be at risk of going away like you look at Java the only reason that Java will go away is eventually people will stop using it like in you know 2050 um there will be some point when frankly there just aren't enough people using Java that you know that it starts really to wind down in terms of the support for it but I mean obviously it's not even a question regardless of the fact that Java is not cool and scolar is cool there's no question that Java is going to be around and richly supported in 2020 it's not certain the same as true of scalar I don't think we've gotten to that point one of the reasons is that another reason that um Java was successful is it actually happens to be pretty easy to write things that um handle Java bite code I mean writing a Java compiler writing a good compiler is hard but Java is a simple language in terms of the tool chain scolar is not it costs a great deal of money to deliver um infrastructure around Scala and this is one of the reasons that the tooling is actually not that good unless that tooling gets better the future of skyar is not completely secure so you know this is obviously a pretty pretty fundamental difference in uh opinion and emphasis I think skyar is on a path to be extremely successful and to live a long time but I don't think its future is assured in terms of sustaining and making worthwhile the expenditure of the many many many millions of dollars that need to be expended to make the scolar ecosystem truly robust um okay so um mream that's one of the one of the big points actually Paul had a really interesting point about whether um fragmentation of a community is a bad thing and I think it's think about Division versus fragmentation I actually admit that C++ in an example I hadn't considered it's a very good example but I would describe that as division not fragmentation division into two is okay fragmentation into 30 is bad and rightly or wrongly what I tend to see in some companies who have concern about the proliferation of Scara coding Styles is they don't think it's fragmentation into two they're not saying you know we've got um the people who write code like this and you know they're not saying for example we've got the object people and the functional people they're concerned that there is a great deal more inconsistency um than that I think they were the major issues that I wanted to um make with respect to the other panelists um I actually strongly agreee with Paul's point that we do need to have new approaches because the problems are changing in Enterprise or software or whatever you call it there are clearly new classes of problems and I think scholar is at an exciting point where it is actually very suited to addressing some of them okay with respect to Brian um actually the usual word here is whining not winging winging is the Australian word so I learned that when I when I first came here yeah I need a translator yeah I'm still not convinced that um my talk was not either cohesive or coherent I didn't think you made that case very strong um disagreement as I've said about the issue of um mainstream but also I'd really like to make a point about naive versus clever it is possible to be simultaneously naive and clever indeed it's quite easy you You Can Be Clever at doing things that either don't matter or are not necessarily the right things so naivity is partly a question of whether you're interested in doing the right things clever or not clever is in terms of how you do that thing so for example I'm actually sorry that I guess I did speak disrespectfully of a particular Community member but I happen to have a great deal of experience of relational databases and same that you can solve all the problems or something in one line of code I think I think that actually is a naive comment I um I'm sorry if I was not respectful about the individual but I think that comment is naive this is you are dealing with things that are very complex things and it doesn't really matter how clever your algorithm is going to be you are still for example going to find issues between um the compatibility of and locking models and dialect supported say um between MySQL and db2 and Oracle that are really not about cleverness and not about Elegance the other point I think that is um a strong point of difference between myself and Brian and also I think between myself and maybe some of the others on the panel is that I do fundamentally believe if people if people can't read your code easily you shouldn't assume that the fault lies with them because you are imposing a tax on the reader so for example um it may well be that if I read more of your code I would learn it's probably true I'm sure I would learn more about functional programming however let's suppose that there exist people who are not as good programmers as you are should I read all their code as well should I put put the time into reading code in the thought that it will educate me when in many cases I'm going to read it and think what the what were they thinking so you know I think that is frankly a little presumptious to um assume that we should require people to pay the tax now I think Brian would probably argue that if you're not that familiar with functional programming you should probably learn more about functional programming and I actually completely agree but I think this is a case where softly softly catchy monkey people will get so for example ity referred to coming from a Java background presumably she acquired more knowledge of functional programming I think we may well all end up in a similar place but I think people have different P um different Paces of getting that one final point I did not say that um if you're a functional programmer don't stay in scholar what I said was if you hate objectoriented programming scholar is not the language View and I I frankly stand by that comment I think I find it very hard to understand why you would choose to use a language that is a hybrid if you hate object-oriented programming and this is I mean this is literally what was on the slide I said if you hate objectoriented programming scholar is not the language for you I stand by that fair enough uh and now uh I think we'll just go in the same direction s here so this is your chance to basically ask most important question of Rod to clarify your his position so you get 30 second to ask the question uh Jason please uh start the timer when each panelist starts the question and then R has up to two minutes to respond to the question okay it's your turn okay so I think I have a couple of questions uh the first one is uh do you think it is uh it is better for for scholar to be like a a big tent Community where we can have people who are basically writing hasal that is pure functional programming no object-oriented stuff uh you know very much a certain style of programming in addition to people you know using it as a better Java uh or do you think that the community should Converge on a single style that's a good point I think that um both things should happen to um some degree I think they clearly really needs to be more consistency in terms of stale go lines so I mean actually I think interestingly um moving on from some of the comments that uh Paul made I think it might be interesting if there was a kind of coding standard for very functional scolar and coding standard for like you know Superior not I mean not just better Java but you know something that is more accessible to people um Coming predominantly from an objectoriented background I think that there could be a case for two um my issue is not with people who want to write functional scolar my issue with people who regard nonp purely functional scolar as degenerate because I don't think that really um represents the nature of the language so I think there should be a big tent but you know what there should be signs to a couple of important parts of the tent it should be you want to drink beer um you're a vegetarian um you want orange juice you know it would be nice to have those signs to the parts of the tent where people uh congregate in coherent in significant numbers I guess that means my turn yeah um gosh question uh that's that's a that's a tough one do you think there might be some value in not expecting a new developer to schala to be production quality productive on day one like might it be worth an an organization taking a month or two solely for training um to try to help with that um convergence of the the developer community in an organization um well I would actually argue that the existence of one or at least a very small number of sets of coding standards would help with that process secondly I related coming back to a point that James made I don't think it's a one-month process I think we whenever we go into a new programming language we look at our code from not one month ago we look at our code from 6 months ago maybe from 15 months ago and we think oh well obviously um I could rewrite that in a much nicer way so I think certainly you know certainly it is great to equip um folk with a sense of a language is a new thing so for example if someone say comes from a Java back ground or from a high school background it would be good if they don't try to treat Scala as you know just different Syntax for what they came from but I think realistically in a world where people get paid to deliver code um there are going to be a hell of a lot of people over the next few years who are not true scarla gures um even if they're good programmers and they're going to be writing code and I think we we need to accept that because you know we don't have um the luxury of sufficiently extended education in all cases Thanks James uh so I think my favorite thing about Scala uh coming from an electrical engineering background with basically very little or no software engineering uh is that it's kind of opened my eyes to um a lot of other paradigms and even other languages so when I was learning schola um you know a lot of the the concepts that I was reading about on blogs and so forth were written not in schola but in hcal or or some kind of lisp or something and that kind of forced me to learn those languages which like broaden my pers perspective even more um so I think that that experience is sort of my favorite aspect of schola um I wonder uh what have you found to be the most enjoyable part of learning schola I have found Skyla to be a very um Rich experience in anyways I think probably the biggest thing for me personally was that it wasn't since I was studying computer science 20 years ago that I had actually you know done any serious functional programming so for me and I I think that is true for most people coming from a um you know similar background to where I was coming from it's really going to be the functional um aspects of Scala that are going to be the things that really make them think as programmers um in a different way iidea yep so my questions um related to say Java eights coming up with um Lambda expressions and things um and more of U support for functional style how do you think um it will impact the functional programming Paradigm not specifically Scala but just generally fun programming on its own do you what kind of an impact do you think it will have that's a um really interesting point I know that some people um even smart people whom I respect um actually seem a little pessimistic about the effect of um Java r on Scala personally I don't see it I think if anything it would be a net positive for Scala um for a couple of reasons one is and I mean this is more personally my observation of how markets play out rather than the technical observation when you have an incumbent and you got to challenge it and the incumbent tries to add a feature that is a key selling point of the Challenger basically it means that the incumbent just massively validated the Challenger and also they've got an implementation of that feature that you know relatively sucks so I think that it is actually pretty big validation for um scolar I they think also that Java cannot do it as elegantly I mean one of the various reasons that Java can't do it so elegantly is everything in scolar is an expression and that's just so beautiful when you're trying to um move towards a functional Paradigm in Java obviously you can't Co retrofit that uh so you know there are many reasons that I think that it won't um be as elegant however I also think that it's a very good thing for scolar in that it may improve interoperability in certain areas one example of that is AA where you know Paul mentioned some of the new uh paradigms obviously the actor model is very important in terms of the new paradigms that um scy of facilitates AA will be a load more attractive to Java developers in Java R and you know that I think is going to make some of those people think okay great I can adopt AA now but well now I've adopted AA maybe I should check out the sculla thing and see whether it's actually nicer so I I think it's goodness for for uh Scola thanks R so uh with your talk um can you explain um what your goals were for the talk uh do you think you had the Right audience do you think you achieved your goals and would you feel comfortable with next Scala Days having someone from high school come in and say scalar is a functional language we should be writing o oh sorry we shouldn't be writing oo and can you also answer a second question which is what is oo I still don't know are there any other computer science questions You' like me to to ask me while I'm while about it I think I mean frankly the latter one I think is a little silly I think that I and many of the people in this room understand object orientation and I I honestly have been asked more times than my life by functional programmers than anyone else to Define oo which I find a little strange uh um the goals for the talk and whether I realized those goals the goals for the talk were partly around this issue of Scola coming to the main stream which you know profound difference of opinion here between certainly Brian and myself um I think it's very very important because scolar is something that I I personally like so sopie to endure a long time and B I think is so good that I would like as many people as possible to benefit from it so you know one of my goals was actually to start a debate about how potentially Scara could um get to the mainstream did I achieve those goals well I think In fairness I should point out that a significant majority of the people in the room actually gave the talk of Standing Ovation so so um you know I think that in terms of the goal of being establishing debate I think I think that was successful I think in terms of it was not one of my goals to foreclose the debate so for example with respect to coding standards I called for coding standards I did not say this is the only way you know do what I say this is the only way you can write um write scholar with respect to a house school person coming in and telling people how to write scholar I'd have no problem with that I might learn from it I I personally would not be out there giving them a really hard time on Twitter I'd be fine with it I would also add that we're here if so if the idea was to have a debate I think we have an existence proof that it was successful absolutely that goal has been achieved and I think we all kind of mve it forward so uh uh I think it's it's a great great place to be so uh now in this next segment uh I've was making notes and uh also I cated a lot of questions from the website by the way Tony Morris who is a revered uh non-compromising functional programmer uh who is uh famous for basically never uh given an inch in intellectual Purity debate and being admirable for that he actually submitted 20 Questions uh which is the daily maximum for the Meetup uh and uh and uh and we're very grateful to him because he voiced a lot of uh sort of the uh I would say extreme ofp uh uh Wing uh um kind of for the debate opinion uh and a lot of them are rhetorical so so I have essentially selected some teams uh which uh are in my opinion best uh for every panelist so I was just going to ask them in a kind of random order uh so I want to start with Brian M uh so a little background so um uh I've done actually uh uh large data uh mining in several languages to compare uh so uh my research group at Dartmouth was one of the first users of the Twitter streaming API when it was created and we uh was doing human behavior modeling in social networks one of the first groups to do this at scale and we created a huge Twitter graph by the starts of the day maybe 5 million users 100 million tweets and uh we uh processed that graph in in in Hill o camel osure and Scola uh and uh and basically to see which which of these languages is suitable for for for industrial usage at uh at this scale and we actually found that all of them are but they require different effort for instance in hus we discovered an integer overflow bar because no everybody actually tried hkale at this scale uh and the garbage collector was overflowing uh but once they fixed it it was performance wise compatible with a camel uh and and closure was surprisingly not that far of maybe a factor of two which was 3 years ago and they made large stride and sculla obviously was was somewhere uh uh nearby uh Hill and and aaml which had a tie so uh so I I love hcll uh and there's a lot of people whom I call crypto Huskers who who are basically husk people who found a job in Scola so Scola gives a natural Refuge to a lot of of hular because that's you know it pays the bills it's it's wiely adopted uh and and uh those folks are very comfortable exchanging type signatures in high skill and reasoning in high skill and it gives you compact language right often you know uh scull has a lot of extraneous synex and type annotations and so forth so uh however husk did not get the ad option which Scola is getting and and I'm not that a great of a hular uh but so I'm wondering in your opinion why what what makes Scala different because we see already Scala is breaking out as Rod said so Scala in some sense is more complex than hkale because it has a lot of all thrown in and less consistency than hkale right so but for some reason Scola is is really being adopted and uh I'm curious what is uh your op what makes a different form of hcal in in in your view what what scull basically should do differently from hosal and I know you don't care about mainstream but you know pretend you cared because what would SC like what is this magical difference in Scala and how Scala Community should you know enlarge it uh to to to to get adoption okay um so scalar is different in that a lot of people value the jvm I I don't personally value the jvm as much as what most people do um but the jvm was a huge seller for uh for for for for Scala um made it accessible to a lot of people that were working in companies that already Ed the jvm they could just easily put their code um into production uh without much push back um and also it is possible to write um you know skyar in a non-functional way and a lot of people appreciate that um I don't but um yeah that's that that's that's exactly why it's mainstream um I I already believe skolar already is mainstream not that I care but um it um yeah it's it's it's mainstream because the jvm everyone was already able to publish code to it and also because you were able to run write Java is code in scolar so if we would like if hus will be distributed as jars essentially uh it probably would make a lot of I'd expect more upt in high school if you're able to publish that as a jar okay no i' i' I'd like more people to appreciate high school but I don't yes okay uh thanks you we'll have a time for the audience questions uh so yeah actually if I can just make a point on that I think the I actually am in strong agreement with Brian's answer um and I think that we saw the same movie play out with c and C++ you know there were various languages that might have became po become popular and C++ at that time won in terms of the Next Generation objectoriented languages and obviously there was a good deal of pain in that at first people wrote um you know see um well not even C with classes they wrote um C with sl/ comments um but in the end people did actually learn how to write um better C++ and and the fact that there was that pathway that enabled a very large community to come on board I think explained uh was a major reason for why C++ was so successful okay I'm also very very pleased that if that movie comes out plays out again skyar is actually much much more elegant than C++ fair enough uh and I I would ask Paul to follow up on this because I know Paul has worked with oaml yes a lot so and I think in in some sense aels uh is the even more Niche it's actually a very interesting language because it's very reliable it's not moving fast as Hill even it's not as fashionable as Hill right so it's like a Workhorse but I found personal that if you need something done you get 70% speed of c and you get all the benefit of of uh uh FP right and you get one package for each need and it works right so like you don't need to choose between Jason forcers yeah uh but it's still not you know it did not achieve uh you know major adoption so what's in your view the re like the key differences what makes Scala better for you well okay well that's an easy one um so I completely agree with Rod that the the value of the jvm from a mainstream perspective is is key and strongly take his point that the the the the quality of the jvm as we find it today um is due to that popularity um I have been around the Java world since 1.0 I remember complaining bitterly about the initial garbage collector um I remember complaining about the memory model uh and so on so um all all that I think is extremely well taken um actually it's interesting you bring this up because my reaction to Scala when I first heard about it was oh thank God o camel for the jvm um and and um that that was that was I literally said that out loud uh so um it's not quite true it's it's not true in some ways that I think are an improvement on oam um it's not true in some ways that I think are detrimental compared to oaml but one thing that I do take pleasure in pointing out is that oaml and Scala are the two hybrid object-oriented functional programming languages to escape the lab um in O camel's case we have the investment of Jane Street Capital and O camel Pro uh these days there's there's a new version of the language that just came out uh literally within the past 2 days uh it's going places in the niches that it occupies um and Scala is going places in the niches that it occupies um I have mixed feelings about the popularity question I have to be honest um I I tend to agree with the comments that you know if if it becomes popular I think that's great if it doesn't become popular it's not going to break my heart um with that said I also agree with Rod's comment that if you believe it's good technology why wouldn't you promote it to to more people why wouldn't you hope that it becomes popular um the question I think that people struggle with is to what extent does that imply some sort of technological compromise um and one of the things that I hope is that um those of us who appreciate functional programming in particular um can communicate the value of functional programming and Comm communicate the meaning of the terminology in a not intimidating not um uh condescending uh kind of way and and I'll be the first person to admit that I don't always succeed at that myself okay uh and question for Jorge so I very much like the uh idea of scholar tribes so uh I think cor formulated best and uh the as I understand it that Scala does not have to be uh this uh huge uh homogeneous kind of uh world that there are nature there are different uh mechanisms in the language that's big enough so different people can pick essentially different idioms or different subsets and and they can standardize in their community on uh on what what works right and so so and I would assume that you know as let's say a company grows uh the number of people increases and inevitably uh the average level drops right because like the more people you get the more sort of average quality programmers you get unfortunately and uh so so my question is you know let's say and I'm wondering how it works on on for square so I would assume that early adopters are uh uh All This brilliant people who pick the technology for a reason right and then basically the the inial tribe is very smart and then they sort of grow and and and they expand and uh essentially uh maybe not case of four square but LinkedIn you you either have already a bunch of jav programmers in need to convert to Scola or you start hiring jav programmers and training them because essentially you cannot hire scalar programmers at this point you hire Java programmers or Ruby programmers and you train them so what how does this Tri model Works dynamically uh over the uh course you know life cycle of a company so so I think that um uh I think that within an organization it's very important to be on the same page in terms of what kind of scholar code you're writing um I I think you know the the the situations that I've heard about in which there is a company where there are people that believe that scholar should be written one way and people that believe scholar should be written another way that I've never heard that end well um so I think within an organization you definitely have to standardize on like you know this is this is how we think Scholars should be written um and we want to have a common standard um but but I don't think that like everyone that writes schola should should be on a common standard I do think that uh I think Rod Rod's keynote uh at Scola days he he sort of um he said that scholar was a language in which you could write poetry and and he compared that to Pearl and it was kind of like a implicit negative comparison um but but I think that's actually one of Scholar's strengths I think the reason that that uh that both rod and Tony Morris sort of like really really like Scala and love using it uh is because it's so flexible right because it lets you you know sort of like take whatever your ideas about what good programming are and Implement them in Scola um and you know these two people may not agree with each other on what those good ideas are but uh but schola lets both of them sort of use the language to uh to sort of like a satisfying uh degree um and so and so I think that's actually one of Scholar's big strengths is that it's so flexible uh but I also think it is it is a big challenge for schola because it does mean that there are uh communities with very different ideas about how code should be written um and I think you know within a single open source project within a single uh uh team in an organization um you you have to be on the same page or else you you can't you can't share a code base if you don't uh if you don't share ideas about how code should be written uh I think that's that's guaranteed to be a disaster Alexi can I make a comment um I actually I really like this notion of potentially tribes or different different um segments of the community with you know fairly consistent ways of doing things without within that segment um of the community I mean I think actually in R respect I probably um starting to see on this panel that maybe I was a bit naive suggesting there should be one set of coding standards but let's suppose we have 10 times as many people using scholar as we do right now which is seems pretty likely could we support say two or three different um convention sets obviously each of those convention sets would be more viable than the whole language is right now so you know I think that it would be great if we could get convergence around ways of doing things I think division into major tribes is fine I think it's consistent with um the entire tent getting bigger fragmentation into loads and loads of different models that that honestly scares um people I mean I I can't actually mention the company because I mean it it's I came um to this knowledge through a business context rather than a technology context so I can't name them but their CTO wants to get rid of the Scala they're using and the reason he wants to get rid of it is because he's concerned uh that in the long term it won't be maintainable because he's reviewed some of it and it seems extremely inconsistent that scares people okay I also should say by the way that I'm trying to persuade him not [Laughter] to oh uh and idea have a question about um skull adoption at Twitter so so marus Ericson is one of uh advisers for for my company and he's principal enger at Twitter he wrote this document called effective scholar right and and uh uh basically uh which which is uh a coding convention style uh and uh I wonder in your practice how do you see that working actually right so there is this document how does the adoption how does effective Scala document get uh implemented how do you go about code reviews do you see people picking up and sort of uh uh basic diversion from it up or down right like because obviously some some people will be very good at it and we'll probably want to do more stuff and how does Twitter react to that as an organization to enforce this standard essentially right so I can speak specifically at Twitter how we do this um as soon as um we have an engineer who comes on board who wants to learn Scala or work in Scala there's basically guidelines around this so review boards um we basically use review board for all our reviewing systems and um you have owners added to all code bases who are actually um Engineers who are across effective Scala and they know the coding standards everything is documented so basically it's a guideline around how you should do things things like a line shouldn't have more than 100 characters in it to um um different sorts of standards in there um but it all boils back down to having leads who can actually take ownership of the code base and say that this is the right way of moving forward this is what Scala school has in it as well um basically telling people what would be the best way of doing this it's enforced upon dur you um using the review Cycles there's also design reviews that happen on each of the systems that we bu build and we ensure that everything is held up to standards and the guidelines that are specified so would you say it actually succeeds so do you see the code base as a result of it conforming to the centers um I would say it succeeds most of the time I wouldn't say 100% of the time because there are always glitches um but I do realize when I see Scala code at Twitter um it's much easier to read I understand what's going on I've seen scala's um code outside of Twitter and it's uh definitely a Havoc at times to read that so um it's like U going back to what you were saying about being in the same company being in the same team you need to be on the same page it develops a notion of uh unanimity within as well as soon as you go out it's harder to maintain that discipline but there definitely should be guidelines around it thanks uh question for James so uh James uh you had a lot of experience with spring before you uh went to scholar and spring undoubtedly uh added huge business value to ja world right so basically it it enabled Enterprise in in in multiple ways and uh I think we're all here uh in San Francisco in in various businesses uh which uh a lot of them work on jvm so this is uh definitely very practical and important concern so uh what can we learn from success of spraying in your opinion techn logically and and business likee right so there is something about spring on two levels right and some it catches the attention of a developer which enables the developer to do new things it becomes this kind of glue in the Enterprise and and it's becomes a uh basically uh business-wise a successful technology what what essentially makes it in your VI successful business like technology what can we do in Scala or with Scala as a whole or subsets of Scala to basically replicate that uh wow that's kind of a big question uh so when I used spring um it was it rescued me from ejb which was awesome at the time and it was also a major source for me uh uh of learning uh you know looking through the source I actually the the first time I ever interacted with spring I was on a team uh of Engineers and the the engineering lead said okay here's spring you need to learn how to use this and and you know start working on the code base so a couple weeks later I had kind of a a vague idea of how to use spring and and you know had another meeting with my lead and he said you know how you're coming along how do you like spring so far and I said yeah you know it seems to be cool like can put stuff together pretty easily uh and and he said okay your next step is to look at the source and tell me how spring works so he he it uh that encouragement to go and like dive deep and really understand how uh how it worked encouraged me to get into open source and learn like how other people are programming um outside of the teams that I knew I was very Junior at this point um and and so I you know I I I grew with spring this was back in the 2.0 days I think and you know I followed it through uh to 3.0 um so uh and I even uh wrote a short uh book on Spring MVC uh uh several years ago and uh so for me Spring was a huge tool in my toolbox to whack out you know enter prisy type Java applications uh and um and do dependency injection and om in combination with hibernate uh and um uh spring integration connecting to q's and things uh also popular Apache camel in that space uh so like all of these tools were very good uh at the time um because they they solved all of the needs of sort of the infrastructure and the plumbing and the the stuff that wasn't domain specific uh to the problems that needed to be solved um but actually now with Scala I find I haven't needed to pull uh any of those tools uh yet you know I haven't I haven't worked on a breath of of uh problems that I did you know uh because I'm still fairly new to Scala but uh as far as the major ones like dependency injection and om uh I I have found that the the features of Scola itself uh sort of supersede the need for um those types of features on a library level um there you know there are many ways to do dependency injection um cake pattern is one of the first ones that we learn and uh graduate to the reader monad um in omm uh I I found that you know direct SQL manipulation um has actually been uh easier for me to do because I can combine it with these other functional patterns um uh again reader Monet or or similar patterns so I think at least for me Spring um was extremely useful for building Enterprise applications um but maybe more so it was useful for that kind of community involvement and um pushing myself beyond my comfort level with regard to how I learned how to code and with Scola it's kind of the same thing except it's happening at the language level rather than a library level okay and my last question of the segment is far out but before I ask it I actually want to ask the audience uh to raise your hands if you are in a startup all right cool now out of this if you are on jvm [Laughter] yeah there is a limit we we'll have to look at Twitter apologize for the inconvenience so okay so I've seen a bunch of hands of guys on startups and uh before SF Scala I actually founded this uh Meetup called Scala for startups because every other Meetup in the city was dormant and then later we merged with SF Scala and basically uh we grew it from zero to about 600 uh members in in in about a year and a half and we've seen a lot a lot of companies coming into skull in the startup space specifically and and uh one of the reasons is that you can do more with less people but you have very high quality people you can actually do a lot more uh and we've seen company after company joining the space and now we're at the point where actually new companies are moving into s specifically for the purpose of hiring Scola programmers or you know basically finding training others but finding good programmers and they actually want to host arm it up so so it's it's it's amazing Kabam is a great example right so folks are picking it up and they find it use so in your keyote you said that that startups are not as you know as as as enjoying as much enjoying scull as as as the Enterprise and uh uh I I don't have much Enterprise experience so in my view that that I mean the the the respons of scolar is amazing so uh so I would ask you how do you see uh from your experience the difference between Enterprise and startups what are sort of the key characteristics of each and and if uh if we want to get more startups on onto uh Scala as opposed to node or Ruby uh basically how do we uh make an argument to the startups that that scal is good for them um well firstly I I think it's fair to say that I've since learned that there was more um startup usage of scholar than I knew so you know I am frequently wrong U when I'm wrong I don't have a problem admitting it so um I think if you look at where Skylar is used it's really pretty interesting in that it seems to be a mix there's startup folk and there is also the Enterprise or whatever you want to call it I mean you know there is there is no question that skyar is very strong in um the so-called Enterprise space in terms of how Scara should appeal to um startups I think Scara should fundamentally appeal to people by being a really good and I think it does that I I don't know that it's like you know scar doesn't have to you know wear lipstick in a tiara to appe appeal to people I mean skyar is a pretty attractive um thing uh so you know I think that one of the key um things that I think would be helpful um would be probably greater guidance in terms terms of getting started I think I think that for pretty much all the audiences that are likely to consume uh scolar I I think that's um very important but I actually frankly don't think that I think another thing that isn't necessarily going to be help theing to startups along with the lipstick in The Tiara is the language progressing incredibly fast I I actually personally don't think that Scara needs an enormous rapidity of new features coming into the land language to be appealing to startups or anyone else yes I mean if you look the fundamental problem and I think this has come not the problem the fundamental question with Scala is how do you understand how do you learn how to get the most out of Scola um like you know I think all of us on this panel are at different places with that I mean I I think I'm probably the least far along in terms of learning um but scolar is a very rich thing where you know we don't need a constant stream of new features that potentially make the whole thing a moving Target for Tool chain and even for adoption I think there's actually this processing that we all need to do as programmers where we actually realize wow now you can do this uh that you know Scala gives us um some great well I almost said some great options and then realized it was a pun so thanks uh so this is now time for the audience question so I will ask Mike to uh bring the microphone to our members and you can you can address the panel in general and then whoever wants to pick the question can jump on it and others can follow up or you can address a specific panel member if you have a question for them okay hi thank you for the uh discussion it was great I want to get back to the question of code readability and elegance versus naivity versus cleverness Etc it seems to me that that's kind of dancing around that debate dances around a more fundamental question which is this is it possible that schola is such a sophisticated language that in order for it to be readable you have to dumb it down a little bit and if that's the case does it also follow that as the adoption expands and more of the unwashed masses come in we have to dumb it down further in order to maintain uh code readability and I that's a question that's not a statement I i' i' really want to know your views on that can I respond to that initially um I think it's a really good question I think frankly as any technology becomes widely adopted there are going to be smart people that come into it there are going to be people who are less smart and the people who are less smart are going to do bad things so you know frankly with respect to Spring you know I mean I missed the bit where I told people that they could not use new when they had the spring container I don't know maybe people thought I said it but you know I would actually see these bizarre things in customer um interactions where you know people are using the spring container in places where I never would have used it um so you know if you have a technology that's going to be very widely adopted people are going to do horrible things and some of the people who do horrible things are going to cause people to make comments about the technology that may or may not uh be fair in the case of Scala it's a really interesting question because Scala is elegant and I think very well put together so I'd really struggle to think about the core language if I wanted to dumb it down to make it more accessible I'm not sure what I'd take out because it it just you know there's such a fabulously neat job of making things um work together so frankly I think it's an education problem I think it's an education and guidance problem it's not a problem uh with the language I'd actually like to respond to that as well um an argument that I like to make about Scola as a language design is that it is an extremely orthogonal language design and Rod alluded to that what I mean by that is um one of its design principles is that you can declare nearly anything in any context there aren't a lot of special cases there aren't a lot of corner cases one of the implications of that that maybe those of us who are fans of Scala don't articulate very well is that that means that rather than forcing your design of your software to conform to some preconceived notion on the part of the language designer um you have more flexibility as an application designer as to how you use the language features to get the job done one way to express that is there are too many ways to do the same thing and you can you can make that point you can make that argument but what I would argue in return is that that means that your application designs constraints in any given part of your application are going to derive from how the rest of your application is designed rather than from constraints that are imposed On You by the language and that's a challenge that's where a lot of the complaints about schola complexity in my opinion come from is this flexibility this the requirement is now on you to design your application in a consistent way throughout your code base as opposed to having to conform to what the language insists you do thanks Paul I have kind of a rhetorical followup um because I don't know uh there's not really an answer that I know of but uh I think if we if we think about the eventual Mass adoption of Scola and more people from different backgrounds coming in wanting to get to a common place uh where kind of everybody can read the code uh or everybody can get to the place they need to go to read the code um and kind of have this convergence in style uh I wonder if that might be self-defeating because I mean just on this panel we have oh it's O camel on the jvm or or I come from hll and I can write in this language or I come from java and I can you know it's it's Java without the semicolons and then you know I learned the other way well not always there's a few so um so anyway I wonder if if we remove some of those uh openings would that be self-defeating in in sort of of our progression toward adoption I don't know can I just comment on readability for a second um so a lot of people when they say readability they mean it doesn't use symbols it only uses letters um I I completely reject that the only thing that I find readable is when you only use values once you start putting side effects in there I can't figure out what the hell you're doing if you only use values it's easy I just read what what what is that value mean what what does this what what does this value represent I'm set I can figure out any code if you use just values thank you uh another question great let's try to keep the questions to questions and not hour long statements um okay I'll try to not make long statement I'll make a short statement so work on Scala compiler it's really cool to be here and see so many people excited about scy so thank you makes my every day better when I struggle with compiled performance that's my topic um so I have a question about like the slowing down with features and you know making it easier for tools to catch up and for people also to catch up with the language so there is this uh issue that you know Scala is coming from research for for many years it was like people were free to add new things to Scala try new ideas and now we have a product which we are all excited about so is for example Ro do you argue that we are like we're basically is Scala going to be following the same um cycle where you innovate really quickly then you slow down you peek and then you die and um and do you want to push us more into like Peak territory and and less into Innovative territory or you could like widen uh the G like the make it longer that we still innovate and you know and we have adoption at the same time by making maybe like some new ways to uh introduce new features in less painful way for example uh interesting uh question I would come back to the point that I previously made that I do think there is a very significant backl log in terms of most people in the community um including even Advanced users and certainly including less Advanced users like myself there is a backlog of work in figuring out how to work you know how to really get your head around what's already there and to me that Priority One is stabilizing the CH chain and um achieving education and that's more important than adding more features that actually make the tool chain more problematic and make the education uh challenge um bigger I certainly would not want Scala to cease to innovate um but I think realistically we've got to look at the fact that scara's done a whole lot of innovation now we've got a lot of people knocking at the door and they want to come in and imagine that room you know the chairs some of them the legs on the chairs are a bit wobbly um you know they might try to um they might um try to put their drink down and find the table Falls over they might actually slip in um some of the um spillage on the floor and this is a dangerous time I think for the focus to be oh let's let's enlarge the room let's bring more people into the let's um you know make the room essentially more complex let's bring more wobbly Furniture into the room I would actually rather say okay it's wonderful that these people are coming in let's just make sure that they really really enjoy the experience and guess what when they're in the room um then they're going to say oh we really like this room you got any more rooms for us can you build us another room so you know I I think there is a balance I would hate to see scyla become um somewhere there wasn't Innovation but you know frankly particularly if you look at the Java audience which is going to be the biggest audience that's going to come to Scala you know these it's like a being a kid in a candy shop you look at all this new goodness you don't say you don't have enough new goodness if if I could un underscore that very quickly let me just remind everyone in the room that Scala 2.10.2 is a statically typed hybrid objectoriented functional programming language with dependent types and delimited continuation what do you people [Laughter] want you forgot macros macros that's right oh I yeah so I I want to jump in on the on the features uh discussion a little bit um so I kind of agree with Greg I think uh like Java changed basically not at all from from java 5 which came out 10 years ago to until like basically Java 8 where they're like finally adding a bunch of stuff to the language um and I think there was a lot of real stagnation in in in the language and in the ecosystem and if you compare it to like the the Enterprise competitor if you compare it to C uh and and the CLR uh Microsoft you know innovated a lot in in terms of language design in terms of VM um and and there are a lot of features in C that Java doesn't have and it can you know in terms of memory management in terms of integrating with native code in terms of uh uh you know variance annotations there's there's just a lot of stuff uh like C is a huge language and it has a lot of features um and a lot of times it's because they were uh necessary to do things for real work right like if you if you want to interrupt with a a C++ native API uh which is you know pretty much necessary if you're building native Windows apps um you can't do it with with a model like what the jvm does it's just like a very poor way of of interfacing with native code um and and so I I kind of agree with Greg a little bit that that sort of like freezing Scala um and a lot of this is like you know the jvm needs to evolve as well and it's not just the language um but but I think that that freezing freezing Scala and freezing the jvm at where they are now is not necessarily the the the best move um I think I think in terms of like core language features right in terms of like like stuff like macros and delimited continuations and things like that uh I I would agree with like slowing things down but um but in terms of in in terms of like developing the language and adding features that let you do things that are not possible right now um uh like the dynamic type and and all this stuff uh I think you know they can be features which are sort of like limited to a particular use case and are not going to affect the day-to-day programming of the majority of programmers uh but that when you do need them they're there and you can use them and they're useful um and I think that's important uh and and so I wouldn't want to see scholar sort of like stagnate for 10 years like like Java did even though I do agree that the the tool chain uh tooling needs to improve quite a bit I think there's I mean frankly I would say that Java completely agree um Java when through a period where it evolved way too slowly and that hurt it I think skyar is evolving too fast so I think you know somewhere between the two lies a sweet spot and I would really like us to try to find that sweet spot rather rather than just assum that you just throw things in you throw things in so thanks I think we have time for one more question from the audience hi um first small comment to Brian um I can sort of feel your pain as far as wi adoption about 13 14 years ago I went from C++ to Java and I was resentful in C++ it was hard and I was really good at it and I had a Competitive Edge now the mass of people would be able to do the same thing in Java much simpler and easier and I was really resentful and it's I I sort of understand but at this point I I need to hire people and I want scholar to be easier because I need people to do it with me and I don't want to go back to Java so I can work with them I wanted the other way around and and and so it's a slightly different Viewpoint um question uh as far as the language complexity or um style I just recently went to scholar less than a year ago maybe six seven months and what I found difficult was I didn't find a single language to to learn it was more like because you can do dsls and it was like a bunch of languages that you have to and you look at this Library they have their own um operators maybe but that's not the main thing there's a different things you look at and they look it's not a single language like like Java is it's like many different things because of a different labories you look at could you comment on that please Scola doesn't have operators that's that's my that's my that's that's my yeah I do know what you mean that's my that's my number one but that is my number one gripe with that with that complaint yeah yeah yeah yeah they they're just methods and and let me tell you what the difference is cu this is very important in a language that actually has operators you have no way of knowing what an operator does other than to know that operator in a language that doesn't have operators but that just has a DOT inference it's not an operator it's just a method on the object to the left or if it ends with a coal and the object to the right and yeah yeah yeah okay um but what that means is with proper tooling you can say please look up the definition of this method right on this class or on this object or what have you that's a huge difference and this is why every time somebody complains about overloaded operators in Scala I say Scala doesn't have operators I understand right yeah I think it actually a very fascinating in Direction talking about practice and Theory I mean obviously Paul is completely right and Theory but it was an interesting um interaction uh so well firstly in terms of my personal usage I must admit I've actually backed off when I first got into scalar I actually created DSL with this to yourself with that and I've personally backed off a bit and I've decided ended up just doing creating the DSL only when I really really understand the problem and when frankly the DSL makes a problem so much simpler I don't I no longer do it just for Cosmetics I mean that's just my personal practice I um wouldn't necessarily advance that as a best practice I think it all to me comes down to some degree of consistency in education so yes if you created a DSL so if instead of you know designing anything that resembles an API everything is like your DSL style and it requires learning it um on the part of readers I think that's problematic but on the other hand like if you use dsls appropriately for things that they simplify in scalar you know you can't read the Java code and the builders and the various other ways that you would do that so I mean again I think it's one of those things like as I said um one of the things that caused um some people to um form a negative view of spring as they looked at code bases where every single thing was in Ed even when it didn't need to be so you know again dependency injection um in at least in its intended context is a very Val valuable thing but you didn't need to use it everywhere and I think if you look at dsls used appropriately personally I wouldn't want to live without that because it's very very elegant emphasize the D rather than the L I I think I think another thing with dsls and Scala is that um I mean I think 80% of the time your library should be just a library and it shouldn't look like a DSL uh but 20% of the time having a DSL is great right like parser combinators you know I just ragged on how there's six different Json parsers and the reason is because it's so cool to write a parser in Scola because you write this you know grammar and it's executable and it presses your language and it's fantastic uh but but I think the flip side to that is that um dsls are very poorly served by the way in which we write documentation for Java libraries and for scholar libraries right like tools like Java do and Scola do are meant for libraries they're not meant for dsls um and so I think it I think there's there's sort of like a challenge there for um for for someone to figure out like how do you uh how do you write better documentation for something that's it's more a DSL than it is a library um and I don't think we've we've really figured that out yet and it and it matters a lot whether you know the D I mean people it's like if you can't read the code is that because the DSL is bad or is it because you're not familiar what the D is about take a look at spray you know if if you're writing Rest apis in schola please take a look at spray because I think it's a really good example of a finely tuned DSL for handling HTTP requests easily right uh thanks Pa so uh we uh don't have the time for the uh hashtag questions so uh hopefully we can actually continue this uh discussion on Twitter and elsewhere but I wanted in close in to ask each of you guys in turn to make a prediction so maybe Jason will do 30 seconds for each person so I have basically very simple question for each of you where do you think scal is going to be in 2018 is it going to be as big as Java is it going to overcome Java uh and uh how uh do you think Community will look like will it be set of tribes will it be kind of a simplified effective scolar like version so basically 30 seconds for the prediction of the future starts with jge oh boy um I so I I I actually don't think that that Scala will be as popular as Java um I I part of me doesn't want it to and part of me doesn't think it will be excuse me can I interrupt I just to have a I really need to go to the restro I'm I'm sorry absolutely 30 seconds guys reality strikes um so so I I I want and I hope Scola to be much more popular than it is now but I I I don't think it will be as popular as Java but I think it we'll still have sort of like a vibrant thriving ecosystem of people that use it to do uh real productive work and people that use it to do uh sort of like crazy academic work and and I think there will be like a big tent of Scola users that uh that look at Scala very differently but um I think it will be much more successful than it is now but I don't think it will be as successful as Java thanks just let's do a minute I think per person well let's see turn yeah um 2018 I mean I'm pretty confident Scola will still be with us um I I don't think it will be as as popular as as Java um I don't care that much but I don't think it'll be as popular as Java I think there will be a l fairly large community of people who kind of use shapeless every day without thinking about it and who still think that scalaz Ed is just Madness thanks Jims uh well yeah I agree um uh I don't have much to add other than I I think we're seeing a lot of people in The Scholar Community Branch out and look at implementing other languages on the jbm rine and fr uh and some others um so who knows maybe some of the community who's not completely satisfied with um some of the decisions uh being made in Scola sip 18 for example uh might you know leave um but then again they might go and do other things that then Inspire Scala to grow so uh I I don't think Scala is going away I don't think it will be as popular as Java but uh I think there's uh going to be some very interesting debate for the next five years than I think um Scala definitely has potential to be a very mainstream Language by the time 2018 comes around um and it will all depend on how the next five years pan out um I don't personally think it'll be as popular as Java but it is on the jvm so it has that Advantage um I also think the Scola community that you will always have different tribes people who believe in different things and who have different opinions so you might get um two or three or more different camps but I think there'll be homogeneity within those camps so um it will be a popular language used in mainstream by 2018 thanks um so I know there's quite a few people that are like me that are that are happy that scull is around and that it's capable enough for us to do functional programming with but I do believe by 2018 there will be other functional programming languages for the jvm um I think that a lot of people that feel dissatisfied with parts of Scala uh will move over to there uh move over to other functional languages on the jbm and I hope that makes Rod happy with his um uh telling everyone to go away if they don't believe in a way right so it's just in time to make a prediction for the 2018 and uh is sculla going to be as big as Java or overcome it and what set of tribes or kind of community it it will look like um well I'm very sorry that sincerely that I didn't hear um answer in particular um it was a good one um but honestly I think I pretty much uh stand by my prediction that Skylar is going to be very big language it is not going to be as big as Java because we're no longer going to see that virtual monoculture the Java achieved that's a good thing so you know I don't think skolar is going to be the thing that everybody has to write everything in and that's just fun because it's not really healthy uh when that happens I think uh Scala will probably be particularly strong in the um Enterprise space I do think that skyar is going to be predominantly with more experienced programmers I I certainly fundamentally agree that skyar is well suited um to highly skilled people but I also think that there are actually quite a lot of really smart highly skilled people particularly you know when we think about India China there are a lot of smart people um who are coming um into software and I think hopefully Scala will provide a home for very very many of them I think that for Scala to have gotten there we will have a degree of convergence in what Scola should look like and I think frankly if you look at Java there even though Java was relatively simple as a language there could have been more inconsistency in Java than there than there was for example people were remarkably consistent about capitalization in Java was the first language I'd worked in where suddenly everyone used the same convention rather than you know fighting to the death over different conventions and that definitely benefited Java I mean honestly it was one of those things no don't argue about it and make it a matter of life and death just accept whatever it is camel case it does doesn't matter it is better to standardize on something that makes it easier for people to read each other's code so I would very much expect that Scala will have um you know gathered around maybe one or two principle um way of doing things I would hope by then that Scala tooling is absolutely awesome because you know technically um there is no reason that it should not be fantastic thank you very much everybody and what I suggest we do let's reconvene this panel again in 2018 and go back and see what happened thank you very much thanks to the audience it was a long panel but I think it was really enjoyable so I appreciate everybody uh joining and kab hosting and I think there is some pizza and beer SE left let's have a hand for all the participants please excellent thanks everyone for coming out tonight there's still a whole pile of pizza and there's still beer in the kegs feel free to grab at least one more I know lots of you have burning questions that remain