Two's Complement - Java and/or C++?

Episode Date: March 22, 2022

Ben and Matt have a work conversation spill over into podcast. Join our hosts as they compare Java and C++ as two possible languages for a new project.

I'm Matt Godbolt. And I'm Ben Rady. And this is Two's Compliment, a programming podcast. Hey, Ben. Hey, Matt. How are you doing, buddy? I'm great. Lovely.

Good to hear. So recently at work, we've been discussing the benefits of Java versus C++. And I figured we should talk about it here because, first of all, it means that you and I can talk about something which we needed to discuss at work, but do it in a way that other people can listen in, right? Yes. So this officially counts as our day job, right? That's right claim this back and everything i think uh-huh right so you know uh we have a new project and we're spiking it out in java which makes a lot of sense i think but we we should let's discuss what are the trade-offs in deciding a language we've asked some of our

guests i think this kind of stuff is like what makes you pick a particular language over another and um i figure we should discuss a little bit about that yeah i think we're going to have to try to describe a little bit about what this project is because with any of these decisions right it's all about the constraints of the project and what you're trying to achieve and a bunch of other things absolutely it's going to be hard for us to have that discussion in a very after it's's like, well, we're doing a thing. Yes. Right? So maybe, I don't know, you could give your description of what this project is and sort of the constraints. Right.

I think so. So obviously we work in finance. And so there's a certain amount of secrecy about what we're exactly doing. So we can't go into huge amounts of detail. But you're right to have some idea about what we're talking about here so we're talking about a system which will observe events in the world many thousands of them potentially thousands per second in some cases and make some kind of decision about when is the right time to either buy or sell stocks based on a whole bunch of signals that we are going to get a team of smart people to come

along and do like you and i are not the kind of people who understand the economics of it or whatever but we can certainly build a framework that lets people come in and make smart signals out of the mess of information coming in and there's a ton of information we have to sift through it somewhat quickly and we're talking something which is somewhat performant not necessarily uh like nanoseconds but in the milliseconds let's wave our hands a bit and say around that to make sort of decisions so does is that your was that a fair description yeah i think i think that's good and i think one of the points you hit on is really important, which is that this project is going to be worked on by a mixture of people, some of whom are professional software engineers and have been doing it for decades. And some of whom have been working maybe for decades, but not as software engineers.

They have their background in mathematics or statistics. And yes, they can code know these days programming is like literacy right like you gotta be able to do it a little bit otherwise you know it's like you know you can't even write an email um but um uh but they're not professional software engineers right like you know just like somebody writing an email isn't a professional writer so um there's and and because of that we don't want what i would normally want on a lot of these types of projects which is everybody solves all the problems together right like you have a big group of people and yes people have different strengths and weaknesses

but the expectation is that like hey you know maybe ben your your your sequel is a little bit rusty and out of date let's have you work with this other person on the team who is a relational database master, and they know every little trick and tip. And if you work with them, the two of you are going to build great stuff, and you'll get better, and they'll get better. I don't know that we necessarily want on this project to say, hey, let's take this person with a PhD in statistics or mathematics and have them learn how to write really great multi-threaded code. That's not a good use of everyone's time. Very specific non-goal.

Those folks aren't interested in it. I think we've talked about this before, the difference between programmers and non-programmer folks. I think as you and I, as programmers, there's a certain amount of pride in just building a nice program and the fact that it does something useful in the world is a pleasant side effect of that we hope right you know our day job we yeah the thing that pays the bills yeah my mortgage is paid thank you very much because the nice thing i build happens to

make somebody some money that's great um for the folks that we're talking about here, the program is very much a means to the end. Their goal is, can I model this thing? Can I predict the future in some way? And the program is how they had achieved that. And they're relatively unexcited by the beauty of the program itself. Some of them are, but most of them just want to get stuff done.

And that's completely understandable. Yep. So that's one constraint. And then the other constraint, which you kind of mentioned, is that we do have a performance constraint and actually at prev prev co we had a name for this which is named after a good friend of yours in mind matt helgi because we called it the helgi middle do you remember me talking about this oh i it rings a very faint bell i can't believe believe it. Yeah. Tell me about the Heligi middle. So the Heligi middle is, so it's the middle world between sort of very low latency, extremely

