summaryrefslogtreecommitdiff
path: root/drafts/its-not-rust-vs-go.php
blob: 1ec29a8dae6c5d3c9414e2515b50d9e09d5e4b55 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
<?php
$title = "'Rust or Go?' Is Not the Right Question (but Rust Is Still the Right Answer)";
if (isset($early) && $early) {
	return;
}
include($_SERVER['DOCUMENT_ROOT'] . '/includes/head.php');
?>

<p class="description">
	I have used Rust professionally for two production projects that see daily usage in our company. One is a rewrite of a small C# HTTP application service. The second is a from-scratch automation library with CLI and HTTP service end-user applications. I chose Rust for its safety, runtime speed, and useful abstractions. <br>
	On several occasions I've received strange messages or suggested reading from coworkers that usually goes something like "here, look at this: this is why Go is better than Rust. You should have used Go." <br>
	Here's what I think.
</p>

<h2>"Rust or Go?"</h2>

<p>
	I don't believe there is a single right tool to do any job. I do believe there are better tools for doing some jobs, and tools that are decent for most jobs. I also believe that Go and Rust are two very different tools for doing very different jobs. Why do these programming languages get compared a lot? Is it because they're both AOTC, statically-typed, "server-side" langauges?
</p>

<p>From <a href="https://web.archive.org/web/20210917125023/https://golang.org/">golang.org</a>:</p>

<blockquote>
	Go is an open source programming language that makes it easy to build simple, reliable, and efficient software.
</blockquote>

<p>And from <a href="https://web.archive.org/web/20210918013407/https://www.rust-lang.org/">rust-lang.org</a>:</p>

<blockquote>
	A language empowering everyone to build reliable and efficient software.
</blockquote>

<p>Wow, yeah looks like they are both trying to solve the same problem. Both claim to allow programmers to build reliable and efficient software. So maybe the difference isn't <em>what</em> they're trying to solve, maybe it's <em>how</em>they're each trying to solve it.


<p>Let's look a little deeper. From the <a href="https://web.archive.org/web/20210909115254/https://golang.org/doc/">Go documentation</a>:</p>

<blockquote>
	The Go programming language is an open source project to make programmers more productive.

	Go is expressive, concise, clean, and efficient. Its concurrency mechanisms make it easy to write programs that get the most out of multicore and networked machines, while its novel type system enables flexible and modular program construction. Go compiles quickly to machine code yet has the convenience of garbage collection and the power of run-time reflection. It's a fast, statically typed, compiled language that feels like a dynamically typed, interpreted language.
</blockquote>

<p>And, from the <a href="">Rust book</a>:</p>

<blockquote>
	Rust is for people who crave speed and stability in a language. By speed, we mean the speed of the programs that you can create with Rust and the speed at which Rust lets you write them. The Rust compiler’s checks ensure stability through feature additions and refactoring. This is in contrast to the brittle legacy code in languages without these checks, which developers are often afraid to modify. By striving for zero-cost abstractions, higher-level features that compile to lower-level code as fast as code written manually, Rust endeavors to make safe code be fast code as well.
</blockquote>

<p>Now we're starting to see some differences in objective. Go is designed to make it really fast to write Go code. It is supposed to be concise (so you type less) and quick to compile. It aims to feel like an interpreted language to work with. Meanwhile, Rust is preoccupied with delivering fast safety and stability.


	Meanwhile, Rust is looking to make higher-level abstractions as fast as large, manually-written, lower-level code. It's also preoccupied with <em>safety and stability</em>.</p>



------
<ul>
	<li>These are two very different languages</li>
	<li>These two languages are solving two very different problems</li>
	<li>
		What attracted me to Rust is the error handling and borrow checker. You
		don't need a runtime and you don't need to worry about a variety of memory
		pitfalls.
	</li>
	<li>
		Rust is not just a systems-level language, and Go is not just a server-side
		language.
	</li>
	<li>Rust isn't *really* about speed or performance. It's about safety.</li>
	<li>Rust is just plainly a more powerful language.</li>
	<li>
		Go is for Python developers who need speed. Rust is for C++ developers who
		need safety.
	</li>
	<li>
		Rust has opt-in concurrent runtimes and opt-in garbage collection. These are
		standard in Go, there's no getting out of them.
	</li>
</ul>

<p>
	Go has great concurrency. Goroutines are high-performance, parallel green
	threads. Rust's concurrency is provably-correct.
</p>

<p>
	Why is the immediate question when someone says they wrote something in Go,
	" why not rust?". The inverse is true. When I tell a dev I wrote something in Rust, the immediate response is "you should have used Go, it's better." This is false. </p>

<p>
	What does suck about Rust? The compiler is slow. It will probably always be a
	degree of magnitude slower than another compiler for a similar target.
</p>

<p>
	It's not Rust vs Go, it's when to use Rust and when to use Go. And the number
	one argument I get for why Go should be used is it's simpler and faster to
	learn and work with. There's the answer! The answer is use whichever one works
	best for you. There's no better or worse, or superiority. Redditors will say
	otherwise.
