Hi everyone. My name is Patrick you. And for today's episode, I have a first in Beyond cutting history because I had three guests on their all software Engineers over a bowl of come and really excited about the go programming language, which is exactly what we cover this episode. Honestly, yeah, her house from the baker room, and Kevin from the brook, I'll put the links to their social in description below. And with that being said, enjoy the episode.
Welcome to Beyond coding, a dive into the world of successful people in IIT from your sponsors Z, Bia, creating digital leaders. Here's your host, Patrick akhil. People just contacting us although we hear you have a new team and I'm like, yeah, but the caveat is with doing it in go-go-go fast, especially people that joined others team. I had a lot of contact with both. I'm gonna try to get into my tea because I knew they were going to switch teams as well. Yeah.
But they were like a bit intimidated I guess by what we're doing and then eventually I'd a heard Adonis was willing to go to work. I had know that that is interesting. How's the house? The kind of internal politics than because you obviously still a teammate. A from someone else basically right? Yeah me and Kevin started as a young professionals which is a good which is a kind of a traineeship that will come has and idea is that you switched
him after a year. So like when you join a team as young professional people will know that you will eventually leave already. So yeah, it's taken into account. Nice. Nice and young professional. That's like straight out of University. I started University. Okay. You might have like 22 years of experience. Yeah. Yeah, so I think you had some Community for as well, just not
know, professional experience. No, yeah, okay, so there it, but they're not called graduate programs, or like training. Not, it's like nah, they tried to it. Kind of, is we try to stay away from the terminology, I think. Yeah. It's also not that there's nothing that's being pushed towards you. Like, oh, you have to go on this trip or you have to go to do this? It's like more of a tool box you can use like, yeah, you can. Yeah.
I mean, this is a difficult one marketing wise because obviously you have a lot of traineeships and me personally, initially, I was also like a professional program. Sounds interesting because there's If it's right, however, I just want to be in a team and I want to contribute my part. I don't want to like feel like an apprentice or something because Zack I learned something for a reason. Yeah. And they did sell me because initially I was like, hey, can we do other stuff?
And I'm like, nah, you should join type your program just like alright let's do it and yeah, okay, that's a good decision. Yeah, yeah, the thing I don't like about those traineeships is kind of your growth is kind of static, I guess if you grow exponentially, nothing else changes prizes. You and the traineeship is still stuck for like two years. If you want to leave early, you got to pay a lump sum of money because they invested here, that's kind of poopy.
Yeah, that's not the case. Welcome. I think that's because they try to sell it as like a talent program. I also see like, a lot of the people that are going very fast, they started in the program. Yeah, great and honest, you had actually, you had go experience before you join Bullock on, right, Galahad a little. I did some things on the on the side while I was actually being
an engineering manager. Yeah, so my experience was literally how I did some stuff in the side and Send my CV to Bull engineering manager, and go developer. Yeah, that's how I ended up here. Nice, and yes, I joined a go team. Okay. So it was also one of the few go teams at that point. That was involved, calm. And then now we cut quite a couple of teams. Actually, what's the, what's the team amount like the scale of the operation? In total.
I mean yeah, like how many think we are at like 190 teams right now? Yeah, bottle comes kills Vulcan come of which go teams would probably be obligate between 5 and 10. Yeah, around antennas. Yeah, so then how many people in team like five or marriage or an average I guess about five? Yeah, that's right. If I was developers. Yeah, of course. Other people that's good. As if you look at the things that have been developed like actual services that run 24/7.
That's I can 5 to 10 teams and then 20 30 people. Yeah, but if you look at the money, That have been written and Ali used tried to company liked by everybody. Then you go up to hundreds of people that use all the systems and applications and see how eyes have been written. Yeah, that's a lot. And the main, the main language is still javo like a jvm language heavy, I'm here.
Yeah. God sends began quite quite OK, be more correct to say the jvm and because I think kotlin is could be the predominant one, these days? You just think? Yeah. And a lot of streaming applications used to be Scala, but I don't think we really do scholar anymore. Yeah, no. Yeah. Interesting involved because teams are can sort of decide to use scholar, was there for some point? But it's sort of died died down, according to sort of came, just came and replaced it. Yeah, yeah.
Just cool. And The Best of Both Worlds Trend in our Java and cold and then in Scotland. Yeah. I mean the record is already already started. So I'm just going to welcome you guys. Welcome guys, thank you. We've already been chatting. I need to see where we where we actually studying so we might start here, who knows? But Brought you all together. Actually, we came all together to talk about go and kind of how they introduce or introducing go into your organization the first place.
But let's start with why go and why would someone introduced go as a programming language within their organization? What problem would go solve? That other languages done. It's gonna throw in the Middle. Where was the pick it up? Go for it. Yeah I guess there's a in. This is a couple of angles you could look this from. Yeah one buddy would be just different people. So I think go comes with quite a different sort of view on things. A lot of Simplicity in the
community. A lot of you know you want you will find the thought. Leaders are like Rob Pike and so really I'm putting on on Simplicity so you'll find the language itself. Be very simple. Yeah. And a lot of people might frown on that and say go but go doesn't have exceptions and go doesn't have you know generics now. But and but then I think you missed the point because you know it's all about Simplicity and and that there's a thing of scale I guess so and development process scale.
Perhaps because go was invented, I guess in Google to replace their slow-building C++ systems. Yeah. And as rope, I could say, you know, you could say go was invented while watching Bolt Builder. Run. Yeah, and so for us, I think that's a big part for me, is how fast it builds and runs. Yeah. And runs in your, you'll see, I pipeline. Yeah. So we speed and simplicity we say Simplicity is then on the opposite side elegant and is it then opinion-based?
What simple as a more elegant is because those are kind of a, I think simple, as in it, fits in your head and a bit more like see But also I'm not not a lot of abstractions language itself, for instance, doesn't have implementation inheritance. Yeah, an interface inheritance, which people also far from now on, you know, a lot of people overuse inheritance as well but I think that's part of the power of go. You can sort of read the code and understand and you can throw
it at Young developers. I guess he experienced ones and it should be okay. Whereas complex language like It's color, you'll be in trouble if you do that. Yeah, so yeah Simplicity from a just I mean, if I think from engineering managers perspective and I want to help the team's go is a good starting point. I think it's interesting when you said simple because I guess one of the things that's also really important winning goal is the you prepare for the reader
over the writer. Yeah, so while writing code, you might write more code. If I take a bit longer, but that does come with the benefit that the reader has a better time or easier time to just go over it. It. Yeah, exactly. I love reading go code at the if it's clean, right? I hear a lot of people saying on go. You can only do it one way. I don't think that's true. You can still do a lot of nasty spell but good readable. Go code is just easy to browse
through. You see what happens compared to other languages. I felt like, I mean, xhosa, how you came from? Cortland Kevin always says, you're more of a fan of cotton back in the day. Yeah. I mean I'm still a fan of like he has the whole streaming API. Hi, that you have? And yeah, the readability I guess if the covid and I think now that I've been doing go for one of your, I don't think the readability is as good anymore because I feel like go code which nicer. Yeah, it's simpler.
And what you said that there is like one way to do it. I guess there was one best way but is that a bad thing? You know like these everybody writes it in the same way. So it's it's really what else I really like is the white, how do I sell it to other? People is like the Synergy with our systems because we're doing a big on-prem to Cloud migration. Go to come.
Yeah, and everything is running on Docker, kubernetes Prometheus, all these things that are written in go is to so all those those client libraries that you use are like natively written in go. And it just, it just works so nice together. Yeah, that's a and also to start at times are nice. Yeah. Compared to like a string would application. Yeah. So those usually get people excited enough to at least try it.
Yeah. So we just the external libraries that you would use already written in go as well. Yeah. Yeah, so the animals are the standard library has a lot of stuff that you would lose, which is libraries for in different things like Json, parsing exists be service. Yeah. Yeah. And I mean hopefully throughout the years that's kind of the promise, right? That go. You also use it if you want
software. That is healthy over a longer period of time and they promised that backwards compatibility. Yeah. And in the standard Library there as well. Yeah, that's also actually one of the things that's listed on our y, go page and Bowl. Yeah. Is if you don't want to have those. And changes so often. Yeah, because of the backward, compatibility promise, you know, that you're not going to upgrade to the next Big Spring framework, release and have lots of breaking changes.
Yeah, which really saves a lot of time. I think I can imagine. So every night, one of the important things with this backwards, compatibility promise, is that even though it's backwards compatible, so you won't get any breaking changes, which might be better, right? You might change an API for the better after experience of having the old use the old API. I also have a lot of important performance improvements because obviously go is what 10 years old, 11 years old.
So they might not have the most advanced garbage collector or they might not have the most advanced Escape analysis. Yeah. But those things are being improved on continuously, so we have seen within the organization after every major release like 1.15, 1.16. 1.17 that we have 20% CPU Improvement. 20% memory usage Improvement. Yeah, the only thing you did was your, we compiled it. Yeah.
And it was compiled in 3 seconds, you redeploy their a swap, the binary, Suddenly you can't stop instantaneous. Yeah, that makes sense. I mean, so you guys are all from bull.com. I don't think we've given an introduction. So for the audience that is all right. Maybe how side of Holland who wants to give an introduction in World football? The calm does. Those there's a balaclava used to be a big web shop and we are moving towards being a big
retail Tech platform. Yeah. I guess from our size and I wish you could compare to something like what Amazon does. Yeah. But locally in the Netherlands Belgium and the French part of Belgium. Yeah, and if we talk about the scale of the operations just over 100 million products, I think about 50 million Partners now, that that sell products on our platform Yeah. It's $50. Okay, it's not that much. We are working with just over a thousand Engineers now I think. Yeah.
I think those are important numbers. Yeah, I love the stats in synopsis. That way. Yeah, I get that in the pull the cam. You, you told me before the show you have about five teams working on go as well. Yeah, yeah, it's been scaling up over the past years. Yeah. Yeah. But now we're about five and also the biggest part of our landscape like, the, the webshop parts, they're slowly adopting as well, in a new layer. Yeah.
So it's getting some more and all the other adopting, a also, because of the Simplicity and kind of synergy with the applications that you're using. I think that's reason I haven't really spoken to them. Yeah, so if you look at the webshop part where they're trying to introduce goal with the basically rewriting it in a big way with the the simple shop where they will use graphql predominantly and You can
imagine, right? Is at the scale that we're at will have a lot of services that are either a bit more Legacy that don't. I don't have a lot of improvements renovation anymore. Yeah. But they still need to be in this graph ql API. Yeah. So what they're trying to do is to have a sort of an adapter in front of those systems that aren't able to include graphql server natively in it.
It is what go makes quite easy. Have a simple binary does not use a lot of resources and it's straightforward to develop over yet. Another complete application that's over. Yeah. Is it makes sense? Did you also I started with go, is kind of my first programming language more in the adult workspace. I did some PHP and some python at University, but go is really where I started first GitHub.
You work on the back end, this is in go, okay, Push It All That Jazz was in go kind of the basics and for me it was, it was pretty simple to pick up because there's not a lot of complexity there, right? I can only do so much and then go routines, for example and channels. I just push that back. So I got the basics down first and then you actually dive into Those were kind of the only Advanced topics there. I mean, testing the testing is
fairly easy. Once you get the hang of it as well, now you have generics and more fuzzy testing stuff like that. But for me, it was very simple to pick up, very simple to understand what other people are actually doing and actually focus on solving the problems, right? Because the technical tools that we choose, even the programming languages, they all should solve the problem. That's why I think it's
interesting. You say Elegance versus Simplicity because Elegance to me is very opinionated Dated, what is elegant for you might be elegant or not. Elegant for exactly. And I think that's also what going away solved is all, you know, you know, our developers can sometimes, you know, go on and on about it. Should I put the bracket here and this is really a good elegant or this and go came out those days with go format and it just sort of solved that all thing.
Yeah, you just format your code in, you don't talk about that and exactly talk about the more important things. I think, the only downside we go from twitch, talk about is a nobody loves it. Everybody loves it, but nobody loves it. Because it's opinionated. Yeah, that's the beauty, right? You don't have a discussion, you just use go fund even if you hate it, that's it. Yeah, but then still. So I've been a bit more online since doing this podcast, a bit more on Twitter.
And for me, that's true camps, right? People that hate go don't like it. Don't like the error handling. Don't like the garbage collection. Have a lot of stuff going against it, or people that love it. Love the Elegance or Simplicity and see the Elegance in there. Yeah love the readability maintainability longevity stuff like that. That there's, there's hardly any Middle Ground. What do you think? Would be kind of reasons against go in that?
And I think, I mean if I take it typical spring application. Yeah. What I don't like about it is that I have this big framework and I guess I'm, I'm someone that likes to understand what's going on. Yeah, do it and it's very opaque and yes, it's easy to build a prototype, but if you run it in production and something goes wrong, then you really have to understand quite a lot of things and then it becomes complex. So, on the first entry it seems
very easy. Oh, I can just build this in this in this, and it's really easy. And I just had this annotation and ago, you really have to go code that, but in the end, the go program, you understand the other one. You don't? Yeah. Until so, in a way for me, it's just where the complexity lies. You just moving it from the one side to the other and I guess yeah. Some people like, the more abstracted things just make it easy for me. Yeah.
Other people like like us perhaps like the I suffer for a while you understand and you know what's going on? Yeah, and maybe it's also a control issue. I am made might be a control freak little bit in terms of my coat. I like to know what's running underneath and what's going on and what do I do? If something breaks. Yeah, so and some people may be just fine with I trust the developers of this other
framework. Yeah, it's also when I had about like three years of experience with Springwood before I like really understood like what was happening? I really started diving. Into like internals and would go like within a month, I was running my first services in prediction and feeling completely confident with it and what everything was doing it. It's were just like yeah, I guess that's a Simplicity but it's it's like there is no magic. Yeah, if you will.
I mean, you were also a better engineer because of that history in Java, right? Oh yeah, of course. Yeah. I know. I still, I still like spring a lot. Yeah, it's just that it took me a long time to really understand what was happening and I guess. Yeah, go didn't have that, like, learning curve for me, I guess. Yeah. Yeah I think internally you're talking about the Notifier service right in our team that you wrote right? Yeah so it's still running. Yeah yeah something I've never
change. Let's get I've been there for in the Steam for one and a half year in my first week. I hadn't touched go before I wrote the service and it's still running, so really getting plastered. You for the update? Yeah, it's only gonna Fester because if new new Go versions, but yeah, it's not doing it all this. Just like receiving a message and spreading it over multiple topics. But yeah, I mean, doesn't have to do. It doesn't have to be. Exactly.
I think there's also a efficiencies efficiency thing applies. Some people just like more efficient things, I think perhaps more prone to premature optimization as well. But I like the fact that I can run a Go app and it consumes 20, 20 20 megabytes of memory. Yeah, versus if you have to run a Java jvm you already in the GB. Yeah. The bins at least for image size and these kind of things.
So I mean Doesn't really matter. But for me, it's just still nice to the lightweightness of it. We had some point, it matters, right? Because you have Cloud costs and you pay for what you use all those on. If you use more memory, you also end up paying more down the line. Especially also, if you have systems like in ball, we have also a platform team that develops systems for all the teams. Yeah. And if you have a heavy system that adds a little bit for every team.
Yeah and then it really matters because you can save a lot of money actually. Yeah, if we drill down to one of the language specifics with, for example, it's either error handling. Which I see people hate or love or people say all the garbage collection is garbage right. Russ does a way better. That's usually the comparison is to the fastest one that it has and that is rust. You can tweak whatever not and screw that you want and then all of a sudden go looks worse in comparison.
Yeah so Russ is interesting one day because it speaks to some of those things but it's I think the learning curve This is really tough Everett idea. Or it takes you. I mean, if you compare you go, you'll be productive probably within a week. Yeah. Whereas with rust, you fight with the borrow checker, for a couple of months, I've no. And if you survive, you know, if your self-esteem survives it, then you, then you start to love
rust. Yeah. And then it really works for you because it's a really powerful language and in that sense rust is very complex, but very efficient again. Yeah, just I want step extra towards the See ya. So in that way I wouldn't recommend for instance, Russ to everyone. Except you really if you really want to have a performance system. Yeah, so there is a use case involved income for instance, we we write this rewrote a service in the recommendations system area.
Yeah. And the developer, their claims 100x Improvement in speed from loading, some II models or something, Canto is confirmed. I can imagine that it can be true because you have Garbage collection and these things. So I think go in that sense. It's nice, it's easy to learn, it's more efficient, probably for most things in Java. Yeah, but it still has to garbage collector, that makes it easier for you and it's just a nice go to language, I think. Yeah, yeah. I don't know why.
So, I see more adoption, right? Also, both from developers as well as organizations. But if you lay out the things that, I mean, we just spoke about if I build a piece of software, what like Five years ago and it's still running and it only gets efficient more efficient by updating it. I don't have any troubles. People can come in a team and be
productive within a week, right? No month onboarding just because the language only maybe organizational specifics but those are hard to absorb then go seems like a pretty good choice from an organizational standpoint know I think in theory it looks very nice but yeah, if you look at say you've got for example within board cam, we've got the off Highway, they are working on it heavily to make it even driven. Yeah. They've asked me. Hey do you want to join? But I don't know.
I really want to do go, a lot of reasons obviously. Yeah. So I looked at it, I was like, hey, I wanted to go but I don't think it's a good idea to now introduce goal while we're rewriting a system within that part of the organization because you've got five, teams are all very good in the jvm world, so why take that away? You still have business value, delivered to the users. Then making a technological choice because you like such a language, or you want something from your own gain?
Yeah, I not be so good. But I think that holds for every language. Yeah. I agree. I fully agree that that is an issue that every language. That's right. Shouldn't be ah I want to use go so let's use going exist. Yeah 30 people that already do with that. Yeah, I know then you get like a mishmash of Technologies and then you have way too much overhead. Right. It's hard to be effective when that when that overhead is there. The funny thing is though that within that sort of the
organization ghost or popped up? Yeah so I've been talking to a couple of those engineers and they said hey we had to write a load test until it just had to do some more testing. We wrote it in go. Yeah, I've already we also wrote it in Java to compare, okay. So go still slips in even though I wasn't there trying to push it, it still happened. It's just you said, we were talking it go when the contest there. I think depends on what you see
is winning. So they both achieves the same output because it was about publishing messages to a topic. Yeah. But right, if the one is being built in a day, and the other one is built in two days and they have the same output, which one wins. If the, one uses 200 megabytes of RAM and the other 100, Which almonds think it's difficult to compare them back to fact. Yeah. Yeah, I think because a lot of systems already, let's say let's give the jvm example.
If a lot of systems already built-in jvm languages companies will still higher for jvm Developers for sure. So then how do you even as a new programming language? How do you fit in between? Is it kind of by solving those isolated problems a bit differently and then comparing it, and maybe making that extra step and implementing it in a different language, I guess. If you really want to make a point, you have to compare apples to apples.
Yeah, will be completely rewriting one application and finding the axis. They want to compare them to. Yeah, I think if you look at Baldwin calm, the way it started to manifest itself is with the smaller things, right? We have systems that run in the cloud and on-premise and we need to access those from machines. So of course you have user authentication. People didn't want to constantly copy their tokens and put them into the header.
So somebody wrote a script they call it Rock sir, the guy left I'm now to maintain I love it with non-rigid, almost, but everybody uses Proctor? Nobody Knows It Go, but everybody uses and it works. It's simple to distribute its own home brewing, everything. So that way it goes into the organization and then somebody sees it, they want to contribute, hey, it's an NGO. And then it takes another. It takes a life on its own and I more tools. Pop up. Yeah. Yeah. But it will never be fast,
right? It's that's a very slow burn of kind of. Yeah, definitely people excited. Yeah, so I don't I also think if you look at The way go has been going in able to come. It has been going slow in the beginning. But as more people come and more people see and get certain people that are really into talking about it because of course, you need the right people for that. Yeah, it really goes like Sky High. We've seen. We seem quite a bit of momentum. Yeah.
Changing the recent couple of months could also be. Well, we'd also be because we started the initiative called torque which is then we don't want to call it a framework, but it's It's a toolkit and go. We want want to trade towards the light lightweightness? Yeah, side more, but that helps people to bootstrap getting a service up. Okay, I mean even with go and its Simplicity takes is still takes quite a couple of days to get a service in the cloud right
there. Kind of a lot of stuff that you have to bootstrap. That's not really interesting. Maybe it's interesting the first time and after that, you know, it's just work. Yeah. So torques, aim is to get people. In the clouds quickly. And they don't want to think, too much about how do you set it up. I just want to run my service and then build the business logic. So I think that also added a lot
of momentum. And I wanted to say with structures, of course also, very example of where go shines because Proctor is a go online to. Yeah, and go, the nice thing about goes it compiles to to static binary, right? Everything is included. No, no, external C. Re so it's really simple to deploy. You can literally just send someone to fall and they just run the tool.
Yeah. So I think if we talking about why going organization, if you're going to write some online tools to make developers lives easier, it must be ago. I think. Yeah, you could say, yes, you can also write it in Rust, but even, even in that to thrust is not as easy because yes, you can compile with a muzzle. See library. And then you also have a static library, but then you have to go.
Do all that work. Yeah, let's go is just defaults and it comes across compiles and to number of platforms, all the ones that you would expect and it's just really easy, you know, I think also the cross compilation and the ease of course completion is one of the been at the Bund benefits because we recently started adopting the new arm-based Macbook support come and I got a hold of one. So then I started to compile our code or services that worked.
But when I started to compile it and put it on, keeping Eddie's, which runs on a different architecture it Didn't anything I had to do was change in environment variable. Then I worked. We'd like the funny thing is that everything was already prepared in the systems that we use, because it's the go art environment variable. Yeah, but it didn't work. So super confused. Okay, we've set up this cross compilation. I've got a different architecture.
Why is it not cross compiling? Yeah, apparently there was always in a book for the past two years because instead of go Arch, it was garch right, the whole was missing and I looked at our code base, they don't want to close in are currently working in and fixed it. That's all. But then I looked at the code base where I came from so many Raj, because the engineer that started kosis team came from your eyes, the same bug there for years, it's the same make
file is copied over. Yeah, yeah, I mean that always slips in, right. But to be able to deploy your code anywhere and it just runs right. Even by simple as changing environment variable, it is very powerful because I see organizations for some reason. I still don't know why switching from one cloud provider to the other getting to that first cloud provider is already at Task in and of itself, right? And then they decide to switch
to a different one. And I'm like, man, Microsoft must have paid them like a lot of money. Like there's a good, there's a good deal there somewhere but then if you are running on go right, where you can just deploy it to a different Cloud environment. That seems like a big plus to me as well.
Now I mean the the simplest thing I've seen which is very powerful, the one we're using at my current project running on Google cloud and we have a cloud function which is an isolated piece of software that runs And it's an image resizer. So whenever we have a new image, it picks up that image and it splits it up and it, you have 10 different sizes, right? Which is very nice. If you have a mobile, you tablet. What?
What have you? If you look at the piece of code, it is not a lot but it actually does a lot of stuff, right? Because image resizing if you figure it out, it's easy. But from the sound of it, it doesn't sound that easy yet. That clown function has been running. We only update exactly, like your guys stuff and that's it. I you don't even have to To look or think about anymore. You just runs solve the memory leak because one of the writers wasn't close one of the readers
wasn't close. But that was the only thing in classic. Exactly. And then it runs again. But even what you say, honest in our current project we have kind of a framework. It's open source but you can use an annotation and you would spin up. Lots of the boiler plate that goes into an HTTP service that will be generated for you.
That is the only thing where I'm like, okay that is kind of boilerplate and that that might be repetitive right because Part is quite verbose and would be verbose over multiple services and so maybe that's kind of the the boilerplate more the verbose notes that people complaining about. Yeah. But then again you do see what happens when you actually when you write that yourself. Yeah. Yeah. I guess that's the thing about goes of robustness.
Yeah, it also bothers me in some sense, but you have to make peace with their in front of my eyes. It's a compromiser. Yeah, exactly. It actually helps me Throat Coat away as well, because you it depresses, you write a lot of duplicates tough sometimes, but it's also like because everything is so verbose, I feel happy when I can draw files away. Yeah, yeah, interesting enough sagely to go, dude. Go go and clean up basically. Yeah.
It's like a fun task in itself which actually, we generics will become less again, I guess because it will be less duplication. Yeah, that's the, I mean so I've had new people or people that are new within go, right? And then we write a function that is like 95%. And is the same except for some variables, some specifics in there. Like man in Java, this would be the same by. We would have one function for two different use cases and I'm like, but they're inherently
different, right? This might be a bit more code. They are actually different. I think generics are probably going to solve part of that if people are trying to use them for that. But yeah, that's usually the struggle I have where I think something is simple right to use cases. It's very specified, which eats which use case you're using. It's easy to follow that way as well. It is more code, right? It's always going to be more code because obviously you have
to use cases. 95% is going to be the same and from the other standpoint it is more code. Therefore, it is kind of worse because this could have been solved simpler more, elegant less code. Let's maintainability that you see the word I heard, and I'm like, but they're inherently different, right? So that argument I don't think you can resolve that. Yeah, I think there's an interesting one because I mean, there's the dry put Principal writes, the and repeat yourself. Yeah.
And I think it's maybe overvalued or something because I mean that's true as long as you're not addressing separate concerns, right? Yeah. If you address stupid concerns and you use the dry principle to say, but yeah, it must be the same piece of code just because it sort of looks looks the same. They know what you're really doing is, you're tying two systems together, that's going to break together if you make it.
Make a change. Yeah, so yeah, I guess that's also where go leans a bit more towards the Unix Unix, philosophy of code generation rather than, you know, obstruction solving everything through abstraction. Yeah. So it is a different way of solving it, I guess. So that's also where I guess it's a bit of a different mindset, or a different. Yeah, way of doing things. Yeah, you agree. Either a barrier or people flock to it. So, yeah, I think the dry dogmatic is bad.
Basically, if I still have Functions and their complete opposite sides of the code base. I would keep those as separate functions. Instead of introducing like a, you tell that solves both and then people like, but I wrote it like the third or fourth time. Now, I'm like maybe now it's a bit more valid. But before that, right, like you wouldn't really do that, right? So it's figuring out distractions, right apps that you wrote them. Yeah. Like introduce him straight
away. Exactly. Right. I think go leans towards more or less premature optimization in that way as well. At least from an engineering mindset. That's what I feel like can be difficult. It's always gonna be difficult. It doesn't. So I don't think it's a silver bullet, right? I don't think we're going to have a silver bullet. There's always going to be trade-offs.
People are very opinionated specially in this in this program, its phase wherein, so there's always going to be trade-offs that having said I've done kotlin. I've done note on the back ends off and go I'm very fond of the kind of Simplicity and getting very productive real quick, right? If I switch Team, I don't know how often you guys switch teams, but if you switch a team and they still do go, you're probably up and running within a
few days. Yeah. Like a bowl of come as well because we've got so little teams. They look at each other's code bases. Yeah. So most Coco bases. Look the same. And the way we're now introducing torque like on has already said it improves that as well. So we create small helper function sometimes or bigger things. So the integration platform guess is one of the most important parts that we cater for, right? So getting a logger within the ball. Come ecosystem.
You need to connect to the corrector services and apis to get it all hooked up. Yeah logger metrics, all the kind of things. Yeah. Yeah it makes sense. What are you guys is? Take on on generics. I mean, it's now it's end of March, it's been here for maybe like a week or two, you guys played around with it. Played around with it when I when I switch to go as a programming language in the beginning was like I miss it a lot and now I don't know. I don't really feel like I need it.
Later. I was a little bit. I tried to, we have a chance at implementation. Yeah, record bears. And I tried to make that more generic because now it only works on strings. But then I was finished and I was like, Yeah, we actually only really use it for Strings anyways. Right. And it threw it away again and that's why I think maybe we have a lot of subscribers coming in.
Yeah. Like I think 50 by now like subscribers of different subscriptions coming in and I think they're we might have some win. But then again it's already with the interface that we created for it's already it feels A generic yeah already so I don't know I miss them when I joined go and now I don't really need them. Now that we have a my guest. Yeah I guess you develop also ways around them. Yeah. I mean I would go very soon and replace some of the at into, you know, all the interface
declarations everywhere. We use because you don't have generics, those would be good places to start using generics. Where you have to like multiple functions, suffixed with the name of the variable or like exhorting, sort string that consistent interface and then you would infer the type in dry, right? Yeah, stopped and do this and you know, old school generics, right? Yeah. The face with switch statement. Yeah. Everybody's her.
And what I did like about not having it is you think twice went? If if you add it you just use generics, right? Yeah. Now that forced you to think I but in what other ways can I solve this? Problem, which is always good. I think, exactly. I think we've already solved a lot of problems by not having it exactly.
As you said, so that's why I'm thinking of a use case where I really would use it. I mean, we have very narrowly, we have some interface implementations right, where you pass a variable and the type is an interface but we already don't like that. Basically, at least within our team, we stray away from that and we duplicate rather than solving it that way. So that would be one. Case, I guess, but you can already do. You can already be effective, right?
The language is already come up until this point yet. It still has generics implementation. Yeah, but if you look at it, right? So besides I'm very hyped by generics because it is, of course, very valuable to have in a big language. Yeah. The way they went about it. It's just fascinating to me because it's not like generics was building a year. It's not like two years. I think it was already five years in a running local while. Yeah but along the whole path they've made multiple.
Proposals null Community is involved in those proposals,
right? They are rejected or they have ideas about it. But the creator of I think of at least one of the main creators of the jvm generics, contributed to the go generics and they wrote their own program to validate generics organ, go, I think it was featherweight or something like that, okay, like the whole idea that you create another language to prove, generic Works in this language, select words compatible because they first wanted to do it in,
go to the do. So we'll break everything that already existed. Yeah. I mean, from an engineering point, when we develop code within our organization, you only have such a blast radius within the organization you do it justjust globally. I mean, like on the even it's pretty good of an achievement,
it's amazing. Yeah I mean it's really taking that promise of backwards compatibility and really taking that step extra really just resolving those developer issues because those issues if they arise within a language, those are Developer issues. Basically they're A certain organizational issues? The organization benefits from those upgrades? Sure. But those are real technical issues for developers to
resolve, right? If you say to, your product aren't listen, we haven't done any updates. So this print is only going to be updates, and we expect we need to rewrite some code. They'd be like, what the heck? Why? First of all, why haven't we done the other days? And why would it take long to rewrite a lot of stuff right? That just sucks?
Yeah, so if you don't have that and can really just focus on delivering value because that I think that is still, at least What my main driver is or one of them is delivering value for whatever. I'm doing it. Be awesome. If that's not there and I haven't, I don't think I've maybe with libraries that I've had to make changes within the standard Library.
I haven't I haven't had such an experience basically, but of course also comes with the downside that it might take longer for the libraries to emerge. Yeah, if you look at now, generic Scott released. Yeah, there's still problems with generic side, they're trying to try to address those in, in 1819. The next update, think one of the Swans is the completion speed. Yeah, one of the key points for
go is having fast. Completion speeds our code base is like up to a hundred thousand lines of code. Take a couple seconds to compile. Yeah. We'd go on a date in which has the direction. It does take 30% longer like no time did. Is it bad? No. Cause for a second still doesn't really break the bank but it is something and they still want to prove it. Yeah, and if you look at the code side of things, generics of course are very useful for
collections. Go always had a map with interfaces so you do have the option to use whatever type you have in the code base but it's not static the packages that they're creating four slices and Maps there in the experimental level of the standard Library. So you can use them now. But they're bound to change because they first want to figure out what works for the developers on the other side of the building, right side of Google that's interesting.
And you can you can look all of these things up and get Hub and just comment about it and learn from it. So that's what I mostly do. I just follow these proposals, try to read To doing. And it's interesting actually because sometimes it doesn't have stuff like memory Arenas. Something that was recently brought up. It's just interesting to read what they're doing is they're very in depth because they're forced to because it's all
public, right? Yeah. Exactly. And not every developer has to deal with the right, they are creating language. They probably deal with these very Niche kind of topics, but it's awesome. That, I mean, from an outside point of view, you can really just take a look inside the kitchen, right? See what everyone's cooking up? See what everyone's kind of monstrosity. See, they're creating or discussing even and what might end up on your plate. Might be beautiful, but you can
actually see how it happened. Which is great. I think do a lot of programming languages have that as well. I don't know. Actually, well, the jvm, of course, has the Japs Darvon and some proposals. Those also quite nice and quite extensive. I've heard that stores have a very open, which one rust also, mr. Ross, compiler open source. Yeah. That's dope. I think, in general, that's just really cool that it's All the informations out there, nothing's behind closed doors.
Almost nothing will be somewhat again but again I like about the go process here is just new features, you know. There's not there's no sugar rush, there's not she said the next feature an arrow and that's also why you might hate it or love it but I really respect that that leadership of that Community can say, no, let's wait off, let's weigh it off. Let's figure it out properly. Let's do I quality. E, implementation. No, we don't need it yet, you know? And I think it's really tough to
actually do that for them. Probably. Yeah, but I quite respect that. And then again in the end you you have the less is more, you know, I think what it does impact uses, I mean, if you look if you look at go, when I started think it was like 15, five years ago, seven years ago, something like that. You look that dependency management? Like yeah just use depth or what the other one's right? Just like, all right.
So apparently to send a library didn't have dependency management back then so the community built multiple versions of dependency management. Yeah. And then one was, I guess a bit more Victoria's and then they went into the standard library, look at go modules, which will get some combination of all of these experiences and yeah, it does have benefits here. Yeah, the other one I guess is going bed which we have now but before the only also rice and there was like a multitude of
them. Yeah. Exactly. I'm glad they they kind of resolve that problem going. Bad is also Oh interesting to just to take a deeper dive into mean the promise of having the one binary that you distribute. That's going to be an issue, right? If you have additional files, you want include HTML files, or something going. Bad does make it nice where you just say go and bed, which is just one of the directives from the go compiler. And I go language itself and it embedded into the binary.
And yeah, if we look at if we look at hiring, so if I would introduce a new language within an organization, well, the question is going to be hiring, right? If no one. Maintain whatever, my team army, whatever we were writing, then it's going to use this right because they knew have a huge dependency on the people that you have there for the languages that we use. We should also be able to hire for basically already love that. We stated that goes easy to learn.
Would you also hire someone that doesn't have go skills necessarily? But obviously, it's open to learn it. Yeah, I would definitely do that. I have done that in the past. Yeah, engineering manager capacity. In fact, at that search, I was working for a company in South Africa, called intersect. And we were eyeing Java developers. But I went went and looked for C++ developers that would do Java.
Yeah. Because you know, that they think more of efficiency and the lower level things and at some point we also switch to to go in that environment. So I think For for engineering manager. I think we need to think a little bit differently there. Yeah. Because we tend to hire Java developers for Java role, but we should hire a good Engineers, right? Yeah, we should find good engineers and ask them what they want to do.
And we should make sure that we don't introduce languages that are going to be deprecated in five years from now. All that no one will pay for. Yes and developers also leave. But I mean, you're quite safe for something that's simple to learn, and And that is supported by someone like Google, you can
have developers in the future. So I think there's a culture thing also at play because I have also heard that, you know, People don't want to do go, we have good Engineers, but they don't want to do go. They want to stick to the deuce deuce their technology, which is fair, right? I mean which which could also be fair.
Yeah. But maybe if if you if you're going to have, you know, a couple of languages in your organization, maybe you should think of that up front and get more at least a quorum of people that would be willing to switch quite easily. Yeah, there are definitely those people. Yeah, I think that a lot of the, the techniques or the practices that you Within a certain language. Hopefully they're transferable
right? Most of the time they are on this is very specific for for language there but I like that from a hiring perspective perspective, just hire good Engineers, write whatever language. They should use whatever tool they pick up from the toolbox, shouldn't necessarily matter or they can learn, for example, how to use a drill. I mean, exactly yourself,
something as well. Yeah, I think that's also important because we also tend to speak of, oh, this is a go team and this is perhaps a cotton team, but I think That kind of thinking is perhaps also wrong. Yeah mmm. Because in your problem space, you you should look at the problem and say, okay jvm is just the best for this. There's a little big ecosystem for this. It's already solved 10,000 times. It's just use it right? Yeah. But then you might also have
this service. It's really simple. It's going to just do nothing. Just use a go because it's going to be a low memory footprint and it's not going to cost a lot or they might be the efficiency one that you really have to push it. Then you should use rust or something. Yeah. You don't want 20 languages in the same team, but I think you should at least have a sort of, you know, a language. I go to language for certain kind of things. Do you want efficiency?
You want compatibility or you know what you want? Yeah, for me, it was also like a Big Moment of clarity at the time that I was looking for a new team that I don't, I think, even you brought it up at, like, do I want to profile myself as a jvm engineer or as a software engineer? Yeah. And when I started thinking about it like that, I was like, yeah, baby. You know, was that the twin cigar?
Yeah, I think that was for me when I really started thinking about that question was like, yeah, I don't think I'm a jvm engineering. I'm think I'm a software engineer and apparently this problem is going to be solved with go. So yeah, I wanted to solve the problem as well. Exactly, what still doing it.
Yeah, I mean, even if you take a step beyond that right, you already have positions like front-end engineer back and writing are very technology-focused and within back and you have jvm go. What have you? I think it's more centralizing towards just good engineer. Good engineering culture, good engineering mindset, being able to pick up a tool and teach yourself how to use it, or be able to resolve it within a team, right?
Because I'm better at certain stuff, you're better at certain stuff, we should just be able to figure it out and I think if if we make a switch within a hiring, the mindset will also change within either teams or the people that are applying, that's what I'm hoping at least because it's just a sad to be labeled or categorized within a certain techniques like yeah, you wouldn't want that to have like an Excel analyst or I don't even know what other stuff you have I'ma roll.
Yeah, more engineer graduate from benefits of introducing go to your organization. Yeah, I mean, if you look at hiring, I do one of the parts of hiring would go. You the one of it and I think we have one other engineer. Yeah, that means we have to Trigo Engineers that higher for the NGO Community. Yeah, I see. Han has a lot when we're looking for team members and the busiest. Yes, because we regarded, you're the only one has it Go engineered. That is quote, unquote capable of doing this.
These hiring procedures Whitney ago language. So yeah, that does have strain as well. Like if you only have three people, you can only do so many interviews a week. Yeah. So it will have some time. Yeah, I mean you're always going to trust the person that you're hiring, right?
As long as I mean, you can Grill them for hours at some But you're either going to make a decision is going to be yes or no. And yes, comes with some amount of trust, they can gain more trust by having a longer interview, process, more conversation, stuff like that. But at the end, you need to trust their mindset. They need to be able to pick up, go either, they know it, or they
do, I run away with that? I've also had people that came into my team and they said after months actually the language, I really don't like, I don't feel productive in it. I, it's not me and they couldn't really put Words, they were missing stuff from the jvm language that had some nodejs knowledge and they went away. They gained that knowledge. That goes not for them too. Verbose. Not elegant, I heard that one as well and they learned from that which is fine. Right.
It's not for everyone. I thought it was a shame because I actually hardly so you're always gonna have that then is there, is there anything that's still missing that you guys wanted to address when this kind of conversation? For me? If you if you look at Ball as well. Where does go start a bowl? Common platform side of things. We already addressed a little bit that was predominantly bison.
Yeah, bash scripts I guess and probably a lot more that I don't know because I'm not part of that organization but they've been trying to move into and the new system they call a bb-8. Yeah. And that requires you to do more within the community space. Yeah. And they looked at it, they were riding operators, right?
The the part of communities where you can create your own platform, That has very good support for go mostly because keeping that is returning, go. All that are berries are prepared to go. Yeah.
Initially I could think they try with python and some people wrote it with Java that works, but they did notice that go works better, it's just just a little things and they are now working with Goal, which I think is quite respectable, because for all of those Engineers was new please for the part which is re doing mostly for bb-8. But you also see that within our community about would come they reach out like, hey You guys have done a lot of go. Can you look at our code, right?
Can you help us out? Because we know we're from this background would like to see what you guys think of it and because it's such an approximate language. It's not that it takes months for me to look at their code base and be like I would have done this differently. Yeah. Just takes I guess a weekend or a couple of horse. Took a smaller parts.
Yeah, that's dope. Yeah, I love the idea that we're still working on it. I'm trying to write my own Operator just to get more into this face, but it's cool. Yeah, yeah. Guys, I must say I really enjoyed this conversation. Let's let's do it again. Sometime sure. Maybe in a few months in a year, I mean we're going to be going to create a lot of content. No actually few through our company, so so stay tuned for
that. If you're still listening, let us know in the comment section below what you thought of the episode. Have you heard of go? Have, you tried it? Did this talk, make you cited. And with that being said, we will see you in the next one. Thanks for listening everyone. If you like the episode, I want to support the show. Don't forget to leave. Leave a rating better yet. Share the episode with a friend. Let us know in the comments section below.
What you want to hear. I will make it happen. Cheers.