performance sensitive systems and batch systems, right? Where in a very low latency system, there are things that like physics will not let you do, right? Right. And the discussion with like a stakeholder or somebody like that is you sort of have physics. It's the old thing of Grace Hopper and the wire. I can see you brandishing it.

This is a nanosecond. There's nothing you can do to change that. And so you have that to sort of fall back on and be like, hey, can't we just do this? Can't we just do that? It's like, no, light doesn't move that fast. We cannot do that. I am 100% certain we cannot do that. And that obviously has a lot of constraints and can be difficult to work with, but it also provides a sort of fundamental layer to work from that is non-negotiable. Right. There's a flaw that's well understood and you yeah no amount of of changing the problem can get away from it in most situations exactly yeah yeah yeah and then in the

batch world it's like okay well you know can you guys do this can you add this can you add that it's like well yeah it's gonna maybe make the batch job run a little bit longer it's like yeah okay that's fine if it's a daily batch job and it takes more than a day, then maybe you've got to change something around. Right. But ultimately, the constraint there is not, at least from the point of view of the business goal, it doesn't matter, right? I mean, as a programmer working on that batch system, and every time you make a change, you need to test it,

it takes you 23 hours and 35 minutes. You might just want to speed it up a little bit, but that's not going to prevent the business from achieving its goals, right? Right, right. So the hell in the middle is you care about both you care about performance oh but not so much that you're constrained by physics right right which means when somebody comes along and says hey could you just add this in the answer is an unfortunate, it's not no, and it's not yes. It's like, well, probably.

It depends. And it's going to be really difficult to figure out if that was a bad idea until six months after we've done it. And so the sort of middle world where you don't have as many hard constraints, but you have a whole bunch of soft constraints. And the intersection of all those soft constraints can be A, very difficult to just figure out, and B, very difficult to sort of negotiate from like a business and strategy standpoint. Right. About like, okay, we have a whole bunch of things we could do.

What will happen if we do them? Which ones should we do, right? You almost don't have the constraints there to tell you. It's like, well, that one's physically impossible. so we can take that off the list right now got it that's it strikes me that most software development falls into this category i think it does actually it's just that i i have previously you know i worked with heligi on a bunch of this stuff so so we we spent a lot of our time down at the physics constrained end. And I think like any kind of, I was going to say art, because that's the only thing I can think of,

but this isn't art, but maybe it is. Any kind of art, the constraint really helps, right? The more constrained your environment is, the more creative you can be within that constraint system. And I think some of the best code I ever wrote and the best ideas i ever had came from constraint system be they ridiculous you know 35 year old uh 8-bit hardware that only can do so much or even games consoles or any of those things or well here's the fastest computer money can buy

here is the shortest cable we can possibly fit these are the constraints everyone else is like laboring under the same constraints go make it do the thing we need it to do as fast as possible so when you're in that and then maybe in the batch job there are just literally no constraints i'm going to put an asterisk i'm sure yeah they're just much there are few i think there's fewer of them generally and it is a little bit of a spectrum it's got one firm side on like one side of the spectrum and then the other one is just sort of trails off into infinity but that that heligi middle is where there are reasonably it's it's a very high dimensional space there are reasonably many trade-offs you can make and still have a good solution that sat there in a in a minima whether it's a global minima is like who knows because there's just so many other choices you could have made. Right. I see. Okay. Yeah. And that sort of like millisecond performance range, I think, is the sort of...

When we were talking about it with Matt, that was sort of the prototypical thing of like, so we were building the system and it sort of had these same kind of performance constraints to it. And he's like, oh, yeah, you know, the problem with that is that you wind up in this place where, you know, you've got fewer constraints and that actually makes the problem harder yes yes so it's very easy to answer like how important is it that i spend this time pouring over my cache layout and my hashing algorithm to find my my thing in in this set of possible things uh compared to well you know we'll just use a normal default unordered map thing or a default hash map container or whatever and then it's probably fine until it isn't probably fine then and you're never quite sure if it's in the middle of that or not you're like is that