</p>

<p>sources</p>

<p>
	Go vs Rust discussions are ridiculous. It should be more like: When to use Go.
	When to use Rust. When to use X… — Inanc Gumus (@inancgumus) September 19,
	2019
	<a href="https://twitter.com/inancgumus/status/1174728131925676032?ref_src=twsrc%5Etfw">source</a>
</p>
<a href="https://insights.dice.com/2020/08/27/rust-in-trouble-after-big-mozilla-layoffs/">Is Rust in Trouble After Big Mozilla Layoffs?</a>
<a href="https://foundation.rust-lang.org/posts/2021-02-08-hello-world/">Hello World! (Rust Foundation)</a>

<a href="https://killedbygoogle.com/"> Killed by Google</a>

<a href="https://dart.dev/overview">The Dart Programming Language</a>

<a href="https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f?gi=c8caad873419">Discord swapped Go for Rust</a>

<blockquote>
	Both Microsoft and Amazon have just recently announced and released their new
	officially supported Rust libraries for interacting with Windows and AWS.
	Official first party support for these massive APIs helps make Rust people's
	first choice when deciding what to use for their project.
</blockquote>
<a href="https://blog.rust-lang.org/2021/05/15/six-years-of-rust.html">Source</a>

<a href="https://hub.packtpub.com/is-dart-programming-dead-already/">Dart -- apples to oranges? I'm not trying to say that go is going the way of
	dart, I'm trying to say that industry-leading companies aren't always stewards
	of their creations. take FreeBSD. It's a thriving, excellent operating system
	capable of "industry-leading company" usage. See the usuals (Netflix, Sony,
	etc). Look at the FreeBSD foundation. Now look at RedHat and IBM. Again,
	apples to oranges? No, just a bad argument to make in the first place.</a>

<p>quotables</p>

<blockquote>
	Take a look Go as well. I think you will find Go much faster to program in.
	The other aspect is threading. They have very different threading models. Not
	sure if you had the chance to research that yet or not
</blockquote>
<blockquote>
	Yes, a big thing is threading. Unfortunately, Rust uses a similar model as
	Java for threads :(. Go is based on Fibers approach which so much faster for
	temporary, lightweight requests. Go is definitely superior for HTTP REST API
	apps. Rust can be better for a single-thread app or general "systems"
	programming.
</blockquote>

<p>
	Rust is not a "systems programming" language. Systems programming is not a
	genre of languages. It's not like saying Italian is a "Romantic language".
	Systems programming is a specific, targeted programming *application*. It's
	the destination, the use-case that a language is being applied to. Rust is a
	general-purpose programming language. I have used it to write a variety of
	tools, low- and high-level, server-side and client-side, graphical and CLI.
	Yes, I used it for some systems programming. Also used it to make a very
	simple and robust web service digested by a variety of other developers at our
	company.
</p>

<blockquote>
	The only way is to learn and try both. That's what I did. Most of the info
	from both sides is biased...Go is definitely very fast and [garbage
	collection] is not the issue people make it out to be. I started last month
	porting [a chess] engine to Rust. I recently took a break from it because the
	syntax and borrow checking were getting insane to deal with. Once I learned
	about the threading issues in Rust, I have put it on the shelf for now. Rust
	is still evolving which is good and bad. It needs better IDE and Debugging
	support than current levels. Hopefully that will continue to improve. There
	was a big Mozilla shakeup (Nov 2020) where they let go of the Rust developers
	and cancelled the project. AWS hired them. So honestly, I am not sure which
	direction the language is going in. Meaning, now that AWS owns the braintrust,
	I don't know where they are headed. My guess is that AWS is using Rust for
	some behind the scenes script-like stuff. Not sure. Will be important in the
	next year or two on which direction things end up going. For Rust to benefit
	long-term, it needs the support of a corporate backer
</blockquote>

<p>IDE support? See rust language server, rust-analyzer, rustfmt, and cargo</p>

<p>Rust is absolutely ready for production use.</p>
<p>
	Anti-Rust zealotry is just as strong as pro-Rust zealotry. The hype goes both
	ways. No, your talking points shouldn't come from Reddit.
</p>

<p>Everything isn't great in goland either. Gofmt and the go module structure were harsh and annoying for me to use. I don't prefer languages with rigorous whitespace requirements anyways. The opinionated standard library is fickler than I would imagine, and the drama churned up over the introduction of generics (a useful, modern programming concept) is popcorn-worthy</p>

<p>The hidden cost of Go: go might be faster to actually type in. But I spend much less time debugging in Rust. The compiler/borrow-checker tells me why I can't write to memory that's already been dropped or borrowed someplace else, and suggests what I need to paste in to fix it. These kinds of bugs take a long time to track down by stepping-through Go code. Some might not even get caught. I don't use a debugger for Rust because I rarely need to step through my code one line at a time to figure out where something became NULL</p>