Nicolas: Hello and welcome to another episode of The Walking Deaths. I'm Nicholas and I'm we are walking in the beautiful Prada again this weekend. ⁓ How was your week, Philip?
Philipp: I am Fili... Yeah, It's been an interesting week for me. I cannot go into more detail yet, but some exciting developments.
Nicolas: Looking forward to hear about it. My exciting development of this week was I tried to set up my development environment again. have this idea that I want to use Vim for development. ⁓ It's Vim time again. It's every year that comes a new, ⁓ year in spring I'm thinking I will be a Vim developer. tried a few attempts. So
Philipp: swim timing.
Nicolas: For the last 16 years, honestly, I tried to go to Wim completely. And the last years I at least settled to use Astro Wim, which is a distribution of Neo Wim with many packages installed. It's the ⁓ my ZSH for your Wim config. Okay. And so all real Wim users, please don't complain about me that I use this stuff. And then I realized something this week. So I was mostly in my terminal. And then I had to switch to my editor and I have these multiple branches or checkouts of the repository. And they need to switch between editors that have these repositories open. And this was annoying. So I thought now with LLMs, I can finally treat my WIM config. It will be fixed by the LLM. And this was a good realization. So I now have TMUX where I have three windows, one for cloud, one for lazy git and one for WIM. This is perfect use case because now I barely need to write code. I only need to read through it maybe and maybe ⁓ sometimes modify some Perfect use case. Now I'm on the Wim train again. Let's see how long this holds up. ⁓
Philipp: exciting. I'm rooting for you. I've been trying out ⁓ Z more because the only times I opened my editor which ⁓ used to be Cursor because it's just a nicer looking VS Code. It was giving me like all these update notifications and like side parts that I don't really care about so I thought maybe I can just use Z and it pops up immediately but somehow it's like hard to find the time to change the ⁓ because I'm just not as much in the code anymore. Maybe this will change
Nicolas: ⁓ also tried to switch to SET ⁓ SET is fast at least, way faster than VS Code. ⁓ my problem with SET is like some shortcuts and some very small tiny details that I was missing. And then ⁓ couldn't switch completely. ⁓ there was one more thing. ⁓ SET has so many updates ⁓ it basically ⁓ a delay every time you want to start it ⁓ it needs update. ⁓ And this was annoying.
Philipp: Yeah, same with Cursor, This doesn't force it, but it's always popping up. This company's shipped too much.
Nicolas: We just say, Okay, and the problem for me, cursor is I feel like a boomer ⁓ using the internet because I'm overwhelmed as hell.
Philipp: Yeah, you have to disable a lot of things. Speaking of cursor, there's a little bit of drama of the week. think that's kind of be fun. So cursor last week released their new custom model, they call it like their own model Composer 2. ⁓ someone on the internet found out pretty fastly that it's the same tokenizer and similar model strings than TMEK 2.5. which is an open weight model from ⁓ Kimi, like a Chinese company. licensing-wise, it is not allowed for them to redistribute it. So people were like, ⁓ is Kerser doing? Are they going to make the reputation? Like everybody's just copying them against the terms and doing illegal stuff. And everybody was like, ⁓ this is really bad for the open weight community because the company now benefits from them. And the Kursha team immediately said, don't know, we talked to them. It's like all good. And they had to basically get someone from the Kimi team to tweet that this is a licensed agreement and the license partnership because they wouldn't shut up about it. So yeah, this has been a little bit of a drama. I think it's interesting that they take like this approach and try to like market this their own model. Apparently like they did a lot of fine tuning on it and reinforced learning. Yeah, I don't know too much of that stuff, honestly, to judge it,
Nicolas: And do you know more about this Keme model? Like, is this a distilled model? Or is it, did they build it on their own?
Philipp: I don't think anybody knows how these are built. They're open-weight but the training data is not open as far as I know. So nobody knows how these are built.
Nicolas: But it makes total sense for Cursor. I mean, you have the 15 billion dollar valuation now. my thinking with all of these EI startups now, I don't get their revenue stream. Of course, they always tell you like, oh, we have so many millions of revenue per employee. But to be honest, like they are mostly reselling tokens. The only company that benefits in end is Nvidia that has like a 75 % margin share. on on the So ⁓ never understood this whole business model and it makes sense then for me like Cursor ⁓ wants to move away from OpenAI ⁓ ⁓ and all the other LM providers because they want to resell their own model where okay hardware is cheap, we need to build maybe data centers which ⁓ mean.
Philipp: partnering with inference providers.
Nicolas: Okay, they don't to host it, ⁓ but I the margin will be way, way higher if they have their own model instead of reselling tokens.
Philipp: I don't know if people actually know what the margins are for companies like Antropiq and OpenAI. It's like so much discussion that says, oh, they're selling subsidized token with those plans. But I'm not sure if this is true. I don't think we have any official information. I don't think they would make a lot of loss with their approach. Maybe a little, but definitely not the exorbitant one. I don't think they pay the same price as API customers would pay in terms of resources.
Nicolas: I think the biggest price ⁓ these ⁓ providers is like the initial research definitely. ⁓ training costs dozens of millions. ⁓
Philipp: It's more and more every generation.
Nicolas: And then of course, building the data centers now where you give a lot of money to Nvidia. And I think these are the heaviest.
Philipp: It's not only Nvidia, they're already using the TPUs as well. ⁓
Nicolas: think from Amazon. Yeah, and I'm not sure.
Philipp: Both and open the eye and then.
Nicolas: But this was this was this weird deal from Amazon. they Amazon invested in OBI in the last round but with this deal of we give you a 30 billion dollar but only half of it like you get now but most of this what we give you you need to spend on our own platform and use our own GPUs. Makes total sense.
Philipp: makes sense. this is all gonna be interesting in the future.
Nicolas: Also, there was an interview with NVIDIA CEO Jensen Wang. and of course he says that every engineer who gets paid 500k a year should at least use 250k in tokens. people who are just working on a side projects like usually they like these $20 subscriptions maybe $200 and ⁓ they are mostly good with it like if you're not Peter Steinberger ⁓
Philipp: He doesn't have to pay for the subscription anymore,
Nicolas: But I think for enterprise, you need to per token if you have an enterprise account.
Philipp: Yeah, I don't know exactly how this works. I'm pretty sure if you're like a smaller company, you still can use these subscriptions. But probably once you want to enforce your no data retention policies or something, you probably want ⁓ forced off that. I don't know.
Nicolas: and here what I'm wondering is right now the whole industry says like burn the tokens as much as possible. Every tech CEO is like burn tokens, burn tokens, build things. And I'm unsure how much they think ahead, like how much this costs in the end compared to the benefits they have to get from it. Especially because if you burn tokens at some point you get lazy. things that could be automated with a script suddenly get done by an LM. Maybe even with the largest model because you forgot to switch or whatever. So curious how this works out financially.
Philipp: So your prediction is that in the future companies will realize that this is a lot of
Nicolas: cost? Yeah and they will try to cut this cost down by either telling everyone you're not allowed to use this model because costs too much ⁓ or they will likely enforce like a limit per then there must be something because it costs a lot money ⁓ and we don't see like a 10x outcome yet right
Philipp: Yeah, I see.
Nicolas: My unfortunate prediction. This is a dark one. Companies will just lay off the people so they can compensate for the high costs. That is it. It's happening.
Philipp: which was already happening but with not much data to prove at least some of the effects.
Nicolas: I mean, we see it with Oracle later people because they need to invest in their AI data centers, although like Oracle was not a good case before because they suffered already. Meta like there are rumors that they lay off 20 % of people
Philipp: also recently did layers
Nicolas: Yeah, block also did layoffs, Although they also didn't work that well, So I think it's a, they just say like it's because of AI.
Philipp: Yeah, we don't know that. Or maybe we with public eye of not here. I don't know it. What's the positive thing of the week? We've been really thinking about this, have we?
Nicolas: So positive thing of the week is that I try to use Vim again. Let's see how long this keeps up.
Philipp: That's good. My positive thing of the weekend, I tried Go. Yes, I tried Go with a friend, a shared friend of ours. We were thinking about a command line tool and I just, you know, instead of saying to the AI use JavaScript, just said use Go and it did some stuff and I looked at it and it probably makes sense. Yeah, there's definitely some cool things that the single binary build just works. The networking library is so much more reliable.
Nicolas: You tried, go really.
Philipp: And when you're going to set it up, you know, with an agent and the loop where it can verify itself, in this case, this is like about setting up an Incos cluster for you for like the stuff we talked about last week. And we wanted to test it. So in the prompt for it, I said, it should use the HCloud API, the Hetzner Cloud CLI. ⁓ basically to provision servers, run the thing and delete them again and do this in a loop until everything works. And surprisingly, you know, I'm not surprised at this anymore. This is crazy, but somehow I'm like, I'm expecting this to work already. And of course it did work. It's one shot at this implementation. ⁓ Yeah, pretty insane. That's cool. Yeah. I'm pretty, I'm pretty bullish now on Go again, because when we were working on this kind of hack thing last week, I wish we had something that is more robust in the backhand but still nicely and easy to deploy like a standard binary. But yeah, you can just write GO I think for that. It's a good language for it.
Nicolas: This is definitely a good language. for me, I tried to look at goal like one and a half years ago and it didn't click, also so coming from Alex here, I didn't see a benefit compared to go. Although I see the benefits of you have this binary that they can install. the ecosystem is way richer.
Philipp: Yeah, the networking code is brutally good compared to JavaScript. Basically, I feel like wipe code. Just a little bit of a fun fact. We found a bug in the ban runtime that allows you to not use your self-signed certificate for serving TLS traffic. It just doesn't work. Nobody cares, apparently, for this.
Nicolas: And there's another thing, the Go networking layer is part of the standard library. Yes. There's this, think no other languages, no other language has this really, right?
Philipp: May not has it was not good.
Nicolas: Yeah, okay, sorry. No other language has a good one. Yeah, that's true. For even Alex here, you have a bunch of libraries. They're actually good, not part of the standard library.
Philipp: I want to love Go more. used it in the past at Sourcegraph and I think we both have like a little bit of experience with writing C from like our early school days. And I feel like Go is a lot like writing C. have structs basically and you just pass things around in functions. But yeah, I definitely miss the muscle memory.
Nicolas: That's my problem. I can't look at the code and immediately see what's happening. Also because of, I think this is my biggest problem with Go. I need to skip all this if not error cases in my head. And a bit of time to get used to this.
Philipp: Yeah, I hope I can do it more because I prefer it over Rust. I feel like I'm not smart enough for Rust. Rust is too complex for me. I used it at Tewin when I was pair programming with people that know Rust. But there's just so much in this language and I'm like, I'm not smart enough for it.
Nicolas: Me neither. Go is quite simple in its way.
Philipp: There's another positive thing of the week, not that I'm speaking about rust. Because There's this company called Astral that as far as I know, built implementations for Python tooling. Tools like UV and whatever they're called. I'm not really familiar with the Python ecosystem, but they built that in Rust. So they made this kind of insane Python tooling, saying again, making it fast and everything. And they were just, as was just announced, they're going to join OpenAI in the Codex team, I think it paints an even more interesting picture on how DevTools work, because I don't think they had any revenue prior to that. And Bun, I know they don't, did not have any revenue prior to that. So a lot of these tech DevTools companies right now seem to only like build something people want and then be sold. I think that's like the strategy.
Nicolas: strategy. ⁓ also like that these companies get bought because then ⁓ then they have enough time and ⁓ money spend on having better developer tooling. think it's great.
Philipp: Yeah, I read a commentary from Simon Wilson who mentioned Armin Roenacher and I think the thing is even if this kind of source project was to be, you know, changing lives or anything weird were to happen, ⁓ it's in such a good that the community could fork it and still benefit from it. So the kind of existence of UV made Python so much better for everyone that it's like a net positive thing no matter what happens now. ⁓ I don't really know why they'd hire them, but I feel like, know, Codex is written in Rust. So maybe they just wanted to have some really good Rust developers.
Nicolas: I would love to see more businesses investing into languages that I'm working on.
Philipp: The part is what other, maybe we end this with it, what other legacy toolings exist out there that have horrible workflows and someone just need to found a company, rewrite the tooling in Rust and make it fast again.
Nicolas: Good question,
Philipp: How fast is RubyLinter?
Nicolas: ⁓ god, let's not get started with think with Ruby only have Shopify that has money to invest into it.
Philipp: I don't think it does not love users as well Ruby anymore compared to like TypeScript and Python of course. But then maybe some database tooling. I don't know everybody uses Postgres. Maybe there's stuff there.
Nicolas: Yeah. That was what I mentioned three weeks ago, think, with PJDog. That's also, I think, in Rust or Ingo. And they are building the sharding. And exactly that totally is missing. There's another thing that is missing from you on the Postgres side. But to be honest, there's a business already out there, which is Monitoring crewbies and generally Postgres monitoring. And there is PG Analyze, for example, also somewhere from Vienna, Lukas Vittel, who did an amazing company there ⁓ on Postgres tooling. There are other Postgres companies out there as well, but ⁓ this is more and not open source.
Philipp: Yeah. So a lot of money still to be had by developer tools, but also really hard to stick through, I guess, the masses.
Nicolas: Yeah, and I would not give a bet on being part of the JavaScript ecosystem because it could be that you are away in three months and no longer the default tooling. It changes so fast there. So I think other languages are ⁓ better to invest in. Like Python, there was a lot of improvement to be done.
Philipp: The fan works, and it works in the TypeScript ecosystem. True.
Nicolas: And there is, for example, this UV improvements that they made. There is a blog post by Patterson, ⁓ very ⁓ Rubyist, ⁓ tried to figure out like what could we put into Bundler, like the Ruby ⁓ that we can learn from UV. yeah, ⁓ that out. It's exactly going in the same direction that we can actually have many improvements, ⁓ than you think. One more thing about improvements. was, in the Ruby land, there is a renderer in Ruby. I'm not sure how it's called. And Tobias Lübcke, who is the CEO of Shopify, he ⁓ let a large language ⁓ over like a whole night to improve the renderer. ⁓
Philipp: This is auto research stuff that Kapati
Nicolas: and it got 50 % faster. of people worked on this over the last few years. So you can definitely still have improvements in all of the toolings, which is good.
Philipp: Yeah, this is, I need to do something with auto research. I think that's a really interesting pattern. As far as I understand, it's a Ralph loop, which is basically just a while loop over make your thing faster. And then when it's done, make your thing faster again. And like clearly like a measurement cycle as well, so it knows it's going in the right direction.
Nicolas: There's one problem I have with this whole new thing that's going on, like the whole AI development. There are so many names for things that are actually easy.
Philipp: Yeah, it's always been that way.
Nicolas: But then there are these MCP protocols like then there's ACP and there's like this and you think constantly like ⁓ I'm too dumb for all of this. ⁓ Did I miss something in my research or like am I over learning? Is there something new? And then you find out okay it's basically a loop and an if and it's always like that. It's just a fancy name. ⁓
Philipp: It's a multiplication now, that's really become really important.
Nicolas: On-road, transformers and models, that's something that I don't understand. There's too much math behind it. Cool. We are at the end of round again. ⁓ I think it's good ending.
Philipp: Thank you for listening.
Nicolas: Thank you as well and other next week again. Goodbye.
Philipp: I am Fili... Yeah, It's been an interesting week for me. I cannot go into more detail yet, but some exciting developments.
Nicolas: Looking forward to hear about it. My exciting development of this week was I tried to set up my development environment again. have this idea that I want to use Vim for development. ⁓ It's Vim time again. It's every year that comes a new, ⁓ year in spring I'm thinking I will be a Vim developer. tried a few attempts. So
Philipp: swim timing.
Nicolas: For the last 16 years, honestly, I tried to go to Wim completely. And the last years I at least settled to use Astro Wim, which is a distribution of Neo Wim with many packages installed. It's the ⁓ my ZSH for your Wim config. Okay. And so all real Wim users, please don't complain about me that I use this stuff. And then I realized something this week. So I was mostly in my terminal. And then I had to switch to my editor and I have these multiple branches or checkouts of the repository. And they need to switch between editors that have these repositories open. And this was annoying. So I thought now with LLMs, I can finally treat my WIM config. It will be fixed by the LLM. And this was a good realization. So I now have TMUX where I have three windows, one for cloud, one for lazy git and one for WIM. This is perfect use case because now I barely need to write code. I only need to read through it maybe and maybe ⁓ sometimes modify some Perfect use case. Now I'm on the Wim train again. Let's see how long this holds up. ⁓
Philipp: exciting. I'm rooting for you. I've been trying out ⁓ Z more because the only times I opened my editor which ⁓ used to be Cursor because it's just a nicer looking VS Code. It was giving me like all these update notifications and like side parts that I don't really care about so I thought maybe I can just use Z and it pops up immediately but somehow it's like hard to find the time to change the ⁓ because I'm just not as much in the code anymore. Maybe this will change
Nicolas: ⁓ also tried to switch to SET ⁓ SET is fast at least, way faster than VS Code. ⁓ my problem with SET is like some shortcuts and some very small tiny details that I was missing. And then ⁓ couldn't switch completely. ⁓ there was one more thing. ⁓ SET has so many updates ⁓ it basically ⁓ a delay every time you want to start it ⁓ it needs update. ⁓ And this was annoying.
Philipp: Yeah, same with Cursor, This doesn't force it, but it's always popping up. This company's shipped too much.
Nicolas: We just say, Okay, and the problem for me, cursor is I feel like a boomer ⁓ using the internet because I'm overwhelmed as hell.
Philipp: Yeah, you have to disable a lot of things. Speaking of cursor, there's a little bit of drama of the week. think that's kind of be fun. So cursor last week released their new custom model, they call it like their own model Composer 2. ⁓ someone on the internet found out pretty fastly that it's the same tokenizer and similar model strings than TMEK 2.5. which is an open weight model from ⁓ Kimi, like a Chinese company. licensing-wise, it is not allowed for them to redistribute it. So people were like, ⁓ is Kerser doing? Are they going to make the reputation? Like everybody's just copying them against the terms and doing illegal stuff. And everybody was like, ⁓ this is really bad for the open weight community because the company now benefits from them. And the Kursha team immediately said, don't know, we talked to them. It's like all good. And they had to basically get someone from the Kimi team to tweet that this is a licensed agreement and the license partnership because they wouldn't shut up about it. So yeah, this has been a little bit of a drama. I think it's interesting that they take like this approach and try to like market this their own model. Apparently like they did a lot of fine tuning on it and reinforced learning. Yeah, I don't know too much of that stuff, honestly, to judge it,
Nicolas: And do you know more about this Keme model? Like, is this a distilled model? Or is it, did they build it on their own?
Philipp: I don't think anybody knows how these are built. They're open-weight but the training data is not open as far as I know. So nobody knows how these are built.
Nicolas: But it makes total sense for Cursor. I mean, you have the 15 billion dollar valuation now. my thinking with all of these EI startups now, I don't get their revenue stream. Of course, they always tell you like, oh, we have so many millions of revenue per employee. But to be honest, like they are mostly reselling tokens. The only company that benefits in end is Nvidia that has like a 75 % margin share. on on the So ⁓ never understood this whole business model and it makes sense then for me like Cursor ⁓ wants to move away from OpenAI ⁓ ⁓ and all the other LM providers because they want to resell their own model where okay hardware is cheap, we need to build maybe data centers which ⁓ mean.
Philipp: partnering with inference providers.
Nicolas: Okay, they don't to host it, ⁓ but I the margin will be way, way higher if they have their own model instead of reselling tokens.
Philipp: I don't know if people actually know what the margins are for companies like Antropiq and OpenAI. It's like so much discussion that says, oh, they're selling subsidized token with those plans. But I'm not sure if this is true. I don't think we have any official information. I don't think they would make a lot of loss with their approach. Maybe a little, but definitely not the exorbitant one. I don't think they pay the same price as API customers would pay in terms of resources.
Nicolas: I think the biggest price ⁓ these ⁓ providers is like the initial research definitely. ⁓ training costs dozens of millions. ⁓
Philipp: It's more and more every generation.
Nicolas: And then of course, building the data centers now where you give a lot of money to Nvidia. And I think these are the heaviest.
Philipp: It's not only Nvidia, they're already using the TPUs as well. ⁓
Nicolas: think from Amazon. Yeah, and I'm not sure.
Philipp: Both and open the eye and then.
Nicolas: But this was this was this weird deal from Amazon. they Amazon invested in OBI in the last round but with this deal of we give you a 30 billion dollar but only half of it like you get now but most of this what we give you you need to spend on our own platform and use our own GPUs. Makes total sense.
Philipp: makes sense. this is all gonna be interesting in the future.
Nicolas: Also, there was an interview with NVIDIA CEO Jensen Wang. and of course he says that every engineer who gets paid 500k a year should at least use 250k in tokens. people who are just working on a side projects like usually they like these $20 subscriptions maybe $200 and ⁓ they are mostly good with it like if you're not Peter Steinberger ⁓
Philipp: He doesn't have to pay for the subscription anymore,
Nicolas: But I think for enterprise, you need to per token if you have an enterprise account.
Philipp: Yeah, I don't know exactly how this works. I'm pretty sure if you're like a smaller company, you still can use these subscriptions. But probably once you want to enforce your no data retention policies or something, you probably want ⁓ forced off that. I don't know.
Nicolas: and here what I'm wondering is right now the whole industry says like burn the tokens as much as possible. Every tech CEO is like burn tokens, burn tokens, build things. And I'm unsure how much they think ahead, like how much this costs in the end compared to the benefits they have to get from it. Especially because if you burn tokens at some point you get lazy. things that could be automated with a script suddenly get done by an LM. Maybe even with the largest model because you forgot to switch or whatever. So curious how this works out financially.
Philipp: So your prediction is that in the future companies will realize that this is a lot of
Nicolas: cost? Yeah and they will try to cut this cost down by either telling everyone you're not allowed to use this model because costs too much ⁓ or they will likely enforce like a limit per then there must be something because it costs a lot money ⁓ and we don't see like a 10x outcome yet right
Philipp: Yeah, I see.
Nicolas: My unfortunate prediction. This is a dark one. Companies will just lay off the people so they can compensate for the high costs. That is it. It's happening.
Philipp: which was already happening but with not much data to prove at least some of the effects.
Nicolas: I mean, we see it with Oracle later people because they need to invest in their AI data centers, although like Oracle was not a good case before because they suffered already. Meta like there are rumors that they lay off 20 % of people
Philipp: also recently did layers
Nicolas: Yeah, block also did layoffs, Although they also didn't work that well, So I think it's a, they just say like it's because of AI.
Philipp: Yeah, we don't know that. Or maybe we with public eye of not here. I don't know it. What's the positive thing of the week? We've been really thinking about this, have we?
Nicolas: So positive thing of the week is that I try to use Vim again. Let's see how long this keeps up.
Philipp: That's good. My positive thing of the weekend, I tried Go. Yes, I tried Go with a friend, a shared friend of ours. We were thinking about a command line tool and I just, you know, instead of saying to the AI use JavaScript, just said use Go and it did some stuff and I looked at it and it probably makes sense. Yeah, there's definitely some cool things that the single binary build just works. The networking library is so much more reliable.
Nicolas: You tried, go really.
Philipp: And when you're going to set it up, you know, with an agent and the loop where it can verify itself, in this case, this is like about setting up an Incos cluster for you for like the stuff we talked about last week. And we wanted to test it. So in the prompt for it, I said, it should use the HCloud API, the Hetzner Cloud CLI. ⁓ basically to provision servers, run the thing and delete them again and do this in a loop until everything works. And surprisingly, you know, I'm not surprised at this anymore. This is crazy, but somehow I'm like, I'm expecting this to work already. And of course it did work. It's one shot at this implementation. ⁓ Yeah, pretty insane. That's cool. Yeah. I'm pretty, I'm pretty bullish now on Go again, because when we were working on this kind of hack thing last week, I wish we had something that is more robust in the backhand but still nicely and easy to deploy like a standard binary. But yeah, you can just write GO I think for that. It's a good language for it.
Nicolas: This is definitely a good language. for me, I tried to look at goal like one and a half years ago and it didn't click, also so coming from Alex here, I didn't see a benefit compared to go. Although I see the benefits of you have this binary that they can install. the ecosystem is way richer.
Philipp: Yeah, the networking code is brutally good compared to JavaScript. Basically, I feel like wipe code. Just a little bit of a fun fact. We found a bug in the ban runtime that allows you to not use your self-signed certificate for serving TLS traffic. It just doesn't work. Nobody cares, apparently, for this.
Nicolas: And there's another thing, the Go networking layer is part of the standard library. Yes. There's this, think no other languages, no other language has this really, right?
Philipp: May not has it was not good.
Nicolas: Yeah, okay, sorry. No other language has a good one. Yeah, that's true. For even Alex here, you have a bunch of libraries. They're actually good, not part of the standard library.
Philipp: I want to love Go more. used it in the past at Sourcegraph and I think we both have like a little bit of experience with writing C from like our early school days. And I feel like Go is a lot like writing C. have structs basically and you just pass things around in functions. But yeah, I definitely miss the muscle memory.
Nicolas: That's my problem. I can't look at the code and immediately see what's happening. Also because of, I think this is my biggest problem with Go. I need to skip all this if not error cases in my head. And a bit of time to get used to this.
Philipp: Yeah, I hope I can do it more because I prefer it over Rust. I feel like I'm not smart enough for Rust. Rust is too complex for me. I used it at Tewin when I was pair programming with people that know Rust. But there's just so much in this language and I'm like, I'm not smart enough for it.
Nicolas: Me neither. Go is quite simple in its way.
Philipp: There's another positive thing of the week, not that I'm speaking about rust. Because There's this company called Astral that as far as I know, built implementations for Python tooling. Tools like UV and whatever they're called. I'm not really familiar with the Python ecosystem, but they built that in Rust. So they made this kind of insane Python tooling, saying again, making it fast and everything. And they were just, as was just announced, they're going to join OpenAI in the Codex team, I think it paints an even more interesting picture on how DevTools work, because I don't think they had any revenue prior to that. And Bun, I know they don't, did not have any revenue prior to that. So a lot of these tech DevTools companies right now seem to only like build something people want and then be sold. I think that's like the strategy.
Nicolas: strategy. ⁓ also like that these companies get bought because then ⁓ then they have enough time and ⁓ money spend on having better developer tooling. think it's great.
Philipp: Yeah, I read a commentary from Simon Wilson who mentioned Armin Roenacher and I think the thing is even if this kind of source project was to be, you know, changing lives or anything weird were to happen, ⁓ it's in such a good that the community could fork it and still benefit from it. So the kind of existence of UV made Python so much better for everyone that it's like a net positive thing no matter what happens now. ⁓ I don't really know why they'd hire them, but I feel like, know, Codex is written in Rust. So maybe they just wanted to have some really good Rust developers.
Nicolas: I would love to see more businesses investing into languages that I'm working on.
Philipp: The part is what other, maybe we end this with it, what other legacy toolings exist out there that have horrible workflows and someone just need to found a company, rewrite the tooling in Rust and make it fast again.
Nicolas: Good question,
Philipp: How fast is RubyLinter?
Nicolas: ⁓ god, let's not get started with think with Ruby only have Shopify that has money to invest into it.
Philipp: I don't think it does not love users as well Ruby anymore compared to like TypeScript and Python of course. But then maybe some database tooling. I don't know everybody uses Postgres. Maybe there's stuff there.
Nicolas: Yeah. That was what I mentioned three weeks ago, think, with PJDog. That's also, I think, in Rust or Ingo. And they are building the sharding. And exactly that totally is missing. There's another thing that is missing from you on the Postgres side. But to be honest, there's a business already out there, which is Monitoring crewbies and generally Postgres monitoring. And there is PG Analyze, for example, also somewhere from Vienna, Lukas Vittel, who did an amazing company there ⁓ on Postgres tooling. There are other Postgres companies out there as well, but ⁓ this is more and not open source.
Philipp: Yeah. So a lot of money still to be had by developer tools, but also really hard to stick through, I guess, the masses.
Nicolas: Yeah, and I would not give a bet on being part of the JavaScript ecosystem because it could be that you are away in three months and no longer the default tooling. It changes so fast there. So I think other languages are ⁓ better to invest in. Like Python, there was a lot of improvement to be done.
Philipp: The fan works, and it works in the TypeScript ecosystem. True.
Nicolas: And there is, for example, this UV improvements that they made. There is a blog post by Patterson, ⁓ very ⁓ Rubyist, ⁓ tried to figure out like what could we put into Bundler, like the Ruby ⁓ that we can learn from UV. yeah, ⁓ that out. It's exactly going in the same direction that we can actually have many improvements, ⁓ than you think. One more thing about improvements. was, in the Ruby land, there is a renderer in Ruby. I'm not sure how it's called. And Tobias Lübcke, who is the CEO of Shopify, he ⁓ let a large language ⁓ over like a whole night to improve the renderer. ⁓
Philipp: This is auto research stuff that Kapati
Nicolas: and it got 50 % faster. of people worked on this over the last few years. So you can definitely still have improvements in all of the toolings, which is good.
Philipp: Yeah, this is, I need to do something with auto research. I think that's a really interesting pattern. As far as I understand, it's a Ralph loop, which is basically just a while loop over make your thing faster. And then when it's done, make your thing faster again. And like clearly like a measurement cycle as well, so it knows it's going in the right direction.
Nicolas: There's one problem I have with this whole new thing that's going on, like the whole AI development. There are so many names for things that are actually easy.
Philipp: Yeah, it's always been that way.
Nicolas: But then there are these MCP protocols like then there's ACP and there's like this and you think constantly like ⁓ I'm too dumb for all of this. ⁓ Did I miss something in my research or like am I over learning? Is there something new? And then you find out okay it's basically a loop and an if and it's always like that. It's just a fancy name. ⁓
Philipp: It's a multiplication now, that's really become really important.
Nicolas: On-road, transformers and models, that's something that I don't understand. There's too much math behind it. Cool. We are at the end of round again. ⁓ I think it's good ending.
Philipp: Thank you for listening.
Nicolas: Thank you as well and other next week again. Goodbye.
