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.
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.
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.