26 ms·

Why the developers who use Rust love it so much

135 points by cyber1 6y ago

atoav 6y ago
Coding in Rust isn't easy, but where it is hard it is hard in a good way. It is like being on a journey with a good friend, who deeply cares about not letting you shoot yourself into the foot and explains you why without judging you. Even if Rust would be wiped off the face of the earth tomorrow, thr things I learned from it have definitly made me a much better programmer.
- logicchains 6y ago
  >explains you why without judging you Yep, the compiler doesn't judge you, that role is left to the community when they discover you posted a library on Github that uses more unsafe code than they'd like.
  - twic 6y ago
    It would be great if that feature could be moved into the compiler, though!
  - uryga 6y ago
    for anyone not following Rust, the drama around the (popular) Actix web framework was a prominent instance of this. iirc people opened issues and PRs re: the project's (significant) usage of `unsafe`, but the maintainer (Nikolay Kim) wasn't receptive; then some folks got nasty about it on reddit, escalating into full-blown drama. sadly, it ended with Kim posting he's "done with open source" and quitting the project. a more detailed (and probably more accurate) account: [A sad day for Rust](https://words.steveklabnik.com/a-sad-day-for-rust https://words.steveklabnik.com/a-sad-day-for-rust)
    - chrismorgan 6y ago
      By no means is it only about Actix; that’s just one of the more notable times that something like that has happened. The eminently reasonable criticism boils down to baulking at people undermining Rust’s safety guarantees with demonstrably wrong unsafe code, while publishing said code in such a way that you’re suggesting that others use it (i.e. it’s not just private code). It is also then often taken further to a general unease at gratuitous use of unsafe code, which I consider fairly reasonable because it’s so hard to get right (it’s unsafe for a reason). Then sometimes a few people take it beyond what might be considered socially reasonable.
      - uryga 6y ago
        > [Actix] is just one of the more notable times that something like that has happened. edited my comment to reflect this, thanks i was trying to keep my summary relatively opinion-free – the internet probably doesn't need my take on that situation :)
      - Dowwie 6y ago
        It is a mistake to marginalize what a small number of people achieved. An organized team successfully "cancelled" the Actix project and smeared its author after repeated attempts-- three distinct episodes over 12 months. This was a campaign that spanned social media and github. It is worth noting that to this date, none of the members of the anti-actix effort have contributed towards a viable alternative, nor have they attempted to resolve their concerns in the actix ecosystem. It turns out that the patrons who complained about free beer never intended to brew their own.
        chrismorgan 6y ago
        I never followed the matter closely, but from the parts that I did follow or investigate, your comment doesn’t feel particularly accurate. • I don’t believe there was any organised team; it arose organically. • In each case the complaints were of concrete problems that incorrect usage of unsafe caused. After that, people did then tend to pile on and baulk at other unsafe code that was probably OK, because the author had been proven untrustworthy in using unsafe code. (“Unsafe” says “trust me, it’s OK”, and that trust had been broken.) And there were one or two people that made it more direct personal attacks—but probably only one or two. • Your final paragraph just seems completely wrong. Various of those that complained did offer alternatives, some of which were turned down. And people did go with viable alternatives, switching to competitors to Actix. Even apart from all that, if you can prove that by some metric a piece of software is bad, why would the burden lie with you to fix it? (Especially if your patches are rejected.) If the problem won’t be fixed, recommending that others avoid it seems perfectly reasonable. You’re presenting a common logical fallacies, that you can’t criticise something unless you can provide an alternative. I don’t need to be able to build a better bridge to be able to point out that it’s falling down. Feel free to correct me if I’m wrong, but I intend to engage no further on this. The points have been hashed out before and there is nothing new to say; things just tend to get heated. Have an enjoyable day. :)
    - codeflo 6y ago
      For the most part, the Rust community seems to value safety and correctness above extracting the last bit of performance. Using “unsafe” code is seen as a necessary evil, only allowed when its use is hard to avoid, local and easy to understand. Mostly, you’re supposed to use unsafe code as the foundation which safer abstractions are built on top of. It’s a bit if an oversimplification to say that the Rust community complained about the amount of “unsafe” code in Actix. It was more about the how and why. From what I gather, the author didn’t accept patches that fixed safety/soundness bugs when they had even a small impact on performance. That’s a trade-off that one is allowed to make in my opinion (if clearly communicated, so that people can make informed decisions on whether to use a piece of code). I think this difference in values (or rather, engineering goals) explains in part why this escalated so badly. But a healthy software ecosystem should have room for libraries that make different trade-offs. Zealotry (in the form of “There’s one right way”) doesn’t encourage experimentation, and shrinks communities instead of growing them.
      - Dowwie 6y ago
        The soundness argument usually didn't carry water and was presented by people who were very much out of their depth (not that I was any more in-depth, but at least I stayed out of the way). The author and others addressed a lot of unnecessary unsafe, though. That which was left remained a sore point for those who demanded code purity. The author was a one-man army who took flak for way too long. Repeated requests to resolve non-issues blinded him to requests revealing actual concerns. It's analogous to the story of the boy who cried wolf. He was not respectful, but also had been fighting way too many battles for too long and consequently was all out of patience. It was a bad situation waiting to boil over.
    - ssokolow 6y ago
      Since I haven't seen anyone cover it from quite this perspective, here's how I saw what led to things blowing up like that: What really got people riled up was that... 1. Nikolay refused to acknowledge the principle (stated in the rustonomicon, IIRC) that a function which can violate memory safety when fed incorrect arguments must be marked `unsafe`, EVEN IF IT'S AN INTERNAL-ONLY API. (Increasing the bus factor with regard to maintainability is core to how Rust competes with C++.) 2. The Actix website gave the strong impression that it was a production-ready dependency, rather than an experiment in squeezing out maximum performance, and, unless you'd been present for the previous stink-raisings, it did appear to be a mature, safe option for writing code in Rust that would then be exposed to the public Internet for an entire world of potential attackers to hammer on. 3. This was the third time Nikolay had done something like this. So, to some people, it felt like Nikolay was actively and callously developing a PR timebomb for Rust and its ecosystem. I won't rule on how they chose to act, but that's my take on why they chose to act.
  - izacus 6y ago
    Yup, I got called a jackass (sic) when I was asking why the most commonly recommended Rust crypto library doesn't support some of the older decryption algorithms which I needed to process some encrypted files. I got so many smug "you don't know what you're doing, it's insecure!" answers from people who clearly had no basic understand how security works. And I only asked for help, I didn't demand or try to accuse anyone of anything. And that's not the only case where Rust community was just permeated with certain arrogance which I've never really felt in any career as C++/Python/Java developer.
    - UK-Al05 6y ago
      I think I remember this. The problem was you we're insisting to add in an insecure encryption algorithm into the crypto library. They didn't want to because they didn't want to add an insecure algorithm to the library to encourage its use. The best bet is to use another library whose goals are different. This was explained a few times. Tbh I'm on the side of the library developers here. If you want to be the official encryption library, you probably want to avoid broken encryption algorithms. Leave the backwords compability encryption to other libaries, designed for the task.
      - izacus 6y ago
        I'm not sure how you could remember this since I wasn't insisting on anything like that and I wasn't even opening a ticket on any official bug tracker - I think you mistook me for someone else. I took extra care not to demand anything and the conversation was mostly on IRC and some specialized subreddits. Also not being able to decrypt data older than a few years with safe Rust libraries is a bit of a strange way to do security - if anything, Rust is perfect for parsing files in secure manner. My concrete use case was processing PDFs which tend to be signed with older certificate algorithms and the idea that being able to verify signatures on those files encourages insecurity is just strange. The only solution offered was to use OpenSSL via C bindings which (besides not compiling at all on Windows) is a security nightmare. In any case, I accept that library (and core language) developers can decide that Rust won't be a language that's usable for verifying and processing data formats that are older than couple of years. What I find it harder to accept is being personally insulted for having a use case that doesn't fit into community's perfect world. That didn't happen in any other communities in my career.
