All right, can we get started? Sorry to scare you guys. That's It's 515 so we want to get started with the panel It'd be great if you guys can come towards the front side. There are a lot of seats open here It'd be easier for us to have more of a conversational style panel All right. How many of you are familiar with a fishbowl? quick show of hands All right So let me quickly help Explain what the fishbowl is all about and then we will get that started So we want to do a panel But you know the the typical problem with the panel is it's just the people stuck on the panel trying to answer the question Over and over and then it gets boring after a while So the idea with fishbowl is that you know people here are not fixed There's always one of the chairs that is left empty so anyone from the audience can come in And participate in the panel. So when they come in to to contribute someone from the panel has to leave Keeping one chair empty. So at any given point in time one chair is always empty Right idea is to kind of rotate people in and out. So if there's a specific question that comes and let's say, you know You're not satisfied with the answer given. Maybe you want something to contribute So you would come up and take the chair and contribute, right? So it will It would hopefully be more inclusive and more involving rather than just the seed group that we start with Okay So i'm going to invite maybe four people to get started with and then encourage other people to kind of come up and kind of take The stage as in when we go So that's the hard part of picking All right lp I'm zoning out on name. Sorry Uh Brian Martin This is going to be totally on the fly nothing prepared So you guys will help i'm going to try and kick start with the first question And then i'm going to get off and then other people can take questions and then we're going to turn it into more of a self organizing thing So the first question I had for the panel is that you know, we've We've heard a lot about Functional programming and the need for functional programming where it's coming from and one of the main driving factors if I understand is concurrency Uh, you know concurrency is one of the main driving factors pushing the envelope for Functional programming And I I can think of a bunch of the examples or bunch other factors that are pushing for functional programming But what in your experience are kind of the core factors that are driving the adoption of functional programming? just the increasing cheapness of multiprocessor computers So even now on an embedded device You have a hard time buying a system that has just one processor in it And most of our programming languages were designed in an era Where multiprocessor systems were unheard of or multiprocessor systems were high performance computing So you would have things like open mp And if you've never done open mp, it is a fantastic nightmare from another world Which is not generally applicable without extensive training and even with extensive training. It's very difficult to get right Because it's it's optimized for systems where memory is resident Not necessarily on the same board as a processor so that multiple processors can share them in a Sort of interesting topology, which just doesn't exist Now so, you know, we have a need for languages that expose constructs and make it simple to reason about concurrent programs And it just so happens that a lot of research into doing that was done in the context of functional programming And functional programming makes Certain constructions of concurrent programs Much more simple airline for instance doesn't allow you to fiddle with memory across process boundaries So that's one area where a language like go falls down compared to airline because go If you are disciplined allows you to write concurrent programs that don't have spooky action and distance effects, but you are allowed to fiddle with memory and Often you are encouraged by the nature of the language to fiddle with memory for performance reasons Whereas an airline, you're just totally shut down In haskell you are totally shut down. You can't do that And that is hugely valuable in rust. You can't do that without either explicitly copying or mutating some data that you now have exclusive control of so Functional languages are hugely valuable because they restrict you in ways that are beneficial on dangerous computers Um, whoo Aside from um Aside from the things that are sort of talked about a lot, which is concurrency, which is uh Well fault fault tolerance has been brought up a lot today as well. Um, I think one of the things that sort of Cells functional languages to people when you're first showing it to them is how much you can do with how little code so you know I don't know how many of you have seen erlang the movie, but it sort of starts with joe. I'm strong showing He's an imperative program as 150 lines and he's the same program in in erlang and it's sort of 10 or 15 lines and the the ability to More with less and to have a more expressive language that doesn't Turn out just reams and reams of code for the sake of churning out reams and reams of code I think is actually it's it's a really big selling point It's not necessarily unique to functional languages. Um, python and stuff have have similar kinds of higher level constructs that allow you to But um, but certainly it seems a far more intrinsic aspect of functional languages to be able to do A lot with with very little and the the um big data fast data talk We just we just had had had an excellent example of this where it was doing a lot of complex processing on a stream with just a few relatively simple lines of of code all sort of chained together and I mean developers as a developer I think you should hate to write code you should try to write as little code as possible And the the less code you can express yourself in the better because it becomes easier to maintain It becomes easier for other people to get on board with and understand And I think that's something that kind of just falls out naturally from from functional programming And and that that for me is a really big selling point for it So I think we had constraints which kind of help you then you talked about expressiveness and we talked about concurrency Yeah I mean, I think definitely concurrency is the big driver If you take a step back, I guess that's because Moore's law started to fail us, right? They couldn't make single cores any faster without overheating And of course there's the availability of big data Which is also accelerating at at rocket speed I think from my from my perspective an important thing is also that we want to bring Domain experts to bear in on the programming tasks as well And if computer science and software engineers have trouble with locking locks and semaphores, you can be sure that People who started out as electrical engineers or or actuaries are really going to struggle I think that's actually becoming an important driver An ironic thing that I sort of felt like asking at the end of Nilanian's talk a moment ago. I hope I pronounced that right Nilanjan, thank you. I'll try to get that right next time It's a bit ironic that we need smart kids to help make a few people rich and the rest of us dumb When google suggests to me that I only look at news items that are similar to ones I've already seen it makes my blood boil Maybe I'm just an old man I think another selling point for functional programming In the case of concurrency He talked about copying data around and that having immutable Data helps to distribute work. Another thing is pure functions Pure functions, which are functions without side effect. They're much easier to distribute Across the cluster across the node across process Since they don't have any side effects I think that's something that in the the imperative world that you don't really get Okay, cool Anyone else wants to add anything else based on their experience. I think we had a few perspectives over here I'm sure there are a lot more experiences people have why they would choose functional languages This is supposed to be interactive Not like boom Cricket yes that could get everyone speaking And it's it's related to Another comment related to what I said about domain experts is that functional programming is simpler. It's closer to math So it's more it's easier to reason about quite simply Easier to reason about I think it's more inclusive to get other people from other walks of life to kind of come in And start contributing get the real domain experts to Actually try and program stuff out Yeah All right. So let's move on to the next question. Uh, which is essentially I mean, I think Nilanjan and I were having this discussion last night about code is liability And you should have as little code as possible You know, at least when I was kind of back in the days when you know much younger much more immature I think what I believed was code is everything I mean clean code writing that is is the be all end all of what the programmer should do And these days I kind of believe that code is really liability and you know kind of taking one step further The languages itself is not that important But yet we have all these religious war about you know closure versus haskell versus Erlang versus this so the question to the panel here is How much does the language really matter and should we really care about it? Or is it just a tool to get the job done? so My my feeling with languages is that it it it is a tool, but it's it's Any other tradesman has a box full of tools for all sorts of different jobs. You don't use a screwdriver to hammer in a nail and just like languages No, no one language is your is your tool to do everything So the choice of language is important in as far as that you need to choose the right tool to do the right job I mean, you know, it sounds like a cliche, but the number of people who think that c++ or java is the tool to do every every job ever You know when all you've got in your toolbox is a hammer Well, everything starts to look like a nail even that really fragile thing over there that will break when I hit it with c++ um So yeah The the the choice of the choice of language is to my mind definitely important It's not the only it's not the only thing you can obviously do multiple things with multiple languages but It's I think incumbent on people making the choice of language to be aware of the different Languages that are that are out there and what their strengths and weaknesses are so that they can make an informed choice of What tool to pull out of their box for this problem? Okay, so you're kind of hinting that Look at languages more as a tool and pick the language based on the right tools for the right job Okay Yeah, I think to add on to that All languages implicitly solve some problem for their creator You know the very few people I think go out and they just make a language that's production quality and ready for Thousands of people to use just for giggles. I don't think it's something that you do So that implies that there is a particular problem or class of problems that the language is meant to resolve so Airlang for instance solves a certain type of soft real-time networked system problem where you need it to stay on all the time and whatnot and C++ despite how you've been burned by it is Intended to solve the problem where you need access to the hardware of the machine and to fiddle with memory in really unsafe ways because you're able to reason Whether rightly or not that fiddling with the memory like that is the correct thing to do I love C++. It's just I don't want to write a telephone system unit again. That's all Oh, yeah No, absolutely not and and it's insane to do that and it's insane to do that because not every Every part of a telephone system needs hardware fiddling And if you look at a company like mozilla who is writing rust to solve the problem of building high performance general purpose applications They've said that okay. We need all of the features of modern c++ Minus the unsafe memory memory fiddling and what does that look like? So, you know, when you when you choose a language functional imperative You are implicitly saying that my problem Is similar ish to the problem that this language originally solved because a language if you strip away the syntax You're just left with the the golden core of semantics and the semantics of languages are radically different The semantic properties of haskell with its lazy evaluation Are radically different from say the semantic properties of rust where it's very eager and you you can't fiddle with memory And I think you get into trouble when you say that there is a general purpose language whose semantic model is similar enough to all possible problem domains It's true. They're general purpose languages. They're they're turing complete. You can cram it in anywhere But it's a real hard time and then on top of that you have the implementations of languages So you have a language that has a virtual machine now that virtual machine has to fit into the problem domain that you need So I work primarily in air lang and c++ And I only do c++ when I can't fit a virtual machine onto The computer that I'm trying to program which is a real shame because I would love to not have to deal with fiddling with memory And rust is not ready yet for any of that Okay Um, I I agree with you both Because there's one thing I think you guys are kind of forgetting is like the business side of thing Uh often you have business constraints So you only have one programmer that knows like php or some other language And your website yes has a chat system. That's real time But there's five users. So do you really need Erlang to build that? So probably not There's a huge Well, you should Baby, but like the the learning curve is high If the guy can gets the job done in five days using php even though it's it's a hammer and he needs screwdriver Then so be it like there you have to balance Like you don't always have to build like a cathedral You can build a shack if it does the job for a little bit and then eventually if there's more traffic And you need to start scaling think of re-architecting And using some other language that's more appropriate Point well made not much more to add at this point But um Yeah, I mean obviously you have business constraints and those can both be of the form You know you thou shalt use the job of em it can also be that you know You're you know coming in as a consultant working for some people and they're going to have to maintain it afterwards But I think it's really important to be aware of other programming paradigms You can do object oriented or functional Programming in any language Though of course you have to make sure somebody Whoever has to maintain it is able to do that when you've been and gone So maybe I can ask you a question you said earl earlang and c plus plus Is your c plus plus influenced by earlang? I thought so Right So I guess the point you're kind of trying to make there a hint or that's what I'm interpreting is that Languages kind of bend you they kind of influence you in a particular direction They open they they kind of broaden your perspective in certain ways That earlier you probably thought was not possible But then when you start exploring a different language, it's like wow, okay You know this this is this interesting concept or idiom in that language that you know Suddenly starts influencing how you would write code in another language. So learning languages I think is important, but you know how important is arguing about a particular language Oh, I wouldn't do that I would you know read books like bruce takes seven languages in seven weeks and and try to immerse yourself a bit And stop arguing and and try and extract knowledge is what I would say Yeah I I think some of the the sort of holy wars thing that we have is not really Predicated on a serious technical distinction. It's predicated more on fear You know you you spend years becoming an expert in a certain language or technology and if you choose wrong You're out of luck, you know I don't think I would be employable if suddenly c plus plus and earlang both went out of style If nobody wanted to use them anywhere, I would I don't know I guess be a farmer, you know So if I were If I were of a certain personality and I had a a certain fear of my particular Technologies that I've chosen to become an expert at if I had a fear of them disappearing I might engage in holy wars because I might want to dissuade people from using Super earlang instead of normal earlang Or Oh, it's called elixir. Yeah Yeah elixir is a fun example It's a language that targets the earlang vm and it keeps the same semantic model So it adds some some syntactical goodies, but it doesn't really fundamentally change How you go about doing computation On the earlang virtual machine called the beam for historical reasons Whereas a language like closure does change the semantic model So it's difficult for a java programmer and a closure programmer to Communicate whereas it's relatively easy for an elixir programmer and an earlang programmer to communicate It's actually interesting. You bring up this point because last year's conference One of the keynotes by brew state was about fear and how fear is used as a way to influence a language adoption And it was kind of an interesting keynote on, you know, some of the driving factors Which is hoping would come up which kind of brought up There's like fear is actually a pretty big factor in terms of language choice Joe i'm strong in that talk at an earlang minicomp I was at a couple of years ago talked about the the sort of path that earlang had followed through Through its life in ericsson and at one point having developed this Really great. Well, obviously i'm biased here, but great language Um And and and started using it quite effectively within the within the company new management came through and No earlang no more earlang banned done. You're all out And the apparently one of the primary arguments there was well I can I can go out tomorrow and hire a thousand java programmers Where am I going to get a thousand earlang programmers from and of course joe's answer quite reasonably was well Yes, but you won't need a thousand earlang programmers and what you're going to have tomorrow Then is a thousand java programmers and then what are you going to do? But you're you're right that at a management level there is definitely this sphere of adopting new things as well It's where we use java because everyone else uses java where you see plus plus because that's the that's the standard choice for this stuff And to which you know my response often is well Yes, you you're choosing it because all your competitors have chosen it and now you're following your competitors And that's how you're planning to get ahead of them It's a good point. Okay All right, we'll open up the floor for other people's to ask questions so that I don't bore you guys You can also please come up as well Yeah Anyone wants to ask a question My uncle I think there is a second side of it is that uh Instead of focusing on the concepts We've told them to learn languages But this language will solve your problem But actually what what do you really want them to learn is the concept And not just the languages concept, but also like Networking and distributed systems and for tolerance Which may be baked into the language like for example Erlang But even if you do you say php or whatever you can still have those guarantees if you really understand the concepts I just want to like discuss that Is there a question in there? It's just more of a discussion on this because I keep hearing like learn this language and learn this language Haskell learn haskell learn Erlang or learn closure But nobody talks about go learn, you know operating systems properly go learn networking properly Like the focus is completely I think is the in the wrong I I I agree I think um learning learning the concept is it's far more important And once you have those underlying concepts moving from one language to another becomes a lot easier because you're not being forced to Well, you're not being forced to to to do stuff language X's way You just need to learn how to apply the concepts that you already know in language X and that that Makes learning the language itself a lot less stressful I think anyone who's who's saying you need to learn language X you need to learn language Y is probably Yeah, I think you're right. It's probably taking the wrong approach It's what what's not necessarily the wrong approach is saying you should probably look at learning language X because it provides a good introduction to these concepts And then maybe go and look at how they're so you know Erlang provides an excellent introduction to Highly concurrent fault tolerant systems. Yes, you can absolutely go and do that in in Haskell or or a number of other languages um, you know C C plus plus provide excellent um introductions into the really low level guts of stuff Fiddling around with memory pointers. What what sockets really look like at a sort of raw level These are these are all extremely useful concepts to have when you go and start using that stuff at a higher level So yeah, absolutely. I think there are there are languages that are good for learning these things And it's good to learn those languages, but I don't think a language should be learned necessarily for its own sake Once you once you want to go and become an expert in that language once you've decided That's you know the path you're going to follow absolutely learn learn that language as much as you can But don't don't just learn a language because it's on a checklist or because someone's told you it's the language of the future Because that's what somebody told me about ruby about 15 years ago. So Also, I mean move beyond the syntax, right? I mean go deeper Necessarily thing learning languages starting with languages is a bad idea you can go for it I mean, that's how I started with scholar, but you'll see some of this programming languages Find the sweet spot like online has distributed concurrent application scholar also getting there with aka So the way I transitioned to distributed that I had to learn Right. I want to work with scholar. I ended up finding jobs which required me to learn distributed computing So I had to pick up So it's also a matter of interest. I mean And and that's why also it's very critical. I think that like nourish pointed out already and it was a previous question I wanted to come up It didn't Is that languages you can't go back in time You cannot go back. So Yeah, I think A great analogy is if you're trying to learn a culture's sense of humor one of my favorite german television shows is about a And it's a comedy. It's about a crime scene cleaner There are no jokes He grows he goes to crimes and then he cleans them up and then he leaves and that is the entire joke Now to internalize the german sense of humor You have to learn the german language and you have to read a lot of german literature. So Uh It is difficult to separate the german sense of humor from the ambiguity of the german language It is difficult to separate the german sense of despair as comedy from the german language itself and and it's difficult in in Programming languages to separate say the the sort of network style of computation That air lang has internalized so deeply from air lang itself And it's difficult to take something like c++ where you have all of these concepts And then also learn the network style of computation because you're you're you're doing so much at one time So that's why you know people will say You know if you want to learn uh reasoning about pure functional programming that haskell which is internalized that concept Is the language that you should probably use uh increasingly I hear in the bay area if you want to learn about how to write memory safe programs Don't do modern c++ write and rust and then port that knowledge to c++ because god help you the GCC won't But that you're you're able to internalize these concepts without having to deal with a whole uh lot of extra context Um, I think I think it really depends also on your personality Learning when you just learn concepts sometimes it's hard to understand them and applying them To learn those concepts is at least for me really useful So finding some problem you want to solve and then trying to figure out a tool to solve it And uh, if by doing so you learn a new language, then it's great um, I think one problem that comes up often for us for hiring is that We we try to hire a lot of computer scientists But coming out of computer science usually you only learn about concepts. You don't write that much code at least That's how it is in our area And then you try to make them write production code and they're incapable They don't know how to apply those concepts into real code and how to glue all the stuff together In theory like they can write a pseudo code and It looks good on paper, but then writing the actual code does not come out properly So I think for that reason Actually learning a language Is good, but you shouldn't follow trends of new languages coming out like on hacker news every week Oh, this is new cool Distributed language built on top of this vm that compiles this javascript and runs on the browser And another point is also for hiring I was saying often computer scientists don't really they're not that useful coming out of school Just because they don't have any experience. So for us for hiring We hire Erlang people and there's like five Erlang programmers and go back So Yeah, I'm being generous. So You can't just go on linkedin and look up like people to hire So you have to look up for people that have A passion or Excitement for functional programming So they have experience in askill or they built Some scheme variants or like they worked In functional programming and you know, they'll have an interest and they already know some of the concepts So then they can translate this knowledge into a new language and they'll be Proactive and be able to write production code more quickly so, I mean I would say learning a language is actually a good way because I was doing python and bb and all that early in my career and the only reason I picked up a scheme was because Eric Raymond told about it in this book and he said that okay, you learn python and or if you have Pick a practical language like python or pearl and just learn lisp for its internal beauty. So I picked up scheme learned a lot of stuff about you know Hygienic macros and all that kind of stuff and then learned common lisp after that that Auto meta object protocol and that stuff like that. I mean had I not Just started blindly learning language. I wouldn't have been introduced to those concepts at all in the first place I mean, I think it's a good idea to just Pick up a language and I mean it may not be relevant for your current job, but you know knowledge never hurt anybody the distinction though is You individually going and picking up versus someone forcing you to learn a particular language, right? So yeah, I mean after I became a convert I did that This Hey All right, what are the questions people have All right, we'll go there and then okay Mayank go ahead So given a language, what are the three things that you will look into it to understand how good or bad certain languages Because we keep having new languages every day. I don't know if I should how do I Analyze it and realize that okay, this is this is a good language or this is what is a good language? Given a language, what are the three attributes you would look for in the language pass the mic to someone else So yeah, you're right. There are there are a a metric shit ton of new languages that come out every year And most of them probably aren't worth your time Uh Why is that, you know, uh when I evaluate a new language what I am interested in is how applicable is it to real-time systems how how well can I Push bytes across a network, um, and how well can I transform text? Primarily because I work on things that have some sort of disastrous consequence They have implicit clocks. They're real-time systems, and I like writing compilers. I do that for giggles though Um So when I evaluate a language, I ask Of that language, you know What's your real-time story? What's what's your your story with regard to uh resource consumption? Can I reason about how you're consuming resources in terms of say? computation time or total cpu time or memory time? I write compilers in haskell and I really enjoy it But haskell is a language that I would uh be concerned about deploying into Things that I get paid to do because I have a hard time reasoning about its space usage Um, you know, you can sort of sprinkle, uh, Strictness things through it so you can force it to do computations But there's no way of automatically saying that you know this resource this memory consumption will only be so much It's why favorite languages that don't have garbage collectors because usually I need to know that you know I have only allocated 40 megabytes, and I will only ever use no more than 40 megabytes But that's just me applying my particular interest my particular niche over and over again to a language To me javascript seems like garbage, but you know, I don't I don't do anything that javascript is good at so that's my Implicit needs being pushed off onto the world and then I just get harsh about it I actually think there's kind of two categories First of all, there's some Programming language or basically just tool to learn new concept. They might just be Kind of coming out of papers or more like research oriented Those you probably shouldn't learn Just for career move but to learn for new concept and explore open Your mind to new concept programming concept The second type of programming language I would say the ones that you want to learn to actually get a job and Become an expert then I think one of the things that you didn't mention is the community around it To pick the language you need to be there needs to be libraries available There needs to be an ecosystem around like the virtual machine It has to be kind of on github and you need to be able to Contribute and evolve the language To make sure there's a future also for that language So when you're picking your language for instance if you picked Erlang Like for me You're on the mailing list your own github checking the issues like it becomes part of kind of your life So you need to be able to pick a language where you can see yourself be passionate about it and be happy working with it every day So, I mean, uh, I mean I didn't have quite a Question logic taking like for example elm I came here. I looked at elm and In one of these talks in functional concern is like and that looks very pretty. I gotta learn that right. I mean Yeah, there's no other reason why I choose languages except that now I understand how signals work How this thing works There are a lot of these frameworks that are coming in like redux and pop-up and all this frameworks coming in javascript Which have putting a lot of those ideas back into mainstream languages. So I mean it doesn't hurt really. I mean I Think you should evaluate. I mean Yeah, there is a question of time and how much time you can spend to do it But if it if it catches your fancy, then why not? When the problem I think is also sometimes to actually really Understand the language you need to spend a decent amount of time. That's true. That's otherwise you might discard a language Which might actually be a really good language, right? So yeah It's it is about that balance that you were talking about. Yes. That that is correct. So I mean There there have been languages that I've been wanting to try out like elixir I have been meaning to try that out. But for some reason I haven't gotten a problem to solve that I could use the elixir and try to and and so I've never tried it Or it hasn't caught my fancy yet. I mean, I think it's different from person to person I mean One other criteria I'd say it sounds kind of silly but Kind of want the language to be a bit fun to use because if you're not having fun when you're learning it and when you're playing around with it You're not going to take as much of an interest in it and you're not going to want to spend as much time with it So, I mean, it's not you know, it's not a good technical basis for choosing a language But it's a good basis for choosing a language that you might want to spend a bit of time with and a bit more time getting to know And I know for for me that was that was definitely the case with Erlang. I I'd sort of played with a number of functional languages before mostly at university And none of them had they'd always just kind of for me been painful to use and I picked up Erlang and suddenly Here was a functional language that wasn't painful to use that that I could just jump in and start doing stuff with and that That sort of grabbed my attention and and gave me the enthusiasm to keep going with and keep learning it So, yeah, as I said, not a not a good technical basis, but I think it's probably worth worth throwing into the mix one So one interesting thing happened when I picked a functional program in the concept is that the paradigm itself Is that I I actually become a better program? I don't know whether it makes sense or not, but it actually happened So one criteria that I use I don't know how effective is that probably non-technical completely is that I Once I learned one particular functional language, I'm probably not going to learn another functional language Usually I don't so one interesting criteria could be to try to learn different programming paradigms It's probably hardest thing to do, but it actually the one that will make you think differently Which is probably the the most important value to have we're thinking differently. So maybe functional programming I don't know what beyond maybe logic programming pick up a logic programming language That could be an interesting way to look at it cool Think we had a question over there The question is uh related to the industry adoption of functional programming Is it considered as a de facto standard for writing web services right now? And like what right this adoption is happening? Is it a hopeful scenario down there? As a professional like how this is being looked at in the industry as a functional program versus C++ program or a Java program I didn't quite catch all of that The adoption of functional programming in industry, how does it compare with you know other languages? So yeah There's something around DevOps, but we'll come to that a little later Yeah, I think the the total adoption if you look at the entire range of software development is uh miniscule but it's sort of a It's sort of difficult Sort of a difficult question because you're you're really saying like well What's what's the adoption rate of Java? And if you look at a certain segment of of industry like banking relatively low On the rise, but still relatively low. So you sort of have to say like what what's the problem domain? And what problem domain are you interested in working in? So for instance if if I were interested in working in web development I would have real problems Because the adoption of functional programming language there is a bleeding bleeding edge But I very much enjoy working on these sort of like big embedded real time systems and Functional programming does incredibly well there. So it's sort of It's kind of a non-answer unfortunately, but miniscule if you take the entire swath of software development But if you take certain niches very high No, just just to add to that a little bit. I know um Haskell is used Surprisingly extensively in things like high-speed trading in finance and so forth Some talking to um Francesca who runs Erlang Solutions. He said A number of large companies that make use of his of his services actually make him sign an NDA that to Because they consider using Erlang a competitive advantage and they don't want their their competitors to know that they're using it So and you know take that take that with a grain of salt because obviously he makes his money selling Selling Erlang services, but I I wouldn't be at all surprised if that's the case And so that that's a kind of thing that makes it even past more difficult to quantify Because you don't necessarily you know There's not a census that goes out goes out every couple of years saying what languages do you use in in your industry and stuff So I I I get the impression that you'd probably be surprised by how many places that it actually is used albeit Not necessarily for the large products, but maybe around the periphery of of some places of some things as well Yeah, I think in numbers of actual people working in functional programming. It's really really low But those people the work they do touches a lot of people so There was a quote. I think at Erlang factory two years ago something like 50% of text messages will go through a switch that runs Erlang and then like on facebook For anti spam it uses ascol or there there's a lot of stuff in the background that no one knows it's running functional on a functional program, but It is in fact, but it's like two guys writing something that can see A million requests a second that's the kind of the difference instead of having 100 java programmers just working on a problem factory One of the greatest validation that functional programming in rise is java 8 Java 8 being adding lambda after decade It's a huge indicator that functional programming is here to stay I mean, I mean people are we're going to be eventually forced To kind of pick it up and learn The counter argument that to that is people still write procedural code in java. So People still write forter on in java if that sounds better But you're right. I mean can't help everybody, you know, but but you're right I mean if you look across the industry the adoption of functional concepts in mainstream languages is on a rise, right? So that's a good indicator Cool Few questions. So I think this gentleman is waiting then I'll come to you and then there and then here Okay, whoever gets the mic, I guess so you got the mic go for it Okay, so you just talked about that the management is pushing that whenever you can do a task like 10 along Programmers, but you management still wants to give thousand java developers because they're easy to find So I'm coming from the other side where management is telling me that when I can have only 10 people working for me Why do I hire thousand java programmers and they want us to revisit all our applications and see if we can fit them in the functional paradigm and So is it really possible? Does all application Fit in the functional paradigm can or how can we go about solving this problem? I think it strongly depends on the application There are some things that are very very focused on say business rules that are inherently messy And you'll never really reduce the amount of manpower that you need to make something like that Primarily because they're political artifacts rather than technical artifacts Which is fine, you know, we we need political artifacts. We're a tribal species But you can look at some things and you can sort of say, you know, you you have Say a large c++ system that happens to be arranged internally such that there are threads that then pass around these tiny little Structs that happens to represent work if you happen to know that that's how the airline virtual machine is implemented Perhaps you can just redo it an airline depending on the constraints of the system. So I have in the past done consulting for that very thing And you can definitely find people whose job it is to go around and analyze systems and say, you know This language is applicable. This language is applicable. This one is applicable To to that problem then give estimates on how long it would take to change them Usually though rewriting is a a real challenge because There are a whole lot of things that are are mysteriously wrong that people come to depend on Which you will then fix or adapt But wrapping and a legacy system and a functional system Is a a a real good approach and you can sort of squeeze it until it's gone Yeah, I was gonna say I also depends kind of the size of the application you're rewriting If it's a million lines like you're you're probably doing a mistake, you probably shouldn't rewrite everything The hybrid approach is probably something smarter Especially when there's business rules involved Unless you have the most amazing test suite in the industry You're for sure introducing new bugs and unformed scene Also deadlines are never met when you rewrite at first you're like, yeah, it's gonna work and then You're six months late and Not even close to having something working because Some of the assumptions made and then the previous programs were just Completely broken or the specs were not defined properly. So there's undefined behaviors that you can you have to kind of Reverse engineer to figure out how it works But if it's starting a new project and it fits the paradigm then you should always go Well, you you should try to go for functional programming You'll you'll need to hire less people. So if your job is managing people then if you're managing tens of a thousand Your job is much easier So if you're doing rewrite probably shouldn't we have really horror stories of what we write we should talk before you do that But I think there is another interesting aspect to this the right the cost associated with it I mean what type of problem? I mean there is a cost of type system or rewriting or reasoning about co-writing functional code If you your application is just taking htp requests are returning just and I don't know whether there is a value for The other the other question I guess in terms of a rewrite is what you actually get by rewriting it Is it is it a more or less stable application? And someone's just said, you know what we should do stuff with functional languages now Then that's not in and of itself a reason to rewrite something if You're adding a huge amount of functionality or you you want to change something major in it or something Sure look at rewriting it look at maybe just adding that new bit in in in a functional language our telco system that I work on By by functional points, I guess roughly about half of it is still the old c++ stuff because We've we've got a small team and There is no point no no significant value at the moment in rewriting the old stuff because it still works And the amount of maintenance we do and it's fairly minimal because it's kind of in a more or less steady state All the new stuff we're adding is in is in Erlang and so we're getting all the nice benefits from that But rewriting for the sake of rewriting is rarely as good an idea as the engineers often feel it is And you know, I've I've been there myself. I'm like, man, we should totally rewrite that But no, it's not it's not always the greatest idea So yeah, the question really is Why why do you want to rewrite it? What value are you getting out of it or or has it just become like totally unmaintainable? Is it a massive morass of code that no one understands anymore? Does it not perform well enough is if there's value there in rewriting it then then certainly, you know, look at it that way but um, yeah, you In addition to the questions that these guys have suggested it's obviously important to ask why why you would rewrite it in the first place Okay Yeah, who's got the mic? Yeah the extent of type safety in function programming languages like We have dynamic function programming languages like the Erlang and closure on the other side and we have Scala And Haskell. How does the type system the type safety has really matter in function programming? Must mandatory to have Okay, we have this monads and all that in Haskell and we have the Functional programming which is like dynamic enclosure like how does it really get along? Yeah, so I I do a fair amount of work in a language that has a strong type system Haskell and a fair amount of work for money in a language that has Basically no type system, which is Erlang Everything is just a term And then you match on terms You say it's not fair, but I think it's true It's strongly typed dynamically typed. Okay, that's fair change around you all the time That's very true. So to answer your question You know, I think There are certain classes of problems that having a static type system is hugely valuable for because you're able to say that You know this This problem that i'm solving is largely algorithmic. It can be modeled mathematically and I can then express that in a certain type of logic I'm blanking on the name first class preparatory logic. I think is what Haskell ships with So if you can encode your problem in that certain type of logic, then it's great You can also squeeze things that don't necessarily fit into that So for instance, if you are working in a language where you're very very concerned or working in a problem domain Where you're very very concerned about memory consumption. That's not really something that gets modeled in Any of the mainstream functional programming languages, even the ones that have dependent typing they don't give you Insight into the compiler's memory use or the language is underlying memory use So at that point if you need to solve for hard memory constraints, you kind of need to abandon Either the the type system either sort of the type system because you need a language that gives you those certain guarantees But problems where you're transforming structures all the time or where you are going to fiddle around a lot and With a certain data structure In a way that is difficult to model a type system is a very useful thing there If you are doing say sort of unconstrained message passing Something that has a static type system is not super valuable because you don't necessarily know where a message will come from The research project cloud Haskell is trying to address that But progress has been very very slow in part because I don't think we've invented the math for it We should talk about this because in a career adding session types to kind of address all of this So one thing I want to add. I'm sorry about that thing about Is uh, so I mean I'm going to agree with him and saying there is a there is a cost associated with the reason I say How much money you want to pay for the correctness right type system is going to give you that you're probably going to slow you down initially But it's it's the this this concept that evolving now and there was an Haskell presentation that I also mentioned about Uh, a typed type driven development. It's it's not taste driven It's a different kind of development where your types are guiding through it's just helping you to think about the problem There's a tremendous value in that Um, I work primarily with Erlang which is not typed Um, but there is an optional type system where you can write specs and run dialyzer, uh, which will Do type analysis for you? Uh, and I think if you're doing kind of any Erlang code in production and you're not using that tool Uh You're kind of you're not shooting yourself in the foot But basically like you're you're leaving out a good tool to make sure there's no bugs I think type systems are are quite useful Uh, just because for one, you know exactly what the interface of your function expects Uh in Erlang, yes, there is compile time kind of types where you know, you're expecting a tuple or a list But then what's in the list? So what what kind of data can I send to this function and receive? Something that's meaningful for me after so in Erlang to solve this problem There's this optional type system That they added they they would have made it mandatory, but it would have broken all the code before So basically this was the kind of Way to implement it without breaking all the code that existed On on that note, um The one thing we did find with having a dynamically type language like Erlang is that the The process that the iterative development process I think goes and you kind of touched on this It goes a lot faster if you if you're ripping out bits adding parameters taking parameters away changing parameters You can do that a lot faster when you're not Having to explicitly describe the types all the way through and I think Erlang in particular provides a very good balance with this in that once you've sort of got stuff working or once you've once all your functions and stuff are Bettered down a little bit you can then go back and add the add the type data to the explicit type data And even without the explicit type data dialyzer is a very useful tool And it will allow you to do a lot of the static checking that that you get in a in a um strictly typed language like Haskell Without the the sort of development overhead of constantly having to have that those those types there Um Yeah, that's pretty much well ahead I think one of the arguments in favor of uh type systems is you know, it kind of helps communicate to other developers looking at that code So it's there's an element about communication Uh, but I also think it kind of depends on the kind of problem that you're trying to solve because certain kinds of problem domains Right what the type is actually is irrelevant Especially if if you like take example of web development most often, you know, it's the strings and you just treat everything as string Doesn't really matter So putting a type system over there might help you with communication But we'll slow you down and we'll add unnecessary complexity as a programmer. You have to deal with So I guess that might be one of the criteria to think about Just just find it a little struggling in statically type. Um I'm Against of static a little system and one bit that is if I want to experiment an ideal. Let's have a large code base Experiment an idea. I want to take a thin slice of the flow and just change something and immediately get the feedback That becomes harder And Haskell has an option where scholar gets that where you can Disable the type check for a second. Just say just compile it for me. I just want to see what happens That is an interesting experience that I miss that dynamically languages Yeah, even the type inference helps a lot in scala, whatever we have that helps a lot makes the field To be a dynamic language or still it's static Only if you can go beyond the three hours of debugging the compiler errors and shit like that I've seen other people do it. I've not ventured into it. Just if I can add to the previous question Could could you guys talk a little bit about how? How you would compare personally a lang versus haskell Feel free to make unqualified opinionated statements But just from a programming Point of view personal programming point of view. What do you specifically like and dislike at the risk of starting awards? Okay, you can uh, so comparing airline at haskell, uh You know, I I use haskell when I need to Transform something within a single machine So I I take an input to a black box and then I push it out Of that black box and I need it to be of a a a certain Quality of correctness. I need to be relatively certain that this black box that I'm pushing stuff into Will push the the correct notion out But this is all resident on the same machine Or if I need it to be uh very fast in terms of cpu and I've got a lot of ram available So, uh, when I program in haskell, I am thinking about transformation of structures And I am thinking about an arbitrary machine where I've got effectively unlimited resources Uh, when I program an airline, however, I am implicitly thinking about groups of machines that are coordinating over a lossy unreliable network Usually the machines are resource constricted in some way and uh, even though airline doesn't really expose at a language level The resource consumption in terms of memory and in terms of cpu. It's all documented So I happen to know how much a single process costs I happen to know how much a single tuple costs and while you can find that and say ghc It changes from version to version because it's not something that's pegged In uh the language or the implementation itself. So it's it's kind of a difference between, you know ghc ghc haskell is a Research language and it's intended for software that needs to be correct And the software implicitly has a very short service lifetime Meaning that you run it it runs very quickly and then it stops Whereas airline is a always been a production oriented system meaning that its operational semantics are well understood Um, and its service lifetime is very very long. So you turn it on and then you don't shut it off for decades or Um with a couple of modifications to the language until the heat death of the universe So the the design of the language and the tooling that you're given are different because you need to be able to in 30 years Interact with a running machine Whereas in haskell, of course, you've just got this binary blob that's just turning along that runs for about two and a half seconds Um, so the the the difference in focus Changes how the tooling works changes how the the languages work and it changes how people approach building things in either language so that That has an effect so service lifetimes resource consumption. Um, those are the two things that I think of As different substantially different between airline and haskell, you know ignoring the type system and all of that Because that's just fancy dressing on top of those two core concerns So I think then may you've deployed something into production in haskell, right? So what was your criteria of a choosing haskell and like correctness So we needed we needed correct software and we needed to make it really quickly So and and we need to push things into production really really fast Um, I mean in the sense of I would make a change and then that change needs to be Introduction and I need to make sure that it's correct and I don't have time for exhaustive testing and analysis I want to spend the time thinking about a feature and then I want that feature to work And I don't care about anything else So from from that kind of background, I think maybe haskell was a was a very good fit for us Um, especially we did not have we we did not have real-time or Resource constraints Like for what Erlang is useful, but um, yeah So the correctness and being sure when you actually push something, you know having that high amount of certainty I mean, but but I would like to emphasize not a mathematical amount of certainty But a amount of certainty that I would expect from a good piece of software Just that much certainty which is much easier to approach um in the way Haskell encourages you to think about things I think right But but I haven't really used Erlang well before so Yeah, I think that's an interesting point when you work in haskell You are implicitly very very concerned about correctness and when you work in Erlang you are very very concerned about fault tolerance So you've accepted the fact that bad things will happen And you can deal with them and they will be controlled and they will be restrained But but a different nature of bad things right in Erlang the kind of bad things that you're looking at Or maybe perhaps at a systemic level whereas in haskell the kind of bad things that I want to protect myself against are at a software level I I don't I don't want uh, I don't want wrong output to go out. Um, I I don't want a data structure to come in where One key value pair is just ignored because I did not parse it into the right type. So I aren't we talking about a different kind of errors or Is that question sure, you know, I think in both languages you get logic errors, right? Like The type system doesn't doesn't save you from transforming an abstract syntax tree incorrectly so long as the type checks You know in both Erlang and haskell you will get logic errors, but You know, I I often don't think about Erlang problems in terms of the cluster because that's a that's a radically different problem I think about Faults in terms of faults in an individual machine So you get some input It causes a code path that wasn't well tested to be triggered Which causes a fault which causes a crash and then gets restarted because the supervisor and you've just logged all of that Like all of that is now logged and you can go back and inspect it. So really it's pushing off correctness and in To a later date. So Uh, you know, you might drop that single transaction But you were implicitly working on a system in which if you service most of the traffic or the majority of the traffic Then it's fine. Um, you know the system that I work on It spews or it it doesn't spew, but it has around 10,000 errors per second Which sounds like a lot except it's servicing You know between 50 and 100 million things per second So 10,000 is relatively small and the amount of time that it would take us to write a haskell system That was resource constrained and cpu constrained and also retrain everybody is radically more than it takes us to Build the the logging system that records the particular input and then we just run a trace tool over the system to find out What codepath went went sideways So really it's it's do I need correctness right now or do I need correctness eventually when something Something crazy happens Cool So the the question was how do you manage your management to do functional programming in production How you manage your management is a question Blackmail So aside from blackmail, um You know I I have been fairly lucky in my career in that I only work at places that are on board with using functional programming Um, so I live in the u.s. West coast So I am like a kidney candy store basically and that there are a lot of new companies all the time And they're really willing to do risky things So I actually don't have great experience with bringing functional programming into a new organization Um, but in terms of sustaining one That that's sort of a different thing where you know you uh To the earlier question of uh, how many functional programmers are there really if you look at my organization There are around 120 software engineers. Most of them are python python a little bit of java There are only seven of us that are air langers. So, you know, uh be generous and say one tenth of the workforce is air langers But we make the majority of the profits in the company So it's sort of this this ongoing story of we don't have faults that bring the system down We make a shitload of money for the company And so the the story to upper management is even though it's really hard to find us and even though it's very expensive to hire us It's a clear value proposition Um, but as to how you get something into a company that's going to have to be somewhere else So I guess I can talk about that a little bit because we started with a c plus plus call manager and Sort of managed to weedle Erlang into it to the point that it's now what we develop all the new stuff in um I don't necessarily have a good general purpose answer for this but I can talk sort of briefly about the process we went through Which was basically um one of our developers Discovered Erlang at a conference decided it was the way of the future And rather than sort of taking it straight to management saying right We need to write everything in this because that's never going to fly We just started writing some little things, you know that that um to sort of Demonstrate it and also to convince ourselves that it was the right way to go So we wrote a um a load tester for our phone system that emulated and it happily emulated like a thousand phones on on my laptop um Without sort of breaking a sweat and then I took a day to distribute that across two machines And suddenly we had this distributed load tester in this language and Demonstrating This sort of stuff by writing useful stuff that that can Simultaneously give value to the company and demonstrate the power of fp was um Sort of the way the way we got our foot in the door Of course, you've also got to somehow sneak some time in to actually do this because they probably won't let you do it On the on the clock as such so luckily we had a sort of period of downtime We're not much was going on and we could work a couple of hours a day on this sort of thing But once you once you've demonstrated some stuff and then you can sort of go and present this stuff talk a bit about What what it is why it's useful to the company and stuff At the time we were still a relatively flat management structure So we only had sort of our immediate boss and the and the cto to convince and the cto Luckily was a guy just just coded. I don't care how you do it Um, which is rare. I would imagine but we were lucky in that respect and then you know by the time we got bought by short held up the um The functional part was such a big part and so sort of intrinsic to the whole thing that there weren't it wasn't even a A question like no one no one has ever even suggested to us that we should take the Erlang pardon I just rewrite it in c++ because that's what the rest of the system is in Thankfully because I think I'd have a conifption if they did Uh, for my part, uh, at our company, uh, we had to start a new project and basically we're in meeting room on trying to discuss Which language we should pick? Uh, I think the for for this is to build a real-time bidding platform. This was like five years ago Uh, and some suggested c Uh, no jest was just starting back then and some were like, okay, no jest would be a good fit And then I suggested Erlang And uh, obviously, uh, I was the only one that suggested Erlang at that point But uh, instead of picking the language in that meeting, uh, we concluded that we'd take two months and build prototypes in each language Uh, and Erlang just came out clear winner that like just by myself. I was able in like a week to build A simple bidder and talk to one of the requirements was to talk to kisandra and the code was maintainable and testable And it was much easier In c I didn't get very far because Just to get what you get starting with Erlang you have to write 100,000 lines of code to be able to distribute to be able to Do smp and all that it's it's really complicated and then I won't even talk about no jest, but uh, so I think it's it's kind of a You need to have a company that has a good culture to start off with and like a c a cto or Whoever's directing engineering to be open-minded But uh, usually the best way is to prove that it can work Uh, and then if they're if they don't accept then maybe on the side start working with functional programming And then come back a week later and be like, okay Well, I did solve the problem using java, but I also did this prototype on the side and it runs twice as fast And blah blah blah and then just show that it can work and slowly We'll get some momentum. Hopefully and you'll be able to introduce more fp in the company So I guess if I were to kind of dissect the two kind of experiences, right I think To me the takeaway is let data speak for itself Right in both the cases you have Like in your case you you guys decided to take two months Try out something and then use the data of whose reach where how the code is maintainable Etc etc that matters to the company and make a case for it in your case It was about let's not run right now to the cto Let's build something in the side Which is not really mission critical at this point But actually collect some data get some expertise and then kind of convince The management about it. So I guess that probably is the general purpose answer Yeah, I guess so what you're saying is each company would have some kind of in-house products in house tools in house things that needs to be done And that's a good platform for experimenting with new ideas new languages new paradigms And maybe that gives the confidence to try it out then on a mainstream project. Yeah I mean there's a two aspect of the question is functional programming actually Doing functional programming in your existing programming language I don't think anybody will complain about that though. I mean But I think becomes interest challenges when you're switching languages Can you use the mic please because I think people are start leaving Now there's more time for dinner There's just that other people can hear else they will zone out, right Mike Sorry, so the point what I want to emphasize is like most of the companies We do a lot of in-house to in-house prototypes or proof of concepts kind of thing Where a great amount of energy and time was invested in using the native languages or the kind of Languages like Java or typical and I hardly in my experience 10 years experience in the industry Hardly could anybody could able to come up with the concept of a functional program Functional programming does exist and that these things makes things much more simpler to and in terms of scalability fault tolerance or in terms of Like what are the powers of functional programming bringing into like this is what we are spending a lot of time in the Conventional programming like techniques. We are building up systems which are fault tolerant which are like High availability systems and scalable systems. We are doing convention spending a lot of energy over there so there's nobody There to speak out like what is a potential that's true functional programming is going to bring into picture like awareness like This is the conference of a I was into functional program for the last few months like out of my own hobby I was looking into the what is the true kind of thing this functional programming is Why is that whatsapp? Why is the far facebook? Everybody is talking about this functional programming like so this made me looking Look into those aspects. That is what I felt like Yeah, this is what the technology or the developers Who is driving the technology has to think about it and start experimenting all functional programming Languages and techniques and try to adapt To the functional of course It is not like I'm not totally drawing the native programming or the conventional programming because everything goes in hand hand in hand like some Falls of Some some some pieces of some gaps some languages are going to fit into easily into other so it is not like everything fits into one gap But awareness is something like we need to bring it in-house through what we are already doing Okay Already doing but a proactive role has to be taken by the people who are real passionate enough to try out this And showcase it to the other people so that they can gain confidence So even before you go to the management the the bigger point is is there awareness Are people going to try out things like this exactly that is probably a bigger challenge So right now tackling the management right now What I see is all this limited to the startups like in banglou Most of the startups are the guys who are thinking differently and trying to experiment different kinds of They have Success and failures over there. But what is the thing that they're trying? This is a kind of awareness is not finding in the industry like industry they always stick to the like one kind of coding guidelines and one kind of Programming paradigm like which is I think I don't think it is going to it's not going to work out if this continues for For more time like this like I just just wanted to add add to that right I think I think we're in a good place right now because if It's it's unreasonable to expect an enterprise to adopt functional programming because you don't have the resources to do that At least in the bay area, you know that there are people but it's it's simply impossible for me to run a company If I don't have programmers right so I would choose Old language any day over choosing a functional programming language if I wouldn't get the people for it But the good thing is that if you are enthusiastic and you know a bunch of people then you can And you know what problem needs to be solved you can solve it on your own As a separate company and then sell off the solution to them The environment is very conducive to Solving small problems and giving it to people Right so you don't even have to if you think the problem is big enough If you think the cost benefit is worth it, right? But if you just want to write functional programming for the sake of it then Maybe you shouldn't be doing it in the enterprise, right? Maybe you should do it on your own So There's a couple of aspects to this, right? I mean, uh, there's a fear factor in here, right? Nobody gets fired to select an IBM product for an example, right? There's a safety plays a role and lots of interesting psychological Very much cultural as well But one of the pattern I have seen successful because that's what we do. That's a company That was the power job to see for that scholar adoption is picking up And the the places where I've seen it's been really successful Is where somebody evangelized inside the company If you care about your passionate event, you have to stay be a leader inside the company Because last thing you want to do is a go to management So you want to use this functional programming thing? We want to pick our length scholar, whatever and by the way Let's hire 50 consultants to solve that problem You cannot do that. That's that's that's a no win scenario. So data driven. That's a huge thing I have seen places where people took up in weekend Cranked out a coding language Monday morning to a team say hey, I'll solve this problem And team completely switched to closure or scholar So, I mean someone needs to be inside the company who can address this fear factor of management Yes, I can't take the responsibility or I can't lead the steam to the do has gone That's very critical It's not just a fear factor of management as you said you need you need someone to evangelize but you also Before you even start evangelizing to management You really need to convince the rest of the people that are going to have to end up working on this That this is what they should what they want to be working on as well. So when when we were moving to Erlang I sort of Sam and I were in Canberra and the rest of our team were over in New York and I took an opportunity of a trip over in New York to sort of Convince all the other developers first that this was the way they want to go And when you can present a united front to management and say we all think this is the way to go That's I think that's a much stronger message than hey, I've I've got this crazy idea and the rest of your colleagues looking You're going what the He never mentioned that to us So yeah, I think that that's another element. It's just it's not just a question of getting the decision makers on board It's a question of getting the other people who it's going to impact directly on board and convincing them That they should be also helping you to convince management But I think there are a couple of people waiting so I have Less of a technical question and more of a history slash community question So lisp is probably the oldest functional language Probably invented in the 60s. I have less of experience with Functional programming. So I'm curious to know why lisp is where it is today It's not while it's Its ideas are around Both common lisp and mit lisp Are not seen in production. We don't hear of companies using it I've heard somebody speak of the community as being toxic. So I'm just curious to know, you know, why Things have turned out this way if If people do know about it One of the factor Maybe I'm just I would be incorrect in some information here. So I apologize beforehand One of the factor I think that played a huge role. I mean Remember always not the best language always wins. I mean, there are lots of interesting factors in there I mean for lisp, I think one of the biggest problem is that Or or any x language there for an example is that if I want to pick it up How is the ecosystem looks like? I mean, do I have to write my own logging library or http library out there? So so in the new incarnation of lisp, which is a closure I think has a much better a brighter future because of the the selection of the platform for an example jvm And I suddenly have I don't have to write another http library because just can use out there I think that's one of the critical factors that played a huge role I think one of the problems with historical lisp was You had much more primitive machines that it was trying to run on and lisp's primary selling point Such as it was was that you could create a new language to solve your problems And the sort of lisp response was when people would say well, that's great But honestly, I don't need that many languages I just need this Atari to do something and the lisp response was buy a lisp machine Come on have have a have some decency here. So, you know Nowadays you can have languages that take More inefficient routes to performing computation While saving programmer time So, you know nowadays you can say, you know, I'm going to make a make a special purpose language that does this thing And it's going to take more cpu time But I've got effectively unlimited cpu time for this particular thing that I'm doing so it works out But it's also why you don't see lisp nowadays and say High performance computing or in physics simulation because you still need to access the machine in an incredibly efficient way It's just that now Lisp closure, which is really the only one that survived because it doesn't have The worst people in the world surrounding it Common lisp is a really interesting language, but a lot of the common lisp community is very elitist Is probably the nicest way of putting that And it unless you happen to be Damaged in some way and enjoy that you're going to tend to stay away from common lisp But you know to the point you made earlier not all the best technology Wins out You know, I study a lot of historical engineering because I work on these sorts of systems that have really bad consequences when they fail And you you just don't have that many examples in software So I study the space race quite a bit and one of my favorite examples The is the space race in the space race is the first stage rockets in the lift engines That's the thing at the very bottom. So if you think of the Apollo rocket or the unbuilt soviet rocket, it's the real big part The soviets what they were going to do was build a hyper efficient engine so they could have a smaller rocket But it took longer to develop I won't go into the details of how it's more efficient, but the american approach was Just make it bigger and louder And it was way more expensive. It was way less efficient, but it worked quickly and You know russia never got to the moon the us did and then we all stopped going to the moon for reasons that I don't fully understand But it's that idea of you know Even if it is 10 percent better Is the time that it takes to get that 10 percent worth it? And I think historically the answer for lisp was no I don't need my own special purpose language. I need to be able to program this computer that I have I think one of the big problems that he he noted is really the community The lisp's curse is like something real where Everyone's kind of a purist and they don't want beginners to be joining and If they don't agree with something they just fork and create their own list. So there's like 600 Thousand lifts out there And which one are you supposed to pick? If you pick common list, then you get the worst community. Well, the worst This is recorded, right? But yeah, the community is not As amazing as the the airline community I'd say so Uh, I think that that's kind of the the main problem that happened there But it's the same thing in other communities like for instance, Erlang We had a discussion this year at the Erlang factory in san francisco About trying to help beginners joining the language And uh, some people Which are pretty famous in the community still Uh argued about that it's already easy. We don't need to do more um and it was kind of Shocking to hear that when we're trying to grow the community and get more people Do functional programming and Erlang and all that that some people still kind of uh They want to keep it for kind of the elite people that know and keep that knowledge in a closed circle So I think for it's for lips. That's kind of what happened And everyone has just been rewriting their own list. Uh, so that's Doesn't help adoption Cool, I think there's we have a question not necessarily about Functional programming as such but about new generation of programming languages, right? The only thing that has got a large number in the number of programming languages is the number of package managers that they write for Right and this is a major problem when it comes to tooling because Essentially a lot of developer time is wasted on building very similar infrastructure Yes, there might be a slight advantage like you use a curly brace instead of a square bracket for listing your dependencies but it doesn't seem like a major improvement and say nicks tried to make common ground for everybody but not many people seem to be interested in Uh, throwing away their language specific package manager and like moving to a common package manager Do you think this will ever be resolved in the future because for a older systems, right? All you needed to do was type dot slash configure make make install. That's how I learned the nicks They hit pretty much and now It's some rebar some mix some cabal Right, I mean and for every new language just to understand. How do I install the library? I need to go up and learn for one hour more right uh Where do you think this heading? So the the industrial revolution is fascinating because it really got started Because people thought you know what screw should all be the same size So before the industrial revolution you would have these screws and they were all radically different So everybody that was building something would have to hire a guy that all made screws And every new project every new bridge everything all custom made Um, and then you sort of had this clear value proposition to having standardized parts And right now in software. We haven't found our industrial revolution. We're all still running out there We're all craftsmen. We're in small guilds. We we hate the potters across town Eventually we will Random walk our way into standardized pieces And I think part of that random walk is everybody saying hey, this has a minor flaw I'm going to build my own package manager or my own lisp or my own compiler You know, uh, eventually I think we will just sort of stumble on to standardized pieces But where we are now I don't think within our lifetimes we will necessarily see that result Technological changes slow, uh, you know, it's faster than it used to be we're not spending 2000 years Improving the point of spear, but we still do take quite a while to improve things And that sucks. I wish it were different Yeah, I think uh It's kind of unfortunate, especially for Erlang The package managers are non-existent really I think in the last four years, there's maybe like five that were created Somehow and that like five people views To to actually get that working You need like an effort of the whole community or have some sort of foundation that will guide And fund this packet manager And I think Elixir has been kind of Doing a good job at that part compared to Erlang, but uh It is definitely a problem that needs to be solved And I hope it gets solved during our lifetimes because at least for Erlang Like these days, there's The mainstream build tool is rebar, but there's also rebar three that works with some package Some others doesn't work There's Erlang mk, and then there's a bunch of other stuff There's plugins to try to make them work together It's it's kind of a mess and then in the end it just makes the adoption way harder for someone because like you said You need to spend two days to try to understand how to build the release to put your application in production And it's really it really shouldn't be that way The challenge there is the the challenge there is that's Erlang focused You know if you want to do Erlang and python and c++ and java, you've you've got four different things there You know for a while it seemed like maybe autocom would be the solution But you when you build the all-seeing all-knowing thing it's terrible You know it's it's general purpose to the point of being absurd and I honestly don't know what the solution there is But to that point, I mean dependency management in general is a very hard problem to solve I mean, it's not a trivial problem. It's I mean Any language for that matter right javascript if you see is struggling with that problem big time I mean any language we pick has that big challenge Brian sort of touched on this but one of the particular problems that Package management faces is it's not really clear where it should live either you've got rebar and and lmk and stuff Which are language specific things and then you've got things like cpan and stuff for pearl and and what have you But you've also got sort of os level stuff like rpm and and and deb packages Which are kind of trying to more or less do the same thing and And they're trying to do in a general case for for all sort of packages and But but that means that they sort of miss out on particularly useful features of language and similarly the language ones filling those that niche but they're useful useless for the other languages and That's I'm not I'm not proposing any kind of solution for this That's just another another reason that possibly Brian's right that we might all be In our cold cold graves before anyone actually figures figures this out properly No, so I mean no what what I what I want to what I want to ask is What would this solution even look like I can't I can't really perhaps I'm too young, but I can't really understand how Uh a package management system across different languages and systems would sort of work together and look like isn't the fragmentation already to I and that is exactly what I was about to say when it will become like the next kcd comic But then but then the problem to solve is that for each for each language if the package management system is good Then tying it all together with just a bash script is enough, right? I mean what what what what are you really what what is the Pain point is the pain point that within languages the package man systems are not good enough With like for haskell you have cabal and you have stack and whatnot Which is like he said a fundamental problem with the nature of dependency itself It's not really that people who are behind haskelkorn design a decent decent package management system, right? It's just that it's hard So is that the question or are you talking about across languages if I want something installed in one place? That's the problem that you want to solve Okay, I was talking about across languages. That's why I brought nix as an example over there Because over here essentially the problem with multiple tooling, right? is for example, I work at a slightly larger company and A bunch of n ports are open in like 10 tools are open in probably Yeah, you can't arbitrarily get download from arbitrary websites But isn't the current way that we're trying to approach this solution trying to use Orchestration tools like chef or salt or puppet or write your own but I mean is is that the answer that? Okay, so that Partly helps I mean at the risk of making an n plus one package manager, which tries to unify the n package manager But I don't even think something like no what I mean to say is if you take something like A very small embeddable language and wrote a package manager in it. I'm not suggesting that we do it and This is hardly going to be like 300 kb extra along with And it is one package manager that works for every language. I'm talking about package managers They're not build systems. I understand that build systems might require system space I mean like Um Language specific features. Yeah, I'm talking about package manager. I made a mistake by uh referring to mix. I meant hex The elixir this thing right and cabal. I meant cabal install not cabal so having these package managers seems like an Like npm right, I mean probably it's not necessarily a good answer, but it is an answer Um, just putting a number of Directories inside directories you take that and move on pretty much because yeah, because whatever These sources are cheap enough for you to do that. But um Yeah, but I mean I am I think it's okay to have Lots of different languages and different ecosystems and just have really figured out things within the language within the language ecosystem to get things working, but But I think the problem is maybe hard enough for me to understand how everything will work together itself Is so hard the only way I can think of doing it is I'll do it manually using a bar script I can't even think of what else I would want to replace it with because anything that I replace it with I would lose the ability to customize things that I would lose the ability to Specify something that is ecosystem specific, right? So I I don't know So let's just agree that we're not going to solve this problem I think a gentleman over there has been waiting for a long time. So let's kind of quickly My question is a little uh, maybe offbeat here. I mean, maybe I'll give the bad guy All of you have shipped system. I mean, uh, work on production systems using functional languages So my question is what are the features in functional languages that you don't like Right, uh, that each of the languages, whether it's Erlang or Haskell or tooling, uh, like tooling, for instance, if I pick Try and find out how to do debugging with common list, uh, you'll tear your hair out Somebody says go get slime because somebody says go get list works. So, uh, whether it so my question is two part one What are the personally individually each of you that you do not like in the languages functional languages that you work in? second, uh What are the things in the tooling that you would like to see better for the current languages that you're using? so In no particular order, I mean, none of that is more priority But I I just want to understand your because you all of you have shipped systems in functional languages So I wanted to get your perspective on those things. Can I just paraphrase your question a little bit? Yeah, sure So we'll just go in this order each person Just a tell what's your favorite functional programming language And then what is the one thing that you would like to change about that language? And then what is the one thing that you would like to change about the tooling in the language? Okay, right. So three questions in one question Um, I work with Erlang in production If there was one change I could do to language it would probably To have a way to have a limit on message cues So that you don't have to implement backpressure wherever you have asynchronous calls Uh, and then the biggest problem in the tooling I would say it's build tools So, yeah, I think you're going to get three earlings in a rose favorite language here. Um There we go problem solved. Um The the message you link thing is is is an interesting Although I'm not I'm not sure what a good solution for that would be is the thing that wouldn't complicate the language further Which isn't to say it's not a problem. You're absolutely right. Um So just to give a slightly different answer then the probably the biggest problem we found out We found in rolling Erlang out to production is that there Is very poor support in it for running it as a unique style service So there's a bunch of bunch of behaviors you expect from a unique service You expect to be able to start and stop but you expect to be able to send it a c cup to rotate the logs You expect it to hold on to the terminal when you started until it's fully started and then return an error code And basically none of that is is built into Erlang As a shameless plug. We wrote an open source program called ULT that will provide all of that So you should definitely look it up if you're running Erlang in production as What was the thing? Oh, yeah tooling what I'd like to see Done much better in Erlang is the release hand and kind of goes goes to the build system But is specifically the release handling Erlang's got this whole sort of system Theoretically in place that allows you to build a release And that will provide you with hot code upgrading and all these other magical things And no one I've talked to has ever really used it successfully in large scale because it's really difficult and not particularly I don't I don't think it's brilliantly put together for what it's supposed to be doing I'm not suggesting I could do it better, but it's it's No one seems to be able to use that well. So I'd like to see that done really well It takes a lot of discipline to get right Yeah, well, there's there's my problem, right? Yeah, it's it's really easy to screw up You need to have a system around the system to get it right to detect that you've Incorrectly upgraded things Once you have that in place once you've spent all that money Which I'm sure Ericsson has private tools for that and Adrol has private tools for that It's real sweet, but before that point. It's just real bad. Yeah So I'll talk about Haskell so from I think the ability to reason about Memory consumption and usage is very important It's not a problem that we've really hit right now But it is something that is definitely going to be a problem for us going forward From a tooling point of view I would like to see faster much faster compile times I I mean especially for larger more complicated somehow And the nicer the abstraction seems to be the more the compile time is And that's I would I wanted to be more like a dynamic programming language I just want to run it and see it Also more support around distributed kind of model Allowing things like hot loading and stuff Which is technically perhaps not even possible with the Language like Haskell but approaching that in whatever possible would be nice Cool So let's see the My my current favorite language that I don't actually work with is is rust But it's not really a functional programming language. It's an imperative language with a lot of compile time guarantees So I won't I won't talk about rust, but if anyone wants to talk about it at dinner I would love to do that. It's a fascinating language, but it's not functional It is very much imperative with some functional niceties put in It's dynamic c is the best way to describe it You know it it does actually have strong static typing so it it's uh It's primary focus is memory safety And so it it had it had a linear type system so that you could say well this this Bit of memory that you're able to represent in the type system is only used once and then they backed away from linear typing, but I think now it's a Multi-value resource typing something like that. It's got a particular name. It's a particular logic um But it's relatively new and it's not a functional language. Uh, my favorite functional programming language is airline So I forget what the other questions are supposed to be What's one thing that you would like to change about your favorite programming language and one thing that you would like to improve in the tooling Got it. Uh, I would like to Remove the limit on the number of atoms that the system can have so I am very very interested in Airlang systems that have incredibly long service lifetimes And there are a couple of fun ways to knock over an airline box One is to dynamically create atoms And my later point will get into this If you dynamically create an atom, there are only about two million of them that are allowed in the system There's an atom table that is effectively just an a c array And once you fill that thing up if you go past the end you crash the airline vm So your entire system goes offline I would fix that. It's uh relatively easy to fix. We've had or relatively from the semantics model point of view to the message queue problem Easy to fix. We just have not paid anyone to implement it What I would like to fix in the languages tooling the airline compiler is real dumb It's very simpler. It's very simple It does not do much analysis of the program and because it doesn't do much analysis of the program Its optimization is real dumb. So for instance one easy win would be constant folding So a lot of time in airline programs, you'll see things that are macros that are really just a constant, but uh Airlang macros are textual substitutions And there'll be a constant in terms of their function that then computes the value and then over and over and over again in your in your uh program that will be computed So then you'll see people that will come through and they'll Do that manually and then they'll put a comment off to the side and say here's the computation that this is If you've just had constant folding you wouldn't have to do that But urlc is designed as most airline things are to be simple and obviously correct Because it's from an earlier era where computers were very difficult to have these sort of static guarantees So a nicer compiler is is my answer My favorite language is scala. That's what I use here So one of the things that I really like to improve is see getting better is the type inference functionality And having some sort of effect system so that I can track the mutations through the application And the tooling is the binary compatibility checks What's also the upgrades also as as this language going to mainstream We are having larger and larger applications figuring out whether because I want my language to evolve Get new features get excited and also kind of balance the engineering bits and figure out whether it's in cup products So I'm going to actually answer the original question. Which is one thing I don't like about some functional programming Languages, so I'm going to speak a little well. I'm going to talk a little bit about closure And everyone keeps telling you about all these great aspects of immutable data structures and like, you know You can associate onto a map and it doesn't affect the first one I mean the original one, but that actually comes with its own set of problems, which you'll get into Which is that it generates a lot of garbage Like especially if you're like taking a map in your so so if you actually look into the closure code, there are Like there is a like a lot of like optimizations that people have tried to make to like make sure that you know, like You know, you see that you're associating the same keys over and over it'll like, you know reuse Like it'll not hold the pointer to your older map and stuff like that But at least the first thing you'll always do in like a closure problem Is you'll you'll find like all these places where you're mutating a map like in a row and you'll immediately make it a transient which You know, it takes away from the like some of the some of the benefits you'd expect So with regard to immutable data structures creating garbage. Have you heard about rust? Um So the I mean, that's a cute way of saying it But uh because the the language in its semantic model has memory as a first class concern You can have immutable data structures that don't require any runtime allocation They only require allocation if you happen to modify the structure and then you Only ever have one owner for something So there is no need for a garbage collector because you can statically say that this The lifetime of this Piece of of memory is such and such a thing in such a function So if I have two threads that are just you know passing the same immutable structure back and forth If I choose to modify that structure Rust will guarantee that either I have to force a copy and so the threads have two copies of the thing Or they only modify them at once or one at a time So you never have to you know copy the thing and then you have two copies of memory unless you explicitly do that I I think with regard to garbage collection, you know it For a long time it seemed like the right thing to do Because we had lived through manual memory management where the compilers had to run on very primitive machines So they couldn't guarantee much about the the manual memory And you just had to have you know the sort of like reason to model in your mind Uh and now we've gotten to the point where we've invented enough math Where we have fast enough computers where it turns out you can actually start to statically analyze this sort of thing So I think immutable data structures are real nice and in garbage collected languages They have that exact problem But I think in the future and I don't think rust is necessarily the language of the future I think it might end up being a lisp type language where people go. Oh rust was so good But Its features end up being in every language So I think we'll start to see new classes of language coming where you can statically analyze memory And you'll have immutable data structures that don't spew garbage all over the place Yeah, we might all be dead by that time but it will happen All right, I think we are at seven so that's pretty much the end of the panel So if you have any other questions that you were not able to ask that's okay We're gonna have dinner and then you have more time to ask people Specific questions that you you know, we're not able to ask so far. So thanks the gentlemen over here in the panel Appreciate all the insights. Thank you and thank you guys for sticking around Dinner I guess is ready so we can have dinner and see you guys tomorrow at 9 a.m sharp