Why Rust is so hard? - Ask Hackers

1.Regex: badly needs fuzzing

> It was a weekend learning project, and all I wanted to do was create a freshman level data structure from scratch.It's worth mentioning that the implementation difficulty of data structures in Rust is not representative of the general difficulty of programming in Rust. Just because this is hard doesn't make it a bad language. Rust's philosophy is that you deal with the trouble of writing unsafe code each time you need a new low level abstraction, and when done, you don't have to worry about it again.Also, writing generic datastructures in C++ without falling afoul of UB, and/or getting destruction semantics right can be quite tricky. Rust ... really doesn't have additional issues here; raw pointers in Rust work the same way as in C++, except they're a tad verbose. The only difference is that in Rust you probably want to provide a safe API, whereas in "freshman C++ datastructures" the datastructure does not have the unsafety neatly encapsulated. This is a hard task in both Rust and C++, especially with generic datastructures.Writing datastructures isn't really a common task. It's a "simple" task because it's simple in C and C++, but here's no real reason it has to be in Rust. You can write inefficient datastructures in 100% safe Rust without too many problems, much like you can implement datastructures in regular-joe Java. Writing efficient, low-level datastructures can be pretty hard, but like I said it's a rare task so not much of an issue.<a href="http://cglab.ca/~abeinges/blah/too-many-lists/book/" rel="nofollow">http://cglab.ca/~abeinges/blah/too-many-lists/book/</a> and <a href="https://doc.rust-lang.org/nomicon/" rel="nofollow">https://doc.rust-lang.org/nomicon/</a> are pretty good resources about writing unsafe Rust. The exact boundaries and semantics of unsafe code are still being pinned down so while I do want to improve this documentation I'm waiting for that to happen first.In general I advise folks to not write unsafe Rust till they are sure that they have a clear grasp of safe Rust. But if you want I can have a look at what you tried and help you improve your design. I'm very interested in making such things more accessible (on one hand, the Rust community doesn't really want to encourage the use of unsafe code, on the other hand, sometimes you need it and it would be nice if it was easier for people to use when that situation arises) so learning what people stumble on is important to me.> Unfortunately, I don't think they're very concerned about my particular use cases (and maybe they should > > I think all this says is that you don't write very much of the kind of code which benefits from generics. You can dismiss my point of view, but some of us do use them a lot, and it's one of the driving reasons I use C++.It seems like you're using generics the way you use templates for metaprogramming in C++. I totally get how powerful TMP is (I love to use it myself, though I can get carried away), but be aware that Rust is a different language and you have to approach it differently. It's important to consider the limitations of the system when designing a solution -- if I designed a solution for C++ and implemented it in Rust, I'd hit problems in the last mile and find it very annoying to make it work (using macros or something to fill in the gap). However, if you design the code from the start with Rust's advantages and limitations in mind; you may come up with a different but just as good system. This is something I hit every time I learn a new language. I hit it with Rust, Go, and many years ago, C++. So it may help to approach the language with a fresh mind.Yes, coherence is painful. I seem to hit coherence issues pretty rarely myself, but they're annoying when they happen. There's work going on to improve these pain points (specialization!), but it's overall not that big a problem.I think an example of what you tried might help. Preferably a more holistic example, condensed minimal examples tend to hide instances of the XY problem.> Disclosure: I don't really know what an "overlapping instance" means in this context.cases where you have more than one implementation that make sense for a given call. C++ solves this by allowing things to overlap and introducing overload resolution rules. Rust solves this by not allowing overlap.> but I'm guessing the memory foot print would be at least twice what it is in C++. (I should measure that though.)Go does make extensive use of the stack and has decent escape analysis, so it might not be that bad, really. But measuring it is probably the best way to go here.> Some other time it's because the standard library doesn't have a trait for a commonly implemented method, so I can't write a generic function to call that method.Do you have examples? In some cases generic methods are outside the stdlib in different crates, e.g. num_traits.

2.Maestro: A Linux-compatible kernel in Rust

If you spend time reading the article, you can agree or disagree with his choices, but he provides several reasons for why he chose to rewrite in Rust over after the initial project was written in C:"At that moment, I decided to switch to Rust (my first project in this language), which represented several advantages:- Restart the project from the beginning, using lessons learned from previous mistakes- Be a bit more innovative than just writing a Linux-like kernel in C. After all, just use Linux at that point- Use the safety of the Rust language to leverage some difficulty of kernel programming. Using Rust’s typing system allows to shift some responsibility over memory safety from the programmer to the compiler."Unfortunately, your comment doesn't add anything to the conversation and distracts from the interesting project being presented.

3.Rust 2024 the Year of Everywhere?

Here's an example (of complexity or difficulty, or .. whatever your preferred defs/vocab) that arose for me today (but on any day I do any Rust programming or reading I could find a similar example).This is an answer on the forums to a fairly beginnery-looking question: <a href="https://users.rust-lang.org/t/what-does-borrow-mean/81794/3" rel="nofollow">https://users.rust-lang.org/t/what-does-borrow-mean/81794/3</a>In what language ecosystem other than Rust would that answer arise as an answer to a beginner's question? Haskell, or a research language perhaps. I can't make head or tail of the Rust Playground example there. In fact if I look through most of recent questions on the Rust forum, there's probably 1 in 10 where I even grok the question, let alone the answer. I haven't experienced this elsewhere. Rust has a culture of complexity, and its community is in a state of denial about it (for I think a fairly obvious reason). Furious denunciations ensue even if anyone dare suggest such a thing!

4.Things that used to be hard and are now easy

> writing a fast program in C is often simpler compared to writing a fast program in RustI think it really depends on what you need to do. If you need a HashMap or a BTree, getting your hands on high-performance implementations of those structures in Rust is much easier than in C. Also "sprinkling some threads" on existing serial code can be much easier in Rust, using a library like Rayon. But I take your point that designing new data structures and doing unsafe things with pointers can be more complicated.> Overall Rust made programming harderThis is certainly a matter of opinion, but I like to argue that writing large, correct systems software was always this hard. Rust frontloads a lot of the difficulty, forcing you to handle every error condition, lifetime mismatch, and potential data race before it will even consent to run your tests. When you're first learning Rust, or when you're writing toy code where safety doesn't matter to you, this can feel like an unnecessary burden. But I think we've learned from experience that writing large systems software without this discipline leads to an endless stream of memory corruption and concurrency bugs.

5.Ask HN: What are some good Rust code samples?

(I'm going to write about Rust learning resources in general, so this may not fit the question, but believe the concepts are still worth considering)Rust is a very hard language to learn, not only because of the inherent difficulty, but also because of the lack of a structured way to approach the learning itself.Reading codebases is a very good practice in programming, but I don't think it benefits below the intermediate (if we put it this way) level, as you may not even notice many of the design choices.You're going to need a lot of time to become fluent, so it's crucial to clarify what's your target. If you just want to play with the language, anything will do; if you're serious, it's important to follow a path that it's stimulating, otherwise, you will just get bored and stop.I've tried Rustlings as a beginner, but it wasn't very stimulating. Gjengset's videos are extremely slow - they could be cut to a third, and still keep the same content; again, not very stimulating.For beginners, a possible path is to study the reference book (there's no escape from that), then optionally find a "strongly guided" projects-based book, then find some projects to work on (which may include "weakly guided" project-based books).A project-based book I suggest is "Rust Programming By Example" (Packt). The code quality is not very good, but it has several different projects to play with.Another book that may be interesting is (I haven't read it yet) is "Hands-on Rust- Effective Learning Through 2D Game development" (Pragmatic Bookshelf).After you're past the strongly guided projects phase, you may start to work on weakly guided ones. Two very good books (by the same author) are "Mazes for Programmers" (Pragmatic Bookshelf) and "The Ray Tracer Challenge" (Pragmatic Bookshelf).After that, sky's the limit, as you'll be surely ready to join established projects. The "Rust weekly" newsletter publishes projects who welcome beginners.You may want to read, at some point, "Programming Rust" (O'Reilly). It's tedious to read it after the reference book, but it has a different, slightly more in depth, view on the Rust language.

6.What's next for language design? (2017)

The list includes, from my reading, modules, errors, asynchronicity, side-effect types, fancy linting, and formalization. Elements 1, 2, and 5 exist in some sense in almost every area of engineering, while 3 and 6 are easily ignored if you don't need them. That leaves side-effects, the old bugbear of all functional programming.The difficulty with Rust is that it's "batteries not included", which is a term we use in software for the equivalent of a car sold with no wheels, body panels or seats. Sure there's a package manager, there's also an auto parts catalog.

7.Facebook's Novi wallet hits trouble as two top engineers depart

Not exactly; it's simply that under California law, non-compete clauses are unenforceable in employment contracts.The California Business and Professions Code section 16600 states that “every contract by which anyone is restrained from engaging in a lawful profession, trade, or business of any kind is to that extent void.”What you're saying might be true about the personal opinion of judges; I have no knowledge of that either way. But the fact of the matter is that state law makes non-competes void in employment contracts.That doesn't mean you can take your company's IP with you, however, as we've seen happen in other high-profile cases, like the engineer who went to Uber with a bunch of tech stolen from his previous self-driving car company: <a href="https://www.nytimes.com/2017/05/30/technology/uber-anthony-levandowski.html" rel="nofollow">https://www.nytimes.com/2017/05/30/technology/uber-anthony-l...</a> "Uber Fires Former Google Engineer at Heart of Self-Driving Dispute".But general knowledge of cryptography and blockchain primitives is not that sort of IP, unless the company has some truly novel cryptographic construction, or the engineers in question are trying to take code with them – I'm sure they're smarter than that. Besides, blockchain code for one project wouldn't necessarily be useful for an entirely different project unless it was an almost exact duplicate. Lastly, for blockchains to succeed they likely need to be open source or at least shared-source; no one will trust a closed-source, single-party controlled blockchain. There's no point in using the technology that way: you might as well just have a ledger in a database. So any successful blockchain tech will end up being open source, and there would be strong indications of copying unless the people working on it make a massive effort to obfuscate and rewrite.Let me put it a different way: if you had the source code for AWS's S3 or DynamoDB, they wouldn't be of any use to you. They're so complex and proprietary that if you wanted to form a company to offer competing services, you'd be better off and would get a product to market faster by building the functionality from the ground up (unless you could somehow take the entire team that has expertise with the existing software with you). The source would probably have value for bug-bounty hunters and blackhat hackers, but someone wanting to build similar services would be better off starting from scratch with the latest platforms (e.g. Rust) and programming/validation techniques.Very specialized cutting-edge areas like self-driving cars and computer vision that have advanced algorithms and machine learning are exceptions. I think blockchain tech is well enough understood that it's past that stage, except perhaps for complex smart contracts, especially ones that involve multiple blockchains, and maybe advances to speed up network transaction speed.I have no blockchain expertise whatsoever, but I'm pretty sure I could build a cryptocurrency from scratch from first principles given my existing knowledge of cryptographic primitives, and having skimmed Satoshi's original whitepaper and read casually on the topic. There's probably some fine-tuning magic in getting a few parameters right (like block size, difficulty, whether to be deflationary, etc.) but the basic structure of blockchain tech is pretty well understood by this point by people interested in the technology, even casually interested folks like myself. You submit a transaction for publication onto the blockchain and offer a fee for a miner to include it in their block. (How the network propagates these requests effectively peer-to-peer I'm not entirely sure, but I imagine that the wallet clients have hardcoded seed servers that they use to discover others for broadcast, after which candidate blocks move peer to peer across the network. There may be discovery techniques similar to other P2P networks.) So-called full nodes probably discover and maintain connections to a suite of other full nodes, which they use to broadcast transactions and candidate blocks across the network.A miner successfully cracks the hash for the next block, based on the current difficulty level (set by time since last block), and includes all the pending transactions they know about that fit into the block (limited by block size). The pending transactions are cryptographically validated by their respective wallet public key signatures. You'll need to get that signature validation just right to make sure it's validating every input. Pending transactions include an operation code instructing what operation should be performed: transfer funds to another wallet, transfer funds to another wallet given N out of M signatures from other identities, and so on. More advanced blockchains than BTC have sophisticated programming models with many operations to make "smart contracts"possible involving multiple actors, but you don't need that complexity for a basic working network that can move blockchain currency. Bitcoin has basic operations and multi-signature transactions; Ethereum has a fully Turing-complete programming model, to enable its smart contracts and sophisticated constructs like the DAO. To prevent abuse and infinite loops you have to "pay" for the amount of computational power your transaction/contract uses based on its complexity, and also set a maximum number of operations it will perform before stopping (and you still have to pay for its execution if that happens).If I was truly going to implement a cryptocurrency from scratch I'd probably start either with Satoshi's original code as a reference minimal implementation, and compare it with the current mainstream BTC clients (which have fixed bugs etc. since then). That's all open source, then adjust as necessary to meet your goals.

8.Don't use markdown for documentation (2018)

I have difficulty putting into words how much I loathe technical writing that is structured anything like a textbook or dissertation.It's a pain in the ass to use, and I wish more people would focus on concise and easily referenced/searched/indexed material in markdown rather than novels written in TeX.For example, Agner Fog's writings are fantastic content, and awful to navigate. The Rust Programming Language does exist in book form, but I find myself referencing it constantly as a technical manual and it would suck to do that if weren't structured the way it is using mdbook.For the love of all that is sacred, please stop writing technical manuals like I'm going to ever going to read the whole thing. Every piece of information should be short, fit entirely in a reasonably sized browser window, be indexed for search, and if it lends itself to cross-referencing it should be filled with links to itself.That's the kind of thing that markdown and site generators using markdown excel at.