Skunkleton 6y ago
Also: almost everyone who uses rust does so by their own choice.
- elsjaako 6y ago
  This is mentioned in the article
- pengaru 6y ago
  I don't get this comment, rust is a new language that isn't widely embraced by employers yet. How would rust have a significant number of users forced to use it?
  - power78 6y ago
    He means: another reason rust users love it so much is because they are not being forced to use it
  - mcintyre1994 6y ago
    It’s discussed in the article but that quality kind of ‘games’ the metric SO are using - what % of people using it want to keep using it? If people were forced to use it for work then you’d likely see a lower number regardless how good it is just because it wouldn’t be every single person’s preference. It’s not a bad thing - a new language that doesn’t reach that point probably dies - but it does make it easier to score highly on their metric.
- canofbars 6y ago
  Also the same for Haskell so I would have expected to see that much higher.
- tempodox 6y ago
  Which makes it seem logical that the people who consistently use it do so because they love it. Point proven. Other than, say, JS for instance. If you want to make webware you just have to use it, regardless of whether you like it or not. Or C/C++ for embedded. There are efforts to bring more languages into that space but at the moment you'd be hard pressed if you wanted to use anything else.
smabie 6y ago
"In type checking, only the signature of functions are considered. There’s no relying on the implementation for determining if callers are correct (like you can do in Scala, or Haskell)" What does this mean?
- twic 6y ago
  You can know the exact parameter and return types of a function by reading its signature. You can't do that in Scala, because of type inherence. This is legal Scala: def twice(x: Int) = { x * 2 } But you can't know the return type without reading the function body. That example is not so bad. I routinely used to confront things like: def applyComputation(x: Int) = { determineComputation().compute(x) } And now you're off on an adventure to work out the return type. EDIT There's sort of a deviation from this with "impl trait" returns. There the signature says that the function returns some type which implements a certain trait, but you can't tell exactly what.
  - jfim 6y ago
    It's been a while since I've written any Scala, but if I recall correctly it's frowned upon to use type inference for return values in method signatures.
    - twic 6y ago
      Yes, inference. My phone is very keen to use the word "inherence", which I didn't even know was a word. In Scala it's frowned on. In Rust it's not possible.
    - MrBuddyCasino 6y ago
      > it's frowned upon to use type inference for return values in method signatures The language shouldn't allow it in the first place. Its a symptom or not balancing power with complexity and shows up elsewhere in Scala. They "were so preoccupied with whether or not they could that they didn't stop to think if they should."
      - 6y ago
FlyingSnake 6y ago
Rust is a fantastic language, and once past the borrow checker level, it can be quite productive. One interesting compatriot of Rust is Swift, which also ticks most of the checks in that list. Also Swift has IMO a better development experience, due to Apple’s initiatives. I wonder what Rust developers think about swift.
- asiachick 6y ago
  From everything I've read Swift is still slow relative to Rush because it uses ARC and so there are increments and decrements of usage counts all over the place. To put it another way, Swift handles memory safety at runtime, Rust handles it at compile time? There is/was talk of trying to either do escape analysis or add some hints so the compiler can get rid of those checks but AFAIK that hasn't happened yet?
  - zozbot234 6y ago
    Rust has Arc<> too, but it's optional. And it only increments and decrements wrt. Arc references that might affect when the object is dropped; it doesn't need to do so with references that are outlived by some existing Arc reference. I think this is what you're calling 'escape analysis' in your comment, but Rust does it statically and the 'hints' are ordinary Rust syntax.
  - skohan 6y ago
    It's a bit more complex than "swift is slow". As you say, ARC can lead to some performance cliffs when using reference types (class), but Swift manages memory statically for value types (struct, enum). Modern idiomatic swift uses reference types quite sparingly, and Swift can be quite performant, but usually requires prolific use of profiling and optimization to get there. Best case performance for Rust will probably always be better, because even for statically managed types, Swift leans more heavily toward copying values where Rust tries to leave them in place whenever possible.
    - zozbot234 6y ago
      "ARC can lead to performance cliffs" is quite optimistic. Obligate reference counting ala Swift has even lower performance than obligate GC, at least wrt. throughput. It's pretty much a dead end in many ways.
