Why I Switched From Rust to Go on the Backend

Pitchforks down, please! I felt your anger as soon as you clicked on the article. I have nothing against Rust — I prefer it for various use cases. All programming languages are means to an end. In my case, Rust simply did not cut it, and I had to gut the project and rewrite it in Golang.

The project is a simple backend webhook service for Hasura. If you aren’t familiar with Hasura, it’s a wrapper around a Postgres database that gives you an instant GraphQL API. It’s very handy for people like me, who are solo developers building out a passion project: writing out every REST endpoint or GQL resolver takes a ton of time, and it’s mostly the same CRUD operations on every model. This kind of falls apart when you need some more complex logic — for that, Hasura allows you to map a GQL request to a custom webhook. I use this for S3 file uploads or authentication, to name a few.

Problem One: Dependency Injection Woes The Rust dependency injection story is a interesting one. As soon as you ask for a concrete type, i.e.

You have to pass an instance of Database into do_stuff ; no exceptions! You can’t “subclass” Database (subclass is literally not a concept in Rust). So, if you were a programmer who didn’t test their code, then this would be perfectly fine; in reality, you’re really ever going to have one implementation of Database, so there’s no reason to make this function take anything other than Database .

And us testers? We have to rewrite the function signature. Database needs to be a trait, and then we take that trait and we implement it on our mock objects. Okay, that’s not so bad. In fact, I’m doing essentially the same thing in Golang; so where does this start to actually fall apart?

Problem Two: Async Traits In Rust, you have easy async, you have easy traits, but having async traits is a little difficult. Most examples I’ve found in Rust of async traits use the async_trait macro. That’s very helpful, and I was using it and was a happy camper.

In hindsight, this problem has a solution. Perhaps I should have given it another go before I made the switch to Go, but at this point I was already kind of frustrated…. by the next point.

Blah Blah Blah rust has bad compile times. We’ve heard it a thousand times; you can’t have a language that does everything and no downsides. That’s just impossible — Rust’s cons are that lifetimes are difficult to wrap your head around, and its compile times.

I have a nice, beefy laptop — the M1 Mac is a workhorse. Absolutely no problems with compiling rust on my Mac. Typically, when I write servers, I develop locally and make sure that each time I make a change, I reload the local server and test the feature very quickly before I commit to a real unit test. That requires lots of compiles between trials; which is fine! Again — no issues with compiling Rust on my Mac.

The easiest way for me to orchistate many local services without having to worry about running npm run in each service (Hasura, web hooks, mock s3, mock oauth server..) is to have a docker-compose.yaml that runs all of these things. That means, typically, it’s a docker-compose.dev.yaml because I don’t actually use the docker compose to deploy. only to develop locally. This has the side effect, though, of my Rust code needing to be compiled in the container — since:

I have two options: either throttle my whole computer by spinning up a massive image for Rust to compile in, or deal with 3+ minute compile times. My dev cycle grinded to a halt, and I felt incredibly unproductive. I tried changing my workflow to write the code and the test before manually testing, or to not use auto-hot reload, but I felt cripped. I just couldn’t do it.

I finally bit the bullet and switched to Go. You will be missed, Rust: I greatly enjoy writing Rust code. I find it beautiful and expressive, utilitarian yet elegant.

If I’m writing local helper libraries, performance sensitive code, any backend services I don’t need to run in a container…. Rust is the first pick. Especially if I don’t need to convince anyone else to use it.

I’ve experienced a whole host of problems with this approach. The QA team isn’t knowledgeable enough to do anything outside of auditing _process_ compliance. This won’t catch bugs, design flaws, etc.. and the transfer of knowledge from the architects to the ‘coders’ is often riddled with misunderstandings and confusion. Multiply with production schedules and the need to mark something as ‘complete’ (in tools) and you get a massive problem (poor quality) that just has to be resolved further down the pipe. This is particularly problematic in the automotive industry where SOP dates are basically set in stone, with poor upfront scheduling (not matching provided estimates) and new feature demands during the program from the customer.

It’s very tempting. It’s treating the ‘coding’ part like an assembly line. It *can* work so long as estimates are respected in the schedule and you have very effective review processes during the knowledge transfer....but this is where I see it break down, especially when teams are too lean - which usually seems to be the case when you’re tempted by constantly lowering costs.