contributing to it or not sorry you'll have to excuse my my dog who is it occurred to me actually earlier when i was making a cup of coffee before we came to do this recording that we started doing this when my now one-year-old dog was absolutely tiny. So I wonder – I can't remember when we did our first episode, but we must be coming closer to an anniversary of sorts. Although when this goes out, who knows. But yeah, now I have a full-sized dog running around and barking at everyone anywho the the heligi middle and the milliseconds and the and the under constrained thing which means that i i suppose charitably you could say that means there's a lot of scope for individual choice about what is best for the people working on the project which i think probably leads us to yeah the idea that with this what we're developing

in is java because of the various people that are available and the skill sets they bring. But obviously there are other reasons why it's a great choice. Yeah. But we wouldn't even be having this conversation if we weren't in the helly middle, right? Like the choice of programming language would be, well, FPGA. That's – The very far low extreme, yes. Right, right, right. And then bumping up above it is CC far low extreme. Yes. Right. Right.

And then bumping up above it is, you know, CC++ style maybe. Although, again, you know, we're going to talk more generally about Java. It's not impossible to have Java at that end. And, in fact, we worked on larger trading systems at previous companies that were all in Java. And they did pretty well, thank you very much. You know, it's all about choosing the right thing for the right team and that kind of stuff which i guess is the theme for today is like why what are the trade-offs and yeah why what what uh so so and it's interesting because in those worlds i actually think java is not a great solution and this is my opinion this is just sort of like based on my experience but it's like if you start getting into the world of having to write low or no garbage Java where you're like kind of torturing the language to try to figure out how to get it to prevent it from doing garbage collections of any kind.

A fundamental property of the language you have to basically disable and there's no help from the system to do that. Right. So I think maybe we should dig into that a little bit because maybe it's not. And also it's worth saying while we're here when we're talking about java here really we mean any kind of jvm based language right because they're pretty fungible which is a real excellent property of the ecosystem that you can mix and match closure and java and scala i think is scala one of those as well cotland cotland yeah great groovy. Groovy. Man, there's a whole bunch of them. But talking about the no garbage aspect here,

so a trading system has to react to events coming in, and you want to act timely to those, in a timely fashion to those events. And ideally, it's not just the fact that you can rely, sorry, it's not just that it's a fast response. It's that the properties of the time that's taken are sort of well understood. You can say it's like between three and five microseconds would be a really lovely thing to be able to say i can react between right and i know that there's some variance because the computer isn't a perfect uh environment anymore for for programs there's other things going on cache lines are going and whatever but what you want is low variance in your your response time

because you can always account for a relatively slow to some extent you can you can deal with slowness um if if you know it's going to happen but if it's a wide range of like yeah most of the time it takes five microseconds to respond but sometimes it takes 50 milliseconds you're like well those are the times when you're going to lose a ton of money in the kind of world that we're talking about and so i would rather have a 30 millisecond all day every day reliable time than something which has the properties of three to five mics most of the time and 50 milliseconds some of the time that's under some conditions which are very difficult to understand and reproduce exactly so right right given those things and obviously as a as a as more of a native programmer um the the things i think about in that world is is my cache warm is my branch predictor uh well trained all those things

right in the java world you have the uh the the runtime that is trying to adapt to make your program run as fast as possible it can do jit compilation and that's great um once that's settled down though that usually the jit is is good you know you've run your code a few times now it's warm there's a whole bunch of things we can talk about maybe about that but like most of the time I one thinks about the JIT sort of stabilizes at some point you don't have to worry about it anymore but if you're creating new objects and which is a very idiomatic Java thing to do then at some point the garbage collector is going to kick in and of course the garbage collector is amazingly sophisticated and clever piece of software using multiple threads

