Speaker 1: Imagine for a second, right that you are just relaxing
Speaker 1: on a gorgeous, sun drenched beach.
Speaker 2: Oh I'm already there, right.
Speaker 1: You have a cold drink in your hand, the waves
Speaker 1: are gently crashing, and you don't have a single care
Speaker 1: in the world.
Speaker 2: Sounds perfect. Why am I so relaxed?
Speaker 1: Exactly because back in the real world, you have a
Speaker 1: digital double Oh wow. Yeah, like a tireless, invisible assistant
Speaker 1: who is currently handling all of your mundane daily tasks.
Speaker 1: It's checking your schedules, filtering your messages, and basically doing
Speaker 1: all the heavy lifting of your life while you just
Speaker 1: sit back and listen to the ocean.
Speaker 2: I mean that sounds like pure science fiction.
Speaker 1: Honestly, he surely does, right, But today we're going to
Speaker 1: show you exactly how close that reality actually is. Welcome
Speaker 1: to the deep dive.
Speaker 2: Glad to be here for this one.
Speaker 1: Yeah, Today we are opening up a really fascinating piece
Speaker 1: of source material. It's a book called Building Telegram Bots
Speaker 1: Develop Bots in twelve programming languages by Nicholas Maudzik. And well,
Speaker 1: we are going to expor how you can build these
Speaker 1: digital assistance yourself.
Speaker 2: Yeah, And what stands out immediately about mad ROC's approach.
Speaker 2: And I love this is that he didn't write this
Speaker 2: to show off like abstract theoretical coding.
Speaker 1: Tricks, right, it's not a text put exactly.
Speaker 2: He built these bots to solve highly relatable everyday problems
Speaker 2: he was actually facing while living in Tokyo.
Speaker 1: The examples are incredibly grounded. I mean, anyone who has
Speaker 1: lived in a massive metropolis knows the absolute panic of
Speaker 1: like missing the last train home.
Speaker 2: Oh yeah, and having to pay for a ridiculously expensive taxi.
Speaker 1: It's the worst. So instead of constantly checking an app,
Speaker 1: he just wrote a bot that automatically tracks the last
Speaker 1: train schedules and drops his optimal transit options right into a.
Speaker 2: Chat window, which is brilliant. Yeah.
Speaker 1: He also built an IoT webcam bot that snaps a
Speaker 1: picture and sends it to his phone whenever someone rings
Speaker 1: his doorbell. And oh, my favorite party bot, ah, the
Speaker 1: party bot. Yeah, it uses a mini projector to display
Speaker 1: random incoming chat messages onto his life living room wall
Speaker 1: during get togethers.
Speaker 2: It's so cool because it illustrates a fundamental shift in
Speaker 2: how we should view automation. You know how so well,
Speaker 2: a bot isn't just a corporate customer service gimmick anymore.
Speaker 2: It is a highly customizable personal tool to reduce friction
Speaker 2: in your daily life.
Speaker 1: Right.
Speaker 2: But the structure of this text is what makes it
Speaker 2: a masterclass. He doesn't just teach you how to build
Speaker 2: a bot. He teaches you how to build the exact
Speaker 2: same bot using twelve different programming languages.
Speaker 1: Which naturally brings up the big question, right, and really
Speaker 1: the entire mission of our deep dive today for you,
Speaker 1: Why in the world would you solve the exact same
Speaker 1: problem in twelve different programming languages when you could just
Speaker 1: learn one and stick to it.
Speaker 2: Yeah, sounds like a lot of extra work.
Speaker 1: It does. The best way I can think to describe
Speaker 1: it is like cooking. Imagine cooking your absolute favorite go
Speaker 1: to recipe. Okay, I'm with you, but instead of just
Speaker 1: making it in your own familiar kitchen, you cook it
Speaker 1: in a massive commercial restaurant, pitchin when you cook it
Speaker 1: over a campfire in the woods, and then I don't know,
Speaker 1: you cook it in a tiny, high tech kitchen on
Speaker 1: a submarine. That is a great analogy, right, You're making
Speaker 1: the exact same food, but the process teaches you just
Speaker 1: as much about the constraints the tooling and the environment
Speaker 1: as it does about the meal.
Speaker 2: Itself, and that environmental constraint is precisely the point of
Speaker 2: the exercise. By holding the output constant the BOD, we
Speaker 2: get to clearly see the variables in the languages themselves, right.
Speaker 1: It strips away the distraction of what you're building.
Speaker 2: Exactly. It is about deeply understanding how different programming languages
Speaker 2: approach the very nature of problem solving at a systemic level.
Speaker 1: Like how they handle memory yes.
Speaker 2: How do they handle memory management? How do they structure
Speaker 2: their syntax to prioritize human readability versus raw machine level performance.
Speaker 2: When you build the same tool repeatedly, the philosophy of
Speaker 2: the language just kind of reveals itself.
Speaker 1: Okay, let's unpack this Before we can start touring these
Speaker 1: different programming kitchens. We actually need some groceries, or in
Speaker 1: this case, we need a bot identity.
Speaker 2: You can't code a bot if it doesn't exist yet.
Speaker 1: Exactly, we have to start with the absolute foundation of
Speaker 1: the telegram platform, and to do that, we are going
Speaker 1: to look at one of the most famously readable, user
Speaker 1: friendly languages out there. Ruby.
Speaker 2: Ruby serves as an excellent gateway because of its design philosophy.
Speaker 2: It explicitly prioritizes developer happiness.
Speaker 1: Developer happiness, I love that.
Speaker 2: Yeah, it reads almost like plain English. Yeah. Architecturally it's
Speaker 2: an interpreted scripting language, and that means that means you
Speaker 2: don't have to run it through a compiler to translate
Speaker 2: it into machine code before executing it. An interpreter simply
Speaker 2: reads your code line by line at runtime, which makes
Speaker 2: spinning up a prototype incredibly fast.
Speaker 1: But before we write a single line of Ruby, we
Speaker 1: have to meet the boss.
Speaker 2: Ah, yes, the Botfather.
Speaker 1: To create a bot on Telegram, you don't just fill
Speaker 1: out a web form. You actually have to chat with
Speaker 1: a bot. To create a bot, you talk to prafana
Speaker 1: Agat bot Father, who is the literal old godfather of
Speaker 1: all telegrambots.
Speaker 2: The book highlights some hilarious details here too.
Speaker 1: Oh my gosh. Yes, Botfather is available twenty four to seven.
Speaker 1: Never sleeps, but according to his bio, he quote takes
Speaker 1: showers and always looks fresh. I mean, you gotta appreciate
Speaker 1: the lore, right his profile picture isn't.
Speaker 2: Yeah.
Speaker 1: The author makes a great joke about this, actually warning
Speaker 1: you not to leave this token hanging around on a
Speaker 1: public GitHub repository quote. Especially now that Microsoft.
Speaker 2: Owns it, we'll developer humor there.
Speaker 1: Right, so you keep it haydden in an environment variable.
Speaker 1: Now diving into the Ruby environment, setting this up is
Speaker 1: incredibly smooth. You use Ruby's package manager, which is called
Speaker 1: JEM to install the telegrambot library yep standard setup, and
Speaker 1: you create a simple file like step zero dot rb.
Speaker 1: But how does the code actually know when someone sends
Speaker 1: a message? Like?
Speaker 2: Mechanically, the mechanics rely on what we call a polling loop. Specifically,
Speaker 2: the script calls a dot get updates method. Okay, Conceptually,
Speaker 2: think of it like a kid in the backseat of
Speaker 2: a car constantly asking are we there yet? How about
Speaker 2: now are we there yet?
Speaker 1: Oh man?
Speaker 2: Right? The Ruby script is in a continuous loop, constantly
Speaker 2: knocking on Telegram server door asking if any new data.
Speaker 1: Has arrived, and when a message finally does arrive, it's
Speaker 1: not just the text the user typed. The book shows
Speaker 1: how if you use Ruby's toyomal function, which formats data
Speaker 1: into a really readable structured list, you can actually see
Speaker 1: the full anatomy of a Telegram payload.
Speaker 2: It's surprisingly dense.
Speaker 1: It's a massive package of data. You get a message
Speaker 1: you get the from field detailing the user, the chat
Speaker 1: channel info, the exact timestamp, and of course the actual
Speaker 1: text itself.
Speaker 2: And this is where Ruby's high level abstractions really shine.
Speaker 2: To make the bot reply, you don't have to manually
Speaker 2: construct some complex httppost requests from scratch.
Speaker 1: Thank goodness.
Speaker 2: Right, you use string interpolation instead of clunky commands to
Speaker 2: concatenate or glue text together. Ruby lets you seamlessly evaluate
Speaker 2: variables right inside a string. You just write hello, followed
Speaker 2: directly by a hashtag message up from dot first name.
Speaker 1: Which instantly grabs that specific piece of data from the payload.
Speaker 1: So the bot replies, hello Nico exactly. It completely abstracts
Speaker 1: away the complex network requests and the dense data parsing.
Speaker 1: You get a fully functioning, responsive bot in under ten
Speaker 1: lines of code.
Speaker 2: It's beautiful.
Speaker 1: But and here's where we hit a wall. Ruby is
Speaker 1: brilliant for a personal bot. Well, what happens if your
Speaker 1: bot goes viral?
Speaker 2: Uh? The scaling problem?
Speaker 1: Yeah? If that interpreter is reading code line by line
Speaker 1: and suddenly ten thousand people are messaging your bot at
Speaker 1: the exact same second, that are we there yet? Polling
Speaker 1: loop is going to become a massive bottleneck.
Speaker 2: Precisely, the interpreter becomes a huge liability under heavy load.
Speaker 2: If you want raw speed and if you want a
Speaker 2: standalone executable file that runs directly on the machine's hardware
Speaker 2: without needing a Ruby environment installed on the server at all,
Speaker 2: which is a hassle it is, so if you want
Speaker 2: to avoid that, you have to leave scripting languages behind entirely.
Speaker 1: Here's where it gets really interesting. We want the readability
Speaker 1: of a script, but we need the heavy duty performance
Speaker 1: of a compiled binary, and that architectural shift brings us
Speaker 1: to a completely different.
Speaker 2: Language, NIM. NIM is a fascinating piece of technology. If
Speaker 2: you look at NIM code on a screen, it visually
Speaker 2: looks and feels very much like Python.
Speaker 1: Oh really yeah.
Speaker 2: It uses indentation and really clean readable syntax. But under
Speaker 2: the hood, NIM doesn't interpret. It compiles, meaning it translates
Speaker 2: your code down into clus plus U or JavaScript and
Speaker 2: then uses a C compiler to turn it into a
Speaker 2: highly optimized bare metal machine binary.
Speaker 1: Okay, I have to play the skeptic for you here though,
Speaker 1: because reading the NIM section of the text, the developer
Speaker 1: experience felt incredibly jarring after how smooth Ruby.
Speaker 2: Was, Well, yeah, that's a different beast.
Speaker 1: With NIM, we need the NIM compiler, we need the
Speaker 1: Nimble package manager, and we have to install a specific
Speaker 1: vs code extension by constantin Zeitzev just to get syntax
Speaker 1: highlighting right. And even then I can't just click run.
Speaker 1: The author outlines how you have to configure custom tasks.
Speaker 1: Do Jason build tasks. You have to use terminal commands
Speaker 1: like nimcar to compile and run.
Speaker 2: It's definitely more involved.
Speaker 1: And to make a simple secure web request to get HUBSAPI,
Speaker 1: the code straight up fails unless you manually add a
Speaker 1: just dossl flag to the compile command. With Ruby, the
Speaker 1: web request just worked. Why take on all this extra friction?
Speaker 2: If we connect this to the bigger picture, you have
Speaker 2: to understand the fundamental trade off of compiled systems. The
Speaker 2: friction you're describing is the literal price of optimization. When
Speaker 2: you manually add that digdssl flag, you are making a
Speaker 2: conscious architectural decision through a process called dead code elimination.
Speaker 2: Dead code elimination, Yes, NIM gives you the ultimate power
Speaker 2: to exclude massive libraries you just don't need. If your
Speaker 2: specific bot doesn't need to make secure external web requests.
Speaker 2: Nim won't include that heavy SSL cryptographic code in your
Speaker 2: final binary.
Speaker 1: Oh I see.
Speaker 2: The result is a final program that is astonishingly tiny
Speaker 2: and lightning fast because the processor executes it directly.
Speaker 1: So you trade a little upfront convenience for a massive
Speaker 1: back end performance boost.
Speaker 2: Exactly.
Speaker 1: So, when we build the nimbot, we use the telebot library,
Speaker 1: but we also have to import something called async dispatch,
Speaker 1: and this introduces a completely different paradigm than that Ruby
Speaker 1: polling loop we discussed earlier.
Speaker 2: Yes, the text introduces the async pragma, which is vital
Speaker 2: for concurrency.
Speaker 1: Right.
Speaker 2: Think about synchronous programming. Like a single barista at a
Speaker 2: coffee shop. They take an order, make the coffee, and
Speaker 2: hand it over before even making eye contact with the
Speaker 2: next customer in line. That sounds infuriating, It is if
Speaker 2: the coffee takes five minutes, the line stops moving. That
Speaker 2: is a synchronous bottleneck. Right. A synchronous programming is like
Speaker 2: a head barista taking an order, handing the ticket to
Speaker 2: the espresso machine, and immediately turning to take the next
Speaker 2: customer's order while the first coffee is brewing in the background.
Speaker 1: But traditionally, writing that asynchronous logic leads to what developers
Speaker 1: call callback hell right where the code becomes this deeply nested,
Speaker 1: unreadable mess of functions waiting on other functions.
Speaker 2: Exactly, and that is where NIM shines. The ACYNC feature
Speaker 2: allows you to write asynchronous code as though it were
Speaker 2: simple top down synchronous code.
Speaker 1: Wow.
Speaker 2: Yeah. It yields control back to the event loop without
Speaker 2: deeply nesking functions, keeping the logic clean while maintaining massive concurrency.
Speaker 1: The author also uses a brilliant security trick in NIM
Speaker 1: that you simply can't do in Ruby, going back to
Speaker 1: that golden rule of hiding the token. In NIM, he
Speaker 1: uses a built in function called slurp secret dot key.
Speaker 2: I love the name of that function, slurp.
Speaker 1: It's great mechanically. What this does is reach out, grab
Speaker 1: the token from a local hidden text file on your
Speaker 1: hard drive, and bake it directly into the binary during
Speaker 1: the compilation step.
Speaker 2: It's an elegant demonstration of compiler power. Because NIM compiles
Speaker 2: down to machine code. That token gets embedded into a
Speaker 2: binary format.
Speaker 1: So it's not just sitting in plaintex. No.
Speaker 2: A malicious actor can't just open a text file and
Speaker 2: read it on your server. They would have to reverse
Speaker 2: engineer and decompile a machine binary to extract that string,
Speaker 2: which raises the security barrier exponentially.
Speaker 1: And the bot we build a NIM is super fun.
Speaker 1: It's a Cats and Dogs blot classic. The compiled code
Speaker 1: listens to the chat and if a user types the
Speaker 1: word cat or dog, it triggers a new photo function.
Speaker 1: It pulls a local image file, attaches a custom caption,
Speaker 1: and fires it back to the user. It proves that
Speaker 1: even though NIM compiles down to raw c it handles
Speaker 1: media and chat interactions effortlessly.
Speaker 2: It does, but it also highlights the eternal programmers dilemma.
Speaker 2: You love the fast write elegant syntax of Ruby, but
Speaker 2: you also want the raw, compiled speed and type safety
Speaker 2: of NIM. The friction of compilation versus the joy of scripting.
Speaker 2: It's natural to ask if a language exists that bridges
Speaker 2: that gap.
Speaker 1: Which brings us to a language that genuinely feels like
Speaker 1: the best of both worlds.
Speaker 2: Crystal Crystal is fascinating because it was explicitly heavily influenced
Speaker 2: by Ruby.
Speaker 1: Yeah, if you glance at a Crystal file, you would
Speaker 1: swear you're looking at Ruby code.
Speaker 2: But just like NIM, it compiles directly. To see the
Speaker 2: author provides a benchmark to prove this speed. Actually, he
Speaker 2: runs a script to calculate the Fibonacci sequence up to
Speaker 2: one billion a billion. Yes, and in Crystal, this massive
Speaker 2: calculation takes fewer than five seconds.
Speaker 1: That is insane.
Speaker 2: That is a level of CPU performance that a dynamically
Speaker 2: typed interpreted scripting language could never dream of achieving.
Speaker 1: How does it do that?
Speaker 2: Crystal achieves this through advanced type inference. It looks dynamically
Speaker 2: types like Ruby, but the compiler figures out the data
Speaker 2: types of compile time, enduring memory safety and raw speed.
Speaker 1: I have to challenge this premise, though, go for it.
Speaker 1: Calculating the Fibonacci sequence to a billion in five seconds
Speaker 1: is an incredible feed of engineering. Sure, but we are
Speaker 1: building a telegram bot to tell us when the next
Speaker 1: train leaves or to reply with the picture of a dog.
Speaker 1: Isn't optimizing for that level of intense CPU performance? Total
Speaker 1: overkill for what is his essentially just a text messaging
Speaker 1: assistant for.
Speaker 2: A single user checking a train schedule. Absolutely, it's overkill,
Speaker 2: But think about scalability and infrastructure costs. Okay, if your
Speaker 2: bot is adopted by one hundred thousand users, an inefficient
Speaker 2: scripting language will require you to rent expensive, heavy duty
Speaker 2: cloud servers just to keep up with the memory overhead
Speaker 2: and the interpreter lag.
Speaker 1: That gets pricey fast.
Speaker 2: Because Crystal compiles to such highly optimized, lightweight C code,
Speaker 2: you could theoretically run that massive one hundred thousand user
Speaker 2: bot on a cheap five dollars a month virtual private server.
Speaker 2: You aren't just optimizing for speed, you are optimizing for
Speaker 2: server resources.
Speaker 1: Oh. That puts it in perspective. The efficiency pays off
Speaker 1: at scale, and Crystal doesn't sacrifice developer experience to get
Speaker 1: there either, not at all. It has an amazing built
Speaker 1: in sandbox feature called Crystal Play. You type that into
Speaker 1: your terminal and it instantly launched the web server on
Speaker 1: port eighty eighty, where you can test your code live
Speaker 1: in a browser.
Speaker 2: It's so user friendly.
Speaker 1: But what really blew me away was the standard library.
Speaker 1: The author shows an example where the code queries the
Speaker 1: GitHub api to search for repositories. In most languages, you're
Speaker 1: hunting down third party libraries for network requests.
Speaker 2: Crystal, however, has eahttp client and Jason Parsing built right
Speaker 2: into its core standard library that is so convenient you
Speaker 2: don't have to import external packages just to perform basic
Speaker 2: modern web functions. The language is fundamentally designed for the
Speaker 2: Internet age out of the box, and.
Speaker 1: When you are ready to build a larger project, Crystal's
Speaker 1: tooling treats you like a professional. From second one. You
Speaker 1: take Crystal init app my bot, and it instantly builds
Speaker 1: out an entire, scalable project skeleton, testing folders, get ignore files, license,
Speaker 1: and your shard dot EML dependency file.
Speaker 2: And that Shard dot eml file represents a massive philosophical
Speaker 2: shift in how Crystal handles packages compared to traditional ecosystems.
Speaker 2: How so well, Crystal's package managers called shards. Instead of
Speaker 2: relying on a centralized package repository which acts as a
Speaker 2: single point of failure that can go offline or be
Speaker 2: compromised by supply chain attacks, Crystal allows direct Git access
Speaker 2: for dependencies.
Speaker 1: Meaning you simply point your code directly to the source
Speaker 1: code repository on GitHub. You completely bypass the middleman centralized server.
Speaker 2: Exactly which inherently makes your build process significantly more resilient.
Speaker 1: So we've explored the developer happiness of Ruby, the bare
Speaker 1: metal optimization of NIM, and the scalable hybrid power of Crystal.
Speaker 1: So if Crystal writes like beautiful Ruby and runs with
Speaker 1: the blistering speed of c is Crystal the ultimate programming
Speaker 1: language for building our personal digital assistance?
Speaker 2: This raises an important question about the nature of tool optimization.
Speaker 2: There is really no six thing as an ultimate language, ah,
Speaker 2: the classic developer answer, Well, it's true. The best language
Speaker 2: depends entirely on your specific ecosystem and constraints. For instance,
Speaker 2: Crystal currently relies heavily on a Unix like environment. If
Speaker 2: your native development machine is running Windows, you have to
Speaker 2: use the Windows subsystem for Linux or WSL, which adds
Speaker 2: a layer of virtualized complexity that might defeat the purpose
Speaker 2: of a fast setup. Furthermore, the best language is often
Speaker 2: simply the one that aligns best with your own mental
Speaker 2: models of logic.
Speaker 1: So what does this all mean? We started this journey
Speaker 1: imagining a digital double handling your life while you relax
Speaker 1: on a beach, and what Nicholas Muljik's book shows us
Speaker 1: is that getting there isn't about finding one magical, perfect
Speaker 1: piece of syntax. It's about learning how to translate your
Speaker 1: physical problems into computational solutions. Whether you choose the interpreted
Speaker 1: ease of Ruby to whip up a quick script to
Speaker 1: check your doorbell, or you embrace the compile time friction
Speaker 1: of NIM to build a tiny standalone binary, or you
Speaker 1: leverage Crystal to build a massive, highly scalable architecture for
Speaker 1: thousands of users. The real takeaway here is empowerment.
Speaker 2: Yes, absolutely, building a.
Speaker 1: Personal bot is a gateway to upgrading your own life.
Speaker 1: You truly can stop worrying about checking the train schedules
Speaker 1: at midnight and let your code do the heavy lifting
Speaker 1: for you.
Speaker 2: It democratizes automation. You don't need an enterprise grades server,
Speaker 2: rack or a whole team of engineers to have a
Speaker 2: personal assistant. You just need an understanding of your own constraints,
Speaker 2: a few lines of code, and a chat app.
Speaker 1: And that leaves us with one final slightly wild thought
Speaker 1: to Mullover.
Speaker 2: Oh boy, we've.
Speaker 1: Seen today just how easy it is to spin up
Speaker 1: a digital double to fetch images, parse Jason data, or
Speaker 1: monitor trans at times using surprisingly little code. The barriers
Speaker 1: to entry are practically gone. They really are, But as
Speaker 1: these programming languages become increasingly abstracted, as the compilers get smarter,
Speaker 1: and standard libraries do more of the heavy lifting for
Speaker 1: us right out of the box. How far are we
Speaker 1: from a future where our personal bots become smart enough
Speaker 1: to write code for other bots?
Speaker 2: Oh wow?
Speaker 1: Imagine relaxing on that beach not just because your bot
Speaker 1: is checking your emails, but because your bart noticed a
Speaker 1: repeated inefficiency in your daily routine, automatically generated a brand new,
Speaker 1: compiled robotic assistant, deployed it, and solved an inconvenience you
Speaker 1: hadn't even consciously noticed yet until next time. Keep dye
Speaker 1: moving deep