Scale By The Bay 2020: Panel: Programming Languages in the Era of the Cloud

Scale By The Bay 2020: Panel: Programming Languages in the Era of the Cloud

Recording: Scale By The Bay 2020: Panel: Programming Languages in the Era of the Cloud

[Music] hey once again everyone welcome to the programming language panel this is a really exciting to have a lot of uh you know folks here that can contribute to the discussion and um but myself i'm a long time uh scala big data developer i've also been getting into uh russ lately and and have to do python for data science and and once upon a time i remember uh when i worked for vmware for many years i got into python and said hey this is it this is all i ever want to do you know and obviously like you know there's been a lot of evolution i've learned ruby so i mean i i think this is always you know the um pokemon language is always like religion you know like everyone is always debating about them and everyone is really passionate so we're looking forward to a to a good uh passionate discussion here and i think my main like thing for everyone else is really around like uh you know to start off with like where do the rest of you see in terms of like the programming language landscape and and how um it is serving you know the needs of the cloud today with like so much distribution concurrency um and uh with developers like getting involved in operations and like you know where do you see the current landscape and how it you know contributes to it so um you know william do you want to introduce yourself yeah yeah hello everyone um yes and i am working as a software engineer at moya moya is a company based in hamburg germany for ride sharing and it is basic like we are relying on the um uh more a lot of information about where the vehicle is and and uh um having a lot of components and services that are interacting with each others so we are working a lot with distributed systems and i'm excited to hear from all of you about this topic welcome everyone and you can uh introduce yourself maybe we can start with uh john pretty okay hi hi everyone i'm i'm john i'm often known online as propensive i'm a long-term scholar developer i've been using it since 2004. and um not entirely sure why alexis invites me onto a panel about the cloud but i do i do use uh google cloud platform um i suppose my my interest in uh would be in relating uh scala and the opportunities that uh uh strongly type statically typed language could offer to improving reliability on the cloud and like alexi mentioned at the beginning avoiding us all becoming yaml developers uh next is jana i'm sorry hi um i'm jana dogen um i'm a principal engineer at aws but most of my like programming language work was at uh google i worked on the go team for a while um i was actually like one of the earliest members of the team uh when the you know the language was still small um it just you know took over it became like a more interesting language i think in this domain and i initiated a lot of like things related to google cloud's go support and before that finally i was my first 20 project at google was making scala a google free language like a language that is supported in our production so i just like went from like two extremes like one extreme you know of scala to a language like go um but you know like i really wanna talk a bit about um maybe like the runtime aspects um you know concurrency model like that sort of like things so if you have any questions i would love to you know see them and who is next um maybe bill hello i'm bill benners and uh i'm a scholar guy i have lately this year been working on the fifth edition of this book uh which is about study which is a massive rewrite of the language that compiled the ground up so we decided you know it since it times well with the pandemic we'll rewrite the entire book and it split into two even two volumes so that's what i've been working on uh lately um and uh my my uh feeling about the cloud was um that it's uh it feels kind of a level like like in the old days of assembly language maybe even or maybe c maybe not assembly but um i think uh you know maybe some programming languages or improvements or whatever can make it more feel a little more high level um but that would require that you kind of have somehow cross these uh across the network and have things on both sides and that's one of the things i felt is that like i compile to a jvm let's say in a different jvm and then then we hope that the protocol matches so even just the type type systems that we have it would be nice to have uh you know type checking across those boundaries but there's other kinds of type systems like session types that can you know actually not compile if the protocol doesn't line up right and then you can do things like anal static analysis to give you deadlock freedom so i think there's like a lot of opportunities for that sort of stuff but on the other hand um the this thing is heterogeneous and people just haven't in the past wanted to have like the same language across things they wanted you know these people use python these people use java whatever and have them talk to each other so anyway that's my uh where i'm coming from with the cloud uh so i don't know who who's next uh ruler i think is next in my zoom order hey uh i'm roonar i'm one of the co-founders of a company called unison computing and we're working on a programming language called and platform called the unison which we're hoping will be a sort of operating system for the cloud so where i'm coming from at the cloud is that it's same as bill basically i feel like it's way too low level that you know uh the cloud we see it's kind of a new kind of computer and it's early days yet and so it doesn't this computer doesn't really have an operating system uh you know like you might be thinking oh aws is an os for the cloud but it's more like a bios like it provides you know basic places where you can call into from a single os process to get you know some basic services and even things like kubernetes or whatever uh kubernetes is just a big linker you know it's not it's not a uh you know like a shell for the for the cloud computer which is what we uh what we hope to build uh and the way that we're approaching it is that every program in unison will have a unique address based on the hash of its implementation so everything shares a vast global memory space and you'll be able to call into basically anywhere in memory uh at any time in the future and anywhere on the planet and beyond uh borrow your next all right so um alexei thank you for inviting me my first time at uh scale by the bay as i have very little to do with with scala um i i'm a java developer for the last what 19 years um ahead of devops advocacy with jfrog um jeffrey is a company that mostly talks to um engineers and in the edge of devops do tools that help devops and especially in the cloud and obviously our products support any possible or not any possible we're close to um most of the most popular programming languages um so we we're pretty familiar with the ecosystems of of which one and and um if i want to make a statement about the programming languages in the air of cloud of the cloud i would say that now especially in the era of the cloud you need to ask yourself why do you want to write something in one language is not other and there are valid answers and there are less valid answers and valid answers might be i need my code to be very very fast in runtime and then you will look at the modern languages for that purpose rust obviously or you can say i want extreme productivity when i write this code but then i care less and i don't care about platform dependence because i run in docker and then you go with with go go with go huh um or you can say i need a language that the people who are not necessarily developers can write almost a pseudocode and it will magically run and then you obviously do python right so those are kind of good answers to the question why there are less nice answers like i want it on my resume or i'm in love with the language or this is my religion and it's all valid but probably have less value as for for the business or for the code that you want to run in the end of the day your code with and and and with cloud it's now even more clear because um it kind of as as alex say put it in the beginning we have those consolidation forces and as as the market matures and everything and now it's true for the developer market it's easier to write to to find a developer with the popular language than the one that is not popular and that promotes the popularity even more uh but it's also true for indoor on terribility which is kind of might not sound intuitive especially in the world of microservices when we kind of hey why do you care you just do rest api and everything talks http and it's all yaml and json but in the end of the day if you have interoperability between modules which are written um with the same language and the same libraries the same architecture this interoperability goes beyond what passes on the on the wire so that's kind of my stand and let's fight thank you barak and i appreciate really appreciate you bringing your fireplace because you know i found that when i declare announce a fireside shot at the conference i had some people coming in if you don't really have a fire place they can ask for their money back so it's very important you know to have a fireplace if you declare fireside shots so next time i have one i will follow your example so nobody you know can ask for a refund uh so great uh and last but not least is brian kemp shriel who has his own cloud now hey thanks um i'm i'm brian cantrell i'm the cto of oxide computer company um we're actually a de novo computer company uh seeking to deliver of the the hardware and software benefits of the what we call the public cloud to those who are running uh who want to actually own and operate their own computers it turns out there are people like that so rack scale machines it's kind of interesting people talk about the os as a metaphor the bias is a metaphor because that's actually how i've spent my career is in those literal artifacts um firmware uh low level system software kernel development um operating system software and uh and control plane storage software and so on um we do virtually everything new for us as in rust um we are um by design and also by by uh because the right tool for the job we're a big rust shop um i think uh baroque made a very good point and it's a point that i would really reiterate in terms of the cloud um you know we live in an era of great language heterogeneity and i think that is that that is a tremendous feature i think too often we have these languages kind of declare war on one another and that does not make sense um and what i look for is as someone who spent a lot of time in c i actually written a lot of javascript uh there was a time when i really had great ambitions for javascript in terms of its of its rigor that i ultimately gave up on um but the i think when we look for for a language and we're trying to match that to a task that we're doing we want to find that the values that we actually care about in that particular task and this is what baruch i think also alluded to you know do you need it to be do you need to perform do you need it to be debuggable do you need to be quick do you need it is this something that's going to be a prototype do you need to be written by a scientist do you need to be accessible and these are different things that are that come in the tension and not one one language is very unlikely to be the right fit for all jobs so i think we do a better job when we think we do a better service to software engineers when we think about the values that a particular language might have and then matching that to tasks at hand thank you very much brian uh now we'll let moderators ask some questions i think evan is uh up for the first question uh sure thing so i think following on from what baruch and brian had alluded to about um you know choices of programming languages so um it you know it was said that it really depends on what uh you know tasks you want to do and that's understandable everyone has different priorities but do all of you think are there specific you know features of programming languages there are platforms or communities that that you think are you know are more relevant for the cloud for example like type safety other things or do you think that doesn't really matter you know like what what do you think are those important characteristics if any yep so i i can go um i think obviously there are and alexi kind of threw it in the air and said what is how do you develop to the cloud it's it's we don't know that and i think there is obviously everybody do what they do but we have kind of manifesto for what development for the cloud is and that's the 12 factor up and beyond the 12 factor up and 14 18 19 i don't know by the way why they're all like even numbers but for some reason the number of factors are always even so um one of those factors or many of those factors have a very significant impact on the selection on programming language um for example the startup time and the teardown time it's extremely critical for the cloud because of the scalability you need to scale up so you need to make your service available on new pods as fast as possible and you also need to be able to kill malfunctioning as fast as possible but also gracefully so for example if you take a programming language which takes very very the application takes very very long time to start up that will affect your ability to scale in the cloud and there are many others and type safety for example well again i mean if you are going to if you do continuous delivery to the cloud how certain are you that your code is doing what it's supposed to do well the answer is never you have is always you have no idea right because we can only test in production uh the ultimate test will be in production but if you manage to increase your um trust in the code by having type safety then you will obviously be in a better place so for the cloud i think there are very clear um properties of the language that that should be and those that you don't care about for example platform dependency now with docker you really couldn't care less i can explain like uh my also perspective from you know what i observed when i you know so go growing so big in this area um one of the things that like you know we a couple of things that you know we already mentioned that like uh runtime initialization is just really fast because of the nature of the you know the platforms that you're running you just want to really you know scale the resources up and down like so runtime initialization was a big issue for tons of like run times for a while and like go was giving you this like small runtime and you know we were putting everything in a static binary so the you know the initialization was very hard was not dependent on a lot of like external resources and so on and so on that became a huge thing and uh interestingly all of this like you know command line tools started to like you know utilize go for the same reason so you know in the devops world like it just became a thing because you know you would just write the server and then maybe like um you know if you have like any command line tools and whatever you would still like rely on the same language and like be done uh so that kind of like was a very compelling story for tons of people in terms of deployment also like you know static binaries have been really great like even though we have containers uh people were like you know having difficulty you know distributing or like verifying and all of that stuff like just bundling everything into one simple thing uh was very like a good you know you know advantage and um if you think about like containers like our container images are extraordinarily large because of like you know runtime dependencies and so on a small static binary was very nice because you know you just kind of like end up having all this like you know 50 megabyte of a docker container with all of your external dependencies in your server and that was just like really nice you know build pack push you know distribute and so on and so on one of the other things that i actually like liked about go and like tons of people i think liked it is uh you don't really like um you know cross compilation in go was always a nice thing if you're not depending on any c libraries and uh the standard library came with all of this like networking packages like http like all the stuff like the json library like stuff that you actually need and you know they don't really require any like c compiler or whatever so like being able to cross-compile on your like mac to targeting your like you know linux machine because you know in cloud your environment is most likely to be linux it was really like a nice story for tons of people so i would say that like there's a lot to do with like you know like how fast and how small and like you know the initialization and the packaging and everything just really contributed a lot to ghost success hey can i ask you a quick question of baruch you said platform dependency you don't care or do you mean platform and dependency you don't care no i i mean if i don't care i don't care about both but but what i i really meant since it's all containers anyway i don't really need my binary to be able to run on any of the 42 existing flowers of platforms okay i i just shipped my machine as we spoke so whatever i build it this is what's going to run in production and i and i couldn't care less okay cool thanks thank you that's by the way a very big hit to the jvm right because their selling point is kind of uh going away once you i mean now you really i mean so go is platform dependent so what you compile it once that's your target platform it's running cloud why not so that's that's an interesting that's a very very interesting very dramatic shift in the industry one of the biggest selling point of the jvm is going away in front of our eyes that's that's impressive so evan you were asking if there were any kind of absolutes um and with with a uh a tip of a hand to type safety um i have to say the older i get the i maybe the uh the more hardened i get on this that i on the one hand you you don't you want to allow things to be uh done quickly on the other hand i've seen so much harm done in production systems by type unsafe code um that i actually think that one of the most honestly one of the most important and unsung developments in programming languages is actually typescript where um bringing because javascript gave us a real false dichotomy where we were forced to live in a completely failed state from a programming language's perspective and it's it's really um challenging when you have these errors that are effectively typos that you don't see until they're running in production that's really unacceptable um and we should demand better uh and i think typescript is a very important uh innovation in that regard and i think type safety is something that we really need to demand of ourselves and the uh yes it it shifts cognitive load slightly um in that one is forced to slow down ever so ever so little to actually um give the the programming language some uh some hint as to what you want to go do so it can help enforce your own rules but i feel that for just about any language um we need types types are actually a really good innovation i'm i'm ready to disagree if someone wants to like if if if that's what you need in your lives but if someone else wants to say something else go ahead i i would i would second what what brian has said uh i think i think type safety is very important i think also one of the biggest challenges in developing for the cloud especially when you have microservices is that the whole time your apis and your integrations are evolving so you're often not just developing for one particular current state if you're deploying a micro service it has to be often compatible with the current production version and the the next version because you want to sort of move these things in in lockstep and that that i think is one place where um i think some new developments in type theory could be very useful so things like dependent types you could potentially have a type representing your old version of the api and a type representing your new version and you could you could branch the code exactly where you need to for the old version or the new one checked by the compiler putting your trust in the compiler to to verify that in the same way that you trust the compiler to to verify that you won't get linking errors at runtime but just extending that outwards to to the cloud i think that's a an area of opportunity um for for applying type theory and and some of the newer developments in type theory to avoiding what is the equivalent of linking errors in the cloud yeah that's that's fascinating the disagreement that i wanted to bring is not necessarily anything to that you you say it's obviously very important and you know what defining an api version as a type is is is mind-boggling because that will solve so much pain for for our development for sure what i wanted to say is that there is a very clear niche for um for for programming languages uh with with dynamic typing and uh it's not a cloud it's not it's not like the ultimate production if you wish but we spoke about the data scientists that are using python heavily and the reason they're using python heavily is because it allows them to write a pseudocode that eventually runs uh adding type theory on top of that will definitely make them if you wish have to be a developer in order to express their algorithms and see if they are working and this is this is something that i think won't be one be acceptable i will give you an example um my wife she works in search engine optimization and she's not a developer she never learned the programming language but now she's using python for for example to build models of um how um site maps should look like so they will be indexed better she's not a developer and she's writing python and if i when i make fun of her hey you are a developer now too she's like no i'm writing algorithms and it works so adding types to that will be a disaster and i think there is a very clear niche for this type of programming languages as well i completely agree with the like mental overhead of versions like uh for example i can give an example which is like not like super nice or whatever but uh you know cloud providers have all these apis they have minor and major versions like once there's a major version they all generate new client libraries so like you can say that like some of the new types are actual versions but you know like um you have package versions and then you have api versions and you have some other like compatibility versions that you know it's just kind of like becoming such a huge mess for the user because they have to understand and navigate the entire mental model and you know it's just more of like trying to figure out like what version matters for them and like it's kind of like i think losing the value because of the complexity of the like the complex nature of the situation so i'm not sure like what is the best way uh to do this like at google um all the apis were really simple because you know the company had the internal has this like mono repo just go and fix people's bug like issues if you know you're deprecating something but um what is what was interesting was like um in your service description you would never actually like delete things you would only add new stuff and you would just deprecate the older like apis over time and go fix people's bugs but in the protocol level in the wire level it would you would still support it just in case somebody hasn't upgraded like maybe like some more pragmatic solutions like that is the way to go i'm not sure i've seen like so much like virgin mental overhead come in you know because it's inevitable so um i'm also skeptical about that hey runar can you do that in unison yeah i wanted to address that uh so in unison okay so the problem is like john said with the linking uh and and janna you were describing this as well where you know you want to call into some code that's somewhere else uh and it's exactly the same problem with with uh binaries on your machine like they're in different places in memory and then it's the linker's job to make sure that you call into the the right thing and dynamic linking is the same you know you want to call into the right dll or so object or whatever but uh you know once we move to the cloud it's like oh all of a sudden like we're writing code that for like single processes and then we call into other processes using like these network protocols and stuff and so what we're aiming to do in unison is that you'll just have the api of the thing that you're trying to call as a first class thing and it gets compiled with your program and then you simply tell the other location hey i want to run this code like you know here here's the actual hash of the api that i expect to be calling uh and it's all checked at compile time uh and so that whole linking issue uh we're hoping will just go away and so great so just to my understanding of this is is basically that the every expression is like a function that has holes you fill in and you can evaluate and they hash that as they make a hash of it so that when you link between things it's it's based on the implementation hash so that's sort of the version but it's very low level so things will always get the one that they were compiled against the ones where they said this is the hash i want to use no matter what happens later in time so the question then becomes i think for me was like well how do you update like i want to do a new version of something you know all right you update in a very first class way like for instance you could have a queue of you know versions of an api or you know some code that you want to run in a sim location and just have it listed on the queue and update itself by reading the next version off the queue in a very first class way i think john had raised a good point about how we can use um what have been some more arcane elements of type theory in the kind of in boots on ground in the cloud um speaking personally and i'm a systems person i'm not a pl person at all um but honestly algebraic types have changed the way i think of errors in the cloud the way i process that thanks to russ really and i having worked now with algebraic types in rust i i couldn't go back to actually dealing with errors any other way i think that the compiler is able to help you out so much and i wonder if there are other innovations like that i like obviously i could see that innovation brought to many more languages um i think you know if you were talking about you know your your wife working in python and how types would be a disaster for her work and maybe the the which i don't question or doubt um maybe the question that folks need to ask um is how important are errors to the code that i'm writing um because that's you know i there is it's kind of like music you know the difference between a an amateur musician and a professional musician is often their ability to do error handling and i had a drummer once tell me that that they that it required great error handling to be a professional drummer um and maybe that's the question we should be asking of these uh of uh as we are endeavoring to to write new code how important are those errors and i think if errors are important you personally you've got to have algebraic data types to help you out well certainly from the point of view of a developer who works in a statically typed language most of my time is spent understanding error messages working out what they mean and i think the either the python example um to to understand the errors i work with i've had to go through years of experience with types so um that that is not true i i believe of a python developer who who is encountering errors they're more for python user not a developer sure sorry john i was just no i i just felt like i should say something in favor yeah no you're absolutely right that's exactly my point it's not that i think that adding type will do hard types will do harm to python what i'm saying is if you the the barrier for entry to python should remain or i mean other language right doesn't have to be python today we will pile a bunch of stuff which makes entry level to python is hard tomorrow a new uh level a new language with a with a a small um entry barrier will come in but i'm saying there is a very clear usage for those languages for for for which you don't need a science degree in in in uh computer programming or computer science in order to be able to write the code and and to write an algorithm and see a result you don't you don't need it to get started but i think the longer you spend the more time in your life you spend dealing with runtime errors i think the more you're missing out on the opportunity uh like like brian suggested of of types and the um you talked about the speed of getting started you start to feel the pain of having to deal with the runtime errors after you've started and [Music] sorry go ahead i still think that like it just really matters right like if you just want to write a small map function or a reduced function something like that you just want to throw away and see what's going to happen like you don't care about types at that point and you know you if you're dealing with data especially like you don't know what's the you know the schema and so on and so on so it just makes perfect sense to you know work with a dynamic language but yeah if you're like working with a giant code base and need to like maintain layers of layers of abstractions and so on even like being able to actually like rely on some static analysis it's just becoming such a like core like requirement in that like thing so like i would say that like i would go with the aesthetically typed language just for the sake of being able to use some of those tools but also like when we're talking about type systems there's you know different entry barriers to you know different type systems like if we take a look java's type system is just more involved more variables maybe i mean that's what i would say personally from my personal opinion uh it requires a hierarchy like you just need to put you know the classes in certain ways in certain files and you know that just like so much overhead for some folks who are coming in but you know like in some languages types are just you know you can introduce types on the fly more easily you can compose them like more easily or you know you can just organize the code base without thinking too much about like you can introduce types maybe at the later time and so on so like there are there are different nuances here uh depending on the type system as well you mentioned the size of the code and saying that static types are very beneficial for large code bases i think the i think in the case where you have a program where when you run it that runs the whole program from beginning to end every every piece of code is is run in one go if it's small enough that that can happen or if it's simple enough that that can happen then the type system isn't really bringing you much the the compilation step doesn't bring much to developing that program but as soon as it gets beyond that that's where i think the benefit starts to come in even if it's even if it's sort of three or four branches and you have to try different different versions getting those runtime errors to actually be invoked uh is much harder than just seeing the errors in a compiler so yeah i completely agree it just relies also on like you know how likely that you will actually hit a runtime error right like it's more of like are you in a very self-contained situation and like just doing all the high level things or are you actually like impacting what's going on underlying like in the underlying stack so it just it again depends but you know this was not a really good answer sorry yeah that's a very good point i think john i i like that kind of rubric of it you know is it small enough to to uh to be able to run in one go i think there are other two other questions i would ask um the crystal ball that i've always wanted is this line of code that i'm about to write how long will it run how long will it be out in the world um is this something that will post date me um i have written code that i absolutely know will survive me long after my death um there and then there's also lots of code that is you know i'm gonna run this is an awk pipeline i'm gonna run this code once and i'm never gonna run it again um and if i could know that all of the time if we could know that all the time because i think we've all been surprised by code that has clearly survived longer than the original author intended will give them the benefit of the adopt and we will say if you knew that i would come up to this code eight years later and be debugging it i'm just going to assume you would have done a better job when you originally wrote it um and i i'm encouraging like rewrites like every other two years like that's literally my interview question when i'm interviewing with a company to the company are you doing rewrites like if you're not doing rewrites i will probably be very unhappy here because yes i've seen so much stuff like surviving their like timeline so that's interesting i mean that's an interesting point so you want to see stuff rewritten which i think is good and i understand that but there's also code that is so much deeper in the stack i mean we're using the bias as a metaphor lawyer we are all running code in our our computers that were that was written in the 80s um and we um you know that there is some code that is going to be really foundational that we don't want to rewrite and how do we kind of divide that and then how does that inform the programming language that we pick i think one of the aspects that we never talked about is like the diagnostics aspect right like um what we actually expose from the you know the runtime like especially like working on a language that didn't have really good error handling like i'm talking about go for a long time and um you know the other difficulty was that it's aesthetically you know linked like it's a static binary so you can't really like introspect at a later time you actually have to put the right bits before you know while you're building the binary so you can go and like introspect it in the you know production so that's also another aspect and i would like to you know hear some more opinions on this topic yeah this is great i just want to follow up on that like it it's uh we should definitely talk about tooling and what what do you think are important parts of the platforms and also um i i think you know like bill i don't know if you have like opinions on all of this and and and then the other like related one is i know there's a lot of folks in this conference who are like you know jvm users and i think earlier it was talked about that maybe it matters less than the support for platform independence so it'd be great to hear from some of you also to talk about you know the platform that is at the jbm and if that matters um this is bill let's see uh i was just thinking as far as static versus dynamic we we just we kind of did that same debate which is like the same cloud or no cloud i think um but uh what i think is interesting about cloud with static versus dynamic is will there will static types be used across network boundaries that's what i'm kind of curious about and the you know i've seen that tried before i think unison is an attempt to do that and uh gina actually we do away with that okay well why don't you maybe explain that right so you just deploy the code that you want to to have run so there's no actual uh api calls across the network boundary uh within unison you just call units and functions and they're running at a different location yeah but that's what i mean i think it's like rmi circa 1995. yeah or genie no it's nothing like that jeannie jeannie uh was say let's just assume there's a jbm everywhere and then you know the protocol is is actually a java like dynamically loaded java class and it just didn't take off people wanted to actually have talked it was heterogeneous and they wanted to talk xml at the time now json but anyway um that's what i'm kind of curious about is is the extent to which things like that where the language kind of i deploy it and it's actually on the network it will happen in the future um i think tooling is the other thing i mean it doesn't have to be language a lot of a lot of what could make this more high level is tooling yeah some more yaml tooling we'll do it [Laughter] so can i ask about yamal tooling uh because you know i it still it still boggles my mind that you know after 20 years of effort and best practices we all kind of descended to yamaha and what is it about uh the community because it's you know programming language is a social phenomenon right so i think it's very interesting to see that some of them succeed uh not because they're good but because they're popular and it's still mysterious what drives popularity so if you look at go obviously it has backing of google and python happened to be there when data science uh appeared and uh and so forth right so um but you know what does it say about the community or the forces driving it that we all know became yama programmers and uh i mean what do you think about that right why why not like i mean we have for instance baal is a type configuration language but nobody is talking about like putting doll instead of humble so i wonder what folks think about what does it portend for the future of the cloud that we all have to become yaml programmers now i i have opinions on yaml i i think first of all i would like to think good of of our community of the developers and the engineers so i want to blame every this yamal situation on a complete chance and not like this is the best we could do and and and i think it it is it is partly as you said popularity versus how good it is it's not necessarily the winner is the is the quality um and and i think that's one of those cases um someone back in the day decided that yamal is a nice markup language and has benefits on on on json and gave it a try next thing you know we're all yaml engineers right it's just it's just happened and and today when you build the cloud native tool and i will give you jfrog as an example we have a relatively new tool that was born into the yaml edge the jeffree pipelines and when we assessed uh which markup language or domain specific language our pipelines should be described in we decided on yaml just because it is what it is today right we will still probably do the main specific language and uh you will be able to write the same pipelines in in kotlin and groovy and what's not but in we started with yaml because this is what everybody expect from from us right now the only one which tried to go against this um this trend was was jenkins with their groovy dsl in pipelines and i think that they're both writing those pipelines and reading those pipelines are much more improved comparing to yaml but all you hear is how much people are hating it and how much people want something that they know which is yamal back so it's definitely a popularity contest by now and we just need to brace ourselves and wait until it's over hopefully that the next big thing will be a domain specific language and not another yet another horrible markup language it's like yet and yeah age something something yep anybody else's opinions of this i have opinions as well but many people have opinions yeah i just want to speak to the instrumentation point those broader projects it's a very important point um the in terms of the ability to actually um instrument programs and software to figure out what they're doing something that's obviously been very near and dear to my heart so i years ago developed something called the trace that allows us to instrument um running systems it's been something i can't live without um i i think that it is while we were able to add some support for dynamic languages the dynamic language problem is really really hard from an instrumentation perspective and it's um a when you have a static language um that is say generating a static binary there's a lot more you can go do uh and one of the things that i would want to call on on all languages to do russ has actually done a very good job of this um the idea of having debug information in your binary is not in conflict with having an optimized binary so if we can have an optimized binary that we deliver that has a a rich dwarf section i don't love dwarf but dwarf is very rich um that fully describes how tooling can understand that binary we can build really rich tooling on top of it and that as as basic as that is it is not something that has permeated and actually rust is the exception and that it is able to generate an optimized binary with dwarf information in it uh which i've been very grateful for but i think anyone developing a programming language that debugging information is really essential to build the kind of tooling that jan was mentioning is is the problem programming languages themselves should we be using data for a lot of this information rather than executable code that that modifies global mutable state i think yes no like i i think you know like on the one hand i think there's patterns you can use in every programming language right but on the other hand i think there's some support that is good like for example async programming is so hard and like if you look at the jvm for example like it's been built and all of the ides and everything have been built with kind of like single threaded execution in mind right where like basically everything is and that's how people you know debug things and so be great to see a shift in paradigm to like kind of really embrace really good tooling in terms of like debugging uh async and distributed programs and you know you have tracing distributed tracing and like uh good concurrent support and and some of that uh does have to do with the the programming language and the platform there's also like a bunch of you know building blocks needs to be done like um you know i spent last um two years before switching to databases and now i'm back in the same area in distributed tracing and you know like um the the way that you propagate the traces for example in the runtime not i'm not even talking about you know what you do on the wire i'm talking about like how you propagate things on the in the runtime is not like you know there's no consensus on it like you know in in java there is all these like different um you know propagation libraries that relies on different you know some of them are like using tread local some of them are doing their own thing some of them are like explicit libraries that you actually passed you know contacts here and there so like i think that we just really need to sit down as the industry and like acknowledge that this is an issue and like um set the you know the foundational layers uh because right now everything is kind of like a patched like we're just enabling couple of cases if you do all of this 100 things correctly and you know nobody really has time or nobody wants to invest that much of time to you know get that like little value but you know everything was just the building blocks were there it would be could have been so much easier um one of the things that i like about google was the rpc stack we were using gr we were using grp we were using i mean they are right now i'm not working at google um is this common foundational block and you know the context propagation is using this common thing so you know everybody knows that you know they can rely on that like incoming context to take a look at some of those things so you know just kind of like making larger changes like you know adding distributed traces or whatever just so easy because that foundational building block is there uh if this is a pause i have another subject i just kind of curious one of the problems i've seen in uh enterprise software is it when it gets the people have problems on the jvm with uh 20 you know 30 second garbage collection pauses and and sockets timing out um like rust i think you wouldn't have that i'm just kind of curious like i know the garbage collectors keep getting better to try to catch up but it's always like a you know a race between these two to what extent is that an issue like sorry that is a programming language question that's because like russ makes you say when you're going to free things right java does not just i was curious if anybody had an opinion about that how important that is i mean i definitely have an opinion on it i was gonna actually i was gonna wait for evan to give his opinion on it because i think i could give my opinion to you but brian go ahead well i actually so i i'm actually you know what i'm going to give evan's opinion on it is what i'm going to do because i i saw what scale by the bay 2018 right evan where you had your presentation and it was basically some very sophisticated tricks that evan was using to like how can i just at total war with the gc to try to generate uh high performance and the the amount of work that was required cognitive work um felt so much greater than the work required to simply uh indicate to the compiler when memory was being used and when it wasn't being used um that i think if you there's definitely a point where gc is clearly a win at some level it is clearly not a win at some other level and i think it's it's tough when you have a a system that kind of starts at one point and drifts um it to the point where actually gc is no longer a win and it would be much wiser to to actually manually manage the heap with a type safe language memory safe language like rust yeah and i'm seeing like that shift is just really you know making the source code really terrible if you're like if you started with a garbage collected language you know like just basically rely on a lot of like um self-management type of tricks and you know things are becoming unreliable unreadable especially if you're on boarding a new person like just kind of like explaining like hey this is the memory management tricks and like just don't use like this as a regular like regular package or whatever right like just you have to that just like creates a lot of like uh problems and um the shift is like more i think common than what people think especially like when projects are starting small tons of you know stuff related to memory just like very underestimated or just you know you definitely don't care but like you as i'm telling you like rewriting maybe is a good solution to all of these problems but you know that's also not happening way too too often uh so yeah um i i it's almost like you know your entire model of like your program is becoming more of like you thinking about the memory management and you know coordinating the tricks around it and so on so yeah just uh to follow uh thanks uh did we lose that i think dc fine you know and um you you know it takes care of the most common cases but i think more and more as the volume of data expands you know and people do push down a lot more like i was doing database stuff you know and as as people push the envelope more and you know cpus are not getting faster you'll find that you know it becomes people have to start looking like beyond and recognize the limits of what they have and and that's true of gc as well and find paradigm to work great things that was interesting folks i just want to know that we have three minutes left on the clock after that uh we all will go to a different zoom i will post a link momentarily and i'll let you guys i'll tell you guys when to click it but you know maybe we'll just use this kind of few remaining minutes maybe everybody can make a very short closing statement for this panel for this segment uh kind of where what are you gonna do about the cloud in the next year let's say very simple like like where do you kind of place your bets what's exciting or like what are you gonna do about the cloud in the next you know 12 months before next scale by the way and we're going to check next year whether you did this or not 30 seconds each let's just start uh uh with bill i was afraid you're gonna start with me i don't know basically i i'm actually stuck uh because it's pandemic you know things are different now and uh so i'm i'm i'm more in the in the uh scholar three programming uh trying to figure out how to explain it mode so maybe not so much with the cloud that's that's uh that's what i'm focused on is all the new features in scholar three and the transition the transition uh from scholar 2 to scholar 3. and scala tests students as well style tests already runs on dottie on scholar 3. it's called dottie was the name of the project scholar 3 is what it'll be called when it's released supposed to come out rc1 in december and uh you know it's scala so it's like scala was popular for a lot of things in the cloud microservices and whatnot so so you're ready for the cloud you're already done good good good john how about you um i i'm i don't know what to say i'm going to keep on using cloud services i'm uh it's the future still nothing's changed fury your answer to the cloud in a way can you construe it as an answer fury uh i mean not in 30 seconds i can't but um yeah i have i have an interest in um evolving ecosystems of um libraries and published artifacts and um yeah they're the clouds which are all cloud things yeah the the cloud is a a necessary aspect of that okay or you're muted alexi how about you you're next year for the cloud oh hey um i i don't i mean there's been so many good thoughts it's really hard to like uh summarize it you know but but just uh hey i i think it's going to be like you know really really interesting we'll see a lot of innovation in the you know in the coming you know years that's it all right uh jana are you gonna rewrite aws well that's sort of my ten percent right now to be honest um but um actually um you know i'm more invested in observability like diagnostic side of the things i do believe that that's just like a you know urgent thing that we should figure out um we're talking about languages but if you think about the whole stack like in the complexity and like the growing complexity it's just like a you know you have to give users like some sort of visibility right like otherwise none of this thing is gonna scale even engineers working on some of these systems don't understand the systems well so i do believe that tons of like language work will be also like focused on this in the long shot um and i hope that i'm right thank you uh brian you're next year for the clouds yeah so uh boy our next year's gonna be a wild one we've got a lot of software and hardware coming um the uh the cloud is way deeper than you might think um we've got a lot of firmware coming and rust um we've got a de novo operating system coming in rust we've got a lot of stuff coming that'll all be open source in the next year which will be fun um the what i want to see though this is not going to be what i'm going to be doing but what i want to see in the cloud there is far too much bash load-bearing bash in the cloud and bash is garbage from a programming language perspective it's it is a collective embarrassment that we don't have something that is that does bash but better um so i would anyone who's interested in programming languages and systems programming there is a real opportunity here for a scripting language but one that is that is type safe or certainly not the absolute menace to society that bashes even i i laud batch's contribution to humanity but it's time to replace it that's what i have to say no i'm not actually embedded right exactly thank you brian so the destruction of bash for the next year roonar yeah so i'm going to be focusing on getting unison the programming language to uh public beta and so sometime early next year and hopefully by the end of next year we'll have a unison library for deploying unison programs to the cloud thank you ror william what's new for you next year for the cloud uh currently i'm very like i work a lot with aws services and i'm interested to learn more about them and my goal is uh also to learn uh unison get started uh learning it because i saw that it is easier uh less effort to deploy and like uh i also like writing scala i will also do both of them so yeah thank you yeah so we got the first user for you renault here and borrow what's in the cloud for you for the next year yeah so in terms of programming languages in the cloud i don't expect a lot of changes i think the containerization is here with us so it will be go all the way uh more and more go running in more and more containers in cloud in general though i i do expect to see a shift i don't know if like a year or five years perspective but i think we are looking at next frontier which is um edge edge computing cloud computing and distribution to devices and iot is kind of a already has a bad reputation so we need to rebrand it as we usually do stuff that gets bad reputation so aging for computing is the next big thing they will still run containers so it will still be all go in the end of the day but um i think this is where the cloud is going thank you i think the agent fog actually are important parts of the cloud we didn't touch but that's that's certainly coming and we have this topic of a iot mentioned earlier this morning from vp of innovation bosch right so the cloud has different forms and some of them is programmed in the unspeakable unfathomable ways we don't even imagine because they're so small so big so this is this is great thank you guys you