using not a non-stopping garbage collection technique so he doesn't actually have to stop the world and all that kind of stuff but every now and then you'll bump up against it and then you get a big block of variance in your program and so the folks that we've worked with before have kind of come to the conclusion that you can use java in these situations provided once you've got yourself into a steady state you create no new objects right which means it's in a garbage free no more no nothing's going to get thrown away the garbage collector doesn't tend to run anymore because there's nothing for it to do and now you're in a world where you can have a relatively reliable response time and that's great and i think the point now you're in a world where you can have a relatively reliable response time.

And that's great. And I think the point that you're making is, that's not Java anymore. It is. I think in that world, you lose a lot of the benefits of Java, right? Which is, Java has a really, the JVM, has a really great ecosystem

of a lot of different tools and libraries and people that can help you troubleshoot problems, that can help you solve problems with open source tools and other tools. And you throw away about 80 to 90 percent of that when you're like, oh, yeah, I can't make any garbage or I can only make enough garbage to make it to the end of the day that's an i mean so that's another technique we're both aware of is that you know you just get throw tons of memory into your computer and you say right the heap size is one trillion bytes you know like the whole memory of the computer is one heap go hopefully we don't get to the end of it yeah yeah yeah um or you start doing you know weird things where you like garbage collect at very specific times but again like you're now breaking the the model of the jvm when you start doing weird things where you garbage collect at very specific times. But again, you're now breaking the model of the JVM when you're doing that.

And can you do it? Sure. Have people been successful doing that? Absolutely they have. But that's not a world that is well populated. You can't just like Google and find the Stack Overflow answer. Right, if you're hiring someone straight out of university

and they've got Java on their list of skills, that's going to be a new thing for them, right? No one really does this. It's not a very well known issue. Yeah, yeah. So, yeah. So, I mean So in those situations, as much as Java and the JVM are familiar technologies to me, and I feel comfortable using them, it's a place where I would question pretty heavily, like,

is this really the right solution to this problem? Right. And that's specifically for these cases where the variance needs to be kept low. Right. So how does that compare to our situation, would you say? Well, I think we have a little bit which you know we're um listening to messages over an unreliable protocol and so um we if we don't receive those messages uh we will miss them it's not like a tcp connection where it's like, it'll buffer a little bit. Maybe you'll get some back pressure.

That's not going to happen. If we don't hear the message, the tree has fallen in the woods and there was no one there. Did it really fall if no one heard it? Did the packet ever even get sent? Who knows? And so in those situations, like, latency is really important. It's not just a question of throughput. Now, I have definitely seen lots of situations in which the throughput between C++ and Java is at least comparable.

I've seen even some situations in which Java is better because of some of the tricks that it's able to pull. Right. Absolutely. And I think that is sort of a natural use of like in those contexts that wasn't like the sort of tortured garbage free stuff that i was talking about it's just like no it's like the jit runs and it warms up and it gets used to your pattern of execution and it actually can be faster and the gc most of the time keeps up and then every now and then you stop and pause but like the the the price you pay is not so high and amortized over a longish program run it's it's probably even faster than tracking it yourself under some cases right exactly it can be at least

it is at least comparable but in this case it's like no if if you don't read that packet in time you're never going to get it and now you know you have a whole different category of problems, which can be difficult to deal with. And so, you know,'ve written you know I did my undergraduate degree in C++ and that was in you know 1996 and you know I wrote a little bit of it when I first got out of school and I've had some little sort of side projects with it but

I wouldn't ever ask someone to pay me to write a script. That is unprofessional to be like, you should give me money and I'm going to give you C++ source code. Yeah, a lapsed C++ programmer. So even though

that's not necessarily the kind of thing that I would feel comfortable doing, I feel like it is definitely the right solution. Right. So obviously that's an aspect of the system we described, is that there's a number of events coming in, and you've just described something almost like a physical issue. This is more like the physics-based thing.

There are packets arriving, and they're coming in as fast as uh they're being sent by the the sender which is as fast as things are happening in the world outside sometimes that reach reaches line rate on a 10 gig network card and you can't you can't not be dequeuing packets off of the network card because eventually the buffers run out and you're done and you've missed the information there and so that's a perfect example where you want the absolute i say absolute predictability you know people anyone here who does like hard real time systems is laughing at my idea of like you know absolutely dependable performance like no nothing like that but like dependable enough for you to never be more than

