Episode: 3174
Title: HPR3174: Linux Inlaws S01E14: The big programming language panel
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr3174/hpr3174.mp3
Transcribed: 2025-10-24 18:19:48

---

This is Hacker Public Radio Episode 3174 for Thursday 1 October 2020. Today's show is entitled,
Linux in Laws Season 1 Episode 14, The Big Programming Language Panel,
and is part of the series, Linux in Laws. It is hosted by Monochromic,
and is about 53 minutes long, and carries an explicit flag. The summary is
our hero's host and eclectic panel of experts discussion see.
Plus, plus, Python and Rust.
This episode of HBR is brought to you by Ananasthos.com.
Get 15% discount on all shared hosting with the offer code
HBR15, that's HBR15.
Better web hosting that's honest and fair at Ananasthos.com.
This is Linux in Laws, a podcast on topics around
free and open-source software, any associated contraband,
communism, the revolution in general, and whatever else fanciful.
Please note that this and other episodes may contain strong language,
offensive humor, and other certainly not politically correct language.
You have been warned. Our parents insisted on this disclaimer.
Happy mom? That's the content is not suitable for consumption in
the workplace, especially when played back on a speaker in an open
plan office or similar environments. Any minors under the age of 35,
or any pets including fluffy little killer bunnies,
you trusted guide dog unless on speed, and Qt-rexes or other associated dinosaurs.
This is Linux in Laws Season 1 episode 14, the big programming language
discussion. Martin, how are things?
Things are great, except for the Python scripts that someone wrote,
the crash is my audacity, so which is quite intro to our programming language
is special. Martin, just don't blame it all on Python.
No, no, I'm blaming on the author of the script.
Full disclosure, Martin is talking about me because I wrote the script.
Martin is using probably some windows, trying to get Python to run on windows,
because it's audacity, but it's also running on windows.
Not this particular audacity, actually. There we go.
News, okay, news. Yes, so news that ties in rather nicely with our
programming language episode, and something that you will particularly be
also formed of hearing is the fact of the new operating system
AWS has introduced called bottle rocket for actually written in rust.
So this was a complete, well, bottle rocket wasn't a secret,
but that it was written in rust is a news to me.
And so it is entering, you know, if the bookshop is actually using a programming language
to write OSs in, then we want to something quite significant.
What do you think?
Interesting perspective, given the fact that there's another one called
Redox OS, people, we might be tempted to do a special before the use over
on operating systems written in rust.
But yeah, both of them, exactly.
So what exactly is bottle rocket then, Martin, explain a little bit more, please.
Okay, so AWS has decided to add a Linux for containers basically.
It's a cut down version, you know, for containers you don't need every package
under the sun, right?
You just want an OS that can run a container.
So being an AWS, this code has obviously not been available unless I have been
looking in the wrong places, but the exact details of the contents of this OS are.
All things AWS quite well hidden, but it sort of taunts improved security
with removed package years with packet filters, kernel monitoring, etc.
So they've done a fair bit of extra bits around making those specific security
concerns addressed in container OS.
What it looks like.
Cool.
And this is in production right now.
Yes, it's been a release that's GA now, isn't it?
So it has been talked about for a while.
And yeah, so the whole, I mean, I think you mentioned earlier,
which will come onto your news in a minute, but the whole rust thing seems to be
as we'll find out from our guests later on, seriously, on the app as a language.
Yeah, along these very lines, there was something called the Linux Plumbers Conference
in late August where, and you'll find the details, of course, people in the show notes
where a couple of people have taken serious steps to lay the infrastructure
for the inclusion of rust codes beyond drivers, the Linux kernel.
The infrastructure work seems to be quite advanced.
Even the upper echelons are now talking about not replacing the whole kernel
with the rust implementation, but rather seriously evaluating whether to implement
new functionality in the Linux kernel in C are actually rust.
They are already talking about modifying the build system to incorporate rust
and given the fact that this is one of the kind of early steps,
work seems to progress quite a long way already, meaning I wouldn't say
that the kernel Linux kernel is ready for prime time for us now,
but the serious steps are being taken as we speak.
Given the fact that we're talking about a code base of about 25 million lines
and with the technical heritage for one of a better expression of about what modern, 30 years, almost.
That's a long time, so don't hold your breath with running with Linux
kind of purely being implemented in rust or re-implement in rust,
because that's only what happened because of the sheer size of the code base,
but going forward, it wouldn't surprise me to see more and more fragments
written in rust entering the Linux kernel code base.
Something very interesting.
Yeah, definitely. And by the way, I stand corrected on my previous comment.
Bottle Rocket is, in fact, an open source project.
Cool.
Is available on GitHub.
Excellent, excellent, excellent.
What else do we have for the use?
It's slightly different, different news.
Martin, you are running Windows, right?
I'm running four different OISs.
One of them being Windows, yes.
Excellent. You'll be glad to know, Martin, that Windows has now achieved a rolling release status.
Okay.
Similar to fond Linux distributions like Arch and so forth.
Linux is now a real rolling release.
Given the fact that I had the impression that Windows was a,
although Windows 10 apparently will be the last Windows version,
as officially with the Microsoft, I had the impression we were talking about
are fairly upgrades similar to, for example,
canonical does it with Ubuntu.
So you have the 24, you have the 2010, you have the 1904,
and you have the 1910.
And no, but I was corrected in that assumption,
because the Ubuntu, the well known Ubuntu podcast,
as in season 13, episode 23,
Alan Pope revealed it all.
Alan actually is compared.
Yes, Windows to a rolling release approach.
Something very interesting, given the fact that
Windows only issues, I think, as I said, half yearly updates.
But maybe you can elaborate on that, given the fact that you are Windows user.
Well, so yeah, there may release many releases,
whatever they like, but one of my previous Windows machines is still running XP,
so yeah.
I don't want to talk about releases.
Martin, in that case, if you're still running XP, you'll be glad.
I may adopt a different strategy with Windows 10.
Yes, Martin, if you're still running Windows XP,
you'll be glad to hear that an upcoming episode of Linux in-laws
will talk about IT security.
Well, that's very secure, because it's not connected to any network.
So you're running this self-sustain on solar power?
Excellent.
If it's not connected to any network at all, wow, interesting.
Can you send pics?
We can.
Excellent.
Excellent.
Okay.
Anyone else?
Yes.
Which probably should be the default setting for any XP system?
Still out there.
Yes.
Other news.
Yes.
Thunderbird 78 now includes OpenPGP.
So for those officials out there,
still using Thunderbird or using Thunderbird once again,
you do not need plugins like in NICMail to secure this in your mail,
because now Thunderbird includes already OpenPGP
per definition out of the box.
So simply upgrade, import or migrate your NICMail settings to OpenPGP
and Thunderbird actually takes you by the hand and does it for you
or does it with you rather, including key migration on the rest of it.
So that process is really straightforward.
Go.
And the last bit of news from my side is actually Fedora is serious about
getting Butterf as into production,
because they're looking right now for testers for Fedora Core 33 for Butterf.
So if you have a couple of spare cycles,
you'll find the link in the show notes,
give that project a hand.
Okay.
Anything else from your side, Martin?
Well, if you are interested in the history of Linux in a nutshell,
there's a handy link in the show notes,
handy document someone's written on this subject.
So if you want to do it last 29 years of Linux in a nutshell.
Cool.
Yeah, please.
Set me that link and I'm going to include in the show notes.
Okay, if there's no other news,
let's continue with our special on programming languages.
Yes.
And over to the panel.
This is Linux in last season one episode 14,
the big programming language panel.
Welcome, Jens.
Thank you.
Martin, over to you.
Yes, welcome Jeff and Mike.
Would you like to say a few words about yourself before we get started on the programming languages themselves?
We should start.
Yeah.
Oh, Jeff.
Good, Jeff.
Oh, yeah.
So my name is my name is Jeff Land.
I work currently in the VR and eye tracking space in Tokyo.
And before that, almost 10 years in mobile app development.
I'm just a long time C++ programmer.
I occasionally tweet about C++.
And yeah, I think that's all you need to know about me at this point.
Thank you, Jeff.
Mike, yourself.
Yeah.
My name is Mike Mulo.
And I'm a Python trainer.
So I spent the last 10, 15 years mainly teaching Python.
So I do have a scientific background.
Therefore, also a lot of my Python core participants are scientists.
And in addition to being a Python trainer,
I'm also pretty deep in the Python community.
So I'm, I'm organized up a bunch of Python conferences.
And I'm still involved in Python conferences and everything that has to do with Python.
Okay.
And finally, thank you, Mike.
Finally.
And since we did not, we had a cancellation on the rust from the last minutes.
Our own Christoph Siviman will be covering the rust language.
Indeed.
My name is Chris Siviman.
I'm, I'm the co-host of a podcast called Living's Enlossed.
I have been doing rust for the last three years, three and a half years, maybe.
And also gave presentations on rust at this year's 4th and all the rest of it.
And we'll see you later on this beautiful language.
Okay.
Thank you, everyone.
So I'd like to start with a little bit of history on each language.
So where, where, first of all,
where do you think it came from?
Where do you think is purposes?
And how did you yourself get used to it?
So if we stick to the same kind of sequence,
then we can open it up for more discussion after that kind of first intro on the languages for those not familiar with them.
That's okay.
So Jeff, please, what do you want to say about C++?
Well, first, let me say I'm not a representative of C++ of the greater community or anything like that.
I'm just sharing my own opinions today.
But C++, I think everyone's at least aware of kind of what it is to some extent and what it's for.
But it's, it's a rather old language, but the thing I want people to understand is that it's changed a lot.
And in the 15 years or so, I've been doing it.
It's changed quite a lot.
C++ 11 was a huge update.
14, 17 and C++ 20, which was recently standardized.
Or have also changed the language significantly.
And I think really it's,
it's like best features or not features, but it's it's area of applicability is probably.
It's a large code basis that need to be at least somewhat performant.
So in my, like where I began with C++ was in game development.
Around, you know, 2000, around the year 2000, although I started as a hobby programmer.
So I don't know the exact date.
But it's still extremely relevant in that field.
The type safety, the, the abstractions that it provides for high level usage,
but at the same time still being performant are really useful in that space.
And nowadays, I'm using it in the VR space as well, where, where I think it's still a really good language for that.
And of course, there's tons of companies out there with huge C++ code bases.
And so I think really that's where that's where it excels.
Like I wouldn't, you know, start as C++ like script just for, you know, moving piles around or something like that.
I would, I would use another language for that.
But when it comes to like, I'm going to write this big thing that's going to last for 10 years.
I think C++ is a really good choice.
I guess that's, that's, that's, that's, that's the reason.
And then so in my experience from coming to C++, it tends to be in the high performance,
fine and space as well, where people choose that as a language that is, have you come across that as well that it's,
it's, it's, as I think you said already, it's been just well performed and tried.
Yeah, absolutely.
I do think rust can present some challenges to C++.
So maybe we can get into that today because rust also has a lot of similar goals, where it's performance.
It's still high level, you know, like it's not like C.
It doesn't have all the dangers of having to write in my assembly or C like that,
but you can still make really nice high performance programs.
I'm curious to see because I haven't worked on on Wall Street, for example,
if there's been a Dutch and a brush there, but I still think that's the general domain of C++.
So very good, very good.
Okay.
That's a very nice instruction to C++.
So let's move over to Python and.
Well, then getting into the rest of it.
That's okay, Mike.
Do you like to do the same?
Yes. So Python actually has a kind of a birthday.
Guys, a nice anecdote.
Needle von Rossum, or probably if you pronounce it Dutch is chrido.
On Rossum is his originator, the original developer of Python.
He didn't have anything to do between Christmas and New Year's, 1989.
And he developed Python, which I guess is partially true.
He worked at a research institute and asked for the emitter time and he was heavily involved in language development.
And then he put a lot of pieces together.
And Python at this time kind of settled in the niche between C as a system program,
languages in parole, a language is a language you can only write and never spend again.
So it goes for that kind of reputation.
Just being funny here.
But Python settle in this niche to fill this one.
So easy to understand.
There has a background in ABC, which was a teaching language, a toil language,
the syntax indentation. So it should be very easy for people to get in.
But at the same time, also good enough for professional people to do some real work.
And that's actually one of the interesting features of Python.
That's how it developed.
And I think the first public release was 1991 in March.
So Python is going to turn bloody soon.
Actually, and was pretty small.
And I got involved in Python in 1999.
I still remember I bought my first book at this time.
And there was the second German book game out.
I have like five English books.
Now it's like 500.
I'm sure.
And I bought this one in April.
And I needed it to actually do scientific program.
And it was back in my days at a research institute.
And I had a couple of numerical codes.
And the first thing I did this pie is actually a wrap for track.
So for trend existing code.
Being there for decades,
very performant,
but very difficult to use on wrap the whole stuff in Python.
And I wrapped the other thing and see in Python.
And just put everything together.
So I glued three numerical codes together.
And I did it in Python.
And that's one of the good interesting areas of Python.
So called glue language application.
So it used Python to glue together existing systems.
And that's I think where Python trines.
Because Python itself.
See Python,
we can talk about implementations is implemented in C.
And you can easily connect with C on the C.
You can connect with many other languages.
And there's also connections rust nowadays.
And many others.
Yeah, you can also talk to fortune.
And in a kind of more less convenient ways,
you can exchange data and rapid.
And that is how I started this Python.
And I've been involved in this Python for quite a while now since 1999.
And then I get into teaching because I was in university and told some lectures there already.
And then if you if you teach at the university level already.
And you use Python.
Then doing Python training is a kind of something that makes a lot of sense.
And Python, the language is interesting.
It's totally open source.
And it's used in many different areas.
There's not only one area is used in pretty much everything.
So that development or kind of scripting things or this cloud.
Many because the cloud solutions use Python a lot.
Scientific area.
There's a lot of scientists that use Python for a long time.
That's where Python has a lot of libraries.
Machine learning, which is kind of data science,
which is kind of connected to science.
It's one way or the other.
But also web.
And many, many other things you can find Python pretty much everywhere.
That's even hurt.
That's one guy implemented a toy operating system.
Python, which is probably not the best domain.
Yeah, it works.
He used, he used micro Python, which is a Python, especially designed for microcontrollers.
A very different implementation.
Yeah, because Python has two things.
It's a language itself.
And has a reference implementation, which is deep Python,
which is probably 98% or 90% use it.
And there's a bunch of other implementations like PyPy and microPython.
And a few others.
I'm of that conversation.
Aaron Python or Python for Internet and so on.
Okay, so that is.
So I think from what I'm hearing.
Is that you're saying that Python is very because of its variety,
number of libraries and application of uses right now.
That's it's mainstream.
Yes, there's the same.
Python is the second best language for everything.
So that means.
Right.
Python is good in pretty much every area is maybe not the very best.
But you have as much you can use the same language.
If you want to write a web application or if you do one HPC high performance cluster.
Or if you're going to do some cloud development or whatever you like,
you can use the same language when you have very powerful libraries.
That in addition, wrap.
Libraries, potentially in other languages.
That you can take advantage of this functionality also without switching the language.
Yeah, that's great.
Obviously, the.
The fact that it's been open sources makes it quite transparent.
Have you been following the kind of the project as well and all the development around.
Over those years, right?
Yes, there's two things.
There's one thing is like that.
That is there's a policy and software foundation, which is kind of copy a right hold of Python.
And they do all the abstract and the straighter things.
Like they do the Python conferences collect money and restrict this distributed back to the community.
Supporting open source projects.
And there's a core developers.
So I'm following a for some of the list.
I'm not set myself a core developer.
But I'm following those lists and kind of follow what people doing a little bit.
And it's very interesting.
Ways or Python ideas, for instance, they talk about new things that might become part of Python or not.
And I'm following this little bit is very interesting project, because Python doesn't have like a specification.
But has a reference implementation.
It's a bit different approach than C++.
So there's no kind of what people come into that together and setting the rules.
But they have this process called pep and enhancement proposal.
So you have a great idea.
What should become part of Python?
You probably should join Python ideas and discuss it there.
And if it's good enough, you can write this pep thing where describe what you want to do.
How you want to do it?
And if possible, kind of a reference implementation.
The shape that's how it works.
And then you need a sponsor from the core developers that supports your path.
And there's kind of a semi formalized process to get it in this very pretty interesting.
And it seems like works pretty well, because Python wants to strike the balance between.
You'll be able to do a lot of things, but don't have too many features that you kind of get.
Brought by all these many different ways of doing this.
So Python want to have one preferred way of doing something.
There's always many ways of doing things, but usually there's one preferred way and you want to kind of.
Not to have too many ways doing the same thing, which makes it more difficult for people to learn.
Yeah, that's great, Mike.
Sorry, we did do a couple of episodes on Python.
So we want to try and give give a little bit of speaking time to Rustus.
Thank you for that.
So last but not least, our own Christoph on last.
Yeah, thanks.
And having used all the two remaining languages.
I don't really see what Jeff and as well as Mike are referring to the first big project that actually did in C++ was the meta level architecture for the experimental experimental micro kernel that I was developing for the as part of the PhD.
And we did the kernel in C as well as C++.
And I learned C around at the tender age, I think of 14 or 15 something like this.
All through my uni years, I've administered Unix or yeah, but Unix isn't because Lens wasn't around then.
So that was also the program language language of choice for my.
For my bachelor thesis. So yeah, I've been growing up using C and C++ so I can I can totally see what Jeff says.
But then as part of the PhD, we were also looking for a scripting language to do much of the QA framework with.
And so I came across Pearl and Python.
And so I said to say I've been using Python since the early days for as my as my rightly outlined for gluing stuff together in terms of Python as a significant ecosystem.
And for me, programming Python is basically taking a look at what's out there.
That's something called the part by the part of the Python package archive or anything sorry index, my mistake.
And then simply writing the glue code that ties together these modules.
And similarly, rust has also filled this niche in terms of it's within the last 10 years.
I think the first commit was about 11 years ago.
Okay, let me share some more light on the history of rust about 13 years ago, I think 20 or 7 something like this.
Brian H and and friends at the at Mozilla was we're looking for an alternative program language for the implementation of what was then the rendering engine for something called Firefox, which is at the browser from complete mistaken jokes aside, if you take a look at the implementation of much of the code base of Firefox up to that point.
You'll see a very large code base and Brian and Brendan and friends clearly saw the rising technical depth with that code base never mind the more and more effort that they had to pour into this code base for QA.
So they take they basically take a took a look at what's out there and decided to do the to do their own language, not trying to repeat the perceived mistake is probably too strong word for this, but you'll see this actually at some of the language aspects of rust to do it better, let's put it this way.
For example, it has a strong typing system is a compiled language and has a couple of unique traits that basically allow moving of much of the testing of what that you were to typically do after build to compile phase memory management, probably being the one of the primary examples in this case.
The code added to applies if you can convince a rust compiler to generate code to exit to produce an execute the binary, you're almost half there, because Python you just write a script and then hope for the best once you execute it.
So this one of the main philosophy philosophy is behind us is to move this this effort from the from the QA phase compile phase.
And I'm happy to say that the ecosystem that it probably took Python to develop for 15 years or something like that, maybe even 20 in rust has has been done more or less of the last 10 years.
If you take a look at the package index on car on the on the crate out that I always find it's pretty comprehensive Python has four or five web frameworks rust with the within 10 years has developed three main ones and it's still growing.
So I'm really looking forward to the discussion between the three language having used all three of them.
Yeah, thanks thanks.
So Chris that as Jeff already mentioned alluded to earlier, he thinks that rust may be posing a challenge to C++. Have you been using any rush yourself yet, Jeff, or just from a studying point of view?
Just from a studying point of view, I've written most scripts and things like that.
The trouble is like with C++, usually we're working on large code bases.
So I think really rust is going to sneak in and like individual modules, like the next version of our firmware and our company or something.
If we have a good chance to restart, I would consider doing it in rust, but we just have so much C++ code that it's hard to just have a new process that completely isolated place where we can start a rust code base.
So I think that's one of the challenges for.
Yeah, you think that's going to be a problem going forward for adoption of the language as well, not.
Yeah, you know, if people do have this much code basis and C++, then it will there be a place to start a new and the top thing was by it's it's if people have skills companies have invested in.
There's a technology done changing no matter what technology, whether it's program languages or databases, right?
It's they want to maintain that.
Investment is is that why we're not seeing so much of an uptake of rust, or do you think?
I think that's part of it.
One is the existing code bases too, as you mentioned, like training.
Like it just even within my company, we have, I mean, it's mostly C++ code base, but you also need to know Python because there's various scripts.
You need to know a little MATLAB.
You need to know C because there's various bindings that go through C.
And it's like, if I add rust to the code base, that's yet another language that we have to train people on when we hire.
And so that itself is a problem, I would say.
I like to.
Yeah, that's.
Thanks.
I will say one thing though.
If you, if you ask for rust programmers, you get, I would say, and this is my opinion, I don't want to offend anyone, but you get a really high caliber programmer.
Like it really weeds out a lot of bad applicants.
If you put rust on the requirements list for what you're looking for to hire, or at least the wish list.
Things that you would like to see in an applicant.
That's just something I've noticed so far.
Jeff, you get all of them.
Is that is that why you added a cruise?
Just to get off the nutters, think the head of the hipster is drinking coffee, drinking drinks, high latte is in the hipster coffee shops.
Yeah.
Yeah, but a lot of them know what they're doing, which is interesting.
No, it's I'll come back to you in a minute, Chris. Let's get to Mike's view on the on the.
Of course, sorry, yes.
Mike, what's your view on the rust with the C++ debate?
Yeah, I think it's interesting for me.
If I understand right, rust adds the security.
So in C++, you can, if you want massage the memory and do pointer kind of stuff.
We can rust if you do this forward checking thing.
So I'm a layman in this very thing gives you a lot of security.
So you can achieve pretty much the same performance in rust as in C++.
Without potential problems with this sec forwards and what kind of problems and actually if this right.
That's a very interesting perspective, Mike, because I put in a some background.
I presented a paper at Boston this year.
Sorry, sorry, not a paper representation.
Outlining what Redis Labs did with something called Redis Jason to.
It's essentially it's a module.
Running on top of native Redis modules are application specific extensions for databases running on top of a very popular news.
Database called database and essentially what these modules do.
They turn native Redis into an application specific database like a database of able of handing documents of handing graphs of handling full text search and so forth.
And the first iteration was actually done in native C of Redis Jason because C is the program language that the project founder used to implement the server as well as some of the initial extensions as modules.
And then the total re implementation was done in rust.
So what the last did down in Israel actually they wrote a crate that essentially implements the module SDK.
So allowing you to then write modules in rust using that SDK crate that natively then talks the server and the performance overhead that you paid when using rust instead of native C was only in the order of five to 10%.
It's something that I found pretty interesting from a security perspective because in contrast to native C we have to do much of the memory management manually because this is basically what he gives you C++ of course is a little bit different here.
But in contrast to this rust basically takes you by the hand and it won't generate code if the memory management is not up to scratch because it does manage the memory for you more or less automatically.
And essentially you have to know what you're doing in terms of, for example, there's a concept of an ownership where rust ensures that at any given point in time only one scope actually owns a piece of memory that can especially for people who are at the beginning of the learning curve that can be here and challenge him.
Because some of the concepts, especially if you're starting off with the problem where I can be hard to grasp but moving on what I what I feel interesting is actually and that goes back to Jeff's comments.
There was a proposal about two years back where some chat or it's actually two of them started to write Linux device drivers in rust.
That led to the ultimate comment comment by somebody called Linus told us that he sees rust entering the kernel space more and more and more.
Now if you take a look at the Linux kernel you'll notice that Linus started this I think with 12,000 lines of code in 1992 and I think the latest metrics coming from the Linus foundation clock in about 20 million lines of code.
These days for a Linux kernel. It's interesting and I would like to get the perspective of Jeff and Mike on this.
If you see any other traditional large code basis such as such as things kernel basically opening up for for for new languages and rust I think it would be one of the examples here.
So I think Firefox like you mentioned is another obvious example.
I mean there's a huge amount of infrastructure that's just everyone's uses right like these major open source projects open SSH Linux all the all the browser engines I think any of these especially places where security is relevant.
There are good places or I don't know if they are because I'm not involved with all these projects obviously but are good places to consider allowing rust or writing like bindings or things where other people can start adding rust at least around the peripheries, even if we can't rewrite the code basis.
And like I said, I think where security is especially relevant such as the kernel such as browsers. I think that would be a very wise choice.
Okay, Mike, Mike, what about yourself? Do you think about the I think I of course I have to speak from the pricing perspective, I would speak from the pricing perspective.
Now days, let's take the scientists, scientists field as an example. So because I have a lot of contact with scientists and traditionally they use C++ for trying these kinds of languages for their computations.
But more and more, they realize that they have performance problems, but very often the performance is only in a very small area. So they have a solver for PDEs or partial differential equations, for instance.
And this is sometimes a few hundred lines of code, but the whole program is many 10,000 lines or more 100,000 lines of code.
And very often, there's no need to write a whole application C++ or four trend, just of course, you need this few hundred lines for us. So that's probably the trend that you keep the solver in a compiled language and write the rest and Python, which is usually not performance critical.
So moving files around and Python assuming libraries that again, and that's where it goes. And now there's also there's a lot of libraries that in Python, you use Python, but they generate new code.
They generate code in the background, like numbers, one of these things. It's something that can generate a native GPU code, for instance. So you write Python, and this has an asking it generates performance GPU code, because programming GPU is something, if you look at this is some, it's a total science itself.
And anything, if you have not the RGB works, and there are as application programming you want to communicate in this field, that's probably a trend now that Python becomes a front end and generates code in other languages that will be compiled.
So it's like meta programming, if you want. And then you take away the burden of fiddling with all the details, because where I mean, you're not really familiar with all the details, because you run the right application.
And you're not necessarily an expert in one of these low level fields, like GPU or something else or compilers in general, you need to know all the things. And those tools very often do a better job than some person who's not the total expert in this field.
That's how I see how this probably goes.
That's an interesting perspective that I hadn't considered that one. And what you're saying is that these generators are of a certain quality that would, you know, be over and above what a core programmer would produce.
Yes, very often that's actually it's better. So I, if I would write GPU code, probably I know a little bit about you, but try to do it by hand, just for fun, just for testing, probably won't be as good as as the generated code, because they can kind of generate.
Like if you do this, you can do something that generate different kind of versions and compare them internally and take the fastest one.
Yeah, so kind of a little bit just in time compilation, so to do they can inspect because they have a lot of information and they generate an AST and a succinct X3 and can inspect it and make it better and can do a lot of things, which you mean wouldn't be able to do probably or wouldn't do because it would take too much time, but the machine can do a lot of things in a few minutes can rearrange everything and try different versions or kind of things.
And which is often better than the average application program, if they have a very expert in the field, that is a GPU program or knows everything, they might be able to write faster code, but this would take a long time will be very expensive and then we have to change the code manually.
And in the end, it wouldn't pay off like who's writing the sample nowadays very few people write assembler 30 years ago, many more people wrote the sample, but nowadays the samples just generated and very often the generated assembler is faster than manually written the sample, I would say.
Good point, good point Chris, what about your opinion on that?
You're having experience with writing assembler and many other things, do you think a generated piece of code can be the same level?
I fully agree with Mike, yes, if you take a look at projects like LVM, Klang, of course being the C front end here, or if you take a look at the coach generator,
that Russ uses, it uses a slightly modified, I think LVM backend, it's hard to beat this GPUs, of course, like a different story, but I think even there, CUDA and friends have made great leaps in the last couple of years.
Jeff, if I'm completely mistaken, you're coming from the, you're coming also from this embedded area, right? What's your perspective on this?
I would, I would actually agree on the in line assembly anyways, it's really, really, really hard to compete with the compilers.
And part of that is that the instruction sets are so complicated that there's a lot of optimizations that the compilers can make that you don't even realize, especially if you're just sort of learning it just to write some in line.
In the assembly, in the hopes that it's going to be faster, back when I did mobile apps, like for the earlier iPhones and Android's that we're using our V7, our V6, we did do in in line assembly.
And there were certain things like matrix operations and things like that, where we could write it faster than a compiler could generate just because we know the tricks and they're well known.
But outside of that, you really don't want to do it yourself unless you're really an expert and know what you're doing. The compilers are very good.
And kind of the introduction of LLVM as sort of an intermediate language for everything has actually, I think, really helped because now there's tons of things that can compile down to the bytecode and then let LLVM deal with handling with actually generating machine code from that.
So in a way, we're kind of in this school golden age, I think, where you don't have to go that low level, but you can still get the performance and almost everything can in some way or form be compiled down to something that's efficient.
Sorry.
For the people who don't know what LVM is, LLVM from a complete mistake instead of a low level virtual machine, essentially a compiler ecosystem that has various language specific front and Slack, CLang for C1 and C++ similar to to GCC inference with the main difference that LLVM is just as Jeff just outlined is a status as more or less intermediate language as an intermediate representation.
That LLVM then simply takes an empty and produces optimized machine code from this. So the idea is basically a language specific front and takes the program language of choice like Java, GoLang, Russ, and so forth, produces a syntax tree that which is ultimately converted into the intermediate representation, which is then picked up at LLVM.
Um, why do few projects use LLVM these days as that's that, um,
compiler framework, for example, if you pick up something called Xcode, produced by a company called Apple from a completely mistaken.
Um, the, what used to be GCC is now LLVM and CLang as their main compiler drivers for, um, C C++ objective C as well as different complete music of the Swift.
So, so that's where it works with these days, but I found this interesting Jeff that you said that, uh, you actually in the old days you did assembly on, on mobile devices, because essentially what that means you are circumventing.
JVM on these early and odd implementations, for example.
Oh, well, the stuff we were doing with C++ anyways using the NDK.
Okay.
And like, so like in those days, we would, we wrote everything in C++, which is still what game engines do.
And then we just had bindings to objective C++ or objective C in our case objective C++, because you can inline it with C++.
And then, uh, and then you have a Java wrapper for the Android side, but everything's a native code, especially in those days when the, when the phones were like kind of like N64 level.
Um, like not particularly fast, just barely fast enough.
Um, of course, the, it's, you know, it's been exponential, uh, how fast the hardware is improved in the mobile space.
But yeah, at the, at that time, it was still very useful to write, at least very targeted functions, um, and assembly.
Although a lot of, a lot of that stuff is actually just standardized, um, in, in certain libraries.
Right, where like if you're using a math library, it might have, you know, hand optimized, you know, matrix multiplication.
If you're using, you know, uh, char one, it's probably going down to something that's really optimized, as long as you didn't copy, paste some code out of stack overflow.
Yeah, got it, got it. Um, before we move on to does very interesting discussion. Thanks for that guys.
Um, before we move on to ecosystems, I'd like a sort of a, a very quick, uh, two liner around what, how do you see the future of each of these languages yourselves having gone through, you know, many years with them growing up with them.
But what do you think of in five, ten years time, where will we be with each of these?
So Mike, I'd like to start with you.
Uh, uh, predictions are always difficult, especially if they're about the future.
Very good, very, I like it.
Uh, but I, I would say one thing is, uh, and opinions are fine.
Yeah.
One thing is like, uh, there was a blog post a while ago, because you might know that this switch between Python two and Python three was a bit difficult.
So, uh, this is Python develops here. So there's, there's essentially no difference between Python one and Python two, essentially, Python 1.6 into zero is technically the same thing that just changed the license.
But there's a big difference between two and three. So they cut off a lot of backward, compatible thing, incremental things.
There's just something they didn't like. They said, they turned out, that's not good.
And now we have, we want to change it. And if you change it, it's not compatible anymore.
And they changed quite a few things. And there was a big thing in the community, because a lot of, they just thought people just switched from Python to Python three, but it didn't happen.
And a lot of my people had to maintain libraries, the library was for two versions for many years, for more than 10 years of Python three came out in 2008 initially.
And now we are kind of over the thing ever since Python stream, but it's not ever seen.
There's still a lot of exciting things to do.
If you want to make money with consulting, you should consult for Python two supports here.
There's still a card if you'd like to see things that go behind it. Never wanted to change. I think YouTube is one of them.
I'm assuming it's taking. So I'm not going to, but that's, that's what my last information had that YouTube is partially written in Python two.
And they maintain their Python compiler. If I'm not mistaken, so interpreter.
And that would be something that that's not going to happen with Python four. That's the future of Python four will be a bit complicated to Python three to a large degrees.
And also they, there's no Python for the horizon as far as I'm aware that will be announced.
Python three nine is coming out. And that will be a Python three 10 likely in the Python three 11 and so on. So they expose two digits because.
Python two seven is the last. So let's, that's something they want to make it more comfortable and seems like Python is kind of.
Now, very, very interesting language because it's a language that scales so you can as begin or start programming with Python and is very small software that Python you get something done.
But I've been using Python for 20 years. I'm still learning and I teach advanced Python training with meta programming and stuff.
You can do a lot of funny things you can do, but very few people actually need it.
Yeah.
I have never used some production. So even if I've studied them quite a bit for the training, but there's very few use cases for these things.
So it's a language that kind of scales pretty well. And it makes it interesting for a lot of different applications. So the typical user who switches from using Excel for bin analysis to Python.
And the other one is writing very sophisticated AST abstracting straight format formations and converting Python into other languages and doing all kinds of these kind of things.
And that's I think that's one of the talk about it already. So Python has a lot of ways to connect with other languages.
It's a sub set of Python or super set of Python that can translate Python directly to see in addition to wrapping CNC plus last libraries.
There's a Python in Rust. There's Python in that assembly pilot right running the browser.
And if there's another language that will be another binding, so that's probably one way that Python could continue.
And it will be very often the go to getting stop language for programming.
I think a lot of universities nowadays, they switch to Python as a programming one or one language, which used to be Java or sometimes you can see plus plus, but Jeff might agree.
Somebody never programmed before starting the C++ to be the best experience in terms of how fast you can progress.
Python is way more approachable, I think, because you can just start doing some very small scripts that moves your files from left to right.
And there's doing something useful. And then if you want, you can, you don't even the right of function if you don't want in the beginning.
And then you can learn how to write a function and make how to write a class. And you can go gradually and can learn.
You can use a lot of libraries. That's the other thing, which is Python's to be expanded like that, like 250,000.
Libraries on this Python package index, Pi PI. Yeah, that's a Pi PI. And that's a Pi Pi, which is a different Python implementation.
Don't confuse to both the Pi PI, Python package index, and has a lot of a lot of libraries for pretty much everything.
So if you have a task, I think this problem should have, somebody would have had it before.
It's very likely that there's a library out there that is doing it.
And very often, you can do the only thing you have to find a word how to search for it.
The search in Python, I very often gives you many, many hits, which are totally irrelevant. So the search is not that good yet.
Like Google search might be even better. Yeah, Google has some different algorithms to search.
But very likely once you spend like half an hour searching and evaluating different options, you probably find library.
So the 80 or 90% of your problem already, you just have to write to rest. Yeah.
Continue. I think this is something that Chris has done himself right.
A lot of time he mentioned that if there's a piece of code, he needs to write it all go on and collect various bit out of out of Pi PI and.
Modifying and glued them together. Would you do the same with with with rust on with the crates approach?
Absolutely.
In contrast to Microsoft observation that predictions are hard, especially if they're with the future, I'm happy to report actually since now I got the flux capacity working.
Yes, indeed.
So I'm happy to report that in about five years time, rust will have taken over major portions of the open source language ecosystem.
Ultimately, resulting in a version called Linux. What is it?
10.5, which which basically now contains and we're talking about the year, probably 20, 34 or 35 will contain about 70% rust.
The rest is still see legacy code Python will have a niche existence.
Mostly confined to big data.
And see yes or C++ maybe mobile, but rust ultimately will take over the universe, no jokes aside people.
Every ever language has their own specific purpose has that own specific I kind of target audience.
The idea when when Brendan and friends basically about 10, 10 years ago was a set down and this is rust thing.
Was to come up with it with a performance low level language aimed at system programming because essentially what this is what they did when they set down and wrote something called servo.
Given the fact that the ecosystem is growing by leaps and bounds something that took Python about what 20 years.
Rust took only the rest of the ecosystem basically took about 10 years to reach.
I wouldn't say the same level but pretty close to it.
Going forward I see I see rust basically entering.
More and more.
I wouldn't say just low level use cases, but also kind of system domains just put it this way you see this actually if you take a look at the.
At the at the current developments the top project as in the onion router basically is talking with rust.
Microsoft has just discovered that rust is actually a program language going forward, which is in which is very interesting.
As a presentation you find the links in the show you find the link in the show notes.
There's actually a presentation from Microsoft about couple of months back where they said they they are actively evaluating rust in the number of projects where previously and Jeff probably agrees.
C and C++ were the languages of choice for Microsoft to implement their applications and operating system.
For example, much of office is actually written in C++ as a Microsoft office.
Going forward they made different choices.
For example, Visual City code is mostly written in TypeScript.
Python is done to it Microsoft, but it wouldn't surprise me that in about five to 10 years time you'd see much more not only cloud and stuff as an Azure and friends, but also native applications emerging from Microsoft being written in rust.
And you'll see a broad adoption of rust all over the place and Tom Microsoft, I'll just be into examples here. Plus of course the Linux kernel.
It's a very bold prediction.
It's the truth.
What do you think Jeff? Is there anywhere close to the truth?
I don't know if that's the truth, but I think it is would be a good truth, a good future.
I mean, part of the reason why I like rust I think is is because it solves some of the biggest issues that we have.
Like when I use software, I mean the two biggest problems I have in general or one, it's too slow and two, it's too buggy.
But what we need is programming languages that attack those two things primarily.
And that means performance has to be key like a central part of it.
And then safety and rust is all about safety.
That's part of the reason I like C++ is that in some ways we're allied.
The a lot of things that they've added to C++ all the zero cost abstractions, all the higher level stuff that gets like brought down in the compiler to like really efficient code.
That's similar to what rust is doing, but rust is like a clean start, right.
So in some ways, I see it as as like C++ is a little brother.
I don't know if rust likes to be seen that way, but, but to me as a C++.
And I want that little brother to eventually take over grow up because the problem with the C++.
And I was kind of reminded of this when we were talking about Python two versus Python three is that they will not break backwards compatibility for the most part.
There are like you can craft a program that will work in older C++ that will not work in newer C++ like if you intentionally use keywords that were added later things like that.
But for the most part, they won't do that. And that's because so many of the people who influenced committee work on large code bases.
And they're they're very aware of that. They don't want to break anyone's code.
So they'll do things like they'll like they'll acknowledge that no is is bad.
We inherited that from C, but the fact that it it's an integer and a pointer right and a Boolean like that was bad, right.
So they introduced no pointer, which which is targeted to one use case, right.
But then they didn't get rid of no. So now there's all this cruft.
And part of the problem is that they can say like, you know, you only need to learn the new stuff, but in reality, you're working with code bases that have existed for a while and you actually have to learn both the new stuff and the old stuff.
I mean, you'll never have to learn everything because there's part of the C++ philosophy is like everything is possible.
Like whatever it is, any crazy way you want to do something is supported.
But, but yeah, that it's it's both a blessing and a curse, right, that like we can't get away from some of the core issues that were introduced in the language or that were inherited.
Yes, and I mean, obviously the standard keeps evolving even with C++, right. And I mean, Chris mentioned, you know, adoption in tour and potentially Microsoft, but there is obviously a large amount of backing for the language, right.
Which is more, well, more proprietary perhaps than done for rest, but it's such as such the language will keep growing as well as as end evolving, I'm sure.
Oh, it is. Yeah. Well, so like, that's the other half of what sort of what I wanted to say is it is a very rapidly evolving language. And it's a very exciting language, at least for me.
But in that like, right now I'm working in C++ 14 primarily, just because we don't switch to new things until we are sure that every platform, every random color that we might have to use supports it.
But there's like every day, I'm like, oh man, there's this stuff in C++ 17, I wish I could use, right. I wish I could use standard optional. I wish I could use like initializing two variables from one function call.
Things like that. And it's just like literally the day to day stuff that I do is better in C++ 17 or would be better if I was using it.
And this is the same as true for C++ 20. So like a lot of things they are working on are really, really are day to day things because I see a lot of criticism on the internet, like, you know, oh, that they're off like messing around with templates that only matter for, you know, people who write boost or certain libraries.
And that's not really true. Like the way I write C++ now is very different from the way I did it 10 years ago. And I'm very certain it will be different 10 years from now.
Different and better, I should say. So for that reason, it's really exciting because I have, I mean, there was stuff that was like standardized three years ago that I'm still not using.
I know that they're there and I'm excited when we when we approve it in our code base that my life will get immediately better and that they're working on the next things as well.
And the fact that they won't break any of my existing stuff is actually pretty nice. So, so yeah, I think it's a really fun, interesting and exciting place to be, you know, in the C++ world.
Quick, bold question, Jeff. If you consider us to be small brother, the small brother of C++, what do you think is the ultimate shape of a shelf life of C++ going forward?
I don't think it goes away and I don't think rest will ever replace it completely.
Interesting.
There's just like, there's too much there.
Legacy. Okay. Yeah. It's not just legacy. There's still certain things.
And I haven't gone deep enough with rust to know, like, as soon as I write some big rust program, I'm going to find like 20 things that I like more about C++. I'm sure.
Just because there's just so many more features in C++, right?
So there'll be something missing that's been my experience with pretty much every language that I have to use.
That's when I switched to something else. I'm like, oh, why does it like I was doing go recently and there's no generics and go and I was like, oh, my God, I just wish it was C++, right? So I'm sure there'll be things like that.
I mean, rust does have generics, but there'll be other things like that that will keep C++ programmers using C++ even for new code.
I wouldn't go so far as to say it's only legacy, but I do think in general, it's a good thing if slowly rust takes over some of the C++ ecosystem.
Just because I think it's targeted at like the things that we really need, which is fast, secure programs.
I mean, C++ is now 40 years old. I think started to develop the language in 79.
Right. Give us a few more years.
I think it's mature to increase.
But I think part of the part of my point is that like it hasn't gone away in 40 years, right?
Like major languages, like it's going to continue on because it already has 40 years of momentum, right?
So for that reason, it will be hard to replace.
Neverminds a large code basis for C++, of course, yes.
Yeah, I mean, whenever you hear about these bugs, like heart bleed or things, you know, my non programmer friends, whenever one of these hits the generic news or the general non programming news, they go, why is there some bug from?
Like this program in 1991 or whatever.
And it's just like, because everything in computing is built on what happened before.
So we have decades and decades of things going on.
And it's like everything that's been built so far.
I mean, some of it goes away and gets replaced, but it's not just C++, Python, all these major languages are going to be around for many, many more decades.
And that's just the way things are, even if it's not the way things should be.
But I do think that there are still cases where C++ is the ideal language.
And I still have to put my disclaimer that I haven't gone deep enough with rough.
I could just completely change my mind.
I could do a follow up episode next year.
Excellent.
All right, Gents.
Final closing remarks from anyone.
I think that was a great discussion.
And as you've all said, the future of these languages is going to be there for a number of years to come.
We've seen some of the upcoming of Ross.
We've seen the variety and expense of the libraries for Python.
But yeah, so it's your final remarks from anybody.
Maybe just this prediction thing.
So if if Rust will kind of take the increase a lot, and I see a lot of more.
Rust based Python extensions.
So that's for Python school.
It's existing already.
There are some, some people are fitting around with Python interpreter written in Rust.
And right now you can also already write extensions.
And for us, if Rust will take over more of this C++ C kind of field of this low level system language programming thing.
Then I will imagine that the person will have way more extensions that are written in in Rust.
And I think Python really focuses more on this application programming thing.
And then you can take advantage of this libraries.
And you don't have to have to actually know how Rust works.
The programmers are this field.
They don't know Rust, but they can still use a functionality to an extension.
I think that's, that's going to develop.
That's not going to go away.
Okay.
Next one.
Yeah.
No, that's a fair point.
You say your analytics user or those kind of users of a program language.
Then the primary focus is not to write a production.
Many programmers to get their problem solved.
That's your language.
Yeah.
That's one big application area.
So one thing is it's just a lot of people using programming as a tool as part of their job and their engineers or some are kind of things that they're using for problem solving.
And that's a big part of the Python use cases.
There are also people that writing big applications and Python themselves.
But I think by the numbers, there's way more people using Python as tool designs other things to do.
Okay.
Chris, final remark from yourself.
I reckon the whole.
That basically centers around the ecosystem.
Right.
I mean, that goes for C++, C.
Python.
Lesb.
Rust.
Just in a few languages.
Nevermind for them on the rest of them.
If you can convince enough people to contribute to the ecosystem, you get that growth that pipi has been experiencing for the last 15 years.
You get all these libraries like QT for graphical user interface like the GTK for for low level.
We stuff in and so forth.
And they are written in C and C++.
And so going forward programming will consist more and more of taking a look at what's out what's already out there.
And then how to solve the problem with already existing code.
Needless to say, as we saw with hardly another stuff that has that has a certain level of security implications, because if you're using code that you that you haven't written yourself, you don't necessarily know about the technical depth.
Nevermind.
Nevermind.
The about the attack surface of this code.
So it's a balance basically between simply reusing the existing code basis and.
Quality assurance as a technical as a technical depth minimization in terms of how much do you want to spend on making sure that the application does what you wanted to.
Especially in the secure context.
And I reckon this is essentially where rust shines because.
The ecosystem basically consists of rust code and you can be sure of.
The rust compound accepts a code base.
It's normally to some extent that is already.
Because you cannot compile unsaid code, for example, in rust.
And so for me going forward and would be interesting to have the same conversation with the same people in about 10 years time to see if the predictions were right or wrong.
To see where we are with regards to the surrounding ecosystems of these languages and basically how they're grown.
And also basically if there are any favorites, for example, my correct me from wrong, but there are at least three or four web frameworks in in in in python.
And nobody.
Three hundred web frameworks and.
There's there's a few big ones like Django is being the biggest one flask is maybe the runner up and then there's many others around.
There's many new ones coming up because for the easy they're getting better because they learn from the mistakes of the things is always.
That's advantage in this advantage open source because everybody can roll their own.
So a lot of this frameworks out and you don't know which of them is going to survive Django is going to stick around because that's a big.
200 pounds of 800 pound gorilla is a say the big one and a lot of people use Django it's because it's very opinionated out of out of box everything works.
And there are many more micro and mine mini whatever frameworks you want to call them that are have a different approach and you can put things together.
So that's that's like the back space back the application space from python and you have many many new ones that.
Some some are very good in some particular kind of things now everything's getting asynchronous.
And there's some things that just you just can use to use rest applications like this sending Jason back and forth so to speak.
And you don't actually have this HTML generation anymore on your back end.
So there's many different base develop and you will in time will tell which one is going to survive which one turns out to be still relevant in 10 years so.
And I don't claim I can't predict it just say we have to see what's going.
It's not about the ecosystem. Yes, Jeff over to you. Sorry.
Oh, yeah, well, I don't like I don't want to make any predictions about 10 years from now, but I do like what.
What we were saying about python being a language that's easy to learn and I think like each of these languages has their own niche.
And I do think like all all of these languages can grow in their own way, even though I did say I was hoping that rust eats some of the C++.
Some or or user base.
I think 10 years from now will will be in a situation where things are more aligned to way this the way they should be because we have more options now.
And the ones that the ones that are the right options for the right types of programs will naturally grow.
Or at least hopefully.
I guess that's a Darwinian argument, but but yeah, I just think things are going to get better and better.
As as like all of these languages grow as their ecosystems expand.
And as people learn the right use cases for the right languages, right.
And based less of their stuff on what was the legacy.
So I think it's going to be a good place to program 10 years from now.
Or good time, I should say.
Excellent, excellent.
All right, that's like to finally then say thank you very much everybody for your contributions today.
It's been very insightful and we'll hold you to that five to 10 years.
We run off the episode to see where we got to see with this.
Thank you very much for having me.
Thank you very much.
Pleasure pleasure.
Very interesting discussion.
I actually want something today that's always good.
And thank you much for giving rust chance Martin.
That was a very interesting panel discussion.
Martin.
What do you think?
But yes, no, he was I thought it was very interesting.
And as Espera news, it looks like a rest is on the way up.
But yeah, likewise, as we all know, C++ has a large installed code space in many organizations.
Right.
So it's not going away anytime soon.
But you see, if companies that Microsoft are actively considering doing new projects in rust,
there must be something to it.
Of course.
No, I mean, new projects, yes.
If you think about certain software companies that are still running Python 2.7 as part of their code base,
then you know what I mean, right?
Then adopting something that rust more globally is a long way off.
Agreed.
But given the fact that C++ used to be the workhorse at Microsoft in terms of both operating systems as well as applications.
That's a, I wouldn't say it's a bold move, but it's an interesting development.
This way.
Yes, it's very significant.
That's for sure.
We're coming from Microsoft.
I agree with that.
Yep.
Okay, and then it's on to feedback, right?
Feedback.
Yes.
Yes.
Okay.
Should I go first?
Yes, ma'am, please.
Do you have an hour?
Because we have six.
Well, you can.
Some feedback from great J.
Yeah.
20 pages long.
Well, why don't you give us.
Why don't you just give us the highlights, rather than kind of reading it all?
Okay.
The highlights are if you believe in certain religions, then, yeah.
This is the article to read order text.
Okay.
So, yeah, you got the idea, right?
I do get the idea.
Yes.
So in contrast to this bit of news, which are sorry, this bit of feedback, which was clearly not destined at Linux in loss alone.
I'm looking at an email that Emma wrote that Emma wrote in.
Sorry, Emma is of course from rainbow escorts during recent visit.
I had the pleasure of servicing Martin.
Martin, you you actually took my advice.
I don't know why she's writing to you.
Well, we come to that in a minute, but.
Okay, this is for those of you who missed the last episode.
Martin, let me give you the background of the story.
Martin again tried to claim expenses for an expert service that he used.
Thus, a violet violating Linux in loss expense claim policies be accounts.
Wasn't accounts payable.
Wasn't too happy about it.
So they got in touch with me and said, now look, have a work with the goals, right?
Which I did.
And subsequently Martin decided to actually follow my follow my advice and use rainbow escorts services because we do have a corporate account with them.
Perfect.
Is this something you instated?
You should have told me this.
Well, I did tell you Martin.
Okay.
Again, during a recent visit, I had the pleasure of servicing Martin.
So most of his requests were nothing special.
I see, Martin, a few of the things he desired were a bit on the unusual side.
Interesting.
Unfortunately, this no, this isn't explicit show, but the next couple of things that Emma writes are clearly tripled X plus.
So we won't go to the details.
Okay.
No, I thought you were going to say something about her reading chapters from the C++.
No, no, no, no, no, no, no, no, no, no, no, no, no, no.
And actually another very interesting observation.
So we're going to skip the funky, the funky bits.
She closed that feedback with.
I quote apart from his stunning physique and must let statue.
There are other parts of his body that make him ideally qualified for a career in the adult entertainment industry.
More than happy to broker the initial introductions, etc.
Martin.
I see.
There needs to be sort of middle aged bull to be in this industry.
Martin.
Or so you tell me any of this.
If this hole IT's windowed lowest, you had your head it for the porn industry.
How good is that?
I don't know.
You tell me.
Money to be made Martin.
Isn't that your side show?
No, it's not funny enough.
Okay.
I thought since you're usually unavailable in the evenings.
Just let me know if you're serious about this.
And a website can be whipped up on short notice.
I see.
Yes.
I'm sure these things can be arranged pretty quickly.
Yes.
Let's stick with the IT site.
Coward.
Martin, imagine I mean you then kind of appearing on.
I mean, what is the porn, porn industry?
You could have learned of the of the academy awards.
I'm sure that there's something.
And I basically once you win this, I can basically I can say.
I knew him when he wasn't famous.
I see.
Do you think this is beneficial to the propaganda of legacy?
Maybe.
I don't know.
Well, if you agree that this is a why don't you set the example, Chris?
Littings in us as a breeding ground for budding porn stars.
Interesting perspective there, Martin.
Okay.
Martin, if this whole startup GPU data business blows up, just just go for it.
Thanks.
I written with with my current prior who happens to be also Martin's previous employer.
It's a little bit of more time because we just had another injection of funds into the company.
But that's besides one.
So maybe meet you on the other side in cup of years time.
I don't know.
Other side off.
This is just an expression, right?
Meet you on the other side in terms of meeting you on the set.
Is that one?
Oh, I always see a thought when you expired.
No, no, no, no.
That's the other side, journey.
No, porn stars don't expire, Martin.
Porn stars just go to a different sphere.
In case you didn't know.
No, I didn't.
Sorry.
No, there's something that's studying that close.
Apparently, Martin, there's still a learning curve to master before you can venture into the other industry.
But given the fact that you have that you're significantly significantly younger than I am, there's still time to learn.
So that's okay.
Excellent.
Okay, people, that's pretty much it.
And as Martin has anything to add about his second career choice.
Option rather than choice, but option.
It's probably more like the 15s rather than the second to be third off.
Okay, people.
Yeah.
We are on Hacker Public Radio, as usual.
Credits go, of course, like a public radio, third off.
Feedback can be sent to, like, am I dead?
And like Spammers do apparently.
Feedback can be sent to feedback at Linux in loss or one word, dot EU.
And for the time being, yes, you will find us at public radio.
We should change.
You will be the first, you know, listening to this podcast and see you at the next episode.
Before we conclude today's episode, a shameless pitch for the upcoming Big Halloween special
at the end of October.
We need your questions by mid-October.
Ideally open source related.
Unfortunately, what are next week's lotto numbers?
Or what's a must for number?
Only have a slim chance of getting answered.
Simply send your questions to feedback at Linux in loss or EU and listen to our Halloween special to hear the answers.
This podcast is licensed under the latest version of the Creative Commons license type attribution share like.
Credits for the intro music go to blue zero stirs for the song solid market to twin flames for their piece called the flow used for the second intros.
And finally, to select your ground for the songs we just use by the dark side.
You find these and other details licensed under CC at Chimando.
A website dedicated to liberate the music industry from choking copyright legislation and other crap concepts.
Thanks for watching!
Hi!
Hello!
Mr. Wissack, glad you could join!
I'm no problem, yeah.
Martin is pretending his German. He's Dutch, my origin.
So, reckon we should stay English.
The last name I'll tell you, this can be a German name.
I think that's nothing special at the end of the week.
I do think you're Russian in German can muster up to the requirements.
It's a big question.
Yeah, okay.
I'll tell you what.
It's ROS-C.
ROS-C, yeah.
ROS-C, yeah.
Okay, I think we're just waiting for Jeff and then we can get started.
So, and I'm not familiar with a podcast, I have to say.
So, that's a Linux podcast, is this right?
It's an open source podcast.
Open source in more general in open source.
Okay, yeah, maybe, maybe I should explain this.
Why don't you give a shout-in German?
So, come on Martin, try your term.
Okay, so, the Linux in those are two people who are very old.
Very good.
And the Sprachen-U, often a source.
I press.
If my Dutch was as good as your German.
It's a long time since I spoke in an interview.
Okay, by just a minute.
This all started about almost two years ago in the small location in Prague, in Czech Republic.
Um, where some not as decided now it's time for, it's like a humorous podcast.
And hence, Linux in those was born.
I don't know if, if a former named Linux Outlaws rings a bell.
It was a podcast that started about 15 years ago.
Maybe, maybe less by Dan Lynch and Pap Chasel of, of the H fame.
And of course, Dan Lynch being one of the people behind something called Ockcamp.
One of the large, open source UK conferences.
If not the largest, and then Dan got ill and they terminated the podcast or shut it down for wonderful better expression around 2014 to 2015.
Some of this.
And the ill laws are pretty much a little bit of the legacy of the Outlaws.
Um, slightly more on the communist side, more on the humorous side.
Um, but apart from that, keeping up the spirit of free and open source software.
Okay, yeah.
There's a beautiful homepage done by our own Mr. Visor.
Um, and Linux, it lost on you domain.
Linux in laws. Okay.
Hello my.
Yeah, right there. That's nice.
And now you know how Mr. Visor looks as a mom.
Yeah. Okay, so you two have met.
Oh, yeah, Uh, we met.
We first I'm around comments for it.
But maybe two years ago.
Maybe one year ago.
We met last year and we talked a long time, probably we met before, I think you met the
year before also.
But last year we were sitting there for an hour talking about things, I remember.
So it can mean that I talk a lot of people so, and I talk a lot of usually when I'm traveling
talk a lot of people so I might get a little bit to and I'm talk to.
Sure, you didn't forget Chris.
That's so quite difficult.
Thank you.
Who needs any of these in this case?
If you have friends like these.
And nice radio here, the picture of the radio is from the 60s, I guess.
Yeah, for Chris, I have to go to Martin because he did the lion's fair off the website.
I just kind of fiddle around with a little bit here and there.
You've been listening to Hacker Public Radio at Hacker Public Radio dot org.
We are a community podcast network that releases shows every weekday, Monday through Friday.
Today's show, like all our shows, was contributed by an HPR listener like yourself.
If you ever thought of recording a podcast, then click on our contributing to find out
how easy it really is.
Hacker Public Radio was founded by the digital dog pound and the Infonomicon Computer Club
and is part of the binary revolution at binrev.com.
If you have comments on today's show, please email the host directly.
Leave a comment on the website or record a follow-up episode yourself.
Unless otherwise stated, today's show is released on the creative comments,
and we'll see you in the next video.