From your link there was also more of him doing other in depth explanations.
The Johnny Carson show had on a guy who did a take on using key words in gov’t reports.

He is another group at a meeting with an expert. The comments are spot on.

The Expert (Short Comedy Sketch)
https://www.youtube.com/watch?v=BKorP55Aqvg

Brigg’s Wall
1 year ago
The striking part of it is that everyone in the table seems normal, as if it wasn’t ridiculouis their request, and you’re the one only sitting there that it’s not “normal”. Great example of corporate life.

Trev81
1 year ago
My dad was a public school teacher for 38 years. He told me this story once about a meeting his department had with a group of “educator coaches”, whose big talking point was making the grades of all students above-average. Not the national or state average, the school average. They spent the entire meeting desperately trying to convince them that it was literally impossible for ALL of the students to be above the average, and their response? “We don’t care, we know you can do it.”

Thank you two for the comments. Very much on target to my mild rant. I learned things from your insights.

Fortran 77, I am guessing that was a release date. Indeed if that was the case, that's the timeframe that I was learning then heavily using Fortran in college.

Fall ‘78 and spring ‘79, my two ChE senior design classes plus a third ChE specialty class were each using more university mainframe CPU time than than the entire computer science department. Fortunately, one of the guys on my team had taken 1 or 2 additional programming classes so had gotten into JCL and learned code to issue commands that allowed the programs to run more efficiently, faster. Later, he got ahold of a professor's pass code of some sort and that really sped things up. Cardinal rule - Never drop your boxes of punch cards.

Off to engineering finally and working in process R&D in the petrochemical world. Another ChE and I scavenged an obsolete Hewlett-Packard 9825 desktop computer originally the brains of a laboratory GC-MS. We wrote custom programs for our pilot plant data and general statistics using HP Basic. 99% Fortran. The enhancements were mainly for data input-output and a few clever commands for arrays that eliminated lots of do-loops. Yea!

Towards early 1981, powers that be tried to shut down our rogue desktop computer and force us onto the corporate mainframes. Told them to pound sand. Mainframe software too clunky and we were perfectly happy (and lazy). It escalated to a speed trial. Slam dunk, custom programming on the “obsolete” desktop took the data input, ran half a dozen statistic models then printed and plotted the results before the mainframe expert even typed in the data on the mainframe terminal.

About 6 months later, the company bought about 1000 desktops to spread around the company. First IBM PC hit the world. We had ours in the first procurement. About $2000 for the PC vs. the $20,000 we had tied up in the HP 9825. The first year or two, the IBM was largely a word processor for our tech reports. HP still used for number crunching, plotting. Lotus 123 hit the market. Our HP was eventually retired and it's plotter shifted to the PC.

I was a software tester for several years during this PC evolution. I think my main contribution to the software panel was if I had the patience to use and not crash a particular software package, any damn fool could use it.

In early 90s, the Quattro Pro spreadsheet hit the market with this marvelous feature called tabs. Better statistics and plotter interface than Lotus. Retired Lotus 123.

I switched to a different group and sort of fell into using Fortran again. Kind of mind bending kinetic modeling with compiled Fortran. Used MS-DOS edlin command to set up a batch file of input parameters then the computer would run an hour or two and hopefully converge to a solution. No plotting of the output, just a monster list of numbers to eyeball then adjust input for another run. Sucked. Used spreadsheet to log input and key output numbers.

In early 90s, I got back into programming for process modeling using Quattro Pro as the backbone. The strategy is really the same as writing a Fortran program. Use a far left column to tabulate results as the program ran through its steps. Use cells to the right for subroutine comments and calculations. Use Boolean statements to kick out the result to the far left data column cell.

My first try at this fortunately worked as it was a mass balance of an entire oil refinery. Many of the units were a simple but massive accounting exercise from production reports. Some of the units had data voids for my purpose and I'd create a custom model to get a mass balance. About 40 tabs in one Quattro Pro spreadsheet. Most tabs were were operating units. Several were for summary tables and plots that linked to the operating unit tabs. This took 9 months between the programming, management report and public report sent to regulators.

This Quattro Pro trick was used a few times then Microsoft created Excel, copied QP’s tab features and eventually drove them out of business. I switched to Excel.

So…. My conventional programming stopped in the 1980s and switched to the off the beaten track programming off and on until retiring a few years ago.

Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.