ncmncm 6y ago
Money quote: "Rust benefits here that very few people are being forced to use Rust." Probably more people pick up C++ for the first time, in any given week, than the total who use Rust in production today. Rust also benefits from the limited historical baggage that comes with being new and incompatible. Unlike Java, which was in the same position, Rust adopted very few old mistakes, and especially unlike Java made few new ones. But as the language approaches industrial maturity (possibly within 10 years) early mistakes will become evident, and cruft will be seen to accumulate. Rust designers have consciously chosen to keep the language's abstraction capacity limited, which makes it more approachable, but reduces what is possible to express in libraries. Libraries possible, even easy in C++ cannot be coded in Rust. The language will adopt more new, powerful features as it matures, losing some of its approachability and coherence. But Rust has already passed a key milestone: there is little risk, anymore, that it could "jump the shark". The language is gunning for C++'s seat. Whether it becomes a viable alternative, industrially, is purely a numbers game: can it pick up users and uses fast enough? The libraries being coded in C++ today will never be callable from Rust. Go proved that the world will make room for a less capable language (in Go's case, than Java) if it is simpler. Rust is much more capable than C, Go, or Java, and the world would certainly be a better place if everybody coding those switched to Rust. So, my prediction is that Rust and C++ will coexist for decades. The most ambitious work will continue to be done in C++, but a growing number will have their first industrial coding experience in Rust instead of C, and many will find no reason to graduate to C++.
- asiachick 6y ago
  > That means libraries possible, even easy in C++ cannot be coded in Rust. Can you give some examples of libraries that can be made in C++ that can't in Rust and why they can't? Having never used Rust yet I'm curious what the issue is.
  - deleted 6y ago
    [deleted]
  - pjmlp 6y ago
    Imagine something like SwiftUI, including support for dragging components out of a toolbox, and having an eco-system of companies selling such components. https://www.componentsource.com/search/products?f%5B0%5D=at%3A914099&f%5B1%5D=et%3A919786&f%5B2%5D=et%3A919791&sort=bestseller https://www.componentsource.com/search/products?f%5B0%5D=at%... https://microsoft.github.io/microsoft-ui-xaml/ https://microsoft.github.io/microsoft-ui-xaml/ The borrow checker in its current state makes it very hard to build such tools.
moonchild 6y ago
I don't believe that rust solves the right problems in the right ways. This is specifically with respect to the single-owner raii/lifetime system; the rest of the language is imo pretty nice (aside from the error messages, which are an implementation problem). For starters, ATS[1] and f-star[2] both provide much stronger safety guarantees, so if you want the strongest possible guarantees that your low-level code is correct, you can't stop at rust. _____________________________________________ Beyond that, it's helpful to look at the bigger picture of what characteristics a program needs to have, and what characteristics a language can have to help facilitate that. I propose that there are broadly three program characteristics that are affected by a language's ownership/lifetime system: throughput, resource use, and ease of use/correctness. That is: how long does the code take to run, how much memory does it use, and how likely is it to do the right thing / how much work does it take to massage your code to be accepted by the compiler. This last is admittedly rather nebulous. It depends quite a lot on an individual's experience with a given language, as well as overall experience and attention to detail. Even leaving aside specific language experience, different individuals may rank different languages differently, simply due to different approaches and thinking styles. So I hope you will forgive my speaking a little bit generally and loosely about the topic of ease-of-use/correctness. The primary resource that programs need to manage is memory[3]. We have several strategies for managing memory: (Note: implicit/explicit below refers to whether something something is an explicit part of the type system, not an explicit part of user code.) - implicitly managed global heap, as with malloc/free in c - implicit stack-based raii with automatically freed memory, as in c++, or c with alloca (note: though this is not usually a general-purpose solution, it can be[4]. But more interestingly, it can be composed with other strategies.) - explicitly managed single-owner abstraction over the global heap and possible the stack, as in rust - explicit automatic reference counting as an abstraction over the global heap and possibly the stack, as in swift - implicit memory pools/regions - explicit automatic tracing garbage collector as an abstraction over the global heap, possibly the stack, possibly memory regions (as in a nursery gc), possible a compactor (as in a compacting gc). (Java) - custom allocators, which may have arbitrarily complicated designs, be arbitrarily composed, arbitrarily explicit, etc. Not possible to enumerate them all here. I mentioned before there are three attributes relevant to a memory management scheme. But there is a separate axis along which we have to consider each one: worst case vs average case. A tracing GC will usually have higher throughput than an automatic reference counter, but the automatic reference counter will usually have very consistent performance. On the other hand, an automatic reference counter is usually implemented on top of something like malloc. Garbage collectors generally need a bigger heap than malloc, but malloc has a pathological fragmentation problem which a compacting garbage collector is able to avoid. This comment is getting very long already, and comparing all of the above systems would be out of scope. But I'll make a few specific observations and field further arguments as they come: - Because of the fragmentation problem mentioned above, memory pools and special-purpose allocators will always outperform a malloc-based system both in resource usage and throughput (memory management is constant-time + better cache coherency) - Additionally, implicitly managed memory pools are usually easier to use than an implicitly managed global heap, because you don't have to think about the lifetime of each individual object. - Implicit malloc/free in c should generally perform similarly to an explicit single-owner system like rust's, because most of the allocation time is spent in malloc, and they have little (or no) runtime performance hit on top of that. The implicit system may have a slight edge because it has more flexible data structures; then again, the explicit single-owner system may have a slight edge because it has more opportunity to allocate locally defined objects directly on the stack if their ownership is not given away. But these are marginal gains either way. - Naïve reference counting will involve a significant performance hit compared to any of the above systems. However, there is a heavy caveat. Consider what happens if you take your single-owner verified code, remove all the lifetime annotations, and give it to a reference-counting compiler. Assuming it has access to all your source code (which is a reasonable assumption; the single-owner compiler has that), then if it performs even basic optimizations—this isn't a sufficiently smart compiler[5]-type case—it will elide all the reference counting overhead. Granted, most reference-counted code isn't written like this, but it means that reference counting isn't a performance dead end, and it's not difficult to squeeze your rc code to remove some of the rc overhead if you have to. - It's possible to have shared mutable references, but forbid sharing them across threads. - The flexibility gains from having shared mutable references are not trivial, and can significantly improve ease of use. - Correctness improvements from strictly defined lifetimes are a myth. Lifetimes aren't an inherent part of any algorithm, they're an artifact of the fact that computers have limited memory and need to reuse it. To summarize: - When maximum performance is needed, pools or special-purpose allocators will always beat single-owner systems. - For all other cases, the performance cap on reference counting is identical with single-owner systems, while the flexibility cap is much higher. _____________________________________________ 1. http://www.ats-lang.org/ http://www.ats-lang.org/ 2. https://fstar-lang.org/ https://fstar-lang.org/ 3. File handles and mutex locks also come up, but those require different strategies. Happy to talk about those too, but tl;dr file handles should be avoided where possible and refcounted where not; mutexes should also be avoided where possible, and be scoped where not. 4. https://degaz.io/blog/632020/post.html https://degaz.io/blog/632020/post.html 5. https://wiki.c2.com/?SufficientlySmartCompiler https://wiki.c2.com/?SufficientlySmartCompiler
nickm12 6y ago
I love this quote from a friend of mine who was learning Rust: "It's hard but I love it. Dealing with the compiler felt like being the novice in an old kung fu movie who spends day after day being tortured by his new master (rustc) for no apparent reason until one day it clicks and he realizes that he knows kung fu."
- dgzl 6y ago
  Reminds me of learning Vim
- skohan 6y ago
  Sometimes I wonder a key part of the appeal of Rust is that feeling of climbing the mountain. I've noticed that coming to a solution around the particular constraints of Rust can have a eureka feeling which is similar to how it felt applying a new concept successfully for the first time when I was first learning to program (e.g. recursion). I'm not always convinced the solution I come to is superior to what I would have done in a more traditional programming language, but it certainly feels rewarding to overcome challenge, and I would bet that's true of a lot of people, and that it's more motivating than the promise of performance and memory safety alone.
  - deleted 6y ago
    [deleted]
  - Dowwie 6y ago
    I've experienced that climber's high several times while working out problems with Rust during my first two years working with the language. It's a rewarding feeling. I couldn't climb without the community, either. There's so much to learn, especially when one chooses to learn while doing, but it can be done with help. I am convinced that the solutions I come with are superior to those I would write with Python, but the first time solving them may involve a costly investment of time and effort.
- bjarneh 6y ago
  That's an excellent quote; and 100% true based on my experience. The only language that I've struggled even more with is Prolog.
dirtydroog 6y ago
Never before has a programming language received so much marketing. It's very odd.
- nickm12 6y ago
  I take it you weren't programming when Java was the new hotness?
  - HugoDaniel 6y ago
    or Ruby, or Haskell, or elixir... Rust so happens to appeal the front-end crowd as much as the backend people and they are leveraging those windows of opportunity much better than any other language or community. Wasm bindgen is a bliss of fresh air, it even works very well with TypeScript.
- npiit 6y ago
  I don't think that "marketing" is the right word for a FOSS project that is not affiliated with any for-profit entity and has no business strategy. Rust is truly loved by many who had the chance to work with it and that's why it's honestly promoted more than any other modern language.
- eeZah7Ux 6y ago
  People were following the hype and cargo-culting Java, XML, Visual Basic in similar ways. Yet I really feel that the echo chamber effect is stronger now. People seem to need something to be hyped and polarized about. Nuanced conversation becomes more difficult as the hyped crowd overwhelms any conversation.
  - pjmlp 6y ago
    We were discussing VB and Java on early days of Web, places like Compserve, BBSs or plain magazines reader letters.
turbinerneiter 6y ago
It feels like being part of a village that learns to love the dragon it battles.
- deleted 6y ago
  [deleted]
andi999 6y ago
Also the same reason why ppl love c++: Stockholm syndrom.
- FlyingSnake 6y ago
  Most of the people who use rust, do so on their own volition. I don’t see anyone being held hostage to rust due to corporate policies.
- nindalf 6y ago
  86.1% of people using Rust love it. For C++ it's 43.4%. [1] You'd have to explain the disparity in the two numbers if you think they're loved for the same reason. Further, Rust is mostly used by people who choose to do so. There are very few people out there forced into maintaining shitty, legacy codebases in Rust because there aren't very many such code bases ... yet. [1] - https://insights.stackoverflow.com/survey/2020#technology-most-loved-dreaded-and-wanted-languages-loved https://insights.stackoverflow.com/survey/2020#technology-mo...
  - andi999 6y ago
    Interesting study. Of course you are right. But this study poses the question: are ppm forced to work in julia?
  - drewcoo 6y ago
    "It occurs when hostages or abuse victims bond with their captors or abusers." [1] The stories speak of abuse and an unwillingness to leave. This does not detail how they came to be abused or captives. I'm not saying they were asking for it, dressed that way, but maybe these Rust victims' behavior led them to entrapment. That doesn't mean it's not real. This seems a lot like Stockholm syndrome. [1} https://www.healthline.com/health/mental-health/stockholm-syndrome#definition https://www.healthline.com/health/mental-health/stockholm-sy...
- mD5pPxMcS6fVWKE 6y ago
  It's just a matter of age .... I remember back in 1990 99% of C++ users loved it, as it was kool.
devit 6y ago
It's the only production-ready language that is both memory safe and has zero-cost abstractions (i.e. for any C code you have Rust code that compiles to equivalent assembly, and using more abstractions in Rust does not make the assembly less efficient unless the abstraction can't be implemented otherwise). Also as long as you accept not having dependent types (at least for the short and mid-term) and several currently unimplemented features, Rust is the optimal way a programming language can be designed other than assorted minor warts.
- Dowwie 6y ago
  Batteries are very much already included. The missing features you are referring to are likely not show stoppers.
