TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Rust vs Go: A Hands-On Comparison

103 点作者 mre超过 1 年前

15 条评论

leetharris超过 1 年前
Just some random guy&#x27;s anecdote.<p>I learned both of these simultaneously in two quirky ways.<p>I learned Go using the &quot;Learn Go with Tests&quot; book <a href="https:&#x2F;&#x2F;quii.gitbook.io&#x2F;learn-go-with-tests&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;quii.gitbook.io&#x2F;learn-go-with-tests&#x2F;</a><p>I learned Rust through a book called &quot;From JavaScript to Rust&quot; <a href="https:&#x2F;&#x2F;github.com&#x2F;vinodotdev&#x2F;node-to-rust&#x2F;releases&#x2F;download&#x2F;v1&#x2F;from-javascript-to-rust.pdf">https:&#x2F;&#x2F;github.com&#x2F;vinodotdev&#x2F;node-to-rust&#x2F;releases&#x2F;download...</a><p>The thing that stood out the most to me while learning these was their focus on composition over inheritance. Even though I really like C-based languages, I have never liked the inheritance push from the 90s-2000s.<p>I really like some of the things in Go, but overall I felt I just didn&#x27;t need it. .NET, Java, etc are more mature with comparable or better capabilities across the board. It&#x27;s just hard for me to justify Go outside of stylistic preference.<p>I really, really like Rust but ever since learning it almost 2 years ago, I still have not found a single use case for it. It&#x27;s partially the maturity of the competition, but it&#x27;s also that even in HPC, ML&#x2F;DL, etc I&#x27;ve done just fine with the &quot;legacy&quot; stack.<p>I would love to hear from people what their thoughts are on this. What are some scenarios where you see these languages thriving? What makes you want to use them? What&#x27;s the best use case? Would love to evolve my thinking.
评论 #37678184 未加载
评论 #37681793 未加载
barelysapient超过 1 年前
I liked the article but I have a nit with the Deployment section:<p>First, Go has other deployment options other than Docker or providers that support docker containers. For example, Google App Engine (GAE) has a command line interface very similar to Shuttle that enables deployment and hosting of your Go application. This is probably the best &#x27;apples&#x27; to &#x27;apples&#x27; comparison.<p>Go and Rust are very similar in this way because both can be compiled to a statically linked binary with zero runtime dependencies[1]. This is important because both Javascript and Python are interpreted, frequently with run-time dependencies in addition to the interpreter, that can make hosting and deployment more difficult.<p>Since both languages compile to a statically linked binary, they can be hosted virtually anywhere. Any old linux box or VCS with a modern os should work just fine. Optionally, one can serve from behind Nginx or Caddy for extra functionality.<p>I&#x27;ve chosen this approach on a side project. It deploys with a simple `make deploy` command that runs tests, creates the static binary, and deploys the build asset over SSH and cycles the systemd service. It can be rolled back with `make rollback` which reverts by simply changing the symlink and restarting the service.<p>[1] Assumes a modern OS.
评论 #37685208 未加载
steve_adams_86超过 1 年前
I’m in a weird spot where I like both equally, but for slightly different reasons.<p>When I have a dumb idea (they’re all dumb), depending on what its core features are, I’ll prototype it in Go, TypeScript, or Python. Inevitably I’ll want to or I will actually rebuild it with rust once it’s relatively stable.<p>It’s like Go, TypeScript, and Python are pencil and rust is ink.<p>Go is my favourite for strictly back end prototyping, but I don’t love it for processing data. That’s where Python shines. Then sometimes I’ll use a full stack framework like Next or Remix and build a backend there, but transfer it (or important parts of it) to rust eventually.<p>My favourite deployment is a totally static site with a rust backend. But it’s equally easy with Go, and the initial development with Go is always way faster for me. It’s just the long term maintenance story that I don’t love with Go.<p>Also, I prefer Rust’s type system quite a bit. It could just be intuitive to me. I do find several teams I’ve worked with on Go projects have not actually understood the Go type system, and they’ve run into pain as a result very regularly.
评论 #37677910 未加载
评论 #37678986 未加载
评论 #37678323 未加载
tuetuopay超过 1 年前
While the Rust in this article could be a bit better (though that&#x27;s nitpicking and explicitly not the point), I find it showcases the biggest difference between the two: once you&#x27;ve laid out the foundations which takes a bit of time, the resulting code is a lot leaner. The handlers are short, concise, and the separation of concerns is natural. Good job the shuttle team, I now want to try your service :D<p>The thing I feel like misses from the article is the more &quot;second thought but vital&quot; stuff, like observability. The tracing ecosystem for Rust is a blessing, and so boilerplate-free that you sprinkle it all over and never forget about it. From experience, having to manually access the span, put data in it, and defer close, that people don&#x27;t bother doing them. Yay macros!<p>With Go it&#x27;s really easy to throw stuff at the wall, and it&#x27;ll stick. Rust encourages you to put glue on it before throwing stuff.<p>Also once you get used to axum and the various extractors, be warned, you&#x27;ll hardly go back. It&#x27;s so natural and powerful.
评论 #37685230 未加载
评论 #37678079 未加载
hu3超过 1 年前
I found the article quite unbiased, specially coming from a Rust focused platform service.<p>So congrats! Relevant part FTA:<p>Which language is right for you?<p>Go:<p>- easy to learn, fast, good for web services<p>- batteries included. We did a lot with just the standard library.<p>- Our only dependency was Gin, which is a very popular web framework.<p>Rust:<p>- fast, safe, evolving ecosystem for web services<p>- no batteries included. We had to add a lot of dependencies to get the same functionality as in Go and write our own small middleware.<p>- the final handler code was free from distracting error handling, because we used our own error type and the ? operator. This makes for very readable code, at the cost of having to write additional adapter logic.
danesparza超过 1 年前
&quot;Being originally created to simplify building web services, Go has a number ...&quot;<p>Um. No. Go was originally created at Google in 2007 by Robert Griesemer, Rob Pike, and Ken Thompson.<p>Some key reasons for its creation include:<p>Improving productivity of Google engineers - The creators felt existing languages like C++ took too long to compile and had other productivity issues. Go was designed to be simpler and faster to compile.<p>Supporting concurrency and multi-core machines - Go has built-in concurrency features like goroutines and channels to allow easy parallelism and concurrency on multi-core machines. This was becoming increasingly important with multi-core CPUs.<p>Improved code readability and maintainability - Go was designed with a clean, minimal syntax that avoided complex features like inheritance in favor of simplicity. This improved code readability and made programs easier to maintain. Better performance than interpreted languages - While Go is a compiled language like C++, it was designed to provide performance closer to those languages while maintaining some productivity benefits of interpreted languages like Python.<p>Supporting networked systems and servers - Go has good built-in support for networking and servers, making it well-suited for building networked systems, web servers, and other server tools.<p>References: <a href="https:&#x2F;&#x2F;go.dev&#x2F;talks&#x2F;2012&#x2F;splash.article" rel="nofollow noreferrer">https:&#x2F;&#x2F;go.dev&#x2F;talks&#x2F;2012&#x2F;splash.article</a>
评论 #37678035 未加载
评论 #37678678 未加载
评论 #37679153 未加载
ilrwbwrkhv超过 1 年前
Ya thanks for showcasing both.<p>As is evident from the code, Go is simpler and cleaner. In 3 months it would be much easier to reason about than the Rust version.<p>I am happy with our decision to migrate to Go from Common Lisp. I also wonder what is the long term memory usage of the Rust system. With Go I have found very little memory use which remains constant for months before machine swap.
评论 #37677291 未加载
dingnuts超过 1 年前
Why are there so many comparisons between Rust and Go? They don&#x27;t seem to be particularly similar languages, either in use-case or style, but it often feels like the community wants there to be a competition between the two, which doesn&#x27;t seem appropriate to me.<p>Go should be compared to other high-level garbage collected languages: Java, Python, C# -- that kind of thing.<p>Rust should be compared to C++ and C, but I&#x27;d also love to see it compared to other languages with advanced type systems, or contrasted with languages with more traditional or simple type systems.
评论 #37677541 未加载
评论 #37677375 未加载
评论 #37678844 未加载
评论 #37681635 未加载
评论 #37677514 未加载
评论 #37677194 未加载
qaq超过 1 年前
Rust async story is still playing out. Go green threads approach is pretty solid. My go to stack for personal projects: Go SQLC for db access <a href="https:&#x2F;&#x2F;github.com&#x2F;a-h&#x2F;templ">https:&#x2F;&#x2F;github.com&#x2F;a-h&#x2F;templ</a> (kinda JSX for go) for templating HTMX Postgres I have a feeling Mojo will ship 1.0 before Rust finishes sorting out async
ianpurton超过 1 年前
Rust supports more software engineering best practices than Go.<p>Some people say the learning curve for Rust is steep. But, in a way you&#x27;re learning how to write safer code using the latest in language techniques.
评论 #37676943 未加载
评论 #37678828 未加载
评论 #37679000 未加载
评论 #37678057 未加载
kunley超过 1 年前
Not to ignite a flame war, but to make a point about daily bread activities:<p>what was the compilation time of both projects, esp. after using crates like &#x27;anyhow&#x27;? How long did it take to have a full fix-build-test cycle in both languages? How many refactorings per time unit could a smart coder do in both ecosystems?
评论 #37678566 未加载
blindseer超过 1 年前
That seems like a fair article.<p>The error handling in Go is SO verbose. When reading my code (or even reviewing other people&#x27;s code) in order to understand at a high level what is going on, I feel like I&#x27;m squinting through a mesh wire window.<p>Compare this example in Go:<p><pre><code> city := c.Query(&quot;city&quot;) latlong, err := getLatLong(city) if err != nil { c.JSON(http.StatusInternalServerError, gin.H{&quot;error&quot;: err.Error()}) return } weather, err := getWeather(*latlong) if err != nil { c.JSON(http.StatusInternalServerError, gin.H{&quot;error&quot;: err.Error()}) return } weatherDisplay, err := extractWeatherData(city, weather) if err != nil { c.JSON(http.StatusInternalServerError, gin.H{&quot;error&quot;: err.Error()}) return } c.HTML(http.StatusOK, &quot;weather.html&quot;, weatherDisplay) </code></pre> To this code in Rust:<p><pre><code> let lat_long = fetch_lat_long(&amp;params.city).await?; let weather = fetch_weather(lat_long).await?; let display = WeatherDisplay::new(params.city, weather); </code></pre> Maybe on first glance the Rust code can seem alien (what is a `?` doing there, what is actually going on with `.await`, etc) but when you are writing a 100k line application in Rust, you learn the patterns and want to be able to see the domain application logic clearly. And yet, there&#x27;s no hidden errors or exceptions. When this code fails, you will be able to clearly identify what happened and which line the error occurred on.<p>Prototyping even small applications in Go is verbose. And worse still, error prone. It&#x27;s easy to be lazy and not check for errors and oops 3 months in your code fails catastrophically.<p>I know a lot of people like Go on here but in my mind Go only makes sense as a replacement for Python (static compilation, better error handling than Python, faster etc). If you don&#x27;t know exactly what you want to build, maybe it is faster to prototype it in Go? I still would reach for Rust in those instances but that&#x27;s just me. For large applications there&#x27;s no question in my mind that Rust is a better choice.<p>Edit:<p>people have pointed out that I&#x27;m not comparing the same thing, which is true, I apologize for the confusing. But even code where Go propagates the errors, it is much more verbose (and my point still stands)<p><pre><code> err := db.Get(&amp;latLong, &quot;SELECT lat, long FROM cities WHERE name = $1&quot;, name) if err == nil { return latLong, nil } latLong, err = fetchLatLong(name) if err != nil { return nil, err } err = insertCity(db, name, *latLong) if err != nil { return nil, err } </code></pre> And this is extremely common. More discussion in the thread below.
评论 #37678253 未加载
评论 #37678236 未加载
评论 #37678293 未加载
评论 #37678563 未加载
评论 #37678279 未加载
评论 #37678627 未加载
评论 #37678521 未加载
评论 #37678384 未加载
评论 #37682675 未加载
评论 #37682087 未加载
评论 #37678657 未加载
Animats超过 1 年前
Both are amusingly over-complicated.<p>You don&#x27;t need a database, just an in-memory cache. All you&#x27;re storing is recent weather info, which you get from an external server. Caching is just to prevent hitting the external server too hard.<p>Then the program becomes a single-file executable, which means you can get rid of Docker.<p>If you set this up to run under FCGI, it can run on some $5&#x2F;month shared hosting account.
评论 #37678179 未加载
评论 #37678886 未加载
评论 #37678338 未加载
tgz超过 1 年前
How long did it take to develop each web service? Which rps produces?
评论 #37677172 未加载
评论 #37678042 未加载
intalentive超过 1 年前
The Go syntax is so much comfier. Never written in Go but it looks attractive, might have to give it a spin.