Mirek’s conclusion is the following: “Of course one can learn how to operate any database in the world. But it requires significant effort and time. Each new database brings new tools, new concepts and tons of documentation...Whenever possible stay with one generic database to handle most of the traffic. Add new databases only to handle very specific workloads and only when really necessary.” What are YOUR thoughts, Polyglots?
Should you find a burning need to share your thoughts or rants about the show, please spray them at email@example.com. While you're going to all the trouble of shipping us some bytes, please consider taking a moment to let us know what you'd like to hear on the show in the future. Despite the all-caps flaming you will receive in response, please know that we are sincerely interested in your feedback; we aim to appease. Follow us on the Twitters: @PolyglotShow.
Jonan Scheffler: Hello and welcome to Polyglot, proudly brought to you by New Relic's developer relations team, The Relicans. Polyglot is about software design. It's about looking beyond languages to the patterns and methods that we as developers use to do our best work. You can join us every week to hear from developers who have stories to share about what has worked for them and may have some opinions about how best to write quality software. We may not always agree, but we are certainly going to have fun, and we will always do our best to level up together. You can find the show notes for this episode and all of The Relicans podcasts on developer.newrelic.com/podcasts. Thank you so much for joining us. Enjoy the show.
Aaron Bassett: Hey, everyone. Welcome to another episode of the Polyglot Podcast. I'm Aaron Bassett. I am one of the Principal Developer Relations Engineers here at New Relic. And I have the wonderful pleasure today of being joined by Mirek Sedzinski, who is going to talk to us about a recent article they wrote about the misconceptions about polyglot programming over on dev.to. But before we get started, Miroslaw, do you want to give us a little bit of an introduction about yourself then?
Mirek Sedzinski: Sure. Thank you. So I’m Miroslaw Sedzinski. So I'm based in Poland. I've been working as an IT consultant for the last 15 years at Oracle Consulting for the last four years. Most of the time I spend working with big corporations like banks or other financial institutions and energy sector companies, but I also work with a few startups. And usually, I'm engaged in very technical roles like developer technical lead architect. In my free time, I'm also a member of the Kubernetes community.
Aaron: Wow. So you really keep it busy then between the consulting work and the different community things you're involved in. So, what does the community stuff look like? It's a big passion area of mine, being in developer relations. So obviously, I've just immediately latched onto the word community when I heard you say it there. How has the community been in Poland and online over the last year? Has it been as difficult there as everywhere else?
Mirek: Are you asking about the pandemic situation?
Aaron: Yeah, just in general. I know it's really changed the whole face of how we interact, and conferences, and meetups and everything else is just so different these days, or I find it different.
Mirek: Yeah, it changed a lot. It probably depends on the company. I've noticed that in smaller companies, it hasn't changed that much. But for example, at my company, I haven't visited the office for almost one year.
Mirek: So, almost all interactions are done online. We had Child Day, for example, at our company recently, and it was also all online. We have some integration activities, everything online. So it's a very new thing for me.
Aaron: And is this something you've enjoyed, that change? Or are you really looking forward to getting back into the office?
Mirek: No, before this whole situation with Coronavirus, I traveled a lot at work. So every week I was abroad, so it was a dramatic change for me now to work from home. I think I like a mixed approach. So sometimes I like to work from the office, sometimes from home, sometimes on the road. So I really would like to get back to the previous situation.
Aaron: Yeah. I've heard a lot of places referring to it as hybrid, where you have a certain number of days in the office and a certain number of days working from home. That seems to be kind of a lot of companies...I know Apple announced recently they're going to have. I think it's a mandatory three days per week in the office and then some other time working from home. So that's your ideal setup, then is having a bit of time in the office, a bit of time to work from where you want to work.
Mirek: Yeah, exactly. At our company, it was at our discretion how many days we want to work from where actually. And so this is the actual ideal setup that I like the most, to have the freedom to choose.
Aaron: Sure. For me, it didn't really change at all. I'm in developer relations, so we're on the road pretty much all the time. [chuckles] So I've been remote for a long time before the whole thing started. So I'm just glad now that whenever people are doing meetings, everybody's on a video call and not just me. So that's been nice. [laughs] But moving on from that online and offline stuff, then let's talk a little bit about these misconceptions about polyglot programming. That's the real thing here. Obviously, this is the polyglot podcast. Having read this article from you, it's really well into what we like to talk about here. So it's on dev.to. It's titled, “The Misconceptions About Polyglot Programming.” We'll make sure there's a link to things like that in the podcast description for this episode. And you wrote it, I see, almost a year ago, back in July last year. So, do you want to give us just a little synopsis of what the article is about?
Mirek: Yeah, sure. The polyglot programming term was coined to express the idea that applications should be written in a mix of languages to take advantage of the fact that different languages are suitable for tackling different problems. And it's hard not to agree with this, but as always, the devil is in the details. So, on the one hand, there are some domain-specific technologies, including languages, that are good for some domain-specific problems; for example, Terraform is good for provisioning infrastructure or Ansible. Or, if you want to do data analysis, probably you would go with Python or R, not with C++. And I also use those languages on a daily basis. But on the other hand, there are general-purpose, and most of the technologies I've met and I've been working with are general-purpose. So we have general-purpose languages, for example, Java, C#, Go language, and many others. And it's really not that important if we implement microservice, for example, in Go language or in Java or in C#. It will work more or less exactly the same way. But what I think is important is to be coherent when it comes to the technology because introducing new technology always introduces complexity to the project and to our product.
Aaron: Sure. So you're saying when you bringing in new technologies...and obviously, some are very domain-specific, and others are more flexible, shall we say? Where do you think that the trade-off comes in then when you go, "Okay, we're going to move...this problem requires a very domain-specific language, and we're going to make that investment in maybe some re-tooling or re-skilling of our employees to use this language." What triggers that trade-off then or that move between general-purpose to being specific?
Mirek: I think the most important is...how do I say it? Basically, with some tools, you can deliver some things faster in a more flexible way, and probably not only in IT but everywhere. So you'll have some tools that are better for different things, and you should use them. So, for example, when you choose between a hammer and screwdriver, you know when to use the hammer [chuckles] and when to use the screwdriver. So it's the same, I think, with domain-specific technologies and generic-purpose technologies.
Aaron: And I'm not sure you've seen some of the DYI around my house, but I don't think…[laughs] I don't think saying that I would know the difference between them would be… [laughs] If you'd see some of the work that I've done here, I don't think you'd be so sure about that, to be honest.
Aaron: But yeah, I get the analogy and where you're coming from that there are definitely very particular times when you're like, "No, this requires this tool."
Mirek: Yeah. But, for example, if you want to do data analysis, let's say you can do it in assembly language, in Go language, in C#, in whatever language you want, but it will take some time. And when you try to use Python...and what I did actually some time ago. You will notice immediately that it gives you a lot of power to deliver things and implement things in a very, very quick way. It gives you a lot of advantage. So this is, I think, the situation when we can choose this particular language for this particular task.
Aaron: Have you had of optimizing for developer cycles rather than CPU cycles? So you're choosing something not necessarily because it's the fastest way to build something but because it requires the least amount of thought from your developers. So they don't need to learn a new tool or a new language. They can use the things that they are familiar with. Do you think that's a reasonable trade-off?
Mirek: Yes, I think of course it should be taken into consideration as always because learning a new technology is a big thing. And, on the one hand, we, as the developers, are expected to deliver features, functionalities as fast as possible. So, of course, learning new technologies is always fun. But we have to remember that at the end of the day, we are expected to deliver things, and they have to work.
Mirek: Yes, exactly. Having said that, I think that we as the developers and architects should, of course, always be very cautious or put a lot of focus into architecture. This is also something that customers don't care about too much, the architecture of our product. It just has to work. This is the most important thing. But for us as developers or architects, we need to think about the architecture because architecture is what makes our product maintainable and extendable in the future. And I think that the simpler the architecture, the better. So it also implies that we should use fewer languages, fewer libraries.
Aaron: Yeah, to keep that complexity down.
Mirek: Yes, exactly.
Aaron: Then there are different approaches I've come across before. There are some companies I worked at where they very much remove dependencies. And they were just trying to keep the complexity down. They're like, "We don't want to bring too many frameworks. We don't want to bring in too many libraries. We don't want to bring in too many packages. We want to keep down our dependencies." But I've seen that lead to this kind of not built here syndrome where they're then scared to use external sources and instead build everything from scratch all the time. Where do you think that trade-off comes in? At what point do you go, "Okay. Well, it's now time to bring in a new dependency. It's now time to bring in a new framework, or it's time to bring a new language?" Like, at what point does that added complexity start to benefit the business?
Mirek: So, I think that at some point in time, it comes to some extent intuitively. So you can just see those trade-offs. Always when you introduce new technology, you need to learn it, and it takes some time. You will make mistakes for sure.
Aaron: [laughs] Yeah.
Mirek: And you will find new bugs in the product or in the libraries. So you have to take into account. But on the other hand, I think what we need to evaluate is how much speed we can gain by using this new product. The general approach I think is that we should always reuse what is already on the market. If it's not there, we can implement it. So this is, I think, the general approach we should use. And I think that using this polyglot approach sometimes directs us to the other way, actually. So we just want to use new frameworks, new libraries, new tools, not something that we already have, no.
Aaron: Yeah. You want something new and shiny, obviously. [laughs]
Mirek: Yeah, exactly, very often developed from scratch, not always, but very often developed from scratch. That's fine. I think you always need to have some degree of experimentation on the project. It's not that we always need to use only one language forever and only one technology forever.
Aaron: Unless that language is Python, obviously, because Python is just wonderful and should be used for everything all the time.
Aaron: I may be a little bit biased on that one, [laughs] being so heavily into the Python ecosystem as I am.
Mirek: I can just add one thing because I'm also biased, but when it comes to Go language, actually. I love the Go language. So I have the same impression, like you, that the Go language can be used everywhere. [laughter]
Aaron: So for me, switching languages a lot of the time it's not that difficult. Syntax tends to be pretty similar for languages within the same sphere. Where I find it difficult is coming into projects, which are mixing your regular OOP approach with…somebody may be moving in the designing area, and then somebody else is moving to a functional approach, that mixture of different programming methodologies. Do you see that as having a place within the polyglot, or is that a step too far?
Mirek: I think I touched a bit on this in my article as well. Because I also think that learning a language's syntax is not a hard thing, especially if you have some experience, it's like a few days, a week maybe. And writing code is also not a big thing. You can write a "Hello World" application, and you can throw it away tomorrow, and it's not very hard. But what is hard, I think, is to implement enterprise-grade systems, like systems that work; they are maintainable and extendable. And to do that, it's not about the syntax, but you have to keep in mind a lot of other things. I mentioned a few of them in the article, like idiomatic ways of approaching common problems. So this is always something I look for when I learn a new language: how I should log things, how I should handle errors, how I should handle input parameters, and those kinds of things. Of course, there are always new libraries you have to learn, new toolsets to compile the code, to deploy the code, to test the code. You need to integrate it with your CI/CD pipeline. So there are those other things around the syntax and the programming language that, I think, make it difficult for me. And, at the beginning, of course, we also make mistakes. And it's good to have someone experienced next to you so you can ask the questions. So this is another thing that when we introduce the new technology...for example, now I work a lot with Go language. And if you ask me a Go language question or you have a problem with Go language, I can probably help you. But if we start to work with Node.js, for example, and then someone comes to me with a Node.js problem, I will tell him, "No, maybe you go and Google it because I don't know the answer." [laughter]
Mirek: Maturity for sure. That's something you mentioned. So, how big is the community? How popular is the language, and in what areas it is used? For example, recently, I started to look at Rust language. It looks really interesting. But after some research, I noticed that, okay, it's a system language used for really low-level things. So probably even if I want, unfortunately, I can't use it right now on my current project, so those kinds of things. Of course, the tools that are available. What else? Probably also the capabilities of the language, so is it functional or object-oriented? Or maybe there is a mixed approach, which probably, I think, I like the most when you can choose.
Aaron: Yeah, for me definitely as well all those come into play. And I think the only one I don't think you mentioned was documentation. That's a huge thing for me. If I can't find good docs on a language, then I know I'm not going to enjoy that development experience. [chuckles] But the other thing is how important do you think popularity is? And I'm coming from this as somebody who's had to do a lot of recruiting in their time. And I know we touched on it briefly where developers like the new shiny and everyone wants to play with the new shiny. But whenever you're trying to...like, would you start a new project today in COBOL? [laughter] It's going to be very difficult to find developers who know that.
Aaron: Even though it might be the perfect language for the problem, at what point do you go, "Okay, well, this language may be great, but it's not popular enough."
Mirek: Yes, of course, skills. Availability of the people on the market is also a very important thing. When we started, for example, to develop some application in Scala sometime ago, it was maybe even seven years ago. Scala was not that popular. So we could find a lot of people with Java knowledge, C# knowledge, but when we tried to recruit people, there was no one with Scala. So, of course, this is something that needs to be taken into consideration.
Aaron: Yeah. And so, what point do you think is it worse than just retraining people? You go, "Okay, well, we know that there are similarities between the language we want to use and this popular language. So we can just retrain people in the popular language." Is that an option, do you think? Or is that not worth the investment?
Mirek: Of course, it probably depends, and there are always trade-offs. But I think it might be an option for some companies to unify the technology stacks. Sometimes it even comes from the developers, to be honest, because when I was working for one startup, we started to work on some new product, and we were given complete freedom when it comes to the technology. We decided…
Aaron: Oh, that's so scary.
Mirek: Yeah. That was a scary thing, a lot of discussions.
Aaron: So much, I'm sure. [laughs]
Aaron: Sure. That leads to silos.
Aaron: Honestly, I wouldn't be able to pick at this point. I've seen companies go both directions in very similar situations. So I wouldn't even want to hazard a guess. [laughs]
Aaron: I've seen that attempted at a couple of different places where they've just been like, "No, we don't like this whole stack, or there's too much technical debt." Or, as you said, a team has left, and they don't understand the language anymore. And then a rewrite begins, and you end up in a situation now where you still have multiple different systems that are all just slightly divergent and don't quite speak the same language. And I call it revolution rather than evolution where you're just like, "Yep, let's just scrap it and rewrite it."
Mirek: It's risky.
Aaron: Dangerous. [laughs]
Mirek: It's risky, especially when you have a ready product actually and you decide, "No, we wrote it with C++. But if we wrote it with Java, it would be much better. So let's do it one more time." So usually, it doesn't pay off.
Aaron: Yeah. I think the worst case I've seen where a rewrite like that has had difficult, unintended consequences was switching two languages that handled number rounding slightly differently for an application that prepared documents that customers were using for tax records. And after the rewrite, the figures that were being brought back were very ever so slightly different than the figures they had before the rewrite. I'd try and explain that to the customers, but one of the two was inaccurate. And we couldn't tell which one was inaccurate if it was before the rewrite or after the rewrite. [chuckles] But maybe now they're paying the correct tax, but previously they weren't paying the correct tax. That was a difficult conversation to have. [laughs]
Mirek: When it comes to money, it's always a difficult conversation. [laughs]
Aaron: Yeah, very, very much so. And it's one of those unintended consequences of some software. It was never intended to be financial software. It was never intended that these reports would be used for filing your tax returns with the government. It was always so that the business owner could get a bit of an overview into how their company was performing. But we always assume that they would have an actual accounting software that would do their accounting for them. But we didn't realize that the data that we were providing was just enough for them to do their accounts to avoid paying for another piece of software. And we hadn't realized that people were doing this, so accuracy wasn't something we were like, "Oh yeah, well, we need to be part of a penny accurate because these are going to be used in actual, real financial transactions." So that was a scary thing when we found out when customers came back and said, "Oh, all of our tax information is wrong, and we're getting audited. And what do we do about this?" [laughs] The other thing I wanted to ask you with this whole thing between rewriting or not and making changes is when do you decide that something is mature enough? We all love this new and shiny. There's always a bit of a gamble when a new framework comes out or a new library that may look to solve your problem exactly, but you're not sure about its lifespan. At what point do you go, "Okay, this is worth making this investment."
Mirek: I think for me, the most important factors are community and the product created by the given technology. For example, when I looked at Go language, it is used to implement Kubernetes or Hyperledger Fabric. So it looks for me like it's really mature. On the other hand, there are, for example, when I looked at Rust, I think it's a very promising language. But then, when I looked at the projects, there are some operating systems implemented in this language. They are operating systems you've never heard of, probably and a few maybe applications I've never heard of any of them. So when I looked at this...of course, there are many positive opinions about the language. And the community is very live, but still, no good mature product was implemented with this technology. So I will wait for some time.
Aaron: So, what do you think of the project ownership as well? I remember when Go first came out, there was hesitancy around it because it was from Google. And Google whether it's warranted or not, had a bit of a reputation at the time of killing projects, essentially. It had a couple of libraries that had come out that had got some traction, and then Google was no longer using them internally. So they stopped supporting them and essentially killed it. Was that a worry for you when you started getting into Go? I think Go changed their leadership, didn't they? So it wasn't part of Google anymore, but some --
Mirek: No. Go language is completely open-source. But anyway, even if you have something open source, you are never sure if it will survive or not and for how long. So I think it's a really tough question because I know technology is backed by big companies, really big companies, Google, Microsoft, and others. And there is always some...I think they give you some warranty when it comes to how long the product will live. But after that, you never know. When it comes to open-source, I figure there is no warranty at all. But today, there are some technologies that are backed by strong communities. But we never know how it will evolve in the future. So I'm not sure if there is one answer to this question; probably, we should just monitor the situation and then make sure that we avoid vendor lock-in and technology lock-in.
Aaron: Yeah. I'm seeing a lot of places now that one of their big selling points...and I noticed in your article as well you talked about MongoDB, and I do want to talk about it a little bit as I used to work at MongoDB. So it was interesting to me to see that there. But one of their big selling points for their Atlas, which is MongoDB's Cloud service, is they've just recently gone multicloud. So even in your products that you're using, your cloud-based products, you no longer have this vendor lock-in to AWS or to Azure, or to Google Cloud, that you can move everything between those ones. Do you think that's important as well? Everybody always goes on about, "Oh, we don't want to tie ourselves too closely to AWS' services in case you need to move to a different cloud provider." I've never actually done that. I've never had to move providers. Is that as common of a worry as people make it out to be?
Mirek: I've heard about those worries, let's say, but I'm not sure if they are that common. I would say that it's really hard to change providers once you start with a specific one because even if you go with, let's say, Kubernetes, and you can run Kubernetes on Amazon Cloud, on Alibaba Cloud, Azure, whatever, but once you start to use let's say Amazon or any other provider, they always give you those small add-ons on top of Kubernetes. And they also nicely integrate it with other products they provide. So when you decide to move it to another cloud provider, theoretically, it can run there, but it's really hard.
Aaron: Yeah, there's always going to be these little things you didn't quite remember that you were using that you're now going to have to go in and port across.
Mirek: But at least you have the choice when you start. So, for example, if I understand correctly when you decide to use MongoDB, you can choose if you want to use it on Azure or on Google Cloud or in some other clouds. So when you start, you have at least a choice.
Aaron: Yeah, and you don't even need to really choose. So you can pick...if you're creating multiple clusters, you can have them across different providers as well. They're referring to it as multicloud. So as well as having it in different regions, you can actually have like, "Okay, we're going to have our east region be on AWS and our west region to be on Azure," and all those kinds of things. I'm not sure how it works with latency [laughter], to be honest. It seems kind of magic to me that they would be able to do this across providers, and that's another thing I want to touch on as well. In your article, you talk about having to set up these two different provisions on MongoDB and Elasticsearch, and that seems reasonably straightforward to spin up these different databases. But then it's all the things that come after that, ensuring there's high availability in setting up your clusters. And then you've got to have backups, and you've got to have security and user roles and et cetera, all the ongoing maintenance and patching of these servers. Do you think the move to this cloud providers, to this kind of consumption model where people can just go and spin up a database somewhere, you know, your developers don't even need to go to the infra team. They can just go, "Oh, I need MongoDB. So I'm going to spin up an Atlas cluster. It's small enough costs. I can just put it on the company credit card for a few months." Is that a good thing, or from an architect's point of view, is that a horrible thing? [chuckles]
Mirek: I think it's a really good thing, this whole pass model. You can click and get the whole cluster immediately with disaster recovery or high availability and those other things, patching backups. And what is also good is that those new databases usually tend to support more than one type of workload. So it's not that you need to have four or five databases, four or five different types of workloads. You can now find a database that can support three, four, or five of them. Maybe for some very specific ones, you need another technology stack. But for most of your workloads, it's enough to use one database.
Aaron: Yeah. And I can definitely see that both from document store and I started to...so MongoDB's big thing was they didn't have ACID transactions, and now they do have ACID and all that kind of stuff. They're trying to be seen more as being able to fill these different roles. And then, from the opposite side, you've got relational databases like Postgres are now introducing all of the JSON fields and the ability to query documents, et cetera. So yeah, it's not as clear cut anymore as to this is a relational one and this is a document store. There definitely is a lot of bleeding between them.
Mirek: At Oracle, there is also, I think, a term for this. I'm not sure if it was coined by Oracle; probably, it's called converged database. I'm not sure if you heard of it.
Aaron: No, I haven't.
Mirek: So converged database is basically a database that supports many different types of workloads like traditional relational data model, but also JSON, time series data, graph data. Blockchain can also be supported as well. So yeah, I think it makes things a lot easier.
Aaron: Yeah. There's definitely, as we were talking about before, there's additional complexity every time you add something new to the stack. Developers have to learn new APIs or whoever is maintaining and doing all of the grunt work around ensuring it's patched and that there are backups, all that kind of stuff. So yeah, having one tool that itself is a polyglot that can support lots of different things, there's obviously a huge benefit there. So, unfortunately, I think we're out of --
Mirek: I just wanted to add that also security model is a very important thing, especially in the cloud. And when you have two or three security models, basically two ways of adding users, it's quite easy to make a mistake.
Aaron: Yeah. One thing in the cloud as well it's you do again have that vendor lock-in. So you mentioned security models and users. It's one of the few things that I know for MongoDB that's not available in their community edition and the one you can install yourself. It's like all of their user management that you get on their cloud platform on Realm, and immediately you go, "Okay, well, we're using MongoDB." But you're not really using MongoDB. You're using MongoDB Realm, which you're now locked into that platform. So yeah, it can be kind of slightly insidious sometimes, those ones. As you said, you're not overtly aware that you're using these additional things that have been built on top of it until you try to change something else.
Aaron: Well, unfortunately, we're coming up on our time. But I did want to give you a few minutes to give any shout-outs. So we've talked about that you've got an article on dev.to. Your profile there seems to be reasonably busy. You've got quite a few different articles that I recommend people to go and read on dev.to. But where else can people find you online? Have you got any projects you want to shout out?
Aaron: So everybody should check out your LinkedIn. We'll make sure there is a link to that in the podcast description as well. So people can check out your LinkedIn, read the articles there. And then also dev.to we'll link to the article that we've been discussing a lot today, these misconceptions about polyglot programming. And you do have other interesting articles around a lot of architecture things that, yeah, people should go read. There's a lot of good information there, so we will make sure that it's linked as well in the description below. But yeah, this has been a really interesting conversation for me. So thank you so much for joining us today, and especially on your holiday as well.
Aaron: I am so sorry for interrupting your vacation.
Mirek: No worries. Thank you very much for having me.
Aaron: No, no, it's been my pleasure, and please enjoy the rest of the time with your family. Pleasure seeing you.
Mirek: Thank you. Bye.
Jonan: Thank you so much for joining us. We really appreciate it. You can find the show notes for this episode along with all of the rest of The Relicans podcasts on therelicans.com. In fact, most anything The Relicans get up to online will be on that site. We'll see you next week. Take care.