orthoxerox 6y ago
It's a niche language that dominates its niche. I wouldn't write a LoB application in Rust, for example. But if I wrote programs with really tight speed and memory requirements for a living, I would pick Rust for the task. If people were forced to write their website backends in Rust (or even their frontends in Rust targeting WASM) they would hate it. Its performance is overkill for 99.9% of backends, but the means of getting this performance kill your productivity.
- majewsky 6y ago
  My current side project has a frontend in Rust via WASM, and I love it. Way better than the huge mess that is the JS ecosystem.
  - Dowwie 6y ago
    Rust WASM is still very bleeding edge. Let's not give anyone the false impression about what anyone can manage to build today.
- Dowwie 6y ago
  I've been using Rust for backend web dev and networked services for the last two years. I'm working on the greatest project of my life (until my next project) and Rust is really helping me along. The performance and resource efficiencies are great side effects. I don't understand the argument that performance benefits are overkill for web development. Obviously, no one needs to use a flamethrower to light a cigarette. However, a fully-fleshed web server is a very complex system that taxes performance with all that it does. I'm working on a greenfield project and had discretion over what tooling to use. I decided to invest in Rust, eating short-term productivity losses in exchange for long-term gains. Those gains are realized at many points in development, compounding over time. As team members are brought into this project, I will accept a simple "thank you" for bringing joy to their work and renewing their aspirations for creating better products. Web dev doesn't have to be so shitty an experience, but it requires investment. That's a tough sell for managers who aren't coders, but those who rose from engineering understand its importance.
- 6y ago
robotmay 6y ago
I've been casually playing with Rust for a few years now. Wrote a few small things in my previous job that still run a large part of their business, which is pretty satisfying, but only very recently have I found a couple of hobby projects where it just feels like the right tool for the job (for me). Web stuff I'd still much rather write in Ruby, if I'm honest, but for playing around on systems Rust is super fun. I ended up making https://git.sr.ht/~robotmay/amdgpu-fancontrol https://git.sr.ht/~robotmay/amdgpu-fancontrol, of which there's already an equivalent in Python, but the lack of dependencies when installing a piece of Rust software makes it feel very portable and neat. My favourite metaphor for Rust is that it's like a friendly bare-knuckle fist-fight with the compiler. It's not as user-friendly as, say, Elm, but it's streets ahead of Haskell's errors.
- slowwriter 6y ago
  Can I just say, I really appreciate the Community reference Edit: Btw, if you have to ask what I mean you’re streets behind
lbj 6y ago
Where's a good place to start with Rust? Which domains is it particularly good in ?
cassepipe 6y ago
Rust is great but it could gain from explaining itself with memory and pointers or else why a String has the Clone trait and a u32 the Copy trait? I tried to learn it as a first language and it was hard until I started learning C, groking the stack the heap and pointers. I think all the tutorials out there are ill suited since they hide away so much. It's harder to remember stuff if you don't understand why it is that way, well at least it stands true for me. So I would love to see a Rust for beginners tutorial for C beginners. Maybe I'll write it someday. I really got discouraged when it got into the ugly lifetime syntax. But I will definitely come back to it. (Unless Zig shows to be just as safe and less verbose)
- ssokolow 6y ago
  Fair point. The Copy on u32 and lack of Copy on String is confusing until you've grasped that things containing heap allocations are ineligible for Copy, and that Copy is primarily intended for data types the same size as or smaller than a pointer.
kumarvvr 6y ago
A newbie question. As a seasoned C#, Python and JS programmer, what conceptual foundations in CS will make me use rust more effectively? Say I want to create a new database service, on top of Postgresql, using rust. Would the design of rust help me in a specific way? I want to learn and use rust, for systems programming, the kind where I build a high performance underlying system, called by other languages, but it always feels I need to learn quite a bit of theory to effectively use rust. I never felt the same with C# or python. A bit of OO stuff was usually enough to be productive with them.
rust_neutral 6y ago
There's a serious culture problem in the Rust community. Many have asked that a community focused on a programming language be a safe space from politics, but too many in positions of influence vehemently disagree. I feel like I have to be a member of the black bloc in order to fit in.

