<p>Redditers</p>
<p>I'm trying to write some microservices as well as core system modules, on top of which the said microservices will run.</p>
<p>Various posts on the internet suggest using GoLang at least for writing microservices, however, I'm inclined to use Rust as I'm planning to write my system modules in Rust. </p>
<p>If anyone has tried either of these languages, can you please share your experience of using Go / Rust </p>
<p>NOTE: I already know that learning curve for GOLANG is much shorter than Rust</p>
<hr/>**评论：**<br/><br/>Thaxll: <pre><p>Few things:</p>
<ul>
<li><p>Rust does not have as many libraries as Go for talking to various services for server side things ( think cloud, gRPC, logging / tracing, database ect ...)</p></li>
<li><p>Same for frameworks</p></li>
<li><p>Rust needs nightly to build on a lot of recents projects</p></li>
<li><p>The Go standard lib has more packages to do anything backend related ( serialization, http, db, html template ect ... )</p></li>
<li><p>Concurrency is honestly better on Go for now, Tokio is not stable and there is no concensus on what to use and it's fairly complicated overall</p></li>
<li><p>Go tools are good, from the IDE to the various tools to debug, benchmark, profile Go code</p></li>
<li><p>Keep in mind that Go performance is pretty good, for micro services where IO is most likely the bottleneck you probably don't see that much difference with Rust</p></li>
</ul>
<p>On the end if it's just a pet project to learn you should pickup anything you want. tbh I don't think Rust is well suited for micro services where Go is really good at it.</p></pre>DakshHub: <pre><p>Thanks for your reply</p></pre>dericofilho: <pre><p>The choice between Go and Rust is all about memory management.</p>
<p>Rust assumes that you believe that GCs are sub-optimal, and provides you with a complete toolset to operate memory effectively.</p>
<p>Go assumes that you believe that GCs are optimal, and provides you with a toolset to manage pointers in a way that the GC can work effectively.</p>
<p>Therefore, you need to do some research on which of these two philosophies strikes your problem in some fundamental way.</p>
<p>For the sake of the example, let's assume that you have a microservice in your fleet that's a very hot spot. It takes lots of connections per second, some of then it just accept the connection and close it doing nothing. </p>
<p>Also, for the sake of the argument, let's assume you're a proficient programmer in both languages - so implementation problems won't hinder performance. </p>
<p>Coming from Rust, most likely you're going to structure your code around the opportunities to allocate and deallocate the memory and connection pointers. Probably you will take the lifetime of the pointer to the functions modifying the connection state. And manage its termination carefully so to avoid loss of time in some blocking call. So, every time you decide to use something, you will also decide if this same something could be deallocated or not (through lifetime management). </p>
<p>In Go, your experience will be dramatically different. Because you don't get to manually deallocate resources, you will be driven to think whether a certain resource is useful in some part of the code. If not, you will not use it, and it will be the GC's job to decide if the given resource is still used (through escape analysis for instance) - one badly written piece of code and GC will take longer to clean it up or the memory will leak. Go makes it very easy to write GC friendly code, so this shouldn't be an issue as long as you don't outpace the GC.</p>
<p>The trade-off is: you can choose to manually manage the memory, which is great if you know what you are doing and you are willing to pay the DX price in Rust; or, you can choose to give away the memory management to GC, lose control of how the memory looks to you, and you get a much easier DX experience.</p>
<p>The last but not the least. Both programming languages have been improving a lot lately. Rust is working out its ergonomic problems - and while I believe it will never be as easy as Go, it will be easy enough. </p>
<p>And Go has been improving a lot its runtime features (namely the GC) and its developer support toolset (observability tools - thanks @rakyll).</p>
<p>It means that any of these two choices are likely safe bets in long term. </p></pre>DakshHub: <pre><p>Thank you @dericofilho for detailed answers.</p></pre>ar1819: <pre><p>The question is very vague about your requirements. Please elaborate on your definition of "core system modules" and overall architecture requirements - such as CPU and RAM usage, latency, which of the web protocols you need, tooling, etc.</p>
<p>If you asking from terms of language expressiveness - Rust is more expressive. Is it better or not? You decide. </p></pre>DakshHub: <pre><p>Sorry for not being clear in question? My main question was to check the experience of people having written microservices in Go and/or Rust</p>
<p>I've written a prototype microservice in Rust and it doesn't disappoint, however, people generally recommend Go for microservice. </p>
<p>Intention was to check peoples opinion before making a Go / No-Go decision</p></pre>NovaX: <pre><p>There are many non-technical requirements not specified. For example, at work I rewrote our Python code base to Java and then rearchitected the product. This wasn't due to the language, but to match the strengths of the team as the founder's choices were excellent to bootstrap, but didn't match the strength of the team as we came onboard. Similarly the web/mobile frontends were rewritten. It is important to fit the technology to the team, as well as the strengths of the ecosystem, when choosing the technology stack.</p></pre>rayascott: <pre><p>I've coded in Go for a few months and wrote a bytecode parser and a graph database driver. Also experimented with some of the REST frameworks out there. There's a lot of hype about Go and I think it's mostly down to the fact that a) Google own and use it, b) it's really easy to learn & c) it makes concurrency seem easy. </p>
<p>Things I don't like about Go.
The core Go team have struggled to get it to perform at the speed of Java, and it'll never be anywhere near as fast as Rust, because of the GC. If all you're trying to do is get rid of the JVM memory overhead (useful for microservices) then perhaps you're better off with Go, but then you lose inheritance. Something I love. I digress. Rust benchmarks at anywhere between 2 to 10 times faster than Go, and in some cases it's even faster than C. </p>
<p>Error handling is a pain. Write some networking code, and you'll soon see 75% of your code is just spent handling errors. I heard quite a lot of experienced Go Developers complain about error handling. I prefer Rust's Result type that forces you to deal with errors, and the ? operator that you can use to "throw" and error up the stack. </p>
<p>Implied interface contracts. I just prefer seeing contracts stated upfront. Also, in Go, you don't have to group the method definitions of a type. You can define them all over the place spread across multiple files in a package (And people do it! I've seen this in code on GitHub.), which I dislike. Tryna figure out if a type implements an interface can turn into a hunt. I prefer Rust's Impl way of doing it. Also, there are no generics in Go. You'll soon find yourself having to write what essentially feels like boilerplate code, just to get around this, as you slowly feel your life ebb away. Go interfaces are just weird. There's no handy 'conformsTo' or 'instanceOf' keywords so you have to assign to the empty interface and then start your checking. </p>
<p>Rust has better support for enumerated types, where each variant can store it's own custom set of value types. It may not seem useful at first, but it's a really cool way to create types. </p>
<p>Imports in Go are simply defaulted to the head of the master branch of a repo. I'd seen people use vanity URLs (versioned URLS) in their source code(!??!) to get around this, but I never really explored this aspect of code integration, I just thought the idiomatic way of doing it was naive and ridiculous. And the amount of times I heard a Gopher claim that something was done a certain way because it was 'idiomatic' made me wonder if any of them could think for themselves. Rust uses Cargo and it works as anyone with a bit of open source coding under their belt, would expect. </p>
<p>Concurrency. I haven't delved into this much in Rust yet, but from what I have read and seen, I prefer Rust's way of making sure nothing can go wrong when you use channels. Go on the other hand, is a different story. You'll get told to use channels and go routines in Go because they're idiomatic. But the fact is that they are slow. Much slower than ditching green threads. And if you push a value into a channel in Go once the channel has closed at the other end, your app will crash. And guess what? There is no way to tell if the channel was closed at the other end. Good luck with that!</p>
<p>I got tired of hearing something was idiomatic every time you questioned a feature or such like. For example, you are encouraged to use single character variable names in Go because.... ta da! It's idiomatic. FML. Someone pointed out an opensource piece of code that was literally a call x.y.z(). And it wasn't code to handle 3D space coordinates. You are just supposed to know, and follow like an obedient dog. </p>
<p>And one thing that I never hear anyone else mention, but was honestly one of the things that use to grind on my nerves the most was the use of upper and lowercase to denote public/private scope. At first I thought "oh how minimalist of them! Someone finally saw what had been right in front of us for decades and managed to ditch explicit scope specifiers for a cool reinterpretation of size with regard to scope'. Except it catches you up all the time. How? Well look at this:</p>
<p>nb.Debug() - package level function call on a package called nb.
nb.Debug() - public method call on an instance variable called nb.</p>
<p>When you've spent decades writing in other langauges that have the convention of capitalizing type names, it gets super confusing when you see resultType and you automatically keep thinking it's a variable name and not a type like ResultType.</p>
<p>Read "Programming Rust" by Blandy et al.. I've been a software engineer since the mid 90s and it's one of the best books on a language I've ever read. The amount of thought that has gone into the language has me convinced that it is future of systems programming and a very welcomed replacement for C/C++.</p>
<p>There may be less library and tool choices out there for Rust, but I would guess most people give up on Rust because of it's ownership rules, which, if you've spent as much time as I have coding, simple enforce what you probably already know about best practices in coding. You'll be a better engineer for it. </p>
<p>Also, Visual Source Code has support for Rust which includes the Rust Language Server and a step-debugger. Best light weight editor I've used in years. </p>
<p>I've been wanting to get this off my chest for months :-)</p></pre>andradei: <pre><p>That comment comes across to me as mostly emotional opinion (except the performance part) because I like Go for the same reasons you dislike it.</p>
<ul>
<li>I'm not a fan of inheritance</li>
<li>Although Go's convention is to err on the side of brevity, I was never told to or called out for using variables longer than one character</li>
<li>I don't get the vibe that you must follow convention like an obedient dog</li>
<li>There is a <a href="https://manishearth.github.io/blog/2018/01/10/whats-tokio-and-async-io-all-about/">blog post</a> written from a notorious Rust developer that praises Go's concurrency, goroutines, and channels implementation while explaining the details of Tokio (one Rust's concurrency library)</li>
</ul>
<p> </p>
<p>That being sad, I love both languages, but whether I pick one over the other is a matter of how much control I want over memory, how performant I need my library/binary to be, and how limited the target machine(s) is in terms of resources. But for most of my projects Go is good enough. Plus I'm more productive in Go than in Rust, but that's subjective.</p></pre>rayascott: <pre><p>What languages have programmed in in the past? </p></pre>ar1819: <pre><blockquote>
<p>The core Go team have struggled to get it to perform at the speed of Java, and it'll never be anywhere near as fast as Rust, because of the GC.</p>
</blockquote>
<p>GC can be faster than "semi-manual" allocation. Please look into "pointer bump allocations" and local allocations. GC doesn't directly affect speed, it affects latency. From totally unpredictable to hardly predictable ways. If you have hard real-time requirements, aka you work in finance or avionics for example - GC will be in your way. Game devs tend to develop a customized version of GC because of their requirements.</p>
<blockquote>
<p>I digress. Rust benchmarks at anywhere between 2 to 10 times faster than Go, and in some cases, it's even faster than C.</p>
</blockquote>
<p>They used typed arenas - which is actually very cool. But you'll rarely see this in real life projects because this requires some serious forward thinking because it's essentially a static vector. Haven't seen this anywhere, aside from embedded.</p>
<p>Also - it's not faster than C. Its LLVM doing some optimizations better than GCC.</p>
<blockquote>
<p>Error handling is a pain. Write some networking code, and you'll soon see 75% of your code is just spent handling errors. I heard quite a lot of experienced Go Developers complain about error handling. I prefer Rust's Result type that forces you to deal with errors, and the ? operator that you can use to "throw" and error up the stack. </p>
</blockquote>
<p>It's better to annotate error, rather than simply propagate it. Your colleagues will thank you.</p>
<blockquote>
<p>Tryna figure out if a type implements an interface can turn into a hunt.</p>
</blockquote>
<p>Ehh, both VSCode and IDEA can do it. Pretty sure VIM can too.</p>
<blockquote>
<p>Also, there are no generics in Go. You'll soon find yourself having to write what essentially feels like boilerplate code, just to get around this, as you slowly feel your life ebb away.</p>
</blockquote>
<p>I write network and system specific code. I miss generics sometimes. I do not feel "my life ebb away".</p>
<blockquote>
<p>There's no handy 'conformsTo' or 'instanceOf' keywords so you have to assign to the empty interface and then start your checking. </p>
</blockquote>
<p>WHAT?</p>
<blockquote>
<p>Imports in Go are simply defaulted to the head of the master branch of a repo. </p>
</blockquote>
<p>Please repeat with me: imports != package management.</p>
<blockquote>
<p>Concurrency. I haven't delved into this much in Rust yet, but from what I have read and seen, I prefer Rust's way of making sure nothing can go wrong when you use channels.</p>
</blockquote>
<p>Which one? std or crossbeam? BTW Rust still doesn't have an MPMC queue.</p>
<blockquote>
<p>But the fact is that they are slow. Much slower than ditching green threads.</p>
</blockquote>
<p>Slow is about 50-100ns btw. Which is faster than what Rust has in std, actually.</p>
<blockquote>
<p>And guess what? There is no way to tell if the channel was closed at the other end. Good luck with that!</p>
</blockquote>
<p>Don't close channel on the receiver side. You can check that channel is closed during receive operation:
Like <code>val, ok := <-myChan</code> and then check ok.</p>
<blockquote>
<p>I got tired of hearing something was idiomatic every time you questioned a feature or such like.</p>
</blockquote>
<p>At this point, I quite sure you never interacted with experienced Go developers, and just spill out your frustration with some quirks you encountered along the way. But again, beating zealotry with zealotry is not a good tactic.</p>
<blockquote>
<p>For example, you are encouraged to use single character variable names in Go because.... ta da! It's idiomatic. FML.</p>
</blockquote>
<p>Only if it make sense. </p>
<blockquote>
<p>Someone pointed out an opensource piece of code that was literally a call x.y.z(). And it wasn't code to handle 3D space coordinates.</p>
</blockquote>
<p>I saw that in Java codebase, so I should start bashing Java now?</p>
<blockquote>
<p>You are just supposed to know, and follow like an obedient dog. </p>
</blockquote>
<p>Ehh, no?</p>
<blockquote>
<p>When you've spent decades writing in other langauges that have the convention of capitalizing type names</p>
</blockquote>
<p>Personal taste. I spent time writing code in camelCase, snake_case, PascalCase. Don't care, as long as it fits the existing codebase.</p>
<blockquote>
<p>There may be less library and tool choices out there for Rust, but I would guess most people give up on Rust because of it's ownership rules, which, if you've spent as much time as I have coding, simple enforce what you probably already know about best practices in coding. You'll be a better engineer for it. </p>
</blockquote>
<p>Because implementing cycle graph without pain is not "cool enough".</p>
<p>Rust deals badly when application memory ownership is unexplicit by design - you can read about the struggles of those how to try to make good Qt or GTK bindings. Most of the time it ends up in wrapping stuff into <code>Arc<></code>. This is not good.</p>
<blockquote>
<p>I've been wanting to get this off my chest for months :-)</p>
</blockquote>
<p>I'm glad you did - I hope that it helped you. Yet it was nowhere useful - it vaguely contained the words like "CPU\RAM usage" and "latency". It didn't contain anything about ecosystem (libs\tooling - btw arewewebyet?), "stackfull vs stackless model" of green threads with pro and cons of having the scheduler. It didn't had any insight about memory model, and perf implications of jemmaloc.</p>
<p>So - instead of giving engineering response, you ranted. But I suppose it's okay.</p></pre>Hnefi: <pre><blockquote>
<p>BTW Rust still doesn't have an MPMC queue.</p>
</blockquote>
<p>Is there something wrong with <a href="https://github.com/BurntSushi/chan" rel="nofollow">chan</a> and <a href="https://github.com/schets/multiqueue" rel="nofollow">multiqueue</a>?</p></pre>ar1819: <pre><p>Just like with all multithread queues there are questions about fairness\distribution\speed. If you read the source of chan, you will see that Andrew Gallant admitted himself that he is not pro in this stuff(he is brilliant with DFA tho). Crossbeam is cool because it has papers and guarantees under. If you want to know more, both Jeff Preshing and Cameron have very good articles about implementing fast and scalable queues. Also 1024cores.net</p>
<p>Implementing basic *P*C queue is not that hard - you can wrap vec with the mutex and be done with it. Implementing it correctly, however...</p></pre>Hnefi: <pre><p>So, the problem is that there might be a mistake somewhere in the implementation of either crate? Isn't that true for pretty much all software in common use? How does that justify the claim that Rust does not have an MPMC queue?</p></pre>rayascott: <pre><p>And your’s wasn’t a rant. Do you suffer from a personality disorder? Might want to tone down the insults, and personal attacks. I wasn’t having a go at you. Why are you taking my experiences with Go so personally? I get that you clearly seem to know everything. It doesn’t matter if it’s LLVM that’s responsible for the speed optimisations, when what you push into production is simply slower that the same code written in Rust. </p>
<p>Next you’ll be telling me that Rust doesn’t annihilate Go in this benchmark. But hey, I guess it’s OK. GC can be faster. </p>
<p><a href="http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=go" rel="nofollow">http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=go</a></p>
<p>You are actually complaining that I left something out, of my own comments. What is wrong with you? </p>
<p>Oh and you didn’t even mention <a href="https://areweideyet.com" rel="nofollow">https://areweideyet.com</a> How embarrassing for you.</p></pre>ar1819: <pre><p>I didn't insult you - you are more than welcome to invite mods to this discussion if you see it otherwise and see how it goes. And no - it wasn't rant - most of your points was incorrect or subjective - so I tried to make some corrections to wrong assumptions. Your post is a good rant, there is nothing wrong with that, but it doesn't help when one need to chose between one tool and another, like original poster requested. I stand by this. </p>
<p>I also don't know everything. To be honest with each new knowledge I understand that I know even less. This is why when I debate something with someone I don't use my personal taste and use facts. I also try to investigate things before I make any sort of claims. This is why I think that hype driven development is not helpful. </p>
<p>Also - if you want to play benchmarks game while comparing Rust vs Go you could as well use - <a href="https://www.techempower.com/benchmarks/" rel="nofollow">https://www.techempower.com/benchmarks/</a></p></pre>rayascott: <pre><p>I don’t comment on here to take sarcastic barbs from trolls like you that hide behind anonymous usernames. I’ve seen the way you talk to other users on here. Read the rules. And really I’m not interested in your interpretation of the rules or your behaviour. </p>
<p>“Please do moderate based on quality, not opinion. Well written and interesting content can be worthwhile, even if you disagree with it.” In other words, I’m entitled to my opinion. What I don’t appreciate is you calling it a rant when it’s my personal opinion, which is really none of your business. People are actually allowed to voice their opinions on here. </p>
<p>Also, don’t call me a liar, when I’m not... “At this point, I quite sure you never interacted with experienced Go developers”. </p>
<p>I don’t know who you are, or who you think you are speaking to, but you clearly seem to have absolutely no respect for other people, or their opinions. I’m also not here to play games, as I’m sure you have realised. Yet you decide to insult me and the evidence I present that Rust benchmarks faster than Go with a completely unrelated web framework benchmark, which has absolutely no relevance whatsoever with regard to language performance. Those frameworks could be doing any number of varied operations that their competitor is not. Obviously a less feature-full Framework will be faster. Please leave me alone. Thank you.</p></pre>nevyn: <pre><p>It's not obvious why you comment here at all, you seem to not like Go and aren't willing to talk to anyone who disagrees with you.</p></pre>rayascott: <pre><p>Then I suggest you read the original question. He wanted opinions on Go and (god-forbid a different language than the topic) Rust. Have you even programmed in Rust? I answered to help the person who asked the question. I didn’t answer his question hoping someone would turn it into a debate, because I’m not interested in your opinion. Why would I be? I was called a liar, for no reason at all when all I was trying to do was help someone, and now I’m replying to someone who is confused about the thread. Life is too short for this. </p>
<p>I found this page through Google. That’s right, I don’t have Gopher stickers all over my laptop or a t-shirt that says “In Go We Trust”. Go! </p></pre>nevyn: <pre><blockquote>
<p>Have you even programmed in Rust</p>
</blockquote>
<p>Not much, but I'd assume more than you've programmed in Go.</p>
<blockquote>
<p>I was called a liar, for no reason at all</p>
</blockquote>
<p>No, you weren't.</p>
<blockquote>
<p>and now I’m replying to someone who is confused about the thread.</p>
</blockquote>
<p>No, I'm not.</p>
<p>Here's a free clue though, not everybody who disagrees with you is a "troll" or "confused". You should work a lot on how you (don't) take criticism.</p>
<blockquote>
<p>Life is too short for this.</p>
</blockquote>
<p><a href="https://twitter.com/tomgreenlive/status/463016192274202624?lang=en" rel="nofollow">https://twitter.com/tomgreenlive/status/463016192274202624?lang=en</a></p></pre>defunkydrummer: <pre><blockquote>
<p>Things I don't like about Go. The core Go team have struggled to get it to perform at the speed of Java, and it'll never be anywhere near as fast as Rust, because of the GC.</p>
</blockquote>
<p>It can be made as fast as Rust if Google updates Go to give you options to get around/avoid the GC. </p>
<p>This has already been done in the past, for example Lisp can go as fast as Fortran or C with similar tricks (avoiding the GC and using type declarations). It isn't idiomatic anymore, but it helps having this option when needed.</p>
<p>So it can be possible for Go in the future. I also agree with your criticisms, but I just want to be fair. </p>
<p>PS: Excellent critique of the positives and negatives.</p></pre>qu33ksilver: <pre><blockquote>
<p>It can be made as fast as Rust if Google updates Go to give you options to get around/avoid the GC.</p>
</blockquote>
<p>Umm .. Go <em>does</em> give you options to do that. You can disable GC with <code>runtime.SetGCPercent(-1)</code>, and do a manual GC run with <code>runtime.GC()</code>.</p>
<p>But if you do that, you lose the whole point of using Go. If you don't need a garbage collector, you might as well go with Rust or C++.</p>
<p>Use the right tool for the right job. Don't force a single tool to do everything.</p></pre>iroflmaowtf: <pre><p>I'll have you know that your comment isn't idiomatic...</p>
<p>j/k great comment!</p></pre>DakshHub: <pre><p>Thanks a lot @rayascott .. made my choice easy.. will definitely read that book and will share my experience of development using Rust</p></pre>drvd: <pre><p>If the main driver is what you want (e.g. what you want to learn): Just do whatever you want in whatever language you want.</p>
<p>Your question seems to indicate that you do neither of the two languages which makes the question a bit strange because both options might be a way to disaster.</p>
<p>What other requirements than being inclined to write a certain part in one special language are there?</p></pre>DakshHub: <pre><p>Hello </p>
<p>I've started using/learning Rust for a couple of months for my project as many of the modules I need to use is already written in Rust. </p>
<p>Intention was to check if there is any specific reason why I shouldn't use Rust for my microservices and instead choose Golang</p></pre>HowardTheGrum: <pre><p>No, if you are comfortable coding in Rust, there is no particular reason to use Go for portions of your project, and indeed, there is a good reason not to - technical debt and cognitive load. </p>
<p>First, technical debt: Normally this is about the cost of using an 'easy' solution now only to have to reimplement it later in something that can handle a more complicated situation; but in this case, it is not about easy/hard that I am referencing it, just the potential cost of later reimplementation, specifically from the perspective of refactoring. If part of your project is in Go (or any other language) and part in Rust, then this creates a sharper boundary, where you will be more reluctant to move code across it than you would if both were in the same language. So, for example, if later on, you realize that part of your main project could be moved into a microservice, and all your microservices are in Go, you may skip over that opportunity due to the implicitly felt need to rewrite in Go; or vice-versa if it turns out that some portion would work better within the monolithic portion. If both elements are in the same language, you can more easily shatter or compose during refactoring.</p>
<p>Second: cognitive load. I program regularly professionally in vb.net, java, and go; at prior jobs I have had to juggle coding in vb.net and two forms of C, and at other times Perl, Python, PHP, and Javascript. Each time I have to switch frames to a different language, I notice an increased cognitive load - I have to remind myself what patterns apply here, what rules of formatting, do type definitions go before or after parameters, return values before or after parameter definitions, etc. Likewise within a single language, switching between projects that have different sets of frameworks, libraries, or just environments (like C on desktop vs. C on handheld device, or different GUI environments), it takes a little time to get back up to full speed. It is not a huge thing, certainly not enough to by itself determine that you should never include multiple languages - but it is something to consider, and when it is possible to do the entire project in one language comfortably, it speaks against multiplying languages/environments unnecessarily. It is the same sort of impulse that might push one to use GopherJS to write Go code on the front-end, or Node-JS on the backend. </p></pre>NilacTheGrim: <pre><p>Sorry to be that guy that says the dumb thing here: but -- is it just me or does Rust have the most awful name conceivable for a language?</p>
<p>I can't take myself seriously programming in a language called Rust. Sorry.</p>
<p>I know, it's stupid. I essentially see Rust as a more intricate Go, but with a dumber name.</p></pre>