a few thousand packets behind what the network card is dequeuing so that you can keep up with it and keep feeding it new buffers and all that kind of stuff and then some amount of processing and then and then the rest of the system you know is this what so obviously we're having this discussion and you know you and i obviously know where we're going with this right but like what we described really was a system where um as i described it you know you're trying to react to events in the market and you have to react relatively quickly and with lowish variance and we've just talked about like a physical characteristics of how you accrue events happening but making those decisions and handing code over to people who are not computer science majors to write features to say predict when they should buy or sell or whatever.

That's not in C++? Yeah. Well, in fairness, you don't have a computer science degree either, and you do just fine. That's very true. Yeah. But yes, they're not professional software engineers, and they don't want to be, right?

That's not what their career path is. So, yeah. So, we sort of have this system that, I don't know. I mean, I feel like it is probably best done in at least two parts. there might be some sort of layers of abstraction that sort of makes sense and might sort of subdivide what certain people work on just for their own simplicity, their own, like, you know, the scope of things that they have to worry about in their jobs. Right. I think it is interesting, though, to sort of talk about, you know, as we've discussed before,

it's not like modern processors are actually executing the x86. Exactly. Yeah. actually executing those instructions or the JVM doing things that you don't fully understand or the VMware virtual machine that's doing things to the network that you don't understand either. Every time you add these sort of layers of abstraction, it has at least the possibility of introducing behavior that you don't understand. And there's sort of the old joke about, you know, the difference between scientists and engineers is when scientists are surprised they're happy and when engineers are surprised they're sad and so you know i've never heard that before yeah that's brilliant yeah i mean it's the same so so

like as engineers you know when we see something and i'm like i don't understand why that just did that it's like oh crap this isn't going to be my last i'm not going home on time today yeah and i'm going to have three people crowded around my monitor all staring at me. How can this possibly be? Right, exactly. So the more of those layers you have, the more likely it is that you do that. Now, if you want to use the silicon rocks we've tricked into thinking as the basis for your system, you're going to have that x86 microcode thing. That's happening. But you don't have to add other ones to it if you don't want to um and so in the in the situation of you know we we have people who are who are going to be working on the system we're not software engineers you know we're going to add we're going to have to add some layers of abstraction for them um and and and you know the question is

is what do those layers really look like and and are there people that can understand the layers beneath so that when they sort of come to us they say like hey so i ran this thing and it didn't do what i expected right like somebody can peel back the covers and and and sort of explain okay well here's why i did this and here's why i did that right um but a lot of that also sort of depends on you know like developer or you know basically like workflow ergonomics right that's what i was going to get to like this layering and abstraction obviously you add the right number of layers of abstraction to make your life as easy as and as flexible as it needs to be and when you're down at the physics level there are the fewer level you almost were required to use fewer levels of abstraction or to use layers of abstraction which

ultimately net out which is kind of the c++ way and indeed the jvm's ability to you know in terms about software layers of like interfaces and whatever then eventually they can all boil down to yeah look we know what you're doing you're just reading a byte here right good stuff um but then there are another sort of uh aspect to this is the various people on the team and i think we've talked about this before as well like the team dynamics are almost the most important thing it's like how how high velocity can we have our teams be how happy are they at working how comfortable are they with their tool set and when then you add in like the folks we're talking about who have more of a maths background how how confident are we we can give them uh something which doesn't turn out to be a loaded uh rpg

pointing at their own head which is kind of a c++ i know i you know i maintain that it would be perfectly feasible with enough time and engineering effort to hand a sort of gilded environment of like, put your code here in C++ to hand to non-C++ folks and mostly not have them shoot themselves in the face. But that would be a huge undertaking, I believe, compared to having essentially language level safety nets that something like Javaava gives them or you know a lot of the rest of the world that we're using in our in our industry uses python for this because again there are a number of ways you can blow yourself up with python but almost none of them involve strange memory leaks or you know crashing with threading behavior and all that kind of stuff