135 points by cyber1 6y ago

Coding in Rust isn't easy, but where it is hard it is hard in a good way. It is like being on a journey with a good friend, who deeply cares about not letting you shoot yourself into the foot and explains you why without judging you. Even if Rust would be wiped off the face of the earth tomorrow, thr things I learned from it have definitly made me a much better programmer.

logicchains 6y ago
>explains you why without judging you Yep, the compiler doesn't judge you, that role is left to the community when they discover you posted a library on Github that uses more unsafe code than they'd like.
- twic 6y ago
  It would be great if that feature could be moved into the compiler, though!
- uryga 6y ago
  for anyone not following Rust, the drama around the (popular) Actix web framework was a prominent instance of this. iirc people opened issues and PRs re: the project's (significant) usage of `unsafe`, but the maintainer (Nikolay Kim) wasn't receptive; then some folks got nasty about it on reddit, escalating into full-blown drama. sadly, it ended with Kim posting he's "done with open source" and quitting the project. a more detailed (and probably more accurate) account: [A sad day for Rust](https://words.steveklabnik.com/a-sad-day-for-rust https://words.steveklabnik.com/a-sad-day-for-rust)
  - chrismorgan 6y ago
    By no means is it only about Actix; that’s just one of the more notable times that something like that has happened. The eminently reasonable criticism boils down to baulking at people undermining Rust’s safety guarantees with demonstrably wrong unsafe code, while publishing said code in such a way that you’re suggesting that others use it (i.e. it’s not just private code). It is also then often taken further to a general unease at gratuitous use of unsafe code, which I consider fairly reasonable because it’s so hard to get right (it’s unsafe for a reason). Then sometimes a few people take it beyond what might be considered socially reasonable.
    - uryga 6y ago
      > [Actix] is just one of the more notable times that something like that has happened. edited my comment to reflect this, thanks i was trying to keep my summary relatively opinion-free – the internet probably doesn't need my take on that situation :)
    - Dowwie 6y ago
      It is a mistake to marginalize what a small number of people achieved. An organized team successfully "cancelled" the Actix project and smeared its author after repeated attempts-- three distinct episodes over 12 months. This was a campaign that spanned social media and github. It is worth noting that to this date, none of the members of the anti-actix effort have contributed towards a viable alternative, nor have they attempted to resolve their concerns in the actix ecosystem. It turns out that the patrons who complained about free beer never intended to brew their own.
      - chrismorgan 6y ago
        I never followed the matter closely, but from the parts that I did follow or investigate, your comment doesn’t feel particularly accurate. • I don’t believe there was any organised team; it arose organically. • In each case the complaints were of concrete problems that incorrect usage of unsafe caused. After that, people did then tend to pile on and baulk at other unsafe code that was probably OK, because the author had been proven untrustworthy in using unsafe code. (“Unsafe” says “trust me, it’s OK”, and that trust had been broken.) And there were one or two people that made it more direct personal attacks—but probably only one or two. • Your final paragraph just seems completely wrong. Various of those that complained did offer alternatives, some of which were turned down. And people did go with viable alternatives, switching to competitors to Actix. Even apart from all that, if you can prove that by some metric a piece of software is bad, why would the burden lie with you to fix it? (Especially if your patches are rejected.) If the problem won’t be fixed, recommending that others avoid it seems perfectly reasonable. You’re presenting a common logical fallacies, that you can’t criticise something unless you can provide an alternative. I don’t need to be able to build a better bridge to be able to point out that it’s falling down. Feel free to correct me if I’m wrong, but I intend to engage no further on this. The points have been hashed out before and there is nothing new to say; things just tend to get heated. Have an enjoyable day. :)
  - codeflo 6y ago
    For the most part, the Rust community seems to value safety and correctness above extracting the last bit of performance. Using “unsafe” code is seen as a necessary evil, only allowed when its use is hard to avoid, local and easy to understand. Mostly, you’re supposed to use unsafe code as the foundation which safer abstractions are built on top of. It’s a bit if an oversimplification to say that the Rust community complained about the amount of “unsafe” code in Actix. It was more about the how and why. From what I gather, the author didn’t accept patches that fixed safety/soundness bugs when they had even a small impact on performance. That’s a trade-off that one is allowed to make in my opinion (if clearly communicated, so that people can make informed decisions on whether to use a piece of code). I think this difference in values (or rather, engineering goals) explains in part why this escalated so badly. But a healthy software ecosystem should have room for libraries that make different trade-offs. Zealotry (in the form of “There’s one right way”) doesn’t encourage experimentation, and shrinks communities instead of growing them.
    - Dowwie 6y ago
      The soundness argument usually didn't carry water and was presented by people who were very much out of their depth (not that I was any more in-depth, but at least I stayed out of the way). The author and others addressed a lot of unnecessary unsafe, though. That which was left remained a sore point for those who demanded code purity. The author was a one-man army who took flak for way too long. Repeated requests to resolve non-issues blinded him to requests revealing actual concerns. It's analogous to the story of the boy who cried wolf. He was not respectful, but also had been fighting way too many battles for too long and consequently was all out of patience. It was a bad situation waiting to boil over.
  - ssokolow 6y ago
    Since I haven't seen anyone cover it from quite this perspective, here's how I saw what led to things blowing up like that: What really got people riled up was that... 1. Nikolay refused to acknowledge the principle (stated in the rustonomicon, IIRC) that a function which can violate memory safety when fed incorrect arguments must be marked `unsafe`, EVEN IF IT'S AN INTERNAL-ONLY API. (Increasing the bus factor with regard to maintainability is core to how Rust competes with C++.) 2. The Actix website gave the strong impression that it was a production-ready dependency, rather than an experiment in squeezing out maximum performance, and, unless you'd been present for the previous stink-raisings, it did appear to be a mature, safe option for writing code in Rust that would then be exposed to the public Internet for an entire world of potential attackers to hammer on. 3. This was the third time Nikolay had done something like this. So, to some people, it felt like Nikolay was actively and callously developing a PR timebomb for Rust and its ecosystem. I won't rule on how they chose to act, but that's my take on why they chose to act.
