If I had a two pence piece for every time @andycroll's One Ruby Thing acted as my second brain, I'd be able to spend all day in a Brighton arcade on the 2p machines.
The next #meetup is this Thursday at New Relic. I will be away at #RubyKaigi but I'm so thrilled to see the new organizers making this happen monthly! We already have host companies offering space for the future events.
This year, @rubycentral announced that 2025 will be the last @railsconf. While I’m sad to lose a favorite Ruby conference, it’s for the best. The Ruby Central team will be able to focus on their core mission: supporting the Ruby language.
Hmm… I guess I could probably write a blog post about how my quest to speed up regexp matching in a #ruby Rake task led me eventually to #rustlang and how it worked in the end… 💎🦀🤔
Ever find a tutorial that was broken is some subtle but deeply fundamental way?
Ever WRITE a tutorial that was broken in some subtle but deeply fundmental way?
I just released RunDOC 2.0. A tool for writing tutorials that run and embed the results into a markdown document. Check it out https://github.com/zombocom/rundoc
Current status: I opened about 100 links to articles and threads from Google results comparing #ruby, #golang and #rustlang and I'm planning to read them 🫠
(no, I'm not really considering Go, mostly just trying to convince myself that I'm not making a mistake starting to learn Rust and not Go 🦀😛)
He is a dynamic #Rails & #Ruby core team member and Sr Staff Engineer at @Shopify! When not innovating in tech, he loves whipping up culinary delights, cuddling with feline friends, and crafting quirky software.
It's so annoying to see developers calling failing tests "flaky".
Last week I found a factory that assigned a random age to a user instance, so no wonder a test that used the age in some bit of logic failed sometimes. That's not a "flaky test", that's a bug in the factory.
Today I saw a date parser bug be called a "flaky test". It was written on the 21st of April and worked fine until it began to fail today, the 1st of May.
"Tests provide the only reliable documentation of design. The story they tell remains true long after paper documents become obsolete and human memory fails. Write your tests as if you expect your future self to have amnesia. Remember that you will forget; write tests that remind you of the story once you have." (Sandi Metz, "Practical Object-Oriented Design")
I really want to write something bigger in #RustLang 🦀, but I just can't think of anything else beyond that regexp matching where I'd need that raw speed (where #Ruby is not enough), except maybe an indexer for an AppView, but I kinda have too many things open atm to start working on that… 🤔
Just a few thoughts on programming languages that have been rattling around in my head this week, but which don’t each merit a full blog post. The main theme is that the culture behind each programming language leads to some interesting choices, as is the case with spoken languages.
This week I started learning how to program in Rust. Even though I’m using the project-based Command-Line Rust to learn, the author still went with the traditional “Hello, world!” project for the first intro to the language. I was also working on a Go project last week and so it immediately stood out to me that (at least as taught by this author) Rust has the print! macro that allows you to succinctly print to the command line. By contrast, Go requires importing fmt before you can print. This was the first topic that was swirling around in my head this week. What makes language designers choose whether printing output (one of the most basic things a program can do) is built-in or requires an import. I even remember back when I was learning Java in undergrad (I think it was Java 1.8, but I don’t remember) we had to use the savitch library just to get program input (another very basic computer program concept). As I thought about it, I wondered if it has to do with thoughts around compilation and whether the language designers think you’re mostly making user-interactive programs or libraries? It makes sense to me that scripting languages like Python, Ruby, and Perl would have print built-in since you always have to have the interpreter along with you, so all the basics should be there. (The original Batteries Included Python promise, for example) But perhaps the Go developers thought you wouldn’t always be printing to the command line so a more efficient binary could be compiled by forcing you to import the functionality? I’m not entirely sure.
The next thing I started thinking about, again due to learning Rust, was the mutability of variables. In most languages I’ve come across (I think all, except Haskell) all variables are mutable by default. It almost seems pointless to have a non-mutable variable. I understand why many languages have the concept of a “contanst” modifier/keyword. Unlike normal variables, THIS ONE does not change. But the opposite seems so weird since most of what we often do in programming involves changing the value in a variable. Perhaps as I learn more about Rust, I’ll understand their reasoning, but this seems completely backwards to me.
Both Rust and Golang use structs to organize variables where Ruby, Python, and Java use objects. But when both Go and Rust allow you to “attach” methods/functions to structs – is there a true distinction between object-oriented programming and struct-based programming? It seems like it’s just semantics (in the generic sense of the word) – at least at the level at which I program. The only difference I can see is that structs don’t have inheritance, although Go’s “types” solve some of the same problems.
Today’s (the day I’m writing this, not the day it’s going to be posted) shower thought was about programming language versions. On one end you have Java (I think now on version 22) and C# (now at version 12). On the other you have Python and Ruby (both at version 3). Perl essentially stopped at 5 with Perl 6 evolving into Raku. I don’t know what Java is up to. But I think C# is actually using the versions correctly – I’ve heard that each version introduces completely different ways of doing things and that the way you program C# depends strongly on when you jumped in. This is why Python is probably never moving to v4 unless they need to make some kind of huge change. Rust is an outlier with year-based versions. I guess that’s fine, but doesn’t tell you anything like a proper semantic versioning could.
Finally, I know that Rust is the newest of all the programming languages I’ve learned, but I really love how new projects are started. Python isn’t horrible, but it’s currently suffering from a lots of ideas, none of which has complete market share. You could do a simple virtual environment or you could do a more complex virtual environment/lock file situation with Poetry. (And there are about another half dozen variations on these two themes) But Rust….Rust deserves a chef’s kiss. When you start a new project with “cargo new project-name”, not only does it set up your directory structure, but it does a whole bunch of great setup tasks. It creates your Cargo.toml file (with Python, which only really started supporting toml files at the project level a few years ago, you need to look at documentation to figure out what goes in there) so that you have all the basics in there already. But it doesn’t stop there! It also, in a nod to modern programming, creates a git repository AND a gitignore file. It’s a thing of beauty. I would absolutely love for Python to move in this direction officially (not through a random user choice) for their defaults. Even “go mod init” could benefit from setting up a git repo and a git ignore (since the toml is not how Go works – I think they would probably best set up a README.md since Go’s default packaging is through git repos).
I'm Thang and I'm a 26-year-old software engineer from Vietnam.
👍 What I'm good at: #Ruby, #Javascript
📝 What I'm learning: #Rust, #AWS, #Terraform
🔜 What I'm planning to learn in the near future: Qt6 with C++ or Python (to overcome my Electron addiction)
just watched @tenderlove's stream with Maxime on adding an optimization to #YJIT for Array#pack and it's pretty cool, if you have ~1 hour it's a good way to spend it.
Hmm… ok, so this looks promising. The middle is #Ruby Rake task loading records and passing them to #RustLang regexps, the bottom one is a Rust program loading from SQLite itself.
I don't want to duplicate all the feed/model logic in 🦀, but maybe I can hire it to do some more of the work somehow? 🤔
Btw, Rust vs. no Rust - rescanning 3 days of posts on the server for the #ATProto feed:
(This is the same #Ruby rake task, but using the native #rustlang module that I've been experimenting with last week to do regexp matching only. Rust version below, obv. 😛)
Mastodon fetching all replies to a post you're viewing would hugely improve user experience on small and one-person instances. If you know a bit about Ruby and/or Mastodon, please spend a moment reviewing this work in progress:
Ok, looks like we have a winner… 🏆 #RustLang, run directly from #Ruby as a native module, using this tool: https://github.com/matsadler/magnus. Should give me a 2-4x total speedup (regex matching is 15x faster, but some of that time is reading data from SQLite & ActiveRecord). JS via mini_racer works ok too.
The #RustLang module code is actually super short, just two short functions, less than a page total. I'll try to wrap it into a gem at some point, because it's totally generic and could be used in other projects to speed up regex matching 🦀 The configs to build it took me a while to figure out though since I've never made a native gem before.
(One small caveat though is that it doesn't support regexps with "lookbehind" sections, I had to work around that a bit on the #Ruby side)