right so right so a lot of the decision process is around how can we give an ergonomic and an environment to the researchers such that they can do their job really well and we can still be performant enough. Right. Yeah. The performant enough is one of the places where this gets tricky. I think part of that problem is hard no matter what language you choose for this right um you know i i think the the you have to really think about like the sort of the platform and the structure that you're giving them and it is going to be like language specific like obviously in java like to an extent you don't have to worry about memory uh well you don't have to worry about memory. Well, you don't have to worry about memory freeing. You have to worry about memory allocation because if you allocate too much of it,

you're going to burn all your CPU time in the garbage collector and then nothing good is going to happen from that. But that is a feature as well. That is a feature, right? Part of that is a feature. It's like, well, okay, we don't have to worry about this and that's a good thing. Right, right.

And, I mean, a lot of the stuff that you do get in well-designed C++, I can see ways where you could structure things where they were very difficult to use incorrectly, whereas one of the things that I've certainly seen with just not necessarily researchers but novice software engineers is they start to develop superstitions one of the things that I've certainly seen with just not necessarily researchers, but novice software engineers, is they start to develop superstitions around garbage collection and the JVM. About like, oh yeah, you shouldn't use this because it creates too much garbage.

Or, you know, stuff like that. I've seen, you know, folks using patterns from the late 90s about always creating string builders in java and doing all this horrible concat concat concat concat type stuff rather than just writing out the obvious stuff and like since about java 10 well i know i can't remember what it was but like the compiler java compiler has been able to do the thing for you right yes yes you know again there's those superstitions and it's because it's not easy to measure the effects of it, you end up doing these kinds of things. I mean, that's not unique to Java folks.

Let's be absolutely clear. The number of people that will pack structures in weird ways and see because they think, well, this would be better. Well, is it? Right. Yeah. Yeah. Right. So, yeah.

So I think a lot of this actually comes down to some of you know the things that we talked about an earlier episode about performance testing and like having sane and intersubjective ways to do performance testing where like when someone in whoever they are when someone introduces a performance problem whether it's speed or memory or both um there are ways to measure it and there are ways to talk about it that are um not you know the system doesn't feel crisp today um so oh my god that is such an in joke do you want to should we should we explain i think we have to explain that i i said yes i i have only heard this second hand oh okay there when this was uttered so

i i it's there i have a sort of all right i'll give an abridged version where uh if you are the operator of a trading system you turn basically turn it on you can adjust some parameters and you're watching the buys and sells come in and that's all your interactions with and hopefully you notice that you make money at the end of the day or during the day as well and famously one of our our desk heads we would make a change and then he would describe the feelings that he got turning the system on and observing the trades with like literally no information really at all but going oh it seems really you know crisp it's like a good trade whatever changes you made made this better you know like like like it was like some kind of i don't know air freshener variant it seemed very very strange and in fairness in the

games industry we used to have similar things you know oftentimes there wouldn't have been any obvious change that would have made it faster slower or anything but yeah i remember um a colleague of mine in the games industry saying that um that they would add in all these extra variables that weren't wired into stuff to hand to then the like game designers that they would add in all these extra variables that weren't wired into stuff to hand to then the like game designers and they would be like tweaking the boss fight by moving these sliders around going like yeah this is it needs you know 78 um you know secondary aggression which literally did nothing but it was like a placebo thing to make them feel better and they would come up with similar words to describe how it would feel

but you know that's actually unkind i don't want i don't want to think people i think to think that's okay you know don't don't it's funny all right anyways yeah it's unkind but it is funny um so yeah i mean i i think i think it's a hard problem working in this environment where you're going to support people that are going to write code, but they're not professionals at it. They don't want to be professionals at it. They have another profession that they're professionals at. It's a challenge no matter what tools you use. Right.