- izacus 6y ago
  Yup, I got called a jackass (sic) when I was asking why the most commonly recommended Rust crypto library doesn't support some of the older decryption algorithms which I needed to process some encrypted files. I got so many smug "you don't know what you're doing, it's insecure!" answers from people who clearly had no basic understand how security works. And I only asked for help, I didn't demand or try to accuse anyone of anything. And that's not the only case where Rust community was just permeated with certain arrogance which I've never really felt in any career as C++/Python/Java developer.
  - UK-Al05 6y ago
    I think I remember this. The problem was you we're insisting to add in an insecure encryption algorithm into the crypto library. They didn't want to because they didn't want to add an insecure algorithm to the library to encourage its use. The best bet is to use another library whose goals are different. This was explained a few times. Tbh I'm on the side of the library developers here. If you want to be the official encryption library, you probably want to avoid broken encryption algorithms. Leave the backwords compability encryption to other libaries, designed for the task.
    - izacus 6y ago
      I'm not sure how you could remember this since I wasn't insisting on anything like that and I wasn't even opening a ticket on any official bug tracker - I think you mistook me for someone else. I took extra care not to demand anything and the conversation was mostly on IRC and some specialized subreddits. Also not being able to decrypt data older than a few years with safe Rust libraries is a bit of a strange way to do security - if anything, Rust is perfect for parsing files in secure manner. My concrete use case was processing PDFs which tend to be signed with older certificate algorithms and the idea that being able to verify signatures on those files encourages insecurity is just strange. The only solution offered was to use OpenSSL via C bindings which (besides not compiling at all on Windows) is a security nightmare. In any case, I accept that library (and core language) developers can decide that Rust won't be a language that's usable for verifying and processing data formats that are older than couple of years. What I find it harder to accept is being personally insulted for having a use case that doesn't fit into community's perfect world. That didn't happen in any other communities in my career.

Skunkleton 6y ago

Also: almost everyone who uses rust does so by their own choice.

elsjaako 6y ago
This is mentioned in the article
pengaru 6y ago
I don't get this comment, rust is a new language that isn't widely embraced by employers yet. How would rust have a significant number of users forced to use it?
- power78 6y ago
  He means: another reason rust users love it so much is because they are not being forced to use it
- mcintyre1994 6y ago
  It’s discussed in the article but that quality kind of ‘games’ the metric SO are using - what % of people using it want to keep using it? If people were forced to use it for work then you’d likely see a lower number regardless how good it is just because it wouldn’t be every single person’s preference. It’s not a bad thing - a new language that doesn’t reach that point probably dies - but it does make it easier to score highly on their metric.
canofbars 6y ago
Also the same for Haskell so I would have expected to see that much higher.
tempodox 6y ago
Which makes it seem logical that the people who consistently use it do so because they love it. Point proven. Other than, say, JS for instance. If you want to make webware you just have to use it, regardless of whether you like it or not. Or C/C++ for embedded. There are efforts to bring more languages into that space but at the moment you'd be hard pressed if you wanted to use anything else.

smabie 6y ago

"In type checking, only the signature of functions are considered. There’s no relying on the implementation for determining if callers are correct (like you can do in Scala, or Haskell)" What does this mean?

twic 6y ago
You can know the exact parameter and return types of a function by reading its signature. You can't do that in Scala, because of type inherence. This is legal Scala: def twice(x: Int) = { x * 2 } But you can't know the return type without reading the function body. That example is not so bad. I routinely used to confront things like: def applyComputation(x: Int) = { determineComputation().compute(x) } And now you're off on an adventure to work out the return type. EDIT There's sort of a deviation from this with "impl trait" returns. There the signature says that the function returns some type which implements a certain trait, but you can't tell exactly what.
- jfim 6y ago
  It's been a while since I've written any Scala, but if I recall correctly it's frowned upon to use type inference for return values in method signatures.
  - twic 6y ago
    Yes, inference. My phone is very keen to use the word "inherence", which I didn't even know was a word. In Scala it's frowned on. In Rust it's not possible.
  - MrBuddyCasino 6y ago
    > it's frowned upon to use type inference for return values in method signatures The language shouldn't allow it in the first place. Its a symptom or not balancing power with complexity and shows up elsewhere in Scala. They "were so preoccupied with whether or not they could that they didn't stop to think if they should."
    - 6y ago

FlyingSnake 6y ago

Rust is a fantastic language, and once past the borrow checker level, it can be quite productive. One interesting compatriot of Rust is Swift, which also ticks most of the checks in that list. Also Swift has IMO a better development experience, due to Apple’s initiatives. I wonder what Rust developers think about swift.

asiachick 6y ago
From everything I've read Swift is still slow relative to Rush because it uses ARC and so there are increments and decrements of usage counts all over the place. To put it another way, Swift handles memory safety at runtime, Rust handles it at compile time? There is/was talk of trying to either do escape analysis or add some hints so the compiler can get rid of those checks but AFAIK that hasn't happened yet?
- zozbot234 6y ago
  Rust has Arc<> too, but it's optional. And it only increments and decrements wrt. Arc references that might affect when the object is dropped; it doesn't need to do so with references that are outlived by some existing Arc reference. I think this is what you're calling 'escape analysis' in your comment, but Rust does it statically and the 'hints' are ordinary Rust syntax.
- skohan 6y ago
  It's a bit more complex than "swift is slow". As you say, ARC can lead to some performance cliffs when using reference types (class), but Swift manages memory statically for value types (struct, enum). Modern idiomatic swift uses reference types quite sparingly, and Swift can be quite performant, but usually requires prolific use of profiling and optimization to get there. Best case performance for Rust will probably always be better, because even for statically managed types, Swift leans more heavily toward copying values where Rust tries to leave them in place whenever possible.
  - zozbot234 6y ago
    "ARC can lead to performance cliffs" is quite optimistic. Obligate reference counting ala Swift has even lower performance than obligate GC, at least wrt. throughput. It's pretty much a dead end in many ways.

ncmncm 6y ago

