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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Should I Rust or Should I Go?

106 点作者 cjg超过 1 年前

41 条评论

necubi超过 1 年前
As someone building my startup [0] on Rust (and a fan of the language since ~2014) I don&#x27;t think this is a very compelling list of points.<p>&gt; Rust is overhyped<p>People are excited about Rust! Not sure why this is a reason you _shouldn&#x27;t_ use the language.<p>&gt; Rust projects decay<p>The text doesn&#x27;t match the headline here; Rust takes backwards compatibility very seriously, and rust code I wrote in 2016 against Rust 1.10 still compiles with Rust 1.72 in 2023.<p>&gt; Rust is still in beta<p>Mentions missing async traits, which is legitimately annoying, but the workaround with the async_trait crate works in practice<p>&gt; The standard library is anemic<p>This is a tradeoff; big standard libraries become graveyards over time (the classic article on this: <a href="https:&#x2F;&#x2F;leancrew.com&#x2F;all-this&#x2F;2012&#x2F;04&#x2F;where-modules-go-to-die&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;leancrew.com&#x2F;all-this&#x2F;2012&#x2F;04&#x2F;where-modules-go-to-di...</a>). How long was Python stuck with a terrible HTTP client because that was the one in the standard library? In Rust we have an incredible, state of the art regex library because it&#x27;s a separate crate and is allowed to evolve.<p>&gt; async is hard<p>Rust&#x27;s async is hard to get started with; it&#x27;s a barrier to get over like learning the borrow checker and lifetime system. But once you do I&#x27;ve found it productive and incredibly performant.<p>--<p>Overall, I don&#x27;t think that Rust is the right solution to all problems. Rust makes you think about everything you&#x27;re doing, the ways in which your programs use resources, and every possible class of errors. This is incredibly useful for writing fast and correct software, but will be overhead for people who just want to move fast.<p>I also think that static memory management is not the right tradeoff for most application software, although a GC language with Rust&#x27;s ergonomics and crate ecosystem would be amazing for those use cases.<p>I&#x27;d personally always choose Java over Go especially given recent developments like ZGC, GraalVM, and Project Loom which essentially makes Java a better Go.<p>[0] <a href="https:&#x2F;&#x2F;arroyo.dev">https:&#x2F;&#x2F;arroyo.dev</a>
评论 #37527298 未加载
评论 #37532556 未加载
评论 #37532121 未加载
评论 #37532323 未加载
评论 #37532660 未加载
评论 #37532180 未加载
jpgvm超过 1 年前
In what world is Go more reliable or faster than Java? Especially modern Java (or other good JVM languages like Kotlin).<p>It compiles faster but that is about it. Which is a good thing too because it&#x27;s verbose AF and heavily reliant on code generation even after generics shipped so that compiler lines&#x2F;s actually matters.<p>The only knock you can put on Java for reliability is null-safety but lets be real, nil pointers, bad slice initalisation, etc are 10x worse in Go especially these days with @NotNull and powerful editors like IDEA stopping you from doing dumb things. Or simply using Kotlin which is non-nullable by default.<p>That and all the things Go is good at Java is simply better at. (especially once Java 21 ships in the next few days).<p>- Low pause GC? ZGC has Go beat, not just on pause times but on throughput and heap size scalability up into the terabytes. - Non-blocking code with synchronous coding style? Virtual Threads are much much better than goroutines. - Channels? ArrayDeque and friends are faster and have a lower learning curve.<p>Maybe the only area I think I prefer Go to JVM-land is the good parts of the stdlib. Go has lots of shit stdlib <i>cough</i> collections <i>cough</i> but there are some real gems. Namely the x509 and ASN.1 libraries are absolutely top notch.<p>Learning curve is also lower ofcourse, it&#x27;s a very very simple language which is good for beginners and those taking their first steps out of JS&#x2F;Ruby&#x2F;Python into static types, pointers, etc.<p>Anyways, my real point was Java is easily faster and more reliable than Go and it seems pretty insane to reach the opposite conclusion if you have been on top of developments in both languages.
评论 #37527311 未加载
评论 #37527036 未加载
评论 #37527144 未加载
评论 #37529065 未加载
评论 #37534184 未加载
评论 #37527022 未加载
评论 #37531230 未加载
评论 #37527159 未加载
评论 #37527178 未加载
评论 #37534714 未加载
评论 #37528381 未加载
Animats超过 1 年前
- Webcrap - use Go. The arguments for Go for that use case is that 1) Google provides the libraries for most web back-end things you&#x27;ll need, and since Google uses those libraries internally, even the obscure cases have been exercised, and 2) Goroutines are both low-cost and can block, so you don&#x27;t have to face Rust async&#x2F;thread combo hell.<p>- Hard problems that have concurrency, performance issues, or have to be highly reliable such as a database - use Rust.
评论 #37527093 未加载
评论 #37526988 未加载
评论 #37526964 未加载
seurimas超过 1 年前
The features vs versions graph is more than a little nonsensical, and its conclusions even more so.<p>&gt; They should be stable and move slowly so that most of the time of your develoeprs is not spent fighting with their tools.<p>I can&#x27;t speak to Go&#x27;s tooling base, but Rust&#x27;s is head and shoulders above any other ecosystem that I&#x27;ve had to work with. This is definitely more a point in Rust&#x27;s favor than against.
评论 #37528010 未加载
评论 #37527225 未加载
评论 #37527180 未加载
IshKebab超过 1 年前
I don&#x27;t agree with much of this - especially if the alternative is Go. I&#x27;m a semi-fan of Go but there are really very few situations I&#x27;d pick it over Rust.<p>&gt; Rust is the 14th most used language<p>I think the author is a bit confused about &quot;most loved&quot; - that means that people <i>who already use it</i> want to keep using it. 14th most used language is great for such a young and not beginner friendly language. It&#x27;s only 1 place behind Go and that is 3 years older.<p>Additionally Rust is mainly replacing C&#x2F;C++ codebases which are generally much older and slower moving than other languages.<p>&gt; Now imagine being the developer tasked with updating the dependencies of a service that is 31 versions behind... &gt; During the same period, there was 8 Go releases, 7 Node.js releases (but only 2 LTS) and 3 Python releases.<p>This is obvious nonsense. The stability of a language is not measured by the <i>number of releases</i>. Come on, did this guy really write a successful book about Rust? Is this satire?<p>&gt; Rust is actually still in the beta phase, with some important features such as async Traits still missing, which brings more churn to the ecosystem.<p>Really? Is C++ &quot;still in beta&quot; because it doesn&#x27;t have async?<p>&gt; The standard library is anemic<p>Sure that is an issue in C++ where using third party libraries is a huge pain. Doesn&#x27;t really matter so much when you can just `cargo add regex`.<p>&gt; async is hard<p>This is the only vaguely valid point. But on the other hand 90% of the time the solution is simple: don&#x27;t use async.<p>Very disappointing article. I was expecting an actual good comparison of the pros and cons. Go does have some notable advantages over Rust - compile time, ease of cross compilation, simplicity, goroutines, built in fuzzing support, arguably better dependency management. Why not talk about them?
ryanjshaw超过 1 年前
&gt; almost as easy to use as Python<p>At risk of starting a flame war, I don&#x27;t find Python easy to use at all so I have to question anything the author says at this point.<p>I was first introduced to Python 25 years ago and stuck with QuickBasic, C and assembly. I recently tried to do some opencv stuff with Python and the dynamic typing made even the simplest things exhausting. Then there&#x27;s the virtual environment and dependencies situation which is easy to make a mess of if you don&#x27;t know about it upfront.<p>I found a C# library to do the same and was way more productive and finished the task at hand quickly.
评论 #37527184 未加载
eikenberry超过 1 年前
Which do you like better? Programming languages are not things to be judged based on some random criteria, but by how well they fit how your mind works and let you express the ideas you want to express. Different languages hit these points for different people.<p>Best advice you&#x27;ll get is to try both (and more) and use the language you like best and that best aligns with the type of work you enjoy.
评论 #37528135 未加载
whatrg超过 1 年前
Go and Rust do not compete at all in the same domain. A long time ago, Rust did not have the focus it as now and even included a GC<p>But now, asking Go vs. Rust does not make sense at all.<p>If you want a mediocre speed application with fast development, use Go<p>If you want good memory footpeint with mediocre development use rust
评论 #37532638 未加载
lagniappe超过 1 年前
Why not both? I spend most of my time in Go, but learning other languages is always on my radar, most recently OCaml. It&#x27;s just fun and helps keep me spry, if that makes sense.
评论 #37526911 未加载
评论 #37527243 未加载
ketralnis超过 1 年前
Like any time this is asked the real answer is &quot;it depends&quot; while the answer given in the post as in all posts like it is &quot;you should use my favourite instead of your favourite&quot;. There&#x27;s no depth here and nothing that hasn&#x27;t been said before, don&#x27;t waste your time.<p>I know HN isn&#x27;t a fan of &quot;middlebrow dismissal&quot; but go on, read it and tell me it says anything beyond &quot;I like red better than blue&quot;
dwroberts超过 1 年前
&gt; When Rust makes sense<p>It’s missing a subheading for “anytime you do not want a garbage collector” which is true for almost anything real-time &#x2F; graphical etc
vb-8448超过 1 年前
I think the main point it&#x27;s missing: what is the context? In the absence of context, any answer is both correct and incorrect, like Schrödinger&#x27;s cat :D
评论 #37527317 未加载
flashgordon超过 1 年前
So Ive been tugging on this myself. I came up with one heuristic for myself.<p>If you need to write microservices (especially for control planes where there good concurrency and distributed system patterns needed) - I find Go be a fine combination of performance (GC hit will be there over Rust), ease of deployment, programming model (CSP) - at a slight expense on verbosity (say compared to python and you also get used to this with your patterns).<p>If you need high perf&#x2F;low latency&#x2F;near C (embedded systems level) performance - with a type system assisted memory management - then Rust.<p>I have found Go&#x27;s stdlib to be pretty thorough (and the ecosystem to be awesome too). Yes you will always find that set of X things hard to find that others dont care about. But horses for courses.<p>I have invested in learning both (but I also find learning languages a joy). But if you absolutely only have time for one consider your use case and pick appropriately. Yes you can do Rust for services too but given all this dual asyn model discussion still ongoing and a lot of real world services&#x2F;control planes in Go there are already good Go patterns you can leverage right away at a much lower learning curve.
lakomen超过 1 年前
This feels like the beginning of a long blog post I&#x27;d like to read.<p>Go feels natural to me, Rust feels like an ugly looking, needlessly complicated language.<p>Go has decay too. Many packages are abandoned or not properly taken care of. Generics did their own to slow the language down. But even if it&#x27;s not the fastest language, it&#x27;s fast and robust enough to get things done. And that&#x27;s what counts for me.
spiffytech超过 1 年前
&gt; Rust was Stack Overflow&#x27;s most loved language for 7 years in a row ... and yet, was ranked as the 14th.<p>Go is ranked 13th. Seems weird to use language popularity as a criticism when you&#x27;re only choosing between the 13th and 14th place options.<p>Besides, in 2023 their &quot;All Respondents&quot; usage is almost identical, with Rust showing stronger year-over-year growth than Go.
willtemperley超过 1 年前
Use the tool for the job. I use Rust where it makes sense - georust is very useful to me. If I need simple web services I use Typescript. Image processing? Python and numpy. Low latency event handling over web sockets? Java and Lmax disruptor. Modern tooling and IDEs are great, using four or five languages is not that hard.
nixpulvis超过 1 年前
I’m curious, given the current state of Rust, what can be done to help with these issues?<p>Most of them seem related to the way the community organizes itself, and what they value at any given moment.<p>What would a non-anemic STD look like? Could the STD be broken into smaller pieces while still being a standard library?<p>Async has been a point of major frustration for me from the onset. Some people love it some hate it. Is there a good way to appease both sides? What can be done to make the libraries more generic between the two? Having to reimplement everything for async is a nightmare.<p>As for feature bloat in general. I agree, Rust still feels sorta like beta software, but it’s also matured <i>a lot</i>. I’m not sire there’s an optimal rate of feature addition, though I do wish existing feature polish was a higher priority over new stuff. Funny, I was just thinking about this last night while I was stuck trying to fall asleep.
评论 #37528804 未加载
jackmott42超过 1 年前
This is usually a very simple decision. Do you need the performance of Rust? If not, use Go (or Java or F# or C# or whatever GC language you prefer)
评论 #37532702 未加载
评论 #37532097 未加载
rcarr超过 1 年前
As someone who doesn&#x27;t know either language, would love HN&#x27;s opinion on this video that was recommended to me by another HN user on a Rust thread a few days ago:<p><a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=p-tb1ZfkwgQ">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=p-tb1ZfkwgQ</a><p>The general gist of the video is the creator prefer Rust for functional programming and programs without much state and Go for everything else. As someone who&#x27;s coming from a React background I don&#x27;t see why if Rust is brilliant for functional programming why it can&#x27;t also be good for programs with state if the right design decisions are taken to handle it - can you not just use a redux style store with actions and reducers?
评论 #37532882 未加载
rich_sasha超过 1 年前
One argument&#x2F;scenario for the use of Rust I&#x27;m surprised not to see more often is interop with Python.<p>A ton of code, ML&#x2F;AI etc goes through Python sooner or later. For example, as I understand it, PyTorch and Tensorflow, for instance, are written in C++, but primarily to be used in Python.<p>There are very few languages I know of that have compelling interop with Python. C, C++, Rust... Nim? All other major languages have <i>something</i> but as far as I can tell, it is usually some kind of hack&#x2F;rpc kind of thing.<p>Clearly doesn&#x27;t apply to every project, but one key reason why I&#x27;m learning Rust is precisely that I care about Python interior, and don&#x27;t much love C++.
techn00超过 1 年前
I&#x27;m a little tired of this endless discussion ... it always pops up with programming languages, they are tools, use whatever is more fit for what you&#x27;re doing, move fast, break things, learn
评论 #37527195 未加载
评论 #37528298 未加载
synergy20超过 1 年前
I&#x27;m going to restate here again: Go is static compiling friendly, you just ship a single executable and you&#x27;re done, can&#x27;t believe how easy is it to upgrade down the road.<p>rust, java, etc are much more complex.
horeszko超过 1 年前
Ok, so I&#x27;m no expert on Rust or Go or whatever, but I&#x27;ve noticed that many posts and comments seem to rip on Go, and that Go is bad, Rust is better, language X is better than Go, etc etc.<p>My question is why all the hate on Go? And if Go is so bad as these posts claim, why compare everything against it?<p>I&#x27;m not saying Rust isn&#x27;t good or anything like that, but why the never ending hit pieces on Go? Lets just evaluate Rust or any language on its own merits.<p>I agree comparisons can be useful but its getting out of hand with these never ending Rust vs. Go pieces.
评论 #37532480 未加载
endisneigh超过 1 年前
You should Typescript. Performance comparable to Go. A more flexible typing system than both. Easier to learn than both. A worse package system, but that can be mitigated with discipline. What Typescript currently lacks the most is affordances for embedded or performance intensive work as it&#x27;s single threaded, but when performance matters use NAPI to use Rust in your Typescript, but the trajectory of performance of V8 and Webkit is such that I wouldn&#x27;t be surprised if Typescript is within the same order of magnitude for performance as Rust soon enough.<p>:P
评论 #37527239 未加载
评论 #37527370 未加载
ngrilly超过 1 年前
&gt; As far as I know, today, Rust is the only programming language (other than C) able to create efficient WebAssembly (wasm) libraries<p>Zig is also a good option for that, but the language is still in development.
评论 #37531438 未加载
评论 #37531432 未加载
评论 #37527088 未加载
anoncow超过 1 年前
As someone with very little expertise in this, and from the very little time that I can spare for experimental webdev, from a webdev framework perspective, Rust is where Go was 7-8 years back. There are some Rust frameworks available which look promising (rocket), but golang has much more. On the flipside, There is nothing wrong with golang (or at least it has less wrong going for it as compared to the js frameworks), but Rust is appealing because it IS the next big thing.
评论 #37527271 未加载
tubthumper8超过 1 年前
This author has a habit (in this posts and prior posts) of the content of the paragraphs not connecting the dots for the claims made in the headings.<p>&gt; Rust is (over)hyped<p>Whether it is or isn&#x27;t, the content of the following paragraph does not justify the heading. It cites the StackOverflow surveys that says people like Rust and then cites adoption, but doesn&#x27;t connect these points. It&#x27;s possible for something to be hyped but not adopted much if it&#x27;s new-ish.<p>The heading itself is also unclear. Is the author saying &quot;overhyped&quot; or &quot;hyped&quot;? Pick one.<p>Additionally, the author doesn&#x27;t connect this heading to the overall article. They should explain why something being (over)hyped means you should not pick it.<p>&gt; Rust projects decay<p>The rest of the paragraph talks about the Rust release cycle but doesn&#x27;t connect the dots to why this causes Rust projects to decay.<p>Any Rust code written after the v1.0 release is guaranteed to compile forever. If you upgrade your compiler by 30 versions your code will still compile. A new release of Rust doesn&#x27;t mean you have to drop everything you&#x27;re doing and upgrade. If you want to upgrade once per year, you can do that.<p>The same points were raised on the author&#x27;s previous article (&quot;Programming Languages are Platforms&quot;) which was another article that raises points in the headings that are not described further in the paragraphs.<p>&gt; Rust is still beta (despite the 1.0)<p>This paragraph says &quot;related to the point above&quot; but it&#x27;s not related. In this section they say that Rust is missing features (it is) and in the previous section they were implying that it&#x27;s bad that Rust is adding features.<p>This heading is also obviously intentionally inflammatory. If Rust not having async Traits makes it &quot;beta&quot;, would the author have considered Go to be &quot;beta&quot; for 10+ years when it didn&#x27;t have generics. Generics as a feature are *much* more integrated with fundamental parts of the language and cause ecosystem churn &amp; split. See also Java and C#.<p>(For the record, I wouldn&#x27;t consider either of those situations to be &quot;beta&quot; and think the suggestion is preposterous)<p>&gt; The standard library is anemic<p>Meh, &quot;anemic&quot; is a pretty inflammatory word and I wouldn&#x27;t go that far. It&#x27;s intentionally bare bones to avoid bad design decisions that can&#x27;t be removed in the future and so far that&#x27;s been pretty successful.<p>Does the Go standard library even have map&#x2F;filter yet?<p>It seems like this author&#x27;s idea of a non-anemic standard library is that it has a builtin HTTP server. They also suggest in other articles that Rust needs to have a builtin templating language as well. They suggest that not having this builtin leads to bugs, as if a standard library can&#x27;t have bugs as well? The link between these points is tenuous at best.<p>&gt; async is hard<p>These paragraphs are pretty good.<p>___<p>All in all, it&#x27;s a provacatively written article that&#x27;s sure to generate discussion, and especially discussion unrelated to the article itself, but unfortunately there&#x27;s little to no logical flow in the points that it&#x27;s trying to make.
nsonha超过 1 年前
Isn&#x27;t it obvious, just use what everyone use (golang at the moment)? Is your role as a software engineer NOT a job&#x2F;creating values for other people, but to &quot;influence technology&quot; or some sort of activism? I know that there are software engineers like that, but I just don&#x27;t think most people are. Many seem to be confused why they do what they do apparently.
throwawa14223超过 1 年前
&gt; I think that a modular and rich standard library such as Go&#x27;s or Node.js&#x27;s offers way higher productivity to developers, consistency to the ecosystem and reduced costs for businesses.<p>Is the Go standard library really considered rich? Coming from languages like python or ruby I found it pretty lacking. Admittedly I haven&#x27;t used Go in 3 years.
评论 #37529704 未加载
axegon_超过 1 年前
Honestly? Though I am forced to write go at work, I take Rust in a heartbeat(and it is a constant moaning from my end to ditch go and use Rust all the way almost every day). First thing to keep in mind is that Rust today is nothing like the Rust of 2015, even 2020. Way too many things are wrong with go: The packaging is one thing which I absolutely hate. I can&#x27;t find words to express how much I hate the import &quot;github.com&#x2F;whatever&quot; and that is a clear indication of the fact that packaging is an afterthought, which historically was a problem the language designers chose to ignore and kick the bucket down the road, hoping the community figures it out. Another clear indication of this is everything around the environmental variable hell: GOROOT, GOPATH and all that. Error handling is another horrible thing: ok, err := whatever() is absolutely wretched, even more so when you have to write the function definitions. Even when all linters are happy with the code, I can&#x27;t look at it without thinking &quot;this looks as beautiful and idiomatic as a roadkill&quot;. While coroutines(I hate the name goroutines) are cheap, they are not a universal solution to all problems and with that in mind, having a compiled language with no actual threading is ridiculous: threads are a great thing to have(I know this goes much deeper but let&#x27;s not turn this into a novel). While both languages don&#x27;t have inheritance, at least with Rust you have some tools to help you generalize basic things: macros. The statement that golang has all you need in it&#x27;s standard library is a complete joke. While the ecosystem has grown immensely over the years, I feel like it&#x27;s reaching the point where it&#x27;s comparable to the npm hellhole.<p>With Rust you get a perfectly thought out packaging. You also get the best of both worlds - runtimes and threads. By design you are pushed hard to properly handle errors. Some of my large Rust projects take forever to compile, I&#x27;ll give you that, but there is a good reason for it. The compiler is actually helpful and in a lot of the cases it tells you exactly what you need to fix when you mess up. And don&#x27;t even get me started on performance. I have the exact same microservice implemented in both go and rust. And while I did not opt for the most performant rust web framework (poem), it&#x27;s not even a race, it&#x27;s a straight up massacre: when I benchmark the two with wrk, the difference in performance is literally 11 times - same database, same openapi specification, same logic. While the Rust standard library lacks a lot of things, even some basic functionalities, cargo takes care of it for you with 0 effort: cargo new whatever, echo &#x27;rand = &quot;0.8.4&quot;&#x27; &gt;&gt; whatever&#x2F;Cargo.toml and you are done.<p>Don&#x27;t get me wrong, this is not a &quot;bash-golang&quot; comment. But I can&#x27;t deny that when I put the two side by side, go looks like a toy language.
评论 #37528724 未加载
Gualdrapo超过 1 年前
<a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=BN1WwnEDWAM">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=BN1WwnEDWAM</a>
taylodl超过 1 年前
Should I Rust or should I Go now?<p>Should I Rust or should I Go now?<p>If I Go there will be trouble!<p>If I Rust it will be double!<p>So you gotta let me know!<p>Should I Rust or should I Go?!<p>(I&#x27;ll see myself out now...)
NoZZz超过 1 年前
You should probably C that wherever you go there you are.
hinkley超过 1 年前
If you Go, there will be trouble. But if you Rust, it will be double.
anta40超过 1 年前
My POV:<p>Rust for OS kernel programming, e.g <a href="https:&#x2F;&#x2F;github.com&#x2F;dancrossnyc&#x2F;rxv64">https:&#x2F;&#x2F;github.com&#x2F;dancrossnyc&#x2F;rxv64</a><p>And go for practically anything outside that scope: web service, CLI tool, etc.
chx超过 1 年前
Luckily I have written up my heartache with Rust at <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=30954078">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=30954078</a> so I don&#x27;t need to do it again.
cutler超过 1 年前
Glad I read this. No need to waste my time learning Rust.
neonsunset超过 1 年前
Never touch Go and your life will be better.
sibeliuss超过 1 年前
GO
hsnewman超过 1 年前
Go
cozzyd超过 1 年前
Rust is not a good match for embedded Linux so long as binary sizes are so gigantic (same is true for a lot of C++). When your binary takes 100 MB of a few GB emmc, you have a problem.