And the tools that you choose will inform the kinds of problems that you have to solve for them. But the premise that we have going in this project right now, at least, is that we think Java will be a better environment to support those researchers and the code that they write. But it's certainly not the case that the entire system, I feel, Right. I think that's something we glossed over, I think, a bit earlier, is that one of the layers of abstraction, such as we described it, is less of an abstraction layer than a physical layer between a part of the system which can run in pure native and keep up with the network card and then have a way of communicating to the rest of the system through an elastic enough buffer to handle the fact that maybe from time to time the other part of the system isn't quite keeping up but it doesn't matter because the packets are being dequeued and put somewhere where people

are getting it and they've been processed enough to make it straightforward for for the downstream consumer to handle too so that that sort of seems to be the right compromise where we're putting the native engineering effort in the place where it's required. We're keeping our options open in the other world. There could be places where we could still use native aspects or other languages, but like for now, the rest of the system might as well be in a language where out of the gate we can get folks in and they can start writing code and be productive without necessarily being aware of all the foot

guns that c++ brings and it still has a decent chance of being performing i mean like we've said java can be very, very performant. Sometimes it can be C++. So it's a sort of mix and match approach, I think is what we've come to here. Yeah. And I mean, there is a certain additional strength in that diversity of, you know, the more of these platforms that you have, the greater access to sort of tools and libraries and things that you have. If we find some library that solves a particularly important problem for us, and it's a native library, we don't have to pull any JNI shenanigans to shoehorn it into our Java system. We can just build some native code around it and have that be a major component of the system and that will work great

and because you know i mean there's nothing more disappointing to me when i'm working in java and i i clone some project and i've got the jdk installed or it automatically just installs the make file as i would usually do and i go to run it and it's like oh yeah you haven't installed this apt package and i'm'm just like, why? Why? It's the worst. It's a sad, unfortunate situation that the many things that do need native stuff do just require you to apt install it as like a global somewhere and sudo this. You're like, no, we shouldn't have to sudo

anything these days. So yeah, building our own um native components and allows us to put in certainly if they're native um and that's been a mixture even in the the trading systems that i mentioned before the previous companies that were mostly written in java ultimately there was usually a little thing on the very end that was native and it was either shared memory communications or literally unix pipes or or actual jni and that would you know the things that needed it you could target and say well this is the thing that generates tons of garbage so why don't we just have the native code do the work and then net it out to the answer and there's no garbage then right you just right right yeah so i mean at least for this

project for the constraints that we have for the people that we have both researchers and engineers uh the the answer to the question of c plus plus or java in my mind is yes um right and and i think that you know as as the project evolves it will be easy to see you know maybe the proportions on either of those but I can't imagine doing this project where that would be

purely one way one or the other yeah that makes sense to me too so yeah I don't know what our listener will think of this episode

it's been an interesting one because you know this has been names have been changed to protect the innocent version of a discussion we've been having for a month probably yeah or so and this is kind of the the outcome we've come to and i think it's a great compromise between all of the various

pull pullings in this heligy middle that we find ourselves in so hopefully it's been interesting for those listening along and we haven't gone around in too many circles as we have been doing in our own discussions about this yeah this is the condensed version this is yeah the 35 minute version of what has been a month of conversation about this kind of stuff and trying to find and justify and prove to ourselves that this is the right path to go down yeah yeah well i guess Well, I guess we should leave it at that. I mean, we haven't really touched much on some of the really cool specific things that Java can do inside the JVM

and some of the JIT tricks it can pull. But, you know, maybe we should leave that for another episode or if you can find somebody. I mean, that sounds like a great other episode. But for now, we're sort of relying on all that kind of stuff and going, it will definitely be fast enough by a long way and the native code will be applied where it's required

and maybe in other places where it will be useful to have it too. Who knows? Maybe we'll revisit this in six months and be like, wow, this was a bad decision. And let's explain why. Yeah. Well, if that does happen, you'll hear it here. Yeah, that's right.

That's right. All right. Until next time then my friend all right you've been listening to two's compliment a programming podcast by ben rady and matt godbolt find the show transcript and notes at twoscompliment.org Contact us on Twitter at twoscp

That's at T-W-O-S-C-P Theme music by Inverse Phase