Money quote: "Rust benefits here that very few people are being forced to use Rust." Probably more people pick up C++ for the first time, in any given week, than the total who use Rust in production today. Rust also benefits from the limited historical baggage that comes with being new and incompatible. Unlike Java, which was in the same position, Rust adopted very few old mistakes, and especially unlike Java made few new ones. But as the language approaches industrial maturity (possibly within 10 years) early mistakes will become evident, and cruft will be seen to accumulate. Rust designers have consciously chosen to keep the language's abstraction capacity limited, which makes it more approachable, but reduces what is possible to express in libraries. Libraries possible, even easy in C++ cannot be coded in Rust. The language will adopt more new, powerful features as it matures, losing some of its approachability and coherence. But Rust has already passed a key milestone: there is little risk, anymore, that it could "jump the shark". The language is gunning for C++'s seat. Whether it becomes a viable alternative, industrially, is purely a numbers game: can it pick up users and uses fast enough? The libraries being coded in C++ today will never be callable from Rust. Go proved that the world will make room for a less capable language (in Go's case, than Java) if it is simpler. Rust is much more capable than C, Go, or Java, and the world would certainly be a better place if everybody coding those switched to Rust. So, my prediction is that Rust and C++ will coexist for decades. The most ambitious work will continue to be done in C++, but a growing number will have their first industrial coding experience in Rust instead of C, and many will find no reason to graduate to C++.

asiachick 6y ago
> That means libraries possible, even easy in C++ cannot be coded in Rust. Can you give some examples of libraries that can be made in C++ that can't in Rust and why they can't? Having never used Rust yet I'm curious what the issue is.
- deleted 6y ago
  [deleted]
- pjmlp 6y ago
  Imagine something like SwiftUI, including support for dragging components out of a toolbox, and having an eco-system of companies selling such components. https://www.componentsource.com/search/products?f%5B0%5D=at%3A914099&f%5B1%5D=et%3A919786&f%5B2%5D=et%3A919791&sort=bestseller https://www.componentsource.com/search/products?f%5B0%5D=at%... https://microsoft.github.io/microsoft-ui-xaml/ https://microsoft.github.io/microsoft-ui-xaml/ The borrow checker in its current state makes it very hard to build such tools.

moonchild 6y ago

I don't believe that rust solves the right problems in the right ways. This is specifically with respect to the single-owner raii/lifetime system; the rest of the language is imo pretty nice (aside from the error messages, which are an implementation problem). For starters, ATS[1] and f-star[2] both provide much stronger safety guarantees, so if you want the strongest possible guarantees that your low-level code is correct, you can't stop at rust. _____________________________________________ Beyond that, it's helpful to look at the bigger picture of what characteristics a program needs to have, and what characteristics a language can have to help facilitate that. I propose that there are broadly three program characteristics that are affected by a language's ownership/lifetime system: throughput, resource use, and ease of use/correctness. That is: how long does the code take to run, how much memory does it use, and how likely is it to do the right thing / how much work does it take to massage your code to be accepted by the compiler. This last is admittedly rather nebulous. It depends quite a lot on an individual's experience with a given language, as well as overall experience and attention to detail. Even leaving aside specific language experience, different individuals may rank different languages differently, simply due to different approaches and thinking styles. So I hope you will forgive my speaking a little bit generally and loosely about the topic of ease-of-use/correctness. The primary resource that programs need to manage is memory[3]. We have several strategies for managing memory: (Note: implicit/explicit below refers to whether something something is an explicit part of the type system, not an explicit part of user code.) - implicitly managed global heap, as with malloc/free in c - implicit stack-based raii with automatically freed memory, as in c++, or c with alloca (note: though this is not usually a general-purpose solution, it can be[4]. But more interestingly, it can be composed with other strategies.) - explicitly managed single-owner abstraction over the global heap and possible the stack, as in rust - explicit automatic reference counting as an abstraction over the global heap and possibly the stack, as in swift - implicit memory pools/regions - explicit automatic tracing garbage collector as an abstraction over the global heap, possibly the stack, possibly memory regions (as in a nursery gc), possible a compactor (as in a compacting gc). (Java) - custom allocators, which may have arbitrarily complicated designs, be arbitrarily composed, arbitrarily explicit, etc. Not possible to enumerate them all here. I mentioned before there are three attributes relevant to a memory management scheme. But there is a separate axis along which we have to consider each one: worst case vs average case. A tracing GC will usually have higher throughput than an automatic reference counter, but the automatic reference counter will usually have very consistent performance. On the other hand, an automatic reference counter is usually implemented on top of something like malloc. Garbage collectors generally need a bigger heap than malloc, but malloc has a pathological fragmentation problem which a compacting garbage collector is able to avoid. This comment is getting very long already, and comparing all of the above systems would be out of scope. But I'll make a few specific observations and field further arguments as they come: - Because of the fragmentation problem mentioned above, memory pools and special-purpose allocators will always outperform a malloc-based system both in resource usage and throughput (memory management is constant-time + better cache coherency) - Additionally, implicitly managed memory pools are usually easier to use than an implicitly managed global heap, because you don't have to think about the lifetime of each individual object. - Implicit malloc/free in c should generally perform similarly to an explicit single-owner system like rust's, because most of the allocation time is spent in malloc, and they have little (or no) runtime performance hit on top of that. The implicit system may have a slight edge because it has more flexible data structures; then again, the explicit single-owner system may have a slight edge because it has more opportunity to allocate locally defined objects directly on the stack if their ownership is not given away. But these are marginal gains either way. - Naïve reference counting will involve a significant performance hit compared to any of the above systems. However, there is a heavy caveat. Consider what happens if you take your single-owner verified code, remove all the lifetime annotations, and give it to a reference-counting compiler. Assuming it has access to all your source code (which is a reasonable assumption; the single-owner compiler has that), then if it performs even basic optimizations—this isn't a sufficiently smart compiler[5]-type case—it will elide all the reference counting overhead. Granted, most reference-counted code isn't written like this, but it means that reference counting isn't a performance dead end, and it's not difficult to squeeze your rc code to remove some of the rc overhead if you have to. - It's possible to have shared mutable references, but forbid sharing them across threads. - The flexibility gains from having shared mutable references are not trivial, and can significantly improve ease of use. - Correctness improvements from strictly defined lifetimes are a myth. Lifetimes aren't an inherent part of any algorithm, they're an artifact of the fact that computers have limited memory and need to reuse it. To summarize: - When maximum performance is needed, pools or special-purpose allocators will always beat single-owner systems. - For all other cases, the performance cap on reference counting is identical with single-owner systems, while the flexibility cap is much higher. _____________________________________________ 1. http://www.ats-lang.org/ http://www.ats-lang.org/ 2. https://fstar-lang.org/ https://fstar-lang.org/ 3. File handles and mutex locks also come up, but those require different strategies. Happy to talk about those too, but tl;dr file handles should be avoided where possible and refcounted where not; mutexes should also be avoided where possible, and be scoped where not. 4. https://degaz.io/blog/632020/post.html https://degaz.io/blog/632020/post.html 5. https://wiki.c2.com/?SufficientlySmartCompiler https://wiki.c2.com/?SufficientlySmartCompiler

nickm12 6y ago

I love this quote from a friend of mine who was learning Rust: "It's hard but I love it. Dealing with the compiler felt like being the novice in an old kung fu movie who spends day after day being tortured by his new master (rustc) for no apparent reason until one day it clicks and he realizes that he knows kung fu."

dgzl 6y ago
Reminds me of learning Vim
skohan 6y ago
Sometimes I wonder a key part of the appeal of Rust is that feeling of climbing the mountain. I've noticed that coming to a solution around the particular constraints of Rust can have a eureka feeling which is similar to how it felt applying a new concept successfully for the first time when I was first learning to program (e.g. recursion). I'm not always convinced the solution I come to is superior to what I would have done in a more traditional programming language, but it certainly feels rewarding to overcome challenge, and I would bet that's true of a lot of people, and that it's more motivating than the promise of performance and memory safety alone.
- deleted 6y ago
  [deleted]
- Dowwie 6y ago
  I've experienced that climber's high several times while working out problems with Rust during my first two years working with the language. It's a rewarding feeling. I couldn't climb without the community, either. There's so much to learn, especially when one chooses to learn while doing, but it can be done with help. I am convinced that the solutions I come with are superior to those I would write with Python, but the first time solving them may involve a costly investment of time and effort.
bjarneh 6y ago
That's an excellent quote; and 100% true based on my experience. The only language that I've struggled even more with is Prolog.

dirtydroog 6y ago

Never before has a programming language received so much marketing. It's very odd.

nickm12 6y ago
I take it you weren't programming when Java was the new hotness?
- HugoDaniel 6y ago
  or Ruby, or Haskell, or elixir... Rust so happens to appeal the front-end crowd as much as the backend people and they are leveraging those windows of opportunity much better than any other language or community. Wasm bindgen is a bliss of fresh air, it even works very well with TypeScript.
npiit 6y ago
I don't think that "marketing" is the right word for a FOSS project that is not affiliated with any for-profit entity and has no business strategy. Rust is truly loved by many who had the chance to work with it and that's why it's honestly promoted more than any other modern language.
eeZah7Ux 6y ago
People were following the hype and cargo-culting Java, XML, Visual Basic in similar ways. Yet I really feel that the echo chamber effect is stronger now. People seem to need something to be hyped and polarized about. Nuanced conversation becomes more difficult as the hyped crowd overwhelms any conversation.
- pjmlp 6y ago
  We were discussing VB and Java on early days of Web, places like Compserve, BBSs or plain magazines reader letters.

turbinerneiter 6y ago

It feels like being part of a village that learns to love the dragon it battles.

deleted 6y ago
[deleted]

andi999 6y ago

Also the same reason why ppl love c++: Stockholm syndrom.

FlyingSnake 6y ago
Most of the people who use rust, do so on their own volition. I don’t see anyone being held hostage to rust due to corporate policies.
nindalf 6y ago
86.1% of people using Rust love it. For C++ it's 43.4%. [1] You'd have to explain the disparity in the two numbers if you think they're loved for the same reason. Further, Rust is mostly used by people who choose to do so. There are very few people out there forced into maintaining shitty, legacy codebases in Rust because there aren't very many such code bases ... yet. [1] - https://insights.stackoverflow.com/survey/2020#technology-most-loved-dreaded-and-wanted-languages-loved https://insights.stackoverflow.com/survey/2020#technology-mo...
- andi999 6y ago
  Interesting study. Of course you are right. But this study poses the question: are ppm forced to work in julia?
- drewcoo 6y ago
  "It occurs when hostages or abuse victims bond with their captors or abusers." [1] The stories speak of abuse and an unwillingness to leave. This does not detail how they came to be abused or captives. I'm not saying they were asking for it, dressed that way, but maybe these Rust victims' behavior led them to entrapment. That doesn't mean it's not real. This seems a lot like Stockholm syndrome. [1} https://www.healthline.com/health/mental-health/stockholm-syndrome#definition https://www.healthline.com/health/mental-health/stockholm-sy...
mD5pPxMcS6fVWKE 6y ago
It's just a matter of age .... I remember back in 1990 99% of C++ users loved it, as it was kool.

devit 6y ago

It's the only production-ready language that is both memory safe and has zero-cost abstractions (i.e. for any C code you have Rust code that compiles to equivalent assembly, and using more abstractions in Rust does not make the assembly less efficient unless the abstraction can't be implemented otherwise). Also as long as you accept not having dependent types (at least for the short and mid-term) and several currently unimplemented features, Rust is the optimal way a programming language can be designed other than assorted minor warts.

Dowwie 6y ago
Batteries are very much already included. The missing features you are referring to are likely not show stoppers.

orthoxerox 6y ago

It's a niche language that dominates its niche. I wouldn't write a LoB application in Rust, for example. But if I wrote programs with really tight speed and memory requirements for a living, I would pick Rust for the task. If people were forced to write their website backends in Rust (or even their frontends in Rust targeting WASM) they would hate it. Its performance is overkill for 99.9% of backends, but the means of getting this performance kill your productivity.

majewsky 6y ago
My current side project has a frontend in Rust via WASM, and I love it. Way better than the huge mess that is the JS ecosystem.
- Dowwie 6y ago
  Rust WASM is still very bleeding edge. Let's not give anyone the false impression about what anyone can manage to build today.
Dowwie 6y ago
I've been using Rust for backend web dev and networked services for the last two years. I'm working on the greatest project of my life (until my next project) and Rust is really helping me along. The performance and resource efficiencies are great side effects. I don't understand the argument that performance benefits are overkill for web development. Obviously, no one needs to use a flamethrower to light a cigarette. However, a fully-fleshed web server is a very complex system that taxes performance with all that it does. I'm working on a greenfield project and had discretion over what tooling to use. I decided to invest in Rust, eating short-term productivity losses in exchange for long-term gains. Those gains are realized at many points in development, compounding over time. As team members are brought into this project, I will accept a simple "thank you" for bringing joy to their work and renewing their aspirations for creating better products. Web dev doesn't have to be so shitty an experience, but it requires investment. That's a tough sell for managers who aren't coders, but those who rose from engineering understand its importance.
6y ago

robotmay 6y ago

I've been casually playing with Rust for a few years now. Wrote a few small things in my previous job that still run a large part of their business, which is pretty satisfying, but only very recently have I found a couple of hobby projects where it just feels like the right tool for the job (for me). Web stuff I'd still much rather write in Ruby, if I'm honest, but for playing around on systems Rust is super fun. I ended up making https://git.sr.ht/~robotmay/amdgpu-fancontrol https://git.sr.ht/~robotmay/amdgpu-fancontrol, of which there's already an equivalent in Python, but the lack of dependencies when installing a piece of Rust software makes it feel very portable and neat. My favourite metaphor for Rust is that it's like a friendly bare-knuckle fist-fight with the compiler. It's not as user-friendly as, say, Elm, but it's streets ahead of Haskell's errors.

slowwriter 6y ago
Can I just say, I really appreciate the Community reference Edit: Btw, if you have to ask what I mean you’re streets behind

lbj 6y ago

Where's a good place to start with Rust? Which domains is it particularly good in ?

cassepipe 6y ago

Rust is great but it could gain from explaining itself with memory and pointers or else why a String has the Clone trait and a u32 the Copy trait? I tried to learn it as a first language and it was hard until I started learning C, groking the stack the heap and pointers. I think all the tutorials out there are ill suited since they hide away so much. It's harder to remember stuff if you don't understand why it is that way, well at least it stands true for me. So I would love to see a Rust for beginners tutorial for C beginners. Maybe I'll write it someday. I really got discouraged when it got into the ugly lifetime syntax. But I will definitely come back to it. (Unless Zig shows to be just as safe and less verbose)

ssokolow 6y ago
Fair point. The Copy on u32 and lack of Copy on String is confusing until you've grasped that things containing heap allocations are ineligible for Copy, and that Copy is primarily intended for data types the same size as or smaller than a pointer.

kumarvvr 6y ago

A newbie question. As a seasoned C#, Python and JS programmer, what conceptual foundations in CS will make me use rust more effectively? Say I want to create a new database service, on top of Postgresql, using rust. Would the design of rust help me in a specific way? I want to learn and use rust, for systems programming, the kind where I build a high performance underlying system, called by other languages, but it always feels I need to learn quite a bit of theory to effectively use rust. I never felt the same with C# or python. A bit of OO stuff was usually enough to be productive with them.

rust_neutral 6y ago

There's a serious culture problem in the Rust community. Many have asked that a community focused on a programming language be a safe space from politics, but too many in positions of influence vehemently disagree. I feel like I have to be a member of the black bloc in order to fit in.