TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Rust from 0 to 80% for JavaScript Developers

129 pointsby michaelsalimabout 3 years ago

8 comments

Diggseyabout 3 years ago
Some small corrections:<p>&gt; It’s an error handling magic for async functions<p>The question mark operator is unrelated to async - you might say &quot;fallible functions&quot; instead.<p>&gt; This indicates that it’s a macro. Basically a shortcut.<p>I don&#x27;t think &quot;shortcut&quot; has a specific meaning that is related to macros in either Javascript or Rust.<p>&gt; An implementation of trait. So class (?).<p>Not really a class. There isn&#x27;t a good parallel to this in most other languages. It is the link between a trait and a type, and provides a specific implementation of the trait.<p>&gt; Unlike JS, Rust has a type for the result of the promise&#x2F;future called Result<p>The `Result` type is not related to futures. Any function can return a `Result`, and a future can yield any type (not necessarily a `Result`, although it is commonly used in that way).<p>&gt; The Result enum has Ok and Err. If the future is successful, it returns Ok, otherwise Err.<p>Again, no relation between `Result` and futures.<p>&gt; Use this when you’re confident that it won’t error.<p>Personally I would recommend never using `unwrap` outside of tests. If you want to panic on the `Err` case, then `expect(&quot;...&quot;)` allows you to provide an explanation for why the `Err` case should not have been possible.
评论 #31221389 未加载
评论 #31221496 未加载
评论 #31221439 未加载
评论 #31223052 未加载
LAC-Techabout 3 years ago
Rust is one rabbit hole I really, really regret going down. Put weeks of work into it, got frustrated nearly every day, wrote copious notes, re-read things, and the end result is... I still can&#x27;t use it for anything gnarly (ie everthing, because why else would I use a systems programming language if I wasn&#x27;t doing funky stuff with memory?)<p>Rust has great PR but I found it to be a profound waste of time. YMMV.
评论 #31222539 未加载
评论 #31222411 未加载
评论 #31222219 未加载
评论 #31222571 未加载
评论 #31222775 未加载
评论 #31224921 未加载
评论 #31222427 未加载
评论 #31222921 未加载
评论 #31222568 未加载
danbulantabout 3 years ago
Can someone compare this post to mine (1)? I made a highly similar post 2 months ago and got just 2 upvotes and no comments.<p>[1]: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=30869137" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=30869137</a>
评论 #31302780 未加载
lucasyvasabout 3 years ago
There are a few too many mistakes in this to recommend it as a learning resource as-is. If you check back later maybe the author will have some things fixed.
评论 #31223100 未加载
siwatanejoabout 3 years ago
Website renders poorly on mobile (Android at least).
评论 #31222869 未加载
PoignardAzurabout 3 years ago
<i>&gt; Use Cargo.toml instead of package.json. You’ll want to add them manually (instead of using a command like yarn add)</i><p>The cargo-edit tool gives you yarn-like commands to edit your packages. The main command, &quot;cargo add&quot;, will be integrated into mainline cargo next update (I think).<p><a href="https:&#x2F;&#x2F;github.com&#x2F;killercup&#x2F;cargo-edit" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;killercup&#x2F;cargo-edit</a>
评论 #31229439 未加载
purplerabbitabout 3 years ago
Fantastically helpful article, imperfections notwithstanding. Many thanks!
SemanticStrenghabout 3 years ago
Haters gonna hate but the truth is that it transpire everywhere in the design of Rust that it was designed mostly by programmers prone to ivory tower&#x2F;purity thinking over pragmatism, as a consequence the language is one of those with the highest cognitive load&#x2F;overhead and for the <i>wrong reasons</i>. Rust is in many aspects a major progress over C++ (a goal actually quite trivial to achieve, in restrospect). The concept of zero cost abstractions are nice marketing, except when they&#x27;re not. Rust has some design constraints in order to maximize performance like C++. However, because of the collaborative and pure thinking nature of the project, many non-needed for performance choice have been made, to the down of cognitive load and therefore the net result being a loss of programmer joy and intelligence (since cognitive resources are a limited budget). I am aware that rust has reached a point of religion on HN so feel free to censor my sound arguments.<p>Examples: * Immutable by default with a verbose syntax (let mut..), compare this with Kotlin val to var. It appear clear that rewritability has not been well thought, if thought at all. This basically means writing variables is a pain, your thinking process is <i>constantly</i> stopped by making things no longer.. constants.<p>Options. yeah null is so <i>impure</i>. Except you now have done the worst thing you could have ever done to a language, wrapped types... The unergonomy and verbosity is strong. When you see Typescript, Kotlin, C# and Dart non nullable types and smart casts you clearly realize Rust has made a permanent historical accident here. If you don&#x27;t know what I&#x27;m referring, it only cost one google search.<p>Results, same problem as options. Verbose, thought interrupting. The cognitive noise of polluting return types is strong, very potent. If they wanted pure thinking nazism they could have added optionally or not, exceptions on the type signature, like java checked exceptions, or the incoming exception signatures in typescript. The number of rust error handling libraries is a testimony to this failure. When such core features are lacking, a language is a failure.<p>Throwing away object oriented programming is the cringiest mistake of rust though. Because it&#x27;s not cool enough in 2022. Rustc was first designed in Ocaml, with all the cognitive biases this imply. If composition is that nice well make it a proper pattern like Kotlin delegation, except rust did not. And even if delegation was ergonomic, inheritance still is the most sensible approach both in terms of semantics (yes not everything is a has, hypernyms matters) and in terms of features. OOP allow encapsulation which is essential, better code reuse , visibility control, contracts and overriding. Rust do not have constructors so the method to instanciate a resource is conventional.. All of that because people have seen too much memes on twitter about Java factorySingletonDank which are indeed non-representative about reasonable code in the wild. see also concrete examples: <a href="https:&#x2F;&#x2F;medium.com&#x2F;hackernoon&#x2F;why-im-dropping-rust-fd1c32986c88#.iwj1b2bi8" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;hackernoon&#x2F;why-im-dropping-rust-fd1c32986...</a><p>bonuses: String types hell<p>no named parameters in 2022, do they fail to realize denoting and accessing semantics is the most important thing in programming? That means in many context, rust code is much less understandable.<p>no unified async runtime..<p>There are other omissions, such as no overloading, this post is non-exhaustive.<p>That you disagree or not with some or all of my quantifiers is a thing but you have at least to agree that there is a real market for a better C++ that would be non-hipster and pragmatic with a goal of maximizing code clarity and the developper cognitive bandwith while retaining runtime performance. That better C++ would be C#&#x2F;Kotlin-like but leverage LLVM and have no-GC.<p>A testimony from a previously rust fanboy that has following rustc development since its pre-1.0.<p>Edit yes flagging me is a good sign validating the belief of HN being an effective echo chamber that force-align allowed thoughts and beliefs and amplify them.