dockerfile/examples/omnivore/content-fetch/readabilityjs/test/test-pages/bitfieldconsulting/expected.html

239 lines
36 KiB
HTML
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<DIV class="page" id="readability-page-1">
<div id="yui_3_17_2_1_1611753884544_92">
<div data-aspect-ratio="47.0873786407767" data-block-type="5" data-test="image-block-inline-outer-wrapper" id="block-yui_3_17_2_1_1604660651634_14468">
<figure id="yui_3_17_2_1_1611753884544_89">
<p><img data-src="https://images.squarespace-cdn.com/content/v1/5e10bdc20efb8f0d169f85f9/1604661052496-1JWECFMKSRR7UKSHE1L2/ke17ZwdGBToddI8pDm48kBfoYxOA_pZe3DaZs9RVJSIUqsxRUqqbr1mOJYKfIPR7LoDQ9mXPOjoJoqy81S2I8N_N4V1vUb5AoIIIbLZhVYxCRW4BPu10St3TBAUQYVKcIW6kmdqM2CDGG1rvMQo1JpzhjrOryQb_D7KvZjluOzGfODKIY3A_js2Krrat3vB0/rust-vs-go-wide.png" data-image="https://images.squarespace-cdn.com/content/v1/5e10bdc20efb8f0d169f85f9/1604661052496-1JWECFMKSRR7UKSHE1L2/ke17ZwdGBToddI8pDm48kBfoYxOA_pZe3DaZs9RVJSIUqsxRUqqbr1mOJYKfIPR7LoDQ9mXPOjoJoqy81S2I8N_N4V1vUb5AoIIIbLZhVYxCRW4BPu10St3TBAUQYVKcIW6kmdqM2CDGG1rvMQo1JpzhjrOryQb_D7KvZjluOzGfODKIY3A_js2Krrat3vB0/rust-vs-go-wide.png" data-image-dimensions="1091x513" data-image-focal-point="0.5,0.5" data-load="false" data-image-id="5fa52f3ca27e0764adfc294a" data-type="image" alt="rust-vs-go-wide.png" data-image-resolution="750w" src="https://images.squarespace-cdn.com/content/v1/5e10bdc20efb8f0d169f85f9/1604661052496-1JWECFMKSRR7UKSHE1L2/ke17ZwdGBToddI8pDm48kBfoYxOA_pZe3DaZs9RVJSIUqsxRUqqbr1mOJYKfIPR7LoDQ9mXPOjoJoqy81S2I8N_N4V1vUb5AoIIIbLZhVYxCRW4BPu10St3TBAUQYVKcIW6kmdqM2CDGG1rvMQo1JpzhjrOryQb_D7KvZjluOzGfODKIY3A_js2Krrat3vB0/rust-vs-go-wide.png?format=750w">
</p>
</figure>
</div>
<div id="block-f0eb5fb65d68113734ba" data-block-type="44">
<p> Which is better, Rust or Go? Which language should you choose for your next project, and why? How do the two compare in areas like performance, simplicity, safety, features, scale, and concurrency? What do they have in common, and where do they fundamentally differ? Let's find out, in this friendly and even-handed comparison of Rust and Golang, from the author of the <a href="https://bitfieldconsulting.com/books/">For the Love of Go</a> book series. </p>
<h2 id="rust-and-go-are-both-awesome"> Rust and Go are both awesome </h2>
<p> First, it's really important to say that <em>both Go and Rust are absolutely excellent programming languages</em>. They're modern, powerful, widely-adopted, and offer excellent performance. You may have read articles and blog posts aiming to convince you that Go is better than Rust, or vice versa. But that really makes no sense; every programming language represents a set of trade-offs. Each language is optimised for different things, so your choice of language should be determined by what suits you and the problems you want to solve with it. </p>
<p> In this article, I'll try to give a brief overview of where I think Go is the ideal choice, and where I think Rust is a better alternative. Ideally, though, you should have a working familiarity with both languages. While they're very different in syntax and style, both Rust and Go are first-class tools for building software. With that said, let's take a closer look at the two languages. </p>
<h2 id="the-similarities"> The similarities </h2>
<p> Rust and Go have a lot in common, which is one reason you often hear them mentioned together. What are some of the common goals of both languages? </p>
<blockquote>
<p> Rust is a low-level statically-typed multi-paradigm programming language thats focused on safety and performance.<br><a href="https://serokell.io/blog/rust-guide">Gints Dreimanis</a>
</p>
<p> Go is an open source programming language that makes it easy to build simple, reliable, and efficient software.<br><a href="https://golang.org/">Golang.org</a>
</p>
</blockquote>
<h3 id="memory-safety"> Memory safety </h3>
<p> Both Go and Rust belong to the group of modern programming languages whose priority is <em>memory safety</em>. It's become clear over many decades of using older languages such as C and C++ that one of the biggest causes of bugs and security vulnerabilities is accessing memory unsafely or incorrectly. Rust and Go deal with this problem in different ways, but both aim to be smarter and safer than other languages about managing memory, and to help you write correct and performant programs. </p>
<h3 id="fast-compact-executables"> Fast, compact executables </h3>
<p> They're both compiled languages, which means your programs are translated directly to executable machine code, so that you can deploy your program as a single binary file; unlike interpreted languages such as <a href="http://fakehost/test/golang/go-vs-python">Python</a> and Ruby, you don't need to distribute an interpreter and lots of libraries and dependencies along with your program, which is a big plus. This also makes both Rust and Go programs extremely fast in comparison to interpreted languages. </p>
<h3 id="general-purpose-languages"> General-purpose languages </h3>
<p> Rust and Go are also both powerful, scalable general-purpose programming languages, which you can use to develop all kinds of modern software, from web applications to distributed microservices, or from embedded microcontrollers to mobile apps. Both have excellent standard libraries and a thriving third-party ecosystem, as well as great commercial support and a large user base. They've both been around for many years, and will continue to be widely used for years to come. Learning either Go or Rust today will be a sound investment of your time and effort. </p>
<h3 id="pragmatic-programming-style"> Pragmatic programming style </h3>
<p> Neither are primarily functional languages (like Scala or Elixir, for example), and neither are exclusively object-oriented (like Java and C#). Instead, while both Go and Rust have features associated with functional and object-oriented programming, they're pragmatic languages aimed at solving problems in whatever way is most appropriate, rather than forcing you into a particular way of doing things. (If you like the functional style of programming, though, youll find a lot more facilities for it in Rust, because Rust <em>has</em> a lot more facilities than Go in general.) </p>
<blockquote>
<p> We can debate about what an object-oriented language is, but its fair to say that the <em>style</em> of object-oriented programming that C++, Java, or C# users would expect is not present in either Go or Rust.<br> —Jack Mott </p>
</blockquote>
<h3 id="development-at-scale"> Development at scale </h3>
<p> Both Rust and Go have some useful features which make them suitable for programming in the large, whether that means large teams, or large codebases, or both. </p>
<p> For example, whereas C programmers have argued for years about where to put their brackets, and whether code should be indented with tabs or spaces, both Rust and Go eliminate such issues completely by using a standard formatting tool (<code>gofmt</code> for Go, <code>rustfmt</code> for Rust) which rewrites your code automatically using the canonical style. Its not that this particular style is so wonderful in itself: its the <em>standardisation</em> which Rust and Go programmers appreciate. </p>
<blockquote>
<p>
<code>gofmt</code>s style is no ones favourite, yet <code>gofmt</code> is everyones favourite.<br><a href="https://www.youtube.com/watch?v=PAAkCSZUG1c&t=8m43s">Rob Pike</a>
</p>
</blockquote>
<p> Another area where both languages score highly is in the build pipeline. Both have excellent, built-in, high-performance standard build and dependency management tools; no more wrestling with complex third-party build systems and having to learn a new one every couple of years. </p>
<blockquote>
<p> Building Go and Rust code, having come from a Java and Ruby background in my early career, felt like an impossible weight off my shoulders. When I was at Google, it was a relief to come across a service that was written in Go, because I knew it would be easy to build and run. This has also been true of Rust, though I've only worked on that at much smaller scale. I'm hoping that the days of infinitely configurable build systems are dead, and languages all ship with their own purpose-built build tools that just work out of the box.<br><a href="https://samwho.dev/">Sam Rose</a>
</p>
</blockquote>
<h2 id="so-what-s-all-the-fuss-about-"> So whats all the fuss about? </h2>
<p> With all that in mind, and seeing that both languages are so well-designed and powerful, you might be wondering what all the holy wars are about (me too). Why do people make such a fuss about 'Go versus Rust', getting into angry social media spats and writing long blog posts about how only an idiot would use Rust, or that Go isn't a real programming language, or whatever. It might make them feel better, but it doesn't exactly help you, as someone trying to decide which language to use for your project, or which you should learn to advance your programming career. A wise person doesn't make important choices based on who shouts the loudest. </p>
<p> Let's continue our grown-up discussion now by looking at some areas where a reasonable person might prefer one language over the other. </p>
<h2 id="performance"> Performance </h2>
<p> We've said that both Go and Rust produce extremely fast programs because they're compiled to native machine code, without having to go through an interpreter or virtual machine. However, Rust's performance is particularly outstanding. It's comparable with C and C++, which are often regarded as the highest-performance compiled languages, but unlike these older languages, it also offers memory safety and concurrency safety at essentially no cost in execution speed. Rust also allows you to create complex abstractions without paying a performance penalty at run-time. </p>
<p> By comparison, although Go programs also perform extremely well, Go is primarily designed for speed of <em>development</em> (including compilation), rather than speed of execution. The Go compiler doesnt spend a lot of time trying to generate the most efficient possible machine code; it cares more about compiling lots of code quickly. So Rust will usually beat Go in run-time benchmarks. </p>
<p> Rusts run-time performance is also consistent and predictable, because it doesnt use garbage collection. Gos garbage collector is very efficient, and its optimised to make its stop-the-world pauses as short as possible (and getting shorter with every new Go release). But garbage collection inevitably introduces some unpredictability in the way programs behave, which can be a serious issue in some applications, such as embedded systems. </p>
<p> Because Rust aims to give the programmer complete control of the underlying hardware, it's possible to optimise Rust programs to be pretty close to the maximum theoretical performance of the machine. This makes Rust an excellent choice for areas where speed of execution beats all other considerations, such as game programming, operating system kernels, web browser components, and real-time control systems. </p>
<h2 id="simplicity"> Simplicity </h2>
<p> It doesn't matter how fast a programming language is if nobody can figure out how to use it. Go was deliberately conceived as a reaction against the ever-growing complexity of languages like C++; it has very little syntax, very few keywords, and, indeed, few features. This means it doesn't take long to learn the Go language to the point where you can write useful programs in it. </p>
<blockquote>
<p> Go is incredibly easy to learn. I know this is an often-touted benefit, but I was really surprised at how quickly I was able to be productive. Thanks to the language, docs, and tools, I was writing interesting, committable code after literally two days.<br><a href="https://medium.com/better-programming/early-impressions-of-go-from-a-rust-programmer-f4fd1074c410">Early Impressions of Go From a Rust Programmer</a>
</p>
</blockquote>
<p> The key word here is <em>simplicity</em>. Simple isn't the same as easy, for sure, but a small, simple language is easier to learn than a large, complex one. There just aren't that many different ways to do things, so all well-written Go code tends to look the same. Its easy to just dive into an unfamiliar service and understand what its doing. </p>
<pre><code>fmt.Println("Gopher's Diner Breakfast Menu")
for dish, price := range menu {
fmt.Println(dish, price)
}</code></pre>
<p> (In the <a href="http://fakehost/videos">Code Club</a> series, I do exactly that: pick Go projects semi-randomly from GitHub and explore them with a group of Go beginners, to see how much of the code we can understand. It always turns out to be more than we expected!) </p>
<p> Although the core language is small, Gos standard library is very powerful. That means your learning curve will also need to include the parts of the standard library that you need, not just Go syntax. On the other hand, moving functionality out of the language and into the standard library means that you can focus on learning only the libraries that are relevant to you right now. </p>
<p> Go is also designed for software development at scale, with large codebases and large teams. In these situations, it's important that new developers can get up to speed as quickly as possible. </p>
<blockquote>
<p> With Go, you get things done—fast. Go is one of the most productive languages I've ever worked with. The mantra is: <em>solve real problems today</em>.<br><a href="https://endler.dev/2017/go-vs-rust/">Matthias Endler</a>
</p>
</blockquote>
<h2 id="features"> Features </h2>
<blockquote>
<p> Rust supports more complexity than several other programming languages, therefore, you can achieve more with it. For example, it supports generics.<br><a href="https://devathon.com/blog/rust-vs-go-which-programming-language-to-choose/">Devathon</a>
</p>
</blockquote>
<p> Rust is specifically designed to include lots of powerful and useful features to help programmers do the most with the least code. For example, Rust's <code>match</code> feature lets you write flexible, expressive logic quite concisely: </p>
<pre><code>fn is_prime(n: u64) -&gt; bool {
match n {
0...1 =&gt; false,
_ =&gt; !(2..n).any(|d| n % d == 0),
}
}</code></pre>
<p> Because Rust <em>does</em> a lot, this means there's a lot to learn, especially at the start. But that's okay: there's a lot to learn in C++ or Java, too, and you don't get the advanced features that come with Rust, like memory safety. To criticise Rust for being a complex language misses the point: it's designed to be expressive, which means having a lot of features, and in many situations that's what you want from a programming language. There's a learning curve, for sure, but once youre up and running with it, youll be fine. </p>
<blockquote>
<p> Rust competes for mindshare with C++ and D for programmers who are prepared to accept more complex syntax and semantics (and presumably higher readability costs) in return for the maximum possible performance.<br><a href="https://dave.cheney.net/2015/07/02/why-go-and-rust-are-not-competitors">Dave Cheney</a>
</p>
</blockquote>
<h2 id="concurrency"> Concurrency </h2>
<p> Most languages have some form of support for concurrent programming (doing multiple things at once), but Go was designed for this job from the ground up. Instead of using operating system threads, Go provides a lightweight alternative: <em>goroutines</em>. Each goroutine is an independently executing Go function, which the Go scheduler will map to one of the OS threads under its control. This means that the scheduler can very efficiently manage a large number of concurrent goroutines, using only a limited number of OS threads. </p>
<p> Consequently, you can run millions of concurrent goroutines in a single program without creating serious performance problems. That makes Go the perfect choice for high-scale concurrent applications such as webservers and microservices. </p>
<p> Go also features fast, safe, efficient ways for goroutines to communicate and share data, using <em>channels</em>. Go's concurrency support feels well-designed, and a pleasure to use. Reasoning about concurrent programs is hard in general, and building reliable, correct concurrent programs is a challenge in any language. Because it was built into the language from the start, though, instead of being an afterthought, concurrent programming in Go is about as simple and well-integrated as it could reasonably be. </p>
<blockquote>
<p> Go makes it very easy to build a nicely factored application that takes full advantage of concurrency while being deployed as a set of microservices. Rust can do those things, too, but its arguably a bit tougher. In some respects, Rusts obsession with preventing memory-related security vulnerabilities means that programmers have to go out of their way to perform tasks that would be simpler in other languages, including Go.<br><a href="https://sdtimes.com/softwaredev/the-developers-dilemma-choosing-between-go-and-rust/">Sonya Koptyev</a>
</p>
</blockquote>
<p> The concurrency story in Rust is very new, by comparison, and still stabilising, but its under very active development, so watch this space. For example, Rusts <a href="https://github.com/rayon-rs/rayon">rayon</a> library provides a very elegant and lightweight way of turning sequential computations into parallel ones. </p>
<blockquote>
<p> Having lightweight syntax for spawning Go routines and using channels are really nice. It really shows the power of syntax that such small details make concurrent programming feel so much nicer than in other languages.<br><a href="https://medium.com/better-programming/early-impressions-of-go-from-a-rust-programmer-f4fd1074c410">Early Impressions of Go From a Rust Programmer</a>
</p>
</blockquote>
<p> While it may be a bit less straightforward to implement concurrent programs in Rust, its still possible, and those programs can take advantage of Rusts guarantees about safety. A good example is the standard librarys <code>Mutex</code> class: in Go, you can forget to obtain a mutex lock before accessing something, but Rust wont let you do that. </p>
<blockquote>
<p> Go is focused on concurrency as a first class concept. That is not to say you cannot find aspects of Gos actor oriented concurrency in Rust, but it is left as an exercise to the programmer.<br><a href="https://dave.cheney.net/2015/07/02/why-go-and-rust-are-not-competitors">Dave Cheney</a>
</p>
</blockquote>
<h2 id="safety"> Safety </h2>
<p> We saw earlier that both Go and Rust aim, in different ways, to prevent a large class of common programming errors, to do with memory management. But Rust in particular goes to great lengths to ensure that you can't do something unsafe that you didn't mean to do. </p>
<blockquote>
<p> Rust's very strict and pedantic compiler checks each and every variable you use and every memory address you reference. It avoids possible data race conditions and informs you about undefined behavior. Concurrency and memory safety issues are fundamentally impossible to get in the safe subset of Rust.<br><a href="https://bitbucket.org/blog/why-rust">Why Rust?</a>
</p>
</blockquote>
<p> This is going to make programming in Rust a different experience to almost all other languages, and it may be a challenging one at first. But for many people, the hard work is worth it. </p>
<blockquote>
<p> For me the key advantage of Rust is a feeling that the compiler has my back and won't let through any bug it could possibly detect (seriously, it feels like magic sometimes).<br> —Grzegorz Nosek </p>
</blockquote>
<p> Many languages, including Go, have facilities to help programmers avoid mistakes, but Rust takes this to a new level, so that potentially incorrect programs wont even compile. </p>
<blockquote>
<p> With Rust, the library programmer has a lot of tools to prevent her users making mistakes. Rust gives us the ability to say that we <em>own</em> a specific piece of data; it's not possible for anything else to claim ownership, so we know nothing else will be able to modify it. I can't think of a time I've ever been given this many tools to prevent accidental misuse before. It's a wonderful feeling.<br><a href="https://samwho.dev/">Sam Rose</a>
</p>
</blockquote>
<p> "Fighting with the borrow checker" is a common syndrome for new Rust programmers, but in most cases the problems that it finds are genuine bugs (or at least potential bugs) in your code. It may force you to fundamentally re-architect your program to avoid running into these issues; and that's a good thing, when correctness and reliability are your top priority. What's the point of a language that doesn't change the way you program? The lessons that Rust teaches about safety can be useful when youre working in other languages, too. </p>
<blockquote>
<p> If you choose Rust, usually you need the guarantees that the language provides: safety against null pointers and data races, predictable runtime behaviour, and total control over the hardware. If you don't require any of these features, Rust might be a poor choice for your next project. That's because these guarantees come with a cost: ramp-up time. You'll need to unlearn bad habits and learn new concepts. Chances are, you will fight with the borrow checker a lot when you start out.<br><a href="https://endler.dev/2017/go-vs-rust/">Matthias Endler</a>
</p>
</blockquote>
<p> How challenging you find Rust's programming model probably depends on what previous experience you have in other languages. Python or Ruby programmers may find it restrictive; others will be delighted. </p>
<blockquote>
<p> If youre a C or C++ programmer whos spent weeks chasing down memory safety bugs in those languages, youll really appreciate Rust. “Fighting the borrow checker” becomes “The compiler can detect that? Cool!”<br> —Grzegorz Nosek </p>
</blockquote>
<h2 id="scale"> Scale </h2>
<blockquote>
<p> Today's server programs comprise tens of millions of lines of code, are worked on by hundreds or even thousands of programmers, and are updated literally every day. Go was designed and developed to make working in this environment more productive. Go's design considerations include rigorous dependency management, the adaptability of software architecture as systems grow, and robustness across the boundaries between components.<br><a href="https://talks.golang.org/2012/splash.article">Rob Pike</a>
</p>
</blockquote>
<p> When you're working on a problem by yourself or in small teams, the choice of a simple language or a rich language is a matter of preference. But as the software grows bigger and more complex, and the teams grow larger, the differences really start to show. For large applications and distributed systems, speed of execution is less important than speed of development: a deliberately minimal language like Go reduces the ramp-up time for new developers, and makes it easier for them to work with a large codebase. </p>
<blockquote>
<p> With Go, its easier as a junior developer to be more productive, and harder as a mid-level developer to introduce brittle abstractions that will cause problems down the line. For these reasons, Rust is less compelling than Go for enterprise software development.<br><a href="https://kristoff.it/blog/why-go-and-not-rust">Loris Cro</a>
</p>
</blockquote>
<p> When it comes to software development in the large, clear is better than clever. Go's limitations actually make it more suitable for enterprises and big organisations than more complex and powerful languages such as Rust. </p>
<h2 id="the-differences"> The differences </h2>
<p> Although Rust and Go are both popular, modern, widely-used languages, they're not really competitors, in the sense that they're deliberately targeting quite different use cases. Go's whole approach to programming is radically different to Rust's, and each language will suit some people while irritating others. That's absolutely fine, and if both Rust and Go did more or less the same things in more or less the same way, we wouldn't really need two different languages. </p>
<p> So can we get a sense of the respective natures of Rust and Go by finding issues on which they take drastically different approaches? Let's find out. </p>
<h3 id="garbage-collection"> Garbage collection </h3>
<p> “To garbage-collect, or not to garbage-collect” is one of those questions that has no right answer. Garbage collection, and automatic memory management in general, makes it quick and easy to develop reliable, efficient programs, and for some people that makes it essential. But others say that garbage collection, with its performance overhead and stop-the-world pauses, makes programs behave unpredictably at run-time, and introduces unacceptable latency. The debate rumbles on. </p>
<blockquote>
<p> Go is a very different language to Rust. Although both can vaguely be described as systems languages or replacements for C, they have different goals and applications, styles of language design, and priorities. Garbage collection is a really huge differentiator. Having GC in Go makes the language much simpler and smaller, and easy to reason about. </p>
<p> Not having GC in Rust makes it really fast (especially if you need guaranteed latency, not just high throughput) and enables features and programming patterns that are not possible in Go (or at least not without sacrificing performance).<br><a href="https://medium.com/better-programming/early-impressions-of-go-from-a-rust-programmer-f4fd1074c410">PingCAP</a>
</p>
</blockquote>
<h3 id="close-to-the-metal"> Close to the metal </h3>
<p> The history of computer programming has been a story of increasingly sophisticated abstractions that let the programmer solve problems without worrying too much about how the underlying machine actually works. That makes programs easier to write and perhaps more portable. But for many programs, access to the hardware, and precise control of how the program is executed, are more important. Rust aims to let programmers get “closer to the metal”, with more control, but Go abstracts away the architectural details to let programmers get closer to the problem. </p>
<blockquote>
<p> Both languages have a different scope. Golang shines for writing microservices and for typical "DevOps" tasks, but it is not a systems programming language. Rust is stronger for tasks where concurrency, safety and/or performance are important; but it has a steeper learning curve than Go.<br><a href="https://endler.dev/2017/go-vs-rust/">Matthias Endler</a>
</p>
</blockquote>
<h3 id="must-go-faster"> Must go faster </h3>
<p> Ive written elsewhere that <a href="https://bitfieldconsulting.com/golang/slower">performance is less important than readability for most programs</a>. But when performance <em>does</em> matter, it really matters. Rust makes a number of design trade-offs to achieve the best possible execution speed. By contrast, Go is more concerned about simplicity, and its willing to sacrifice some (run-time) performance for it. But Gos <em>build</em> speed is unbeatable, and thats important for large codebases. </p>
<blockquote>
<p> Rust is faster than Go. In the benchmarks above, Rust was faster, and in some cases, an order of magnitude faster. But before you run off choosing to write everything in Rust, consider that Go wasnt that far behind it in many of those benchmarks, and its still much faster than the likes of Java, C#, JavaScript, Python and so on. </p>
<p> If what you need is top-of-the-line performance, then youll be ahead of the game choosing either of these two languages. If youre building a web service that handles high load, that you want to be able to scale both vertically and horizontally, either language will suit you perfectly.<br><a href="https://codeburst.io/should-i-rust-or-should-i-go-59a298e00ea9">Andrew Lader</a>
</p>
</blockquote>
<h3 id="correctness"> Correctness </h3>
<p> On the other hand, a program can be arbitrarily fast if it doesnt have to work properly. Most code is not written for the long term, but its often surprising how long some programs can stay running in production: in some cases, many decades. In these situations its worth taking a little extra time in development to make sure that the program is correct, reliable, and wont need a lot of maintenance in the future. </p>
<blockquote>
<p> My take: Go for the code that has to ship tomorrow, Rust for the code that has to keep running untouched for the next five years.<br> —Grzegorz Nosek </p>
</blockquote>
<p> While both Go and Rust are great choices for any serious project, it's a good idea to make yourself as well-informed as possible about each language and its characteristics. Ultimately, it doesn't matter what anyone else thinks: only you can decide which is right for you and your team. </p>
<blockquote>
<p> If you want to develop faster, perhaps because you have many different services to write, or you have a large team of developers, then Go is your language of choice. Go gives you concurrency as a first-class citizen, and does not tolerate unsafe memory access (neither does Rust), but without forcing you to manage every last detail. Go is fast and powerful, but it avoids bogging the developer down, focusing instead on simplicity and uniformity. If on the other hand, wringing out every last ounce of performance is a necessity, then Rust should be your choice.<br><a href="https://codeburst.io/should-i-rust-or-should-i-go-59a298e00ea9">Andrew Lader</a>
</p>
</blockquote>
<h2 id="conclusion"> Conclusion </h2>
<p> I hope this article has convinced you that <em>both</em> Rust and Go deserve your serious consideration. If at all possible, you should aim to get at least some level of experience in both languages, because they will be incredibly useful to you in any tech career, or even if you enjoy programming as a hobby. If you only have time to invest in learning one language well, don't make your final decision until you've used both Go and Rust for a variety of different kinds of programs, large and small. </p>
<p> And knowledge of a programming language is really only a small part of being a successful software engineer. By far the most important skills you'll need are design, engineering, architecture, communication, and collaboration. If you excel at these, you'll be a great software engineer regardless of your choice of language. Happy learning! </p>
<h2 id="comparing-rust-and-go-code"> Comparing Rust and Go code </h2>
<p> There's a great website called <a href="http://fakehost/test/programming-idioms.org">programming-idioms.org</a> which has a "cheat sheet" showing what the Rust and Go code looks like for over 200 common programming tasks: </p>
<ul>
<li>
<a href="https://programming-idioms.org/cheatsheet/Go/Rust">Go vs Rust idioms</a>
</li>
</ul>
<h2 id="getting-started"> Getting started </h2>
<p> If you're interested in learning to program with Rust and Go, here are a few resources you may find helpful. </p>
<h3 id="go"> Go </h3>
<ul>
<li>
<a href="https://golang.org/dl/">Install Go</a>
</li>
<li>
<a href="http://fakehost/golang">Go tutorials by Bitfield</a>
</li>
<li>
<a href="http://fakehost/books">For the Love of Go</a>
</li>
<li>
<a href="https://tour.golang.org/">A Tour of Go</a>
</li>
<li>
<a href="https://gobyexample.com/">Go By Example</a>
</li>
<li>
<a href="https://play.golang.org/">The Go Playground</a>
</li>
<li>
<a href="https://github.com/avelino/awesome-go">Awesome Go</a>
</li>
</ul>
<h3 id="rust"> Rust </h3>
<ul>
<li>
<a href="https://www.rust-lang.org/tools/install">Install Rust</a>
</li>
<li>
<a href="https://stevedonovan.github.io/rust-gentle-intro/">A Gentle Introduction to Rust</a>
</li>
<li>
<a href="https://doc.rust-lang.org/book/index.html">The Rust Programming Language</a>
</li>
<li>
<a href="https://github.com/sger/RustBooks">Rust books</a>
</li>
<li>
<a href="https://doc.rust-lang.org/rust-by-example/">Rust By Example</a>
</li>
<li>
<a href="https://play.rust-lang.org/">The Rust Playground</a>
</li>
<li>
<a href="https://www.wezm.net/v2/posts/2020/100-rust-binaries/">One Hundred Rust Binaries</a>
</li>
</ul>
<h2 id="acknowledgements"> Acknowledgements </h2>
<p> I am not young enough to know everything, as the saying goes, so I'm very grateful to a number of distinguished Gophers and Rustaceans who took the time to review and correct this piece, as well as providing some really useful suggestions. My special thanks go to Bill Kennedy, Grzegorz Nosek, Sam Rose, Jack Mott, Steve Klabnik, MN Mark, Ola Nordstrom, Levi Lovelock, Emile Pels, Sebastian Lauwers, Carl Lerche, and everyone else who contributed. You might get the impression from reading online hot takes that the Rust and Go communities don't get along. Nothing could be further from the truth, in my experience; we had very civilised and fruitful discussions about the draft article, and it's made a big difference to the finished product. Thanks again. </p>
</div>
</div>
</DIV>