All things Rust.

Rust general, share resources, PDFs and experiences with the language.

A few months ago I started implementing pong using sdl in rust (just for the heck of it). It is a really interesting language, but it required me to really change my way of programming (I've been using mostly C++ before), for two reasons: 1) Rust is an expression-oriented language, something that was new to me. 2) Rust really forces you to think about what you develop, there is no way of doing things "quick and dirty". If you want to get into rust, expect to need a lot of time to learn it. It is the complete opposite of a easy-to-learn language like python, which can be picked up on the go.

I have to say that the Rust standard library is really well designed. It's streamlined and makes everyday tasks very easy to do, and it has the best iterator class I've ever seen. Pipelines of iterator adapters lead to some very expressive one-liners by chaining standard library functions and a few lambdas. This is in stark comparison to C++ which arguably has one of the worst standard libraries that I've ever encountered in a high-level language. In C++ I often find myself writing my own functions for really basic stuff, either because the standard library doesn't include it, or because the way the standard library does it is horribly bad or unsafe. Which often ends up leading to Boost and all the issues that come with that.

>>592 Also I don't want to come off as fanboyish or as a C++ hater with that comment. The C++ library ecosystem is great and has a lot of stuff that I couldn't find elsewhere. I just hate the standard library with a passion because of how often it ends up being utterly useless for what I want to do.

>>592 This may be true but the few Rust libraries I've seen that aren't standard libraries have felt really immature. The ralloc library was naively designed an inefficient. The piston library is overly abstracted, badly documented, and confusing (multiple types and functions with the same exact name, and subtle differences; types whos name do not reflect very well their purpose). Also some libraries do not care about compatibility and insist on staying in beta forever. These experiences have turned me off of Rust. What do you think?

I think the main concept in Rust is the concept of borrowing and ownership to replace garbage collection. People say its a very good system of expliciting defining how data is allocated/deallocated in memory that improves how you think about code. I'm having trouble getting the big picture on how Rust works, I have noticed that Pluralsight has a beginner video course on Rust which might be good.

>>592 I find C++'s libs much nicer than java's. Streams are the only nice thing in java IMO and it misses a lot of things that would be useful like a pair class for example. I also find iterators nicer in C++ but if you use streams in java I guess that wins out.

It's nice, but I don't see the appeal. It doesn't fill any hole of mine that would need filling at the moment.

>>608 >Pluralsight Are you for real? Why the hell would you recommend that out of the myriad of FREE resources available elsewhere? Get out of here. You are advertising.(OBSERVE RULES THREE AND FOUR)

>>687 If everyone used free resources than no one would bother to write and publish books. Notice we have a book thread on this forum...gee, I wonder why people still read published books when they could just use all the crappy free online tutorials? Well maybe people are not living in mom's basement like you and actually have to learn this stuff for school and work. Also video courses on Lynda and Pluralight can often be a faster and easier way of learning than books. So leave your stupid opinions to yourself, there are people here who are actually trying to get work done.(OBSERVE RULES THREE, FOUR, AND FIVE)

>>696 Well I actually bought one of the books on that thread after flipping through the PDF and deciding I definitely wanted that baby on paper. You can tell your employers they are wasting their money paying you to advertise in here. Cheers.

>>685 I'd rather have tuples built into the language though, which can also be used for multiple assignment like in Python.

So can someone recommend a good book for learning Rust instead of just arguing about whether or not books are worth reading?

>>991 The new version of the rust book is pretty good. It's under development but surely it has more than enough material for you to get started. http://rust-lang.github.io/book/second-edition/index.html

Anyone knows if there is some formal proof that Rust is really memory safe?

>>1120 The closest thing I know of is attached.

I've been reading about Rust and tinkering with it a bit and I really like it. Usually I'm against very constraining languages but it's really clean and lightweight, while still offering the possibility to muck about with unsafe blocks. I am a bit perplexed at how it handles generics, though. If I have a generic function, why are the generic types in scope only in the signature and not in the whole body like, say, Java does? It feels very counterintuitive. (also I've been trying to pass as an argument a function/closure with generics and it's being a very wild ride so far)

>>1120 >Anyone knows if there is some formal proof that Rust is really memory safe? Rejoice, this is what the RustBelt project is about: http://plv.mpi-sws.org/rustbelt/ They even have open PhD and postdoc positions if you're in the market for that!

I've been having so much fun with Rust. After using C++ for a while it feels really refreshing to be using a language that it doesn't feel like such a stretch to be calling "modern".

What are the best resources to learn Rust right now? I'd especially love some sort of book with exercises to go along with it (that has worked best for me in the past) but can't really find anything along those lines.

>>4163 How about https://rustbyexample.com/ ?

I love rust, but I really, really wish that impl trait gets merged with the stable branch as soon as possible. Rust types can get long enough that some additional level of type inference is required imho.

>>4570 Wait, impl trait is still nightly? It's becoming the Rust equivalent of C++ concepts, isn't it? It has been a requested feature almost since the language was born, but stuck in a permanent experimental limbo.

When I last looked at rust(maybe a year ago) it seemed like the standard library was poorly documented and everything seemed kind of unstable. Maybe when they get to the next major version I'll start investing more time to getting good at it. I'd really like to use it for low-level devevlopment, rather than the clusterfuck that is C.

So popular convention on the other chan /g/ is to soykaf all over rust What are some reasons to use rust? What do you all think? I'm curious about it but its low opinion makes me think Whats Rust used for? Anyone in industry do it

>>4676 > Industry example? Yes. High throughput networked IO in a backend engine, amongst examples I know of. The concurrency features are used. Also, what's wrong with Rust? Slow standardization? Well yes, that's been a problem. But anyone complaining about static typing should rightly then complain about Haskell, OCaml and basically every other language with a decent type system.

>>4673 >>4673 How hard is Rust to learn? I know some Python,R, C , bit of Common Lisp Never programmed in a functional way( at least, not knowingly)

>>4672 The reason /g/ soykafs on Rust is politics. The reason everybody else loves Rust is because it's a great piece of technology. In my opinion using politics in order to judge software is stupid but your opinion might differ. >Anyone in industry do it Mozilla of course uses it for its web browser. Dropbox uses it for a few components of its distributed filesystem I believe. Google has started looking into if for its Fushia operating system and one of its chrome codec I think but I could be wrong. A Mozilla employee I discussed with told me that Facebook was also interested in Rust but I don't have proof. >>4674 Despite its reputation Rust is really easy to get into thanks to its compiler, its error messages are among the most helpful I've ever seen. Given how you already know C I think you won't have too much of a hard time learning Rust.

>>4675 What are Rust's politics? Is it just that its makers have shown support for one side of the political debate

>>4676 I think the fact that you are aware of all the soykaf people say about Rust on /g/ yet you need someone here to explain it to you is that you laying out cheap bait bring that idiotic soykaf flinging here. If you really need someone to explain to you why Rust gets soykaf on at /g/ then go to /g/

>>4679 I'm sorry to offend but I've never read a real reason, just "Rust is like kicking dead whales down the beach" and an argument breaks out and then some Rust user refutes the technical negative points that the aggressor make up about Rust

>>4675 >The reason /g/ soykafs on Rust is politics. I don't know anything about /g/ or political Rust critics. But I did see this blog post a while ago which smelt wrong to me. https://blog.rust-lang.org/2017/06/27/Increasing-Rusts-Reach.html >We’re looking for people inside and outside Rust’s current community from groups and backgrounds that are underrepresented in the Rust world and the technology world more generally. We want to partner with you to make Rust a more inclusive, approachable and impactful project, while supporting your success on personal goals. ... >Some groups that are underrepresented in technology and in the Rust community that we would especially love insights from include women (cis & trans), nonbinary folks, people of color, non-native English speakers, people who learned programming later in life (older, or only in college, or at a bootcamp as part of a midlife career change), people with disabilities, or people who have different learning styles. But this kind of dubious new-age "equality" ideology is infecting everything on the internet, not just Rust.

One aspect of Rust that I find really interesting is that because the type system prohibits aliased references, it is significantly easier to formally verify than say, general C. You can transform a large class of Rust programs into pure functional ones quite straightforwardly. So there are some nice projects for formally verifying Rust: https://kha.github.io/2016/07/22/formally-verifying-rusts-binary-search.html

>>1309 There's a new paper on verifying Rust's safe vs unsafe semantics due to appear in January, here's a preprint: https://people.mpi-sws.org/~dreyer/papers/rustbelt/paper.pdf

>>4803 Key points: The core language itself is safe, assuming no unsafe blocks or panics. Libraries including Cell,RefCell,Mutex,RwLock,Rc,and Arc that internally use unsafe blocks are safe to use, assuming they obey a given formal specification, which may or may not be broken by optimizations present in the given libraries which may change over time.

>>4804 >> assuming no unsafe blocks or panics. Also no dynamically dispatching trait objects.

I wrote a circular linked list with Rust to get a feel for unsafe: https://play.rust-lang.org/?gist=daea03fac21c6134f96a899e1991d623&version=stable I found it to be quite nice to work with actually. Exposing a safe interface to an unsafe construct is actually surprisingly simple to do. The type system naturally restricts the interfaces you can expose if you don't take in or return raw pointers from public functions.

>Although no current Rust manual dares putting it so bluntly, Rust is a functional language, inspired from recent advances in programming language design. http://science.raphael.poss.name/rust-for-functional-programmers.html What do you anons think about this article? Speaking as someone who doesn't know Haskell yet, the article does seem persuasive. A lot of the "functional" features of Rust are very, very attractive to me compared to the clusterfuck that is c++. They just make sense. That said, most idiomatic Rust I've seen does not look as alien as idiomatic Haskell, making me think that most Rust isn't written in a really functional way.

>>5199 It's "functional" like Haskell in the sense that shared mutable state is a compiler error and that it has a highly sophisticated type system along with pattern matching. That is, it kept the functional features that help with safety. Idiomatic Rust code is often referentially transparent almost everywhere which makes it fairly easy to reason about most Rust programs. It does however use loops when they make sense, and it does not empathize recursion at all. Also, higher order functions and closures work, but they are not as easy to use as in Haskell since you don't have a garbage collector. You have to consider ownership when using them (sort of like like C++ lambdas but a bit nicer). If you are using C++, then yes, Rust is way, way, way saner. Even if you ignore the functional-ish parts and just consider memory safety, or the "functions are pass by move by default with use after move being a compiler error, unless the type is explicitly declared copyable" bit that means that you never have to worry about accidental deep copies. Or the fact that you don't have to decide whether your destructor should be virtual or not, because the compiler will always infer that correctly for you. Or const correctness by default Rust is the smaller saner language that is struggling to get out of C++ imho. It's a new language that breaks legacy with old C++ code, but that would be true of any attempt to truly fix C++. Once you've truly grokked it, going back to C++ is hard and you find yourself thinking in Rust idioms while writing it.

>>5202 Relevant picture.

>>305 > 2) Rust really forces you to think about what you develop, there is no way of doing things "quick and dirty". This so very much. For each function you have to think whether it will consume it's arguments or not, whether you will only access them or you will need to modify it. One thing missing in my opinion is the ability to implement methods for an aliased type, but I guess the type system is not mature enough for it.

>>4570 >>4584 Honestly, nightly is a lot more stable than people realize. While you wouldn't want to use it for production-critical software, it's stable enough for just about anything hobbyist. If there's a major issue, then worse-case you just revert to the previous nights version and work from there.

>>305 >there is no way of doing things "quick and dirty" Where is the fun in that? I'd rather use a language that lets me do things "quick and dirty" and deal with seg faults if it arises

>>5354 >Where is the fun in that? I'd rather use a language that lets me do things "quick and dirty" and deal with seg faults if it arises And I'm sure contractors would rather use plastic straws instead of concrete and "deal" with collapsed buildings when it arises. It's funny how this negligent attitude is literally criminal in every part of society except software.

Since good quality learning material for Rust is very hard to come by, I think this in-progress tutorial series will be of interest for people trying to get their head around Rust: https://www.youtube.com/watch?v=EYqceb2AnkU&list=PLJbE2Yu2zumDF6BX6_RdPisRVHgzV02NW

>>5356 >It's funny how this negligent attitude is literally criminal in every part of society except software. I'm willing to bet there are liability laws in place when the software in question deals with medical and life-critical hardware. Sometimes using plastic straws is fun. Not everything is corporate programming. That said, the other guy's point is not exactly valid. You can slap code together in Rust once you get used to its idioms, even if by default it is more constraining than, say, C. By design. I personally use Python or Node for quick and dirty stuff, C for when I want to feel snugly, and if I wanted to write something more robust without having to bother making it so, I'd probably go with Rust. But both fanboys and haters need to realize Rust is not going to replace anything. It will find its place, like every other language has done, and that's it. Everything else are fantasies.

>>5815 >I'm willing to bet there are liability laws in place when the software in question deals with medical and life-critical hardware. Yeah, and guess what languages they use not C Meanwhile, every other part of the software industry use unsafe languages with bare minimum effort because they know that whenever there is a data breach or ddos or some other consequences it will always be someone else's problem.

>>5817 Don't be so bitter about it. Bugs get fixed eventually.

>>5817 Actually C is used extensively in life critical software for good reason, and it is often the only viable option that meets the safety requirements. But in those cases it's not just C, it's C + frama-C + formal specifications + static analyzers. Often the C isn't even written by hand but written by a tool that guarentees that the generated code satisfies some guarentees, etc. C + ecosystem can definitely be used to produce much safer code than Rust + ecosystem can currently do, at the expense of being much slower to develop in than Rust and requiring a much more difficult learning curve to get started. If Rust can get some equivalent of Frama-C, then it would probably be a better option since it is much more expressive.

>>3037 >why are the generic types in scope only in the signature and not in the whole body? What do you mean? Something like e.g. https://play.rust-lang.org/?gist=be9654e8ec84e1d006ede02b21ad1043&version=stable works just fine (the variable _b is in the body of the function, and is typed with a generic type). Passing a closure with generics can be done like so https://play.rust-lang.org/?gist=11734f3152428ac45d780cb23f651df6&version=stable

>>4676 Rust is developed by Mozilla, and so the communities around the language tend to have the same kind of culture that Mozilla itself does. Mozilla's CEO has made public donations for liberal causes ( https://www.huffingtonpost.com/2014/03/27/mozilla-ceo-prop-8-_n_5042660.html ), they have various women's outreach programs ( https://mozilla.github.io/womenandweb/ ), they've gone after employees for posts made online ( https://motherboard.vice.com/en_us/article/ae3xq5/mozilla-ceo-does-not-tolerate-online-harassment ), and so on. Their views as a company that they aren't afraid to express are in general liberal, pro-women, pro-trans, and in favor of moderation (as opposed to liberty). You can see this expressed within the rust community, for example, in the official code of conduct ( https://www.rust-lang.org/en-US/conduct.html ) and that many projects and communities dedicated to rust have similar documents. Their community is less tolerant of what they view to be "hate speech" or "harassment" than perhaps many other programming communities, and from my personal experience, the rust community has more women and trans people than other online communities. None of this is reflected in the language or documentation itself, however. You could use it your whole life without ever knowing it. This kind of dog-whistle/virtue-signaling politics is the way that a lot of people judge technology, because they are too soft in the head to use the technology for themselves to determine what they like and don't like.

>>5832 you keep posting this over and over...you know youre the only one who cares about SJW memes connected to programming languages, right?

>>5835 Honestly I hate Mozilla because of their political and SJW soykaf and I don't give them a penny when they ask "notice us we do soykaf...". Also I don't give a flying fuarrrk as long as programming language serves it's purpose or goal, I am going to use it.

>>5827 >Actually C is used extensively in life critical software for good reason, and it is often the only viable option that meets the safety requirements. Actually C is the least safe language imaginable. You probably mean latency requirements but that's not true either. There is far more Ada code flying around the sky and in space than C code. >But in those cases it's not just C, it's C + frama-C + formal specifications + static analyzers. >frama-C You don't actually work in this industry, do you? >Often the C isn't even written by hand but written by a tool that guarentees that the generated code satisfies some guarentees, etc. I wouldn't say "often" but there are cool projects like Ivory for generating high performance C from a higher level language. But in that case you are writing Haskell not C. This obviously doesn't count as "using" the language you are transpiling to. >C + ecosystem can definitely be used to produce much safer code than Rust + ecosystem can currently do, Citation needed. >If Rust can get some equivalent of Frama-C http://plv.mpi-sws.org/rustbelt/#project

>>5848 Ive met several guys who worked as programmers on weapons systems back in the 80s. The reason Ada kept getting ignored even though the department of defence manadated that Ada be the standard systems language was simply because Ada was too big a language to run on hardware back then. Imagine trying to make a usable Ada program on an Apple II (with 2mhz processor and 4k RAM). In order to sell systems to the military those systems have to run fast and do a lot of work. C continues to be used because thats what everyone has been using for all these years. C is an easy language to learn that puts on restraints on anything so allows a lot of cheap hacks to push through any design road blocks. Only critical systems like flight controls and missle systems have to be programmed in Ada.

>>5848 >C + ecosystem can definitely be used to produce much safer code than Rust + ecosystem can currently do, Citation needed. >If Rust can get some equivalent of Frama-C http://plv.mpi-sws.org/rustbelt/#project ... Rustbelt does not do what Frama-C does. Rustbelt is a completely different project with completely different aims, it's mainly about proving the memory and threading safety guarentees that the borrow checker is supposed to give you. Frama C lets you write things like this: https://ulissesaraujo.wordpress.com/2011/02/12/correct-sorting-with-frama-c-and-some-thoughts-on-formal-methdos/ i.e. it lets you also prove things that are completely orthogonal to memory safety, such as correct output, and termination in a set number of steps. It gives you much stronger guarentees than Rust. The issue is that C is so low level that formally checking a C program is incredibly time-consuming to do. But it still does get done to a large extent in the big expensive projects. Rust is simply not mature enough for that niche, it doesn't even have a formally checked compiler, to write real-time code on it you basically have to disable all compiler optimizations to get consistent timings. Rust does have the potential to be much better than C in the future though, since formal checking becomes much nicer when you don't constantly have to verify code involving raw pointers. Rust lets you avoid those for the most part and is much better at writing modular code. It also might get Pi-types and various HOL-based tools in the future as an extension of the const generics that are just about to make it to nightly. Give it five to ten years to mature, and I think it'll become a very viable option for DoD projects.

>>5859 >It gives you much stronger guarentees than Rust. You are comparing apples and oranges (formal verification vs a programming language, not programming language vs programming language). Where do you get this idea that Rust cannot be formally verified? It is not true. https://kha.github.io/2016/07/22/formally-verifying-rusts-binary-search.html > to write real-time code on it you basically have to disable all compiler optimizations to get consistent timings. Dubious. It think this needs citation as well. >Give it five to ten years to mature, and I think it'll become a very viable option for DoD projects. The DoD has already been using Ada for the past 30 years, they don't care about Rust. It's the rest of the world that Rust wants to influence.

>>5871 >>You are comparing apples and oranges (formal verification vs a programming language >>5827 >> But in those cases it's not just C, it's C + frama-C + formal specifications + static analyzers. This is exactly what I said. The issue isn't the Rust language itself, since it is very obviously better than a portable assembly language like C. It's about the ecosystem around the language. Rust is still young and lacks both tools and libraries for many tasks. However, it has a lot of momentum and I think it will eventually become a very viable option. It's also much easier to pick up than C + static analyzer ecosystem. >> Where do you get this idea that Rust cannot be formally verified? It is not true. https://kha.github.io/2016/07/22/formally-verifying-rusts-binary-search.html There are some projects for verifying Rust code that are starting to pop up, but they are very immature. Formally verifying a binary search shouldn't have to take two weeks and a thesis as was mentioned in your link. See >>5737 for a formally verified binary search in spec# (code + proof). In Frama C or Ada Spark it's something you pump out in an hour at most.

>>5881 >C is safer than Rust because C has frama-C and Rust has no formal verification frameworks yet Is that the gist of it?

>>5889 Yep. Give Rust a few years and it'll catch up. I'm hyped for the day when it happens.

>>5890 That's fuarrrking retarded. If you needed formally verified code you wouldn't use C or Rust.

>>5894 If I needed formally verified code that also has to satisfy real-time requirements (and where the real-time certification is part of the formal spec), I definitely would be using formally verified C or Ada + Spark, or possibly Rust by the time it matures. The first two are literally the most common forms of verified code in actual applications. The main alternative would be a safe DSL that generates verified C code.

>>5905 >I definitely would be using formally verified C or Ada + Spark, or possibly Rust by the time it matures The point of >>5894 is that spark is specifically designed for real time + formal verification and C absolutely isn't. The amount of code that actually gets formally verified is vanishingly small in the grand scheme of things anyway since it is expensive and far from perfect. Saying C is safer than Rust because formal verification is like saying chickens are faster than penguins because flying. The guarantees made by the Rust compiler are far more significant to writing safe code than what can be achieved with C + static analysis.

One thing I like with Rust as opposed to C++ is that it makes it harder to write slow code. The features that most commonly cause C++ code to be slower than C are not Rust features, and Rust is much better at steering programmers towards actual zero cost abstraction. The main downside of Rust imho is costly allocations compared to a language with a compacting generational GC, and the fact that it makes it harder to implement general graphs of components. On the other hand, avoiding GC and enforcing strict ownership means that Rust programs are very deterministic, arguably even more so than C++ programs, since C++ programmers are more likely to start using shared_ptr earlier due to ownership being harder to track.

I completed the first two exercises of chapter 8 in TRPL. Below is my solution. It's not a pretty solution and it uses too much unwrap(). Do you have any suggestions for improvement? rust use std::collections::HashMap; fn main() { let integers = vec![53, 32, 122, 35, 12, 57, 35, 1, 34, 75, 43, 4, 4, 4, 4, 87, 72, 41, 36, 7, 73, 1, 1, 5, 12, 5, 5, 3, 1, 34, 34, 54, 12, 75, 12, 5, 8, 2, 3]; println!("### Integers ###"); println!("mean: {}; median: {}; mode: {:?}\n", mean(&integers), median(&integers), mode(&integers)); println!("### Pig Latin ###"); pig_latin("Apple"); pig_latin("word"); pig_latin("earth"); pig_latin("Zzz"); } fn mean(list: &[u32]) -> u32 { let sum: u32 = list.iter().sum(); let count = list.len(); sum / count as u32 } fn median(list: &[u32]) -> u32 { let mut list = list.to_vec(); list.sort(); list.dedup(); let median = list.get(list.len()/2).unwrap(); *median } fn mode(list: &[u32]) -> Vec<u32> { let mut mode = Vec::new(); let mut freqs: HashMap<u32, u32> = HashMap::new(); for i in list { *(freqs.entry(*i).or_insert(0)) += 1; } for (k, v) in freqs.iter() { if v == freqs.values().max().unwrap() { mode.push(k.clone()) } } mode } fn is_vowel(c: char) -> bool { match c.to_lowercase().next().unwrap() { 'a' => true, 'e' => true, 'i' => true, 'o' => true, 'u' => true, _ => false } } fn pig_latin(word: &str) { let first = word.chars().nth(0).unwrap(); if is_vowel(first) { println!("{}-ay", &word[..]); } else { println!("{}-{}ay", &word[1..], first); } })

https://blog.rust-lang.org/2018/03/12/roadmap.html Just wanted to let you guys know (specially if you are someone new wanting to learn something about Rust) that there is a "new major version" in the works. The blog talks about the new major changes and improvements.

https://blog.rust-lang.org/2018/05/10/Rust-1.26.html Rust has impl trait and a bunch of other stuff now.

>>8357 Rust should have significantly less boilerplate now, it's about time!

Rust 2018 has been released. Rust allows significantly more code now since it added non-lexical lifetimes.

Is this thread dead or what? Rust has changed quite a bit since it got started.

most of the language specific threads around chan boards are stagnant, add to that the complexity and broad nature of a language like Rust (or C++ or Haskell...) and it shouldn't be surprising how slow such threads are.

I'm new to rust and want to re-implement a project I did in another language, but add more unit tests and things like that. I'm a bit confused as to why this isn't working: type TagIndex = usize; struct Tag { tag: String, original_name: String, updated_name: String, directory: String, } // Implementation block. All "Tag" methods go in here. impl Tag { // Static Method. fn contains_tag(_tag_string: String) -> (TagIndex, TagIndex) { return (0,0); } } #[cfg(test)] pub mod tests { #[test] fn contains_tag_unimplemented() { assert_eq!(Tag::contains_tag(""), (0,0)); } } When I try running the tests, with cargo test , I get an error saying that the compiler doesn't know about the type/module "Tag", even though I declare it at the beginning of the file. I've been messing around and looking online, but I haven't been able to fix anything. Any thoughts?

>>12384 It's because your tests are in a different module. Put use super::*; after pub mod tests {.

>>12384 I fixed it 
use std::borrow::{Borrow, Cow}; type TagIndex = usize; #[derive(Clone, Debug, Eq, Hash, Ord, PartialEq, PartialOrd)] struct Tag<'tag, 'original_name, 'updated_name, 'directory> { tag: Cow<'tag, str>, original_name: Cow<'original_name, str>, updated_name: Cow<'updated_name, str>, directory: Cow<'directory, str> } impl Tag<'_, '_, '_, '_> { fn contains_tag<S>(_tag_string: S) -> (TagIndex, TagIndex) where S: Borrow<str> { (0, 0) } } #[cfg(test)] pub mod tests { use super::*; #[test] fn contains_tag_unimplemented() { assert_eq!(Tag::contains_tag(""), (0, 0)); } }

>>12410 Oh wow. Is that what idiomatic Rust looks like? It's kind of a lot, but I'd be lying if I said I didn't like it. Guess I still have to do my due diligence before I climb the Rusty mountain. Thank you!

>>12438 Not really. He should be using an &'whatever str instead of Cow, although I'm not exactly sure what he's trying to do. Either way, normal rust code usually does not use Cow<str>.

>>12438 keeping str's in structs is weird, usually I'd use String there

>>10 Not too familiar with Rust's "borrow checker" but I have read that it tends to not like linked structures such as doubly-linked lists (since it's not clear what owns what). If this is the case, how would one implement a Trie / Prefix Tree? I'm asking because I'm hoping to create a Trie that maps from a key-press (interpreted as an integer, since I'm using ncurses) to a function, which would make it very easy to support multiple-key keybindings. I know creating a Trie is possible, since there are several trie packages in Cargo, but I just want to know how to implement one without struggling with the borrow-checker.

>>12843 Aren't trie's singly linked? As long as there's no circular references, it'll be fine. Otherwise, just use unsafe. Unsafe simply allows raw pointers. It still does type checking and borrow checking and all that good stuff.

>>12566 The advantage of Cow<str> over &str is that Cow<str> can hold &str and String both. >>12568 >doing a heap allocation when it isn't necessary go back to Java >>12843 >but I have read that it tends to not like linked structures such as doubly-linked lists (since it's not clear what owns what). The problem with doubly linked list is that a Node can have multiple owners. This isn't possible in safe Rust. https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html >Ownership Rules >First, let’s take a look at the ownership rules. Keep these rules in mind as we work through the examples that illustrate them: >Each value in Rust has a variable that’s called its owner. >There can only be one owner at a time. >When the owner goes out of scope, the value will be dropped. >I'm asking because I'm hoping to create a Trie that maps from a key-press (interpreted as an integer, since I'm using ncurses) to a function Just use a map then. https://doc.rust-lang.org/std/collections/index.html

>>10 Rust is not a good C replacement https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-replacement.html This basically sums up my experience with rust. Not the points he makes specifically, but the motivation for the critique and reaction the critique received 1) hear "rewrite it in rust" until you're sick of it 2) explain why you won't be doing that 3) toxic rust weenies come out of the woodwork, ignore why 2) happened, and begin flinging poo, because they are so insecure about their pet language

>>13004 >Safety. Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows. https://github.com/swaywm/sway/issues?utf8=%E2%9C%93&q=is%3Aissue+segfault lol

>>13026 >bugs are directly proportional to lines of code written >there are very few rust bugs see, even when you try to insult others, you just make yourselves look worse

>>13029 Who are you quoting? https://github.com/swaywm/sway/issues?utf8=%E2%9C%93&q=is%3Aissue+use+after+free

>>12923 >pfah! You are not LEET enough to write good rust! heap allocation is often very useful when you have no way of determining the lifetime of an object.

>>13032 Stupid people never learn. Smart people learn from their own mistakes. Wise people learn from others' mistakes. https://blog.ntpsec.org/2017/01/18/rust-vs-go.html https://sjdh.us/2019/02/11/continuing-with-zig.html I've followed Rust enough to know it has no value. The hype has crested and we are beginning to see more programmers look at Rust critically. It has a lot of unresolved problems that should have been solved by now. Even core Rust team members are abandoning ship with increasing frequency. https://words.steveklabnik.com/thank-u-next https://www.ncameron.org/blog/leaving-mozilla-and-most-of-the-rust-project/ There are no jobs in Rust. It's not fun to program in Rust (people don't describe fun as a "learning curve"). In short, it's over for Rust. Enjoy your plush crab.

>>13037 >https://blog.ntpsec.org/2017/01/18/rust-vs-go.html >ESR lol >https://sjdh.us/2019/02/11/continuing-with-zig.html This some toy OS project. How is that relevant? >Even core Rust team members are abandoning ship with increasing frequency. That's just untrue. Steve Klabnik is a literal glitterboy that quit because he found out that Mozilla pays him the least. He is still doing the exact same thing as before though, just unpaid. As for that ncameron guy, he is still working on Rust. Take a look at his Github profile: https://github.com/nrc Or his latest blogpost: https://www.ncameron.org/blog/cargos-next-few-years/ >There are no jobs in Rust. It's not fun to program in Rust (people don't describe fun as a "learning curve"). In short, it's over for Rust. Enjoy your plush crab. https://blog.cloudflare.com/boringtun-userspace-wireguard-rust/ https://github.com/cloudflare/quiche https://firecracker-microvm.github.io/ tl;dr You are a butthurt cnile.

The worst thing about Rust is that it's the enemy of open source code. Think about it. Remember the bad old times when Microsoft ruled you like a king? Then along came Java and Javascript. Java is easy to decompile. JavaScript is by it's nature, open source. These two languages changed everything. Rust is binary blobs on the server. Rust is pushing WASM hard. WASM is binary blobs for the browser. Rust wants you to return to pre-freedom days where you run mysterious binaries of dubious origin to get anything done. Rust is fundamentally anti-freedom.(Always argue in good faith.)

>>13053 rust != wasm, and minified javascript is way less readable than decompiled wasm.

>>13053 A binary blob on the server is as good to you as interpreted source on the server. You can't see it either way.

>>13056 >wasm to rust decompiler I doubt it. >13057 I assume you mean js. The intrepreter is oss, multiple implementations too. Rust is binary blobs. Rust is anti-freedom.

Seriously? Are we now claiming any native-compiled language is anti-freedom? Get a grip.

>>13060 Learn from history or repeat it.

>>13037 >Even things that should be dirt-simple in Rust, like string concatenation, are unreasonably difficult. The language demands a huge amount of fussy, obscure ritual before you can get anything done. >https://blog.ntpsec.org/2017/01/18/rust-vs-go.html NTPSec confirmed for being insecure. Easy string concatenation is how you get SQL injection, CSRF, broken file path concatenation, or some other variant of the same problem. No doubt NTPSec is filled with corner cases that happen if a configuration file or username has a rare special character.

>>13061 >JavaScript is by it's nature, open source Some JS programs are as open source as disassembled binaries.

>>13062 >https://blog.ntpsec.org/2017/01/18/rust-vs-go.html >Even things that should be dirt-simple in Rust, like string concatenation, are unreasonably difficult. Oh wow. Is this for real? Can't he RTFM? https://doc.rust-lang.org/std/string/index.html You can create a new String from an existing one by concatenating with +: let s = "Hello".to_string(); let message = s + " world!";

>>13066 Amazing. It's almost like the language changed in two years. Here is the original version of >It's not that hard "Stefano on 2017-01-12 at 14:11:32 said: This is not really difficult: let mut hello = String::from(“Hello, “); hello.push(‘w’); hello.push_str(“orld!”);" http://esr.ibiblio.org/?p=7294 ESR answers back too. You should go call him stupid some more. That will certainly make people love your pet language. Flawless plan. I should expect no less from the rust geniuses.

>>13077 It has changed, but not as much as your example describes. There are indeed many ways to get a String from a &str, and only recently the community has somewhat stabilized on what to use. However, String.push() and String.add() (operator overloading) has been available since 1.0. The difference is that String.push() mutates an existing string, while String.add() creates a new string. Both are useful in different situations.

>>13061 Here's a bit to make everyone "happier". LLVM IR allows one to generate WebAssembly from C too. No language is safe, enjoy~

>>13081 True, but it's the Rust people pushing WASM hardest. They're so busy trying to replace JS, they can't see they're going to destroy the open web. Everything goes back to being one big proprietary Adobe Flash site again if they win. Except, you can't uninstall WASM.

>>13059 WASM has a canonical s-expression disassembled form. It's much more structured than most machine code, and thus more amenable to decompiling into pseudocode this wasm code was disassembled from a wasm program which computes sha-1 hashes. https://0x0.st/zPt7.txt

Rust has little real relation to WASM. It is not appropriate to discuss it here. The following threads are more appropriate, with the first clearly most appropriate: >>283 >>9169 >>10940 >>10060

>>13077 I don't get what you are trying to say. Are you also too retarded to figure out how to do string concatenation in Rust? >ESR answers back too. >Contemplate this bug report: Is there some API like “select/poll/epoll_wait”? Yeah, contemplate this 1 year pre v1.0 bug report. Jesus Christ ESR is a fuarrrking retard. >>13078 >while String.add() creates a new string. Nope, it calls String::push_str and returns the original String. https://doc.rust-lang.org/src/alloc/string.rs.html#1929-1937

>>13026 Then don't use Sway for wayland. Use a window manager written in Rust, like way cooler... http://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-in-c.html Oh wow, another high profile Rust developer who learned the hard way that writing things in Rust is an enormous waste of time?! Quelle surprise. Like I said, Rust is finished. Even Mozilla is shutting out the lights around them. https://github.com/rust-lang/www.rust-lang.org/commit/285f7bb05411d636b53871c5115640ebdcf1bda2

>>13082 This is a good argument, however consider obfuscated javascript, especially one processed by tools like closure google compiler or uglify.js - every React webapp uses those for sure. Stallman says it is equal to non-free, closed source software, I think it is correct. With WASM you can also inspect strings, calls to specific IPs/domains as you have a binary, but nothing more, so I think level of introspection will be similar to that of a compiled js bundle.

>>13086 I think he meant that you use ::push_str when mutating, while the add() is used. As you can see, add() takes ownership by consuming the whole var as an arg, while push_str merely consumes a pointer by borrowing.

>>13449 haha, way to miss a point. Mozilla shut down its whole IRC server in general, probably because they think it's an outdated way of communication which I personally think it isn't, but the real question is why you find Rust so annoying? Any chance you are a C programmer? I don't think C is going to be maintained forever, Rust has built a good paradigm with ownership, I think you'd be better off adapting the future technologies instead of inventing flaws in it desu

>>13625 I already pointed out what irks me about rust here >>13004 It's not the language. I can easily read the rust book and decide it's a bad language in one afternoon then be done with that. The real problem I have with it is all the toxic rust weenies who show up in every other language's forum with their RIIR requests. They simply cannot fathom that their language, like every other language, has its own flaws, and those flaws make Rust inappropriate for a vast number of use cases. If you guys want to RIIR so bad, why aren't you doing that instead of asking other people to do it for you? >Any chance you are a C programmer? No. Even if I were, this thread isn't about my language, it's about Rust. You can share your positive experience with it. I can share my negative experience with it. The readers can decide for themselves. Personally, I'll be glad to see Rust die. Not because I hate Rust, but because I hate the people using it.

>>13625 > I don't think C is going to be maintained forever > I don't think a language that has lasted 49 years, and has remained one of the most used languages on the planet > to the point where almost every single piece of software out there has some implementation in C > to the point where all five major operating systems are implemented primarily in C > to the point where almost every other language in the top 100 list has a primary implementation in C > a language that has a compiler target for all but maybe 1% of platforms under the sun > doesn't think it will be maintained forever I guess that depends on your definition of 'forever'. If we live that far, it's definitely going to have implementations or emulators that live into the 2100s. If nothing else for historical value.

>>13636 C is just the easiest way to write assembler. It's not going anywhere because it's incredibly basic. that being said: C is also soykaf for anything big and/or multithreaded.

>>13650 Which is still better than a borrow checker that can't handle basic programming like circular references. Much design damage is done in rust trying to satisfy the BC, all while the people inflicting said damage believe it is "making me a better coder!" It would be funny if they weren't so annoying.

>>13653 >can't handle basic programming like circular references "I do not know what smart pointers are" the borrow checker objectively solves more errors than it introduces.

>>13654 >I do not know what smart pointers are Clearly you don't. If it allows circular references in Rust, then it is written with unsafe Rust. Period. That's how the borrow checker works. BC is damage at the core of the Rust language. It leads to damaged designs trying to "safely" satisfy this ridiculous limitation in the language.

>>13636 Past performance doesn't guarantee future results. Consider a horse in 1860. Rock-stable, lasted 40 000 years +, to the point every 1860 day-to-day business is impossible without one. Technology gets better, transition may be slow, but future implementations are virtually free to choose any language under the sun. It probably won't be C. I'm not underestimating historical importance of C though, I think C programming will stick around but in 2040 I think C guys will maintain legacy software like Ada Cobol and Fortran programmers do now.

>>13677 yes, a lot of the STL is written in unsafe rust, why are you making this out to be a big deal?

>>13685 Safety is the key selling point of the language. As you freely admit, most of the STL is unsafe. It's like selling someone a herpes vaccine which is actually just herpes. They didn't have herpes, they didn't want herpes, but now they have herpes. That's Rust in a nutshell.

>>13692 the point is that confining unsafe segments of code into the STL means you only have to worry about a very small amount of unsafe code. I hate to be rude but if you don't understand the point of encapsulation, maybe programming isn't for you.

>>13692 The point of unsafe blocks is for "let's assume this is correct in a way that the compiler can't figure out", it's up to the programmer to make sure it actually is correct. Like say, reimplementing refcounted pointers (Rc ) yourself. The real lifetimes aren't easily describable in Rust's type system so you have to drop down to something that feels more like C/C++ to implement it. But externally your neat little Rc<MyThing> is memory safe to use because whoever wrote the code was smart enough (as in, an adept C programmer) to cross their Ts and dot their Is. And then because of that you can lean on Rust's type system to hold up the other semantics to ensure that wherever you use it you're not going to do something that causes undefined behavior (unless of course, you add more unsafe blocks and mess with raw pointers).

>>13677 This is why Rust will never replace C. When you actually watch people trying to rewrite nasty low level C code in Rust it just ends up being a giant unsafe block with nasty low level Rust code in it. Rust doesn't actually gain you anything except massively bloated binaries. To be fair though, as far as I am aware the Rust project never actually claimed to be replacing C, all that hype just comes from clueless Rust fanbois. The purpose of Rust is to replace high performance userland C++ code with still high performance but also safe code. For that Rust does a good job but it's a much nicher little corner of the market than all the rewrite-everything-in-Rust fanbois realize. >>13684 >I think C programming will stick around but in 2040 I think C guys will maintain legacy software like Ada Cobol and Fortran programmers do now. Even a tiny bit of research would have saved you from writing this complete crap. >Ada Not legacy. Language is still in active development and is used extensively in safety critical systems (e.g. transport, aerospace, military etc.) >Fortran Not legacy. Language is still in active development and is used extensively in high performance scientific computing (supercomputers, CERN etc.)

>>13719 I am not wrong though. Name even three popular software projects conceived in Ada or Fortran in the last 10 years. Name even three popular frameworks conceived in Ada or Fortran in the last 10 years. Transport, aerospace, military - all of these are government branches that use outdated languages like Fortran or Ada for old projects. Also, >Ada isn't mandated for use in the Department of Defense anymore. Supercomputers: https://en.wikipedia.org/wiki/Message_Passing_Interface CERN: https://github.com/cern These languages are legacy, with a tiniest bit of them still present here and there, but only because people don't want to lose a job maintaining their stuff that just werkz. but I would appreciate if you pull out a link or two to support your argument.

>>13721 >Name even three popular software projects conceived in Ada You've shifted from "legacy" to "not popular". >last 10 years The last revision of the language itself was 2012 so there's that. Here are a few famous open source Ada projects anyways RavenPorts package manager (2017-) Muen kernel (2013-) Genode OS framework (2008-) (not 100% Ada) >These languages are legacy, with a tiniest bit of them still present here and there Wrong. Most transport, aerospace, military projects are propriety and not public for obvious reasons and even so I can find plenty of things written in Ada from just the past year from a simple websearch. >NVIDIA rewriting C firmware in Ada (2019) https://www.adacore.com/press/adacore-enhances-security-critical-firmware-with-nvidia >European satellite launch vehicle firmware written in Ada (2019) https://www.adacore.com/press/avio-selects-adacores-gnat-pro-assurance-toolsuite-for-european-space-agency-program >Total Artificial Heart firmware written in Ada (2018) https://www.adacore.com/press/scandinavian-real-heart-selects-adacore-embedded-software-development-platform-for-revolutionary-artificial-heart >International Space Station scientific instruments written in Ada (2018) https://www.adacore.com/press/lasp-selects-gnat-pro-for-clarreo >Safety critical automotive firmware written in Ada (2018) https://www.adacore.com/press/denso-spark-automotive-research >Fortran I don't know that much about Fortran but I do know that it is still taught to Physics university students in 2019 specifically for doing scientific calculations on supercomputers. Saying Ada or Fortran is dead just because you can't see any trendy web libraries for it on github or whatever is just dumb. The world is much bigger than your backyard. sage for off topic

>>13721 The two most important projects that I am aware of that use Fortran are BLAS and LAPACK, which are linear algebra math libraries, they are not new but they are important. Maxima has some Fortran code too (its mostly written in Common Lisp), but that's also a pretty old program, although its still actively developed. There are some other libraries listed here: http://fortranwiki.org/fortran/show/Libraries If I remember correctly, one of the Rust developers said that they had not really even looked at Ada, which is pretty concerning, but this was quite some time ago.

>>13721 >Name even three popular frameworks conceived in Ada or Fortran in the last 10 years. That's just rich. The irony of a Rust fanatic measuring a language by popularity. Present Day, Present Time! AHAHAHAHAHA!

>>13733 I'm not a Rust fanatic. I write Clojure code mainly for my job and my side projects. I also know some C and C++ and right now getting a hang of Rust, which seems decent to me but has some major drawback mostly related to unsafe block fallbacks. >measuring a language by popularity We were discussing whether Ada/Fortran is legacy. I think in that context this is indeed the most relevant metric, how the fuarrrk else are you supposed to adequately deem something as legacy? /ty for reading my blog

>>13692 >Safety is the key selling point of the language Even unsafe blocks have the same type system and borrow checking, they only allow for raw pointers. You are brewing soykaf like someone from /g/, please go away.

>>13735 >I write Clojure Any more garbage opinions about languages you don't know anything about being legacy or replaced by other languages you don't know anything about or can we get on with the thread?

>>13736 It's like you guys don't understand what a directed acyclic graph is. https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html "Different from references and smart pointers, raw pointers: Are allowed to ignore the borrowing rules by having both immutable and mutable pointers or multiple mutable pointers to the same location Aren’t guaranteed to point to valid memory Are allowed to be null Don’t implement any automatic cleanup" I read the book ONCE and never looked at Rust again. How is it I know more about the language than you guys? It's like you're intentionally lying to people, hoping they won't discover this the first time they read the book themselves.

why are rust threads always such a shitshow, it's sad when a language harbours very interesting, fresh concepts allowing for quite substantial discussion around them, but they always end like this. Can't the rust community just go on and stop feeling offended? Don't feed the trolls. I don't know soykaf about rust however, only learned a few conceptual ideas like it's new take on type safety. Say, what real world advantages do I actually have choosing a language like rust over a language like go for example?

>>13751 >Can't the rust community just go on and stop feeling offended? Don't feed the trolls. The rust community are the trolls. >Say, what real world advantages do I actually have choosing a language like rust over a language like go for example? Generics. But you can get generics in other languages without the loss of productivity you are stuck with in rust.

>>13751 Not exclusive to rust, but in languages with sum types and pattern matching one gets a thing called exhaustion. A sum type is akin to saying I have Blah or Foo or Baz each with their own data (say blah has a string, where Foo has an int). So one can compare sum types to enums on crack from a C like language Exhaustion is vital for refactoring code, as when one adds new cases to their type, say Bazy, the compiler tells you every place where the "match" is unexhaustive and tells you what case you missed. This even works on arbitrarly nested patterns. This feature allows your programs to withstand refactoring without breaking most of the time. Since you are comparing rust with go, I will say that if you can take the hit of GC, then you should consider OCaml over Rust. Otherwise stick to Rust.

>>4675 to your point, Facebook uses rust for Libra's smart contract language 'Move'

>>13733 popularity of a programming lang is a very important metric because otherwise the lang can become a tar pit. It also means less potentials readers / contributors to your project depending on how idiosyncratically the language is used and how many SME's there are who can both read the lang and fulfill the goals of the project.

>>13066 >"Hello".to_string() wtf, was "Hello" not a string before?

>>14034 "hello" is a str literal, meaning it is a static piece of memory in the program. You can't add to a string literal because it's just a pointer in the executable. A String is a heap-allocated object, potentially mutable.

Recently started getting into Rust. So far I have ~130 loc for a numerical estimation problem that I've been continually refactoring while learning about Rust's various rules and features, introducing tests and multithreading, testing perf, and so on. Refactoring is really nice, whenever I change a type my linter/cargo check immediately highlights all the rest of the code I need to fix. The borrow checker is also really helpful, as whenever I am trying to refine my solution, it gives me that extra little push to think about best practices. So far, the borrow checker has NOT interfered with any of my plans to write code that would basically be correct in c++, to the contrary, it has helped. The error types are really cool. First I just wanted to write a custom error message and was a bit bewildered that you have to create a whole new type for that. I figured it was just necessary to allow the type checker to help deal with errors. But then later I realized I wanted to bundle some data that lists elements causing the error. Turns out all I had to do was put the element list in the error struct! My only complaint is really that, even though it is a much more constrained/focused language than c++, you still get a lot of questions about whether your solution is "idiomatic." IE, sometimes I'll have an optimization that depends on plain Vec indexing instead of using iterators or map/filter/etc. Or passing a bool flag into a function where I could possibly use an enum. And it makes me wonder if I'm missing full usage of Rust's features and writing uglier code. Kind of similar, even though Rust is very low on OOP stuff, it still has methods. So frequently I'll wonder if I should be using methods, pure functions, or C-style subroutines with the goal of side effects. On the last point, I really like that Rust makes it totally explicit that your goal is side effects by using &mut. I think next I'm going to try out Actix.

>>14228 oh yeah. cargo and rustup are really, really nice.

How ready is Rust for server-side web development? My point of reference is Haskell.

>>14334 I'm pretty sure it's generally more mature than Haskell at this point, but I haven't used it in the past two years so I can't comment in detail. See : https://www.arewewebyet.org/

>>14334 Pretty good for REST APIs. Actix-web is really popular and fast. Like insanely fast. There has been some controversy about the author using needless unsafe blocks (~24 total, but some are reasonable), but it has been kind of moot because he's still getting rid of them: https://github.com/actix/actix-web/commit/b36fdc46db7b606615c417d538059d30427b82fd IMO Rust is a really serious contender for backend, the speed + safety assurances are hardly matched. It's a really nice language aside from that. And while this diverges a bit from your question, it is a viable frontend language with wasm, as long as you don't care about compatibility with old-ass browsers. The Yew frontend framework is promising, it implements an Elm/Redux style reactive system.

Facebook's new cryptocurrency Libra is fully implemented in Rust: https://github.com/libra/libra

It's kind of interesting to see how the discussion started getting worse as time passed by, at first, the discussion was extremely well mannered and meaningful, but eventually, the same crap that you used to see on the other chans started getting here.

>>7251 rewrite it in Mercury::- module pigmath. :- interface. :- import_module io. :- pred main(io::di, io::uo) is det. :- implementation. :- import_module list, string, hash_table, pair, char, int. :- import_module exception. main(!IO) :- Ints = [53, 32, 122, 35, 12, 57, 35, 1, 34, 75, 43, 4, 4, 4, 4, 87, 72, 41, 36, 7, 73, 1, 1, 5, 12, 5, 5, 3, 1, 34, 34, 54, 12, 75, 12, 5, 8, 2, 3], io.format( "### Integers ###\n" ++ "mean: %d; medium: %d; mode: %s\n\n" ++ "### Pig Latin ###\n" ++ "%s\n" ++ "%s\n" ++ "%s\n" ++ "%s\n", [ i(mean(Ints)), i(median(Ints)), s(string(mode(Ints))), s(pig_latin("Apple")), s(pig_latin("word")), s(pig_latin("earth")), s(pig_latin("Zzz")) ], !IO). :- func mean(list(int)) = int. mean(L) = mean(L, 0, 0). :- func mean(list(int), int, int) = int. mean([], Sum, Count) = Sum / Count. mean([H|T], Sum, Count) = mean(T, Sum+H, Count+1). :- func median(list(int)) = int. median(L0) = Median :- sort_and_remove_dups(L0, L), det_index0(L, length(L) / 2, Median). :- func mode(list(int)) = list(int). mode(L) = Modes :- some [!Counts] ( !:Counts = hash_table.init_default(int_hash), each(inc, L, !Counts), ( if [_ - Max | _] = sort((func(_-A, _-B) = ordering(B, A)), to_assoc_list(!.Counts)) then Modes = filter_map((func(K-V) = K is semidet :- V = Max), to_assoc_list(!.Counts)) else throw("impossibru") ) ). :- pred vowel(char). :- mode vowel(in) is semidet. vowel('a'). vowel('e'). vowel('i'). vowel('o'). vowel('u'). :- func pig_latin(string) = string. pig_latin(S) = Pig :- First = det_index(S, 0), ( if vowel(to_lower(First)) then Pig = S ++ "-ay" else Pig = right(S, length(S)-1) ++ "-" ++ from_char(First) ++ "ay" ). :- pred each(pred(T, hash_table(T, V), hash_table(T, V)), list(T), hash_table(T, V), hash_table(T, V)). :- mode each(pred(in, hash_table_di, hash_table_uo) is det, in, hash_table_di, hash_table_uo). each(_, [], !HT). each(P, [H|T], !HT) :- P(H, !HT), each(P, T, !HT). :- pred inc(T, hash_table(T, int), hash_table(T, int)). :- mode inc(in, hash_table_di, hash_table_uo) is det. inc(X, !HT) :- ( if search(!.HT, X, Count) then det_update(X, Count + 1, !HT) else hash_table.det_insert(X, 1, !HT) ). thus, feedback: 1. why does pig_latin perform its own I/O? This severely limits how you can use the function, and even if this is toy code, it's an easy trap to avoid. 2. I vaguely get that mode is inserting a 0 so that you can increment it, but holy crap, I don't want whatever those asterisks are selling. This is probably Rust's fault, though. 3. does rust actually hoist that freqs.values().max().unwrap() out of the loop? Even if it does, spend a line and and assign Max to a variable. That's the kind of optimization that you can accidentally defeat without noticing, and it just looks gross, because it looks like at least an O(N^2) loop 4. how the hell does even a simple function like is_vowel sneak in a potential exception-throw, with that unwrap()... is it because c might not have a lowercase? Then just match both 'a' and 'A' and scrap the lowercasing. I've been told that .unwrap() isn't for real code, that it just's for script-tier tasks, but maybe using it so much trains you to not mind it.

>>14583 > 4. how the hell does even a simple function like is_vowel sneak in a potential exception-throw, with that unwrap() to_lowercase in this example is an overkill. to_ascii_lowercase is much better in this case, since non-ascii characters are not going to match either way.

I'm in love with Rust. The type inference + strict types is fantastic-- completely BTFOs the dynamic typed languages. Refactoring is made easier by both the type inference and the strict types. The fewer type annotations I put on variables, the less code I have to change during a refactor! The simple procedural design lets me Just Write Code. The borrow checker and types make my code Just Work. Documentation for the std library and crates ranges from pleasant to great. Type signatures help fill in gaps. Documentation has tests in it, so it has to be reasonably up to date. There's A Crate For That. All the macros are pleasant to use. Test framework built right in. Errors are just another type-- not another form of syntax and weird edge cases to memorize (exceptions) and not mysterious and dangling (return null, return -1, etc). All my stuff runs fast.

Anyone get the impression Rust is the future? Since computers aren't getting faster anymore, stupid app coders will eventually be forced to write programs with good perf and memory usage. No more GCed, interpreted languages allowed! As well, people are worried about security. Rust prevents a large category of common vulns. Finally, programmers are tired of stupidity. Rust has a remarkable absence of stupidity. imo it just needs more useful libraries. A good cross-plat GUI library for example. It could use the FRP/Elm pattern (several such libs are in progress).

>>15406 Rust isn't the future because it doesn't include AI

>>15407 How would a language go about "including" AI?

>>15414 It does what you want it to do, instead of doing what you tell it to do.

>>15406 probably not. I think the future is when we cut out the middle man and make processors into high-level language interpreters with garbage collection and whatnot. Hopefully with a language that's not brain-dead like javascript, but looking at how things are going, javascript is the future. >>15425 this is what's known as a "user interface", not a language.

>>15431 >I think the future is when we cut out the middle man and make processors into high-level language interpreters with garbage collection and whatnot. I think it's quite the opposite - RISC architectures, such as ARM, will be the future. They are much cheaper in production and easily accessible in a variety of devices. They'll need reliable and efficient software to operate, hopefully that's where Rust comes into play.

>>15440 yes, at the bare hardware/ALU level, RISC is already the future that's here. Most modern CISC architectures are actually RISC architectures with some microcode that is essentially an interpreter. I'm saying that the processor might come with microcode, or perhaps a ROM(which may be written in rust), which interprets a high-level language, probably using JIT techinques to approach speeds of compiled languages.

Serde is really nice in many unexpected areas. Being able to automatically generate JSON and then deserialize it is really great. Completely removes a whole class of headaches you can get when writing web APIs. Declarative APIs. I imagine the other langs with advanced type systems and good macros have equivalent libraries.

>>15431 >make processors into high-level language interpreters This doesn't seem to be the direction we're heading. But we might get WASM processors, which would fit Rust like a glove.

>>15431 >he things user interfaces aren't languages

>>15440 >RISC architectures, such as ARM The thing is, so-called RISC architectures tend to degrade to the point that they might as well be CISC as soon as they get popular. Somebody needs a little extra performance for some specific thing, they add an "extension" to optimize it, software becomes dependent on the extension and now it has to be implemented everywhere. Repeat ad infinitum. PowerPC suffered from this especially, since they kept re-implementing the same features in incompatible ways meaning software was not portable across very similar chips. One could make the excuse "well if you just compiled everything with --no-this and --no-that it would run everywhere" but then your code would run like soykaf everywhere and who wants to deal with that?

Rust's growth has been very significant over the past two years to be honest. Looking at the PYPL index, the number of people looking up a Rust tutorial is more than 10% of the number of people looking up a C or C++ tutorial. That's frankly a much higher level of popularity than I ever expected Rust to achieve, considering that it's an expert-friendly systems language.

I started getting into Rust again, and it looks like the GUI situation has improved significantly. There's now several cross-platform GUI libraries at various level of maturity which just work with a cargo install and ship your application as a single binary, in many cases smaller than a Golang hello world. Which makes it hit the trifecta of cross-platform, ships as a single binary which isn't huge & bloated, while being easy to use & doesn't require a horribly annoying to replicate environment on the dev computer (Cargo handles everything). I can see myself using Rust as my goto language for desktop applications at this point

Is Rust purely marketing? I see a lot of people talking about Rust but don't see many people using it I see no one talking about...R, Perl, C#, Java but I see everyone and their mother using these languages

https://trac.torproject.org/projects/tor/wiki/RustInTor ?

Dropbox and Yelp use Rustlang too.

rust has a pretty specific use case that most organizations don't need. It also has no history of being corporatized so there's very little push for programmers in the workforce to learn it. Corporations are inherently distrustful of anything that doesn't have a warranty. Besides that, yes, rust is a great language and I use it for many of my projects.

>>16267 Rust basically marked itself towards a market that is not used to decent languages. Thus a lot of ideas that i take for granted seem new and shiny. Thus I do welcome it over the competition (subset of Affine logic is great) , however i wouldn't write it unless OCaml or Haskell can't be fast enough for a task (rust has chosen a noisy syntax, and has made itself rather inconvenient for some proper abstractions. Lack of GADTs, HKT, etc.)

>>16267 >I see a lot of people talking about Rust but don't see many people using it What does this even mean? How do you "see" people using Rust? >>16273 imo, GCed languages are not fast or small enough for most tasks. basically any program that crunches numbers or persists and runs in a loop should not come with the associated increase in storage space, memory use, CPU use, and resulting battery use. right now we have accepted the penalties because of the capitalist mindsets of "worse is better" and planned obsolescence. but think of how bloated Android is vs. iOS, and how bloated iOS is vs. a hypothetical smartphone where all the programs are in native or WASM Rust (non-memory-safe languages not an option imo). similar issues with laptops, servers, etc. the only reason the bloat is acceptable is that no constraints are being placed on the massive ecological impact of bloat and hardware churn.

>>16274 Well GC does not come from the worse is better mindset. It instead came from LISP. Now i will say that it's only rather recently (1985~) that we could feasibly make nonGCd languages safe enough for practical development. In the modern day, a vast swaths of domains are fine with a "fast enough" language. Writing languages, Blockchains, internet scraping, crud, AI. And for those I'll easy take haskell or ocaml over rust. This is due to a lot of poor design decisions on rusts end that make it a pain to use. Though even outside those domains, like for example high frequency trading. For most of the application OCaml preforms well enough. One can do a trick where they allocate soke memory in C then have ocaml deal woth it, as it will then not gc it, so you can have hot 0 allocation runs with more type safety than rust (rust lacka gadts). And for fpgas haskell and ocaml seem fairly great at generating fast fpga code. So that's why i think for the vast majority of code OCaml is a better choice than rust

>>16275 >AI machine learning algorithms need bleeding-edge performance. Then again you wouldn't write the really intensive parts in any high-level language anyway, you'd use hand-coded assembler with as many optimizations as you can.

>>16276 Well if you need assembly, then it'd probably be best to generate it from a language like F* (where you can prove behavior and have verified assembly) or write a compiler down from a lesser language like haskell or ocaml

>>16276 Machine learning algorithms that need to run fast generally run on GPU's or ASICs and don't actually care that much about which language is used to script them on the CPU side.

>>16300 In particular, the most important language for ML & speed is probably CUDA, and anything that generates it. Julia is probably the single best tool for this thanks to CUDANative and the ecosystem of libraries that build upon it to generate efficient GPU code.

>>16275 I think you are forgetting one of the single best features of Rust, which is good compiler error messages and the fact that its opinionated nature makes code very predictable. For large codebases, it's general purpose enough to be used as a Java alternative. It's not as concise as a scripting language, but at the end of the day compared to other compiled languages it's still productive enough that access to decent libraries is a more important factor than anything language related.

>>16301 for the love of all that is not proprietary why don't you include a mention to the competing platform OpenCL. It is very much a viable alternative, comparable in performance and is supported by a lot more vendors than CUDA. It is simultaneously a spec and implementation both by the Khronos Group, which develops OpenGL also. Even though I am oblivious to the ecosystem of libraries for machine learning algorithms, I bet there are ways not to rely on CUDA. Code written on both that is uploaded to the GPU by the respective framework tends to look fairly similar, with CUDA having not too many distinctions from OpenCL. See differences https://www.quora.com/What-are-the-differences-between-using-CUDA-and-OpenCL-for-parallel-programming.

>>16302 > I think you are forgetting one of the single best features of Rust, which is good compiler error messages and the fact that its opinionated nature makes code very predictable. Well something like OCaml is also rather predictable both performance wise and speed wise (OCaml is a non optimizing compiler). As for error messages, I find OCaml's to be fine, here is an example let nyet = function Foo i -> 2;; Characters 62-83: ...........function Foo i -> 2.. Warning 8: this pattern-matching is not exhaustive. Here is an example of a case that is not matched: Bar _ OCaml itself is quite explicit about things, due to having a more explicit and flexible module system. > For large codebases, it's general purpose enough to be used as a Java alternative. Well at that point you don't really need the raw speed of rust and are relying on the other features which are better done else where. And in fact I'd argue for big code bases, having a REPL, proper GADTs, tail recursion, etc. Really make working on a large code base much more ergonomic. This of course neglects to mention higher abstractions which are allowed from HKT (Rust as opted to not have do syntax and rather have async support be a subset of this proper system!). Or advance uses of the module functor system in OCaml which allows code to properly scale much better than Rust's current type system and module system allows! I often query my REPL (both in OCaml, Haskell, and CL) for information about the system itself and use it as a very useful feedback assistant (I find it's faster in Haskell to run a specific test I want in the repl, rather than recompile and retest. This allows much faster testing, which means much faster iteration on existing code bases). > It's not as concise as a scripting language, but at the end of the day compared to other compiled languages it's still productive enough that access to decent libraries is a more important factor than anything language related. Library wise, is Rust really ahead of the curve on a language like Haskell? Haskell is as concise as any scripting language (I'd argue much more concise than Python due to proper standard library support for data transformation), and you have the benefit of having many high quality libraries for a wide variety of tasks. My point is thus, if you have the libraries for whatever task you are doing in Haskell or OCaml, and you don't need blazing speed (you mentioned java replacement!), then OCaml and Haskell is going to get you safer code (GADT's extra guarantees will show up eventually in a big code base, they have their time and place), quicker development, more interactive system, and higher level ergonomic features that make it a more obvious choice.

>>16306 I also forgot to post the ADT that accompanied it, however from this error message alone you should be able to determine all the ADT itself. Much like rust (I assume rust has this), this will scale to nested matches upon lists or whatever structure you happen to be destructering.

>>16303 Most machine learning libraries require cuda unfortunately. I wish opencl had broader adoption because Id prefer something non-proprietary.

>>16306 Sure, but OCaml has less adoption than Rust atm. Ideally, a new language should be compared to languages more popular than it. If you compare the new language to languages with low adoption you can always find another language which is nicer from a language design point of view but which just happens to lack adoption. But socially, language adoption is very dependent on momentum, and old good languages rarely catch on. Rust has the nice property that it is "good enough" to rival all the mainstream statically typed high-level languages in expressiveness and memory safety, while also being a great systems language that has enough low level chops to implement a GC or a memory allocator instead of using one. And it has enough community momentum at this point that it's getting easier and easier to use in the workplace.

So that's it, I decided to learn rust. Let us see how hard is this learning curve I heard about ! Any advice for a beginner (already know C and a little C++) ?

>>17932 >C and a little C++ so no SML-like language? how many of these: https://doc.rust-lang.org/reference/influences.html ? are you familiar with monadic error handling or ADTs? normally I'd recommend just rust in motion, dangerrust, too-many-lists, and then standard docs, but you might want to try learning the language and then ask about the parts you find troubling. despite Rust's popularity, I found it quite hard to find good information on stack overflow. Other than checking this one post over and over again: https://stackoverflow.com/questions/41034635/idiomatic-transformations-for-string-str-vecu8-and-u8 getting familiar with API docs is essential. They're not flat documents, and can easily hide information from you.

>>17933 Thanks for the answer, that is what I feared a little, the lack of documentation and specific cases workarounds, due to the language youth.

what happened to this thread? why does everything get so violent when rust is involved? this thread doesn't even read like a lainchan thread anymore

>>18042 What are you talking about?

>>18043 >>18043 >>18043 Please dont be like that. Lets not fight. Im just not in a good place. Im sorry if i bothered you

I'm learning rust and implementing a toy compiler. Can anyone explain modules to me? So I have main.rs, defs.rs, and scan.rs. I can access defs.rs in main with mod defs, but this doesn't work in scan.rs. They're all in the same directory. What am I doing wrong?

>>18385 The module system is one of the only things I really dislike about rust. You're supposed to structure your code like this: different levels of the source tree correspond directly to different levels of the module tree. So if you have two source files in the same directory and you need to bring in a definition from another source file in the same level, you're supposed to use super::mod_name. You're not supposed to have anything like a .h file unless you have some kind of API that you want to expose higher up in the module tree. Since you have a very simple source tree, you would first do mod other_file_name; use other_file_name::<functions or types or global values>; or use other_file_name::*; read the book for more info https://doc.rust-lang.org/stable/book/ch07-00-managing-growing-projects-with-packages-crates-and-modules.html

>>18387 i'm actually coming around on rust's module system. at first i thought it was too verbose and too similar to python (in a bad way) but on the other hand it's kind of nice how explicit it is, and i like how your include statements kind of mirror the structure of the objects in question, so it's obvious where everything lives. ultimately you're paying for the ability to never worry about name collisions. no need to include-guard things or debug all the stuff that can go wrong with templates and namespaces and such in a C++ project. ultimately i don't think it's even more verbose than a carefully designed C++ header, just a different kind of verbosity. i'm a rust noob though so it's entirely possible by opinion on this will change as i use it more.

>>16275 Fun fact: The first version of the Rust compiler was written in OCaml.

>>5213 You ever tried running GCC with any of the -W flags?

Is there a way to set up rust autocompletion and debugging on Emacs? I've managed to to it in VSCode, but I'm trying to migrate all my editting to Doom Emacs.

>>18640 When it comes to auto-completion, racer worked fabulously when I used it with neovim. Try looking into it. https://github.com/racer-rust/emacs-racer

>>18641 Thanks! I had a few path issues with it before, but I guess I'll give it another try tomorrow. Debugger integration is the thing I miss the most from VSCode. Even for python I've got to run pdb on a separate terminal.

>>18640 VSCode will probably be using rust-analyzer, since LSP it it's thing. Or at least I've heard that more effort is being put into that that racer, which also requires nightly. Sadly, it means having to use LSP, but it looks like that's the way most languages are taking...

>>18641 Just as a followup, it worked great. Thanks! I did not have all the Rust packages when I tried it before. I've also managed to get a debugger going (not as well integrated as VSCode, but good enough for now). https://bjbell.wordpress.com/2015/02/17/emacs-rust-debugging/

>>18640 I'm using rust-analyzer with Doom Emacs. 1. Install rust-analyzer 2. Uninstall rls (this will cause lsp-mode to fall back to analyzer) 3. Append '(rust +lsp) to '(doom! ...) in your init.el 4. ~/.emacs.d/bin/doom sync It works pretty well, though Emacs 27 is recommended for faster json decoding.

Can anyone recommend a book to an absolute rookie on rust? I have little to one experience on other languages like C++ or C, i'm looking forward to learn rust

>>19213 TRPL is pretty good https://doc.rust-lang.org/book/foreword.html

>>19213 This: >>19217 The book is amazing, explains things very well, but it's straight to the point, it assumes that you already know at least one programming language. Check out rustlings while you're at it. It's a bunch of simple exercises to test your knowledge of each chapter. Solve them as you go.

>>16306 I think in an ideal world, the GCed, everything-is-a-reference FP langs would be considered "scripting languages" acceptable only for things that provably will not take up computational resources. The current bunch of garbage langs (Python, C++, Java, etc) would die off. Rust or something else with heavy emphasis on value types and a borrow-checker style static analysis would be the default for code that runs longer than 1/4th of a second. Rust is eventually getting GADTs and tail recursion. REPL is nice, but you can just use Cargo tests and the excellent docs for most of what it offers. But it is probably(?) possible to have a language that is highly functional and abstracted like Haskell, but is not GCed and has more explicit memory management. That would kind of be the holy grail.

I'm so frustrated. I've just wanted to use Rust to make things for years, but the ecosystem is still not ready for anything... unless you make huge sacrifices or are an expert building something from very basic building blocks

>>19404 What kind of things are you missing?

>>19406 Web dev - no replacement for things like Flask and Django for python Graphics and games - no good engines or systems like there are for C++ GUI dev - support for things like Qt is not good Everything i research ends up like this.

>>19422 Actix or Rocket are pretty close to Flask.

Refu/g/, tired of being called a tranny whenever I ask this question. I know python fairly well, however I want Rust to be my first "real" language, I am trying the Rust book 2018 edition, however I find it to go too deep from the first pages, talking about static classes or whatever, soykaf I don't really get as I haven't coded in java or C++. Is there a beginner friendly book?

>>19398 Why do you hate garbage collection so much? You're still going to get indeterminate pauses and wasted memory with malloc and free or memory management built with them.

>>19504 Just starting writing some basic programs and look up what you need as you go. That's what i did and go by without reading all of The Book as I learned basics

>>19504 You could try Rust by Example or just start writing soykaf. If the latter, I'd recommend using Codewars, that helped/is helping me with a number of languages

>>19398 I strongly doubt GC's going away any time soon. Explicit memory management is a huge pain in the ass, and most of the time you don't get a whole lot out of it. There's a good reason most languages that don't have GC still have some way to abstract away memory management.

>>15441 >probably using JIT techinques to approach speeds of compiled languages. In scientific computing, this has basically won the war. Python's Numba library is excellent and the only people gunning for python are the Julia people for whom the JIT compilation is slightly more native, at the expense of (IMO) a bunch of syntax warts. Then there are the dinosaurs/huge lumbering collabs still using C++ and Fortran; Rust isn't going to break into that space any time soon.

>>16274 >the only reason the bloat is acceptable is that no constraints are being placed on the massive ecological impact of bloat and hardware churn. based and consciouspilled

>>19422 > Web dev - no replacement for things like Flask and Django for python Even soykafty go server can replace any python http lib/framework. What are you talking about? > Graphics and games - no good engines or systems like there are for C++ Amethyst > GUI dev - support for things like Qt is not good Bindings or still unready to production libs like iced

>>15406 >Since computers aren't getting faster anymore, stupid app coders will eventually be forced to write programs with good perf and memory usage. That's assuming that typical software will be pushing the limits of the hardware's capabilities, and I don't really see that becoming the case as long as CPUs don't start getting slower. I think most increased interest in optimized performant code will be in the realm of CS research, rather than consumer applications. Maybe you're right and increased expectations about what software should be able to do will cause something like Rust to start eating into Java's turf, but I don't think the niche filled by languages like Python will ever really go away.

Okay Rust users, tell me why should I pick your language? My main concerns are Mozilla's trademark policy and ugly syntax. Why is Rust so popular, whereas languages with much better syntax like D are less used?

>>20202 >Why is Rust so popular, whereas languages with much better syntax like D are less used? I can answer this question with regards to D, but a disclaimer first: D is my favorite language. Nonetheless... People have awful misconceptions about GCs, specifically how D handles it; People get confused over there being three compilers; People don't like small ecosystems; People don't think D's trendy; People think D's dead; People were scared of the reference compiler's backend being proprietary (It isn't, now.); Some people remember the D1/D2 schism; There are outstanding bugs because there aren't many people to work on them; People are scared of templates; People don't have faith in the leadership. Some of these have merit (e.g. leadership), others don't (e.g. GC fear-mongering), but these are some of the reasons I see used in rejecting D.

>>19708 No, they'll keep everything slow and cuntsumers will continue to dismiss any claims that things are slow.

>>19702 You're in complete delusion, none of those things are real replacements. Using them will waste years of time

>>19422 >Web dev warp, actix, iron, a lot of others... making performant standards-compliant web servers is one of the things that has seen *a lot* of activity in the rust world recently.

For anyone interested, Mozilla fired their Rust team and forms the Rust Foundation. https://www.phoronix.com/scan.php?page=news_item&px=Creating-Rust-Foundation

I love multithreading in Rust. GCed langs are usually memory safe but not thread safe. Thread safety ensured at compile time is so fuarrrking nice. And stuff like Rayon is so elegant.

>>20335 Corporate goings on are boring.

Can someone help me understand why the following works? When walking through a process' PEB, I had to redefine the LDR_DATA_TABLE_ENTRY struct to this in order for proper transmuting when walking through the module list. / /taken from winapi crate enum c_void {} type PVOID = *mut c_void #[repr(C)] pub struct LDR_DATA_TABLE_ENTRY<'ldte> { pub _reserved0 : [PVOID; 2], pub in_initialize_order_links : LIST_ENTRY<'ldte>, pub dll_base : PVOID, pub entry_point : PVOID, pub _reserved1 : [PVOID; 3], // added this pub full_dll_name : UNICODE_STRING, pub _reserved3 : [PVOID;4], pub ldte_union : LDTE_UNION, pub time_date_stamp : u32 } vs the msdn definition: typedef struct _LDR_DATA_TABLE_ENTRY { PVOID Reserved1[2]; LIST_ENTRY InMemoryOrderLinks; PVOID Reserved2[2]; // removed this PVOID DllBase; PVOID EntryPoint; PVOID Reserved3; UNICODE_STRING FullDllName; BYTE Reserved4[8]; PVOID Reserved5[3]; union { ULONG CheckSum; PVOID Reserved6; }; ULONG TimeDateStamp; } LDR_DATA_TABLE_ENTRY, *PLDR_DATA_TABLE_ENTRY; So neither the msdn docs nor nirsoft had an accurate struct definition. What I saw is I had to remove the two PVOID entries before dll_base and put them after the entry_point member. My question is, is this behavior bc of something I missed with rust's transmute, or is this something windows changed and didn't update the docs? For reference the transmute is this: unsafe { let mut _x = peb.ppeb_ldr_data.in_memory_order_module_list.Flink; let t = std::mem::transmute::<&LIST_ENTRY, &LDR_DATA_TABLE_ENTRY>(_x); } Running on x64 on the latest patch of Windows

>>20202 Along he same vein as this one, as I saw this asked on the Ada thread, I thought I might ask it here. Why Rust and not Ada? Idk about D, but Ada seems to fill the niche of a language like Rust very nicely (in my not too educated opinion, of course, so be free to correct me)

Why do people hate Rust and see it as a threat?

>>20414 I'm not really a Rust coder (yet - just started learning it last week) but I'd bet on it being the usual laziness/fear-of-learning-something-new reasons.

>>20417 >laziness >fear of learning something new This is bad faith and/or projection. The reason people do not like Rust is: >Opened in 2015. https://github.com/rust-lang/rust/issues/28728 >Master/Slave issue >Every executable, by default, contains a copy of jemalloc >Rust wants to replace C++, yet offers no advantages over C++ (Safe is slower, unsafe is no different in terms of "safety" nor speed) >Overly terse named types and keywords that don't communicate their purpose, like "Vec" and "Cell" - AKA soykafty programmers who don't know how to name properly. (Oh, Hi Mozilla!) >Borrowing rules are more strict than what’s possible to safely do. >The rules of unsafe are not strictly defined. >LLVM's optimizer considers undefined behavior a license to kill. Of course, that only matters in unsafe code, but you need unsafe code for anything complicated. Basically it is doing nothing new, it has yet to accomplish any of its goals (Fast and safe!) -- And there are more, but I am just not that into it. Like the fact that you can't sort floats. >static links >Six different types of strings. >dynamically links your program to libc / musc and thats just 10 minutes of searching and randomly recalling problems I dealt with a year and some change ago. Why the fuarrrk can't you sort floats? Is that still a problem?

>>20419 >Like the fact that you can't sort floats. Surely that can't be tr https://users.rust-lang.org/t/cannot-sort-floats/35897 >can't use standard sort function on floats because NaN means they're not totally ordered (^: >oh but look, you can pass this custom function to .sort_by() and now your code is going to compile but panic on NaNs (^: ha ha, holy soykaf

>>20419 >Rust wants to replace C++, yet offers no advantages over C++ There's one very big advantage that C++ people don't really appreciate, and that's cohesiveness. I can look at Rust code and understand it fairly easily. The language is designed in such a way that you can make a lot of assumptions about code written in it and be completely right. With C++, everything's a goddamn mystery, because the language will basically let you do whatever the fuarrrk you want.

starting to learn rust, what am i in for

>>20458 It looks like C++ but it's actually Ocaml meets Ada.

>>20419 >Safe is slower, unsafe is no different in terms of "safety" nor speed) Safe rust fundamentally just enforces borrow-checking rules at COMPILE-TIME. Once compiled, all of the ownership and borrows are indistinguishable from any compiled C code. This is unlike C++ smart pointers which are actually runtime checks and have a runtime cost. Safe rust also has bounds checking at runtime (and sometimes compile time) by default, but it is a minuscule price to pay-- and there are unchecked index functions for when you are 100% certain you're indexing correctly and benefit from the small speed boost.

>>20444 Well said. This is one of the reasons why I, a fairly experienced Go coder, am really enjoying learning Rust. Both languages have an internal consistency that makes reading someone else's codebase a breeze. I'm perfectly okay with both languages not being fully fleshed-out right now, if it means not having to decipher someone else's C++ heiroglyphic spaghetti.

>>20463 >Once compiled that operation may take some time (^: >This is unlike C++ smart pointers which are actually runtime checks and have a runtime cost. At most there's going to be one single check in the destructor to make sure the std::unique_ptr is still pointing to valid memory before deallocating. Is that the big runtime cost you're talking about? >bounds checking at runtime >adding redundant comparison+branching instructions to every iteration of every loop by default, while knowing that loops can have the greatest performance impact in a program >"a minuscule price to pay" >"small speed boost" This would be quite funny if it wasn't so disingenuous. It's okay to not care very much about performance; you just have to admit it openly.

>>20467 >that operation may take some time (^: and famously slow C++ compilers don't? >At most there's going to be one single check in the destructor to make sure the std::unique_ptr is still pointing to valid memory before deallocating. Is that the big runtime cost you're talking about? how does that check actually happen? Does it require state in the pointer? Sometimes space is at a premium. >>>adding redundant comparison+branching instructions to every iteration of every loop by default, while knowing that loops can have the greatest performance impact in a program *every* loop? If the slice is immutable its length will stay the same forever so there is no reason the compiler can't cache the result of the operation in a temporary register, thus making the runtime cost not very significant at all. Also, if you already know exactly the memory bounds, you can use get_unchecked which does no runtime length checks at all.

>>20468 oh and for a safe alternative to get_unchecked, if you just need the first 32 entries, you can use try_from to convert a slice to an array.

>>20467 >that operation may take some time (^: Said the C++ programmer

>>20468 >>20470 >and famously slow C++ compilers don't? Slowness in C++ compiling mostly comes from template abuse. No template abuse, no slowness. On the other hand, slowness in Rust compiling comes from rules baked into the language; it can hardly be avoided. Of course that's not a problem if your program is a small toy program, as most Rust programs would be. >how does that check actually happen? It's a null pointer check. Totally negligible compared to allocating and freeing the heap-allocated memory (which will always happen with every pointer to heap-allocated memory, even in Rust). >Does it require state in the pointer? Any pointer requires state (8 bytes in 64-bit architectures, specifically). >If the slice is immutable its length will stay the same forever so there is no reason the compiler can't cache the result of the operation in a temporary register I guess I need to pray to the compiler that it wont sabotage my program's performance, then. And what if it's not an immutable slice? >Also, if you already know exactly the memory bounds, you can use get_unchecked which does no runtime length checks at all. Memory bounds are almost always known in advance by the programmer, so surely get_unchecked should be the default? >b..but safety... Well of course. It's illusory "safety" (meaning your program will still fail in a panic, but at least it's not a spooky scary segfault) over performance.

>>20471 Actually, now that I think about it, even C free() does a null pointer check, so std::unique_ptr may not actually add any runtime check over equivalent C code.

>>20472 > even C free() does a null pointer check, since kurwa when?

Idiomatic Rust is slower than idiomatic C++. That's a fact. If you think C++ is the superior language because of this, that's fine. There's nothing wrong with thinking that. But for me personally, it doesn't really matter. Rust a) makes up for the speed loss by being significantly safer than C++ and b) isn't really that much slower anyway. It's still way faster than the vast majority of mainstream PLs.

>>20480 Well.. since always? Let's take a look at the good old C89 specification: http://port70.net/~nsz/c/c89/c89-draft.txt 4.10.3.2 The free function Synopsis #include <stdlib.h> void free(void *ptr); Description The free function causes the space pointed to by ptr to be deallocated, that is, made available for further allocation. If ptr is a null pointer, no action occurs. Otherwise, if the argument does not match a pointer earlier returned by the calloc , malloc , or realloc function, or if the space has been deallocated by a call to free or realloc , the behavior is undefined. Returns The free function returns no value.

>>20471 wait, so a unique_ptr is *just* a pointer that can't be shared? What's the difference between that and a rust &mut? >I guess I need to pray to the compiler that it wont sabotage my program's performance, then. honestly if you're using gcc then you need to be praying for that anyway. >And what if it's not an immutable slice? I actually got that wrong... that would be true for an immutable or mutable slice. What would cause the performance penalty would be if you had a mutable variable containing a slice and reassigned it. >Memory bounds are almost always known in advance by the programmer, so surely get_unchecked should be the default? usually when I actually know the length in advance (e.g. when I'm using a fixed length buffer) I use a fixed length array instead. I suppose it is conceivable that you could have a memory region that needs to be growable, but has a known minimum length, and it needs to be faster to access the first part than the rest of the array, but I would probably make/use a specialized data structure for that. >Well of course. It's illusory "safety" (meaning your program will still fail in a panic, but at least it's not a spooky scary segfault) over performance. try_from never panics. It returns a Result type, which can be handled by the program.

>>20483 Oh, you are kurwa right. My paranoia of not passing possibly NULLed pointers starts to reveal it's downsides. Heh xD

Anyone know how to resolve this error? I'm writing a library that involves an unrolled linked list implementation, I decided to do it using raw pointers and a custom allocator for performance reasons. Unfortunately, that means I have to write a lot of unsafe code, and I got a double free error that I don't know how to fix. Here is the function ( with a few debugging messages added): unsafe fn insert_after(&mut self, object: Obj, node: *mut LinkedListNode<Obj>) -> *mut LinkedListNode<Obj> { //it looks like a lot is happening here but it's really just some pointer arithmetic //get a pointer to the block that node is in let offset_from_block = (node as *mut u32).offset_from(self.allocation_slab.cast()) % (mem::size_of::<LinkedListBlock<Obj>>()/4) as isize; let this_block = (node as *mut u32).offset(offset_from_block) as *mut LinkedListBlock<Obj>; println!("slab = {:?}, node = {:?}, offset = {}, block = {:?}",self.allocation_slab,node,offset_from_block,this_block); #[cfg(target_arch = "x86_64")] if ((*this_block).entries[0].allocd as usize) < LINKED_LIST_BLOCK_LEN { println!("a"); let new_node: *mut LinkedListNode<Obj> = &mut (*this_block).entries[(*this_block).entries[0].allocd as usize]; *new_node = LinkedListNode { car: Box::new(MaybeUninit::new(object)), cdr: (*node).cdr + OFFSET!(node,new_node), allocd: 0 }; println!("here!"); a}; //note: node.offset_from(new_node) > 0, no risk of conversion error (*node).cdr = OFFSET!(node,new_node); (*this_block).entries[0].allocd += 1; new_node } else if self.next_block < self.allocation_size { println!("b"); let slab = slice::from_raw_parts_mut(self.allocation_slab,self.allocation_size); let new_block: *mut LinkedListBlock<Obj> = &mut slab[self.next_block]; self.next_block += 1; let new_node: *mut LinkedListNode<Obj> = &mut (*new_block).entries[0]; *new_node = LinkedListNode { car: Box::new(MaybeUninit::new(object)), cdr: (*node).cdr + OFFSET!(node,new_node), allocd: 1 }; (*node).cdr = OFFSET!(node,new_node); new_node } else { panic!("ran out of memory"); } } The error happens on the following line: *new_node = LinkedListNode { car: Box::new(MaybeUninit::new(object)), cdr: (*node).cdr + OFFSET!(node,new_node), allocd: 0 }; I have verified that the double free error happens when the pointer is assigned and not before or after. I don't know why anything is freed here at all, much less double freed. I've checked that all the pointers involved are correct and within allocated limits. Hopefully an unsafe wizard can tell me what's going on.

>>20525 I messed up removing one of the extra debugging messages that makes it too confusing to read, here is the function again: unsafe fn insert_after(&mut self, object: Obj, node: *mut LinkedListNode<Obj>) -> *mut LinkedListNode<Obj> { //it looks like a lot is happening here but it's really just some pointer arithmetic //get a pointer to the block that node is in let offset_from_block = (node as *mut u32).offset_from(self.allocation_slab.cast()) % (mem::size_of::<LinkedListBlock<Obj>>()/4) as isize; let this_block = (node as *mut u32).offset(offset_from_block) as *mut LinkedListBlock<Obj>; println!("slab = {:?}, node = {:?}, offset = {}, block = {:?}",self.allocation_slab,node,offset_from_block,this_block); #[cfg(target_arch = "x86_64")] if ((*this_block).entries[0].allocd as usize) < LINKED_LIST_BLOCK_LEN { println!("a"); let new_node: *mut LinkedListNode<Obj> = &mut (*this_block).entries[(*this_block).entries[0].allocd as usize]; *new_node = LinkedListNode { car: Box::new(MaybeUninit::new(object)), cdr: (*node).cdr + OFFSET!(node,new_node), allocd: 0 }; //note: node.offset_from(new_node) > 0, no risk of conversion error (*node).cdr = OFFSET!(node,new_node); (*this_block).entries[0].allocd += 1; new_node } else if self.next_block < self.allocation_size { println!("b"); let slab = slice::from_raw_parts_mut(self.allocation_slab,self.allocation_size); let new_block: *mut LinkedListBlock<Obj> = &mut slab[self.next_block]; self.next_block += 1; let new_node: *mut LinkedListNode<Obj> = &mut (*new_block).entries[0]; *new_node = LinkedListNode { car: Box::new(MaybeUninit::new(object)), cdr: (*node).cdr + OFFSET!(node,new_node), allocd: 1 }; (*node).cdr = OFFSET!(node,new_node); new_node } else { panic!("ran out of memory"); } }

>>20471 Maybe you don't mean it but I sense smugness in everything you write. It's not necessarily a bad thing but it can get annoying quickly, so be wary of that. What I'm about to post is basically a small fragment from Brandon Falk's (gamozolabs) stream. I thought about making a "Safety vs Performance" thread instead of posting it here but I don't believe that people would really want to discuss it. And if yes, it would possibly be Rust vs C++ so we'd end up with two Rust threads (and people would probably keep trashing this thread with C++ stuff anyway). Feel free to make one yourself, though. ... >If you could provably make all software secure but it has a 40% performance penalty, no one would fuarrrking buy it. Look at allocator developers. Allocator developers every week are coming up with new allocators that are faster in a hot loop. Instead of doing 1.2M allocations per second in a while-true-alloc-free, you get 1.3M allocations a second. And how do we achieve that? Well we throw out all the cookies, all the protections, all of the checks - ah fuarrrk it, fuarrrk all those things because we got 5% improvement in a hot loop of allocations. So you know that thing that you do with 1% of your CPU time? Well we made that 1% of your CPU time 5% faster. Congratulations, your browser is now 0.5% faster. ... >People are trying to nit-pick every single byte in allocators and security-critical things, meanwhile a javascript developer allocates fuarrrking 50 Megs for their tab for something that they'll maybe use in 8 hours.. ... >We all are pretending like we need to optimize every tiny little thing; "Oh, we need a new garbage collector that saves off a couple cycles here." No! When you have 99.9% of your CPU and memory allocation going towards massive, massive fuarrrking programming errors and people implementing O(n^5) sorting algorithms in javascript that are running in the background of your tab every time you receive 2 bytes over a websocket every 3 milliseconds, it turns out that the bottleneck is not actually the root software. And in fact I would say that software has gotten worse, not security-wise, ever since we've given people faster primitives. ... "Programming languages should be hard just to keep the dumb people out" >No, programming languages should basically treat programmers as the dumbest people on the planet and they should hold their hands and they should give them abilities to write fast and performant code. But we shouldn't pretend like developers can not make mistakes. And we should be comfortable losing performance in ensuring those guarantees.. When people look at Rust and they're like: "Oh, but it could be 5% slower than C in this contrived scenario.." Who fuarrrking cares? What are you possibly doing that's saturating CPU so heavily that if you have a 5% slow-down, it's no longer a feasible product? ... "It'd be a fun project. If you fuzz one of your Rust projects and see how much more secure it is than the same project you'd write in C++." >You should do that with students. Have students write something at least 2 to 5 thousand lines of complexity and have some students at some university tasked in writing it in C, and some other university in python, and some other university in Rust or Go, or who fuarrrkin cares, and compare the performance between them, compare the security between them and then also compare the crashes, right? Rust doesn't have security bugs but I would hazard that Rust code is probably more prone to crashing than C/C++ code, and the reason for that is because panics happen at the smallest tinge of incorrect execution. Whereas C/C++, you go couple bytes out of bounds or something, you're fine. It doesn't care, you probably didn't corrupt anything anyways, it's fine! So off-by-ones in C and C++ are usually not a crash and usually not a security flaw. But in something like Rust, an off-by-one - there will always be a panic. And at the end of the day, to an end user or to a life-critical device, panics are just as dangerous as a crash to be honest. ("There are panic handlers for mission-critical software.") ... >But most things are not life-critical. I would be concerned about someone getting arbitrary code execution in my browser than someone crashing my browser. And also, Rust panics are much more obvious and thus easier to fix. ... He does fuzzing for living and as a hobby so he definitely knows tons about safety and performance. If you doubt my words, just check him out or go argue with him yourself, I'm not his secretary. If you want to hear more of this rant for whatever reason, it's in his 3rd Chocolate Milk video on his YT channel (about 5h 35m in). Peace out.

>>20531 >What are you possibly doing that's saturating CPU so heavily that if you have a 5% slow-down, it's no longer a feasible product? web servers, complicated simulations, real-time computing. Coincidentally exactly the places where most of the developers aren't dunces and know what they're doing... that said, I honestly think rust is better just because it forces you to write multi-threaded programs in a way that reduces headache.

>>20531 I thought the point of Rust was that you could write code that was safe and fast by telling the compiler enough so it can verify your program's safety before it runs. Is this incorrect, or is there something else i'm missing?

>>20533 The point of rust is to be a safe language that's viable for systems programming. It focuses on speed because it's necessary for the domain rust was built for, but it's never really been the end goal of rust.

>>20467 >>adding redundant comparison+branching instructions to every iteration of every loop by default, while knowing that loops can have the greatest performance impact in a program >"a minuscule price to pay" what is branch prediction

>>20471 >It's a null pointer check Yet Rust's compile-time borrow checking rules eliminate the need for such runtime null checking (unless explicitly called for by option types). How is runtime pointer checks for everything somehow more negligible than bounds checks? Also there is more than one C++ smart pointer type, others have more overhead.

>>20553 >viable for systems programming. Sure, as long as you're willing to sprinkle a little of that unsafe keyword everywhere (but then, why not just use C instead). >>20562 >How is runtime pointer checks for everything somehow more negligible than bounds checks Bounds checks can happen every iteration of a loop. On the other hand, null pointer checks happen only on destruction and are very much insignificant compared to the cost of actually deallocating the memory. Heap memory ain't free (pun intended). >Also there is more than one C++ smart pointer type, others have more overhead Are you referring to shared_ptr? Of course it has more overhead, because it is a reference-counted type. An equivalent implementation in any other language, including rust, wouldn't fare better. I'm assuming you're not trying to compare apples and oranges

why does EVERY discussion about rust become about whether rust should exist? Shut the fuarrrk up jesus.

>>20578 I suspect it's because C++ programmers see it as a threat. Unlike many of the other attempts to make a C++ replacement, Rust has actually been gaining quite a bit of traction.

>>20578 I believe it's nice to see the language from multiple points of views. >>20576 If your toe hurts, why not amputate your leg? When you write unsafe code you're basically saying: "I know my soykaf and I'm 100% sure this will work, please let me do this." The point is that people can't stay vigilant 24/7 and this definitely helps. If you know that what you're doing is in fact working correctly, you can do it. No problem. But you can't believe that you're God's Chosen Programmer and that you're able to create absolutely perfect code every time you write something. >Just write good code lol

>>20580 >oh woe, those damned C++ programmers! why do they persecute us so?? it must be because they are afraid of our greatness! yes, that's it! I don't know, man. Maybe the fact that rust gets marketed as a better, "safer" replacement for C/C++ has something to do with all the debates and comparisons that pop up? Also, while C and C++ programmers are able to talk about their own languages without any reference to rust, it seems that at least a very vocal subset of rust programmers just can't stop proselytizing about their language in all corners of the internet (like that insufferably stupid "rewrite it in rust" meme) while spreading misinformation about C or C++ (like the weird ideas about smart pointers that popped up in this very thread). I think it's clear with whom the insecurity lies. >>20582 People indeed make mistakes, but then learn from them and become better programmers as a result. Being constantly afraid of even the smallest injury is not a particularly smart attitude.

>>20597 >while spreading misinformation about C or C++ It's also not just C and C++. If you're talking about language X, then some Rust evangelist will pop in to proselytize while denouncing the disbelievers and their tools of choose--even in your own god damn forums.

>>20597 >People indeed make mistakes, but then learn from them and become better programmers as a result. Being constantly afraid of even the smallest injury is not a particularly smart attitude. This right here is why I hate C++ programmers. There's no room for soykaf code in production software especially real-time and systems programming. It costs time and money, and causes problems for people in other fields who use your broken code. Get better on your own time.

>>20597 >People indeed make mistakes, but then learn from them and become better programmers as a result This is the main reason why I believe that even people who write in Rust should know assembly and C and why Rust is one of the worst possible "first languages". It is too complicated for simple stuff (which is something "first languages" concentrate on) and too abstract for a systems programming primer (that is, if you can't see through those abstractions, you're gonna have a terrible time). I'd say Rust is for the programmer who is already experienced and knows enough to see through Rust's abstractions, but is also self-aware enough to know that, even with several years of this experience, they can make mistakes at any time. And inline asm in Rust is fuarrrking amazing. >But then you might as well just write it in assembly Anyway, in the end it's less about running from mistakes and more about understanding that you can make them, too.

>>20632 >I'd say Rust is for the programmer who is already experienced and knows enough to see through Rust's abstractions, but is also self-aware enough to know that, even with several years of this experience, they can make mistakes at any time. very much agree. A newbie programmer wouldn't understand why ownership of references is so important or how it works(or how it is computed). Doing something nontrivial with rust is very frustrating the first few times because of the borrow checker.

>>20631 >There's no room for soykaf code in production software especially real-time and systems programming Which is why you should always test your code thoroughly before releasing it? Not only will you catch memory errors, but also logic errors, against which I assume even your magical super-duper safe language isn't immune. And if safety is of the supreme utmost importance (i.e. people could die), maybe you should use Ada (^: >It costs time You know what costs time? Wrangling with the borrow checker to create anything useful yet not trivial and then suffering through the overly long compilation times every time you want to test something. Seriously, what a waste of time. >Get better on your own time. People will get better on their own time, and they will more likely do so with a language that allows them to learn freely, like C or C++. Then you should not be surprised when they decide to also use those tools at work rather than pointlessly torture themselves.

>>20597 >oh woe, those damned C++ programmers! why do they persecute us so?? it must be because they are afraid of our greatness! yes, that's it! You're making a bad faith argument based off of assumptions. That's not at all what I meant. For most of its life, C++ hasn't really had any serious competition. There was no C# to its Java, no Python to its Perl, etc. As far as I know, Rust is the only attempt at an alternative to C++ that didn't die after two years. I don't think Rust is going to kill C++, and although I prefer it to C++, I don't really think it should, either. The point I was trying to make with >>20580 was more that this is something C++ programmers have never experienced before. Rust evangelism isn't really that extreme. If anything it's pretty mild compared to a lot of other languages. But to C++ programmers, it's horribly obnoxious, because you guys have never had to deal with alternative language evangelism before that didn't fade away after a week. There's a new kid in town and he ain't going away any time soon. You're just going to need to learn to deal.

>>20645 >Rust is the only attempt at an alternative to C++ that didn't die after two years You can attribute that to mainly three factors: 1) It's backed by Mozilla 2) It has some rather fanatical supporters among its soykaf-filled community 3) To be fair, it does naturally fill a small, previously unoccupied niche for languages that are low-level yet extremely academic and safety-obsessed Points 2 and 3 might be related; the target users finally get the language of their dreams, and, mistaking their personal elation for an objective sign of the language's greatness, become proselytizers for the language. After all, who wouldn't spread the word about the second coming of Jesus if they were deeply convinced it was happening? tl;dr some people need to pull their head out of their ass and just quietly enjoy the things they like >But to C++ programmers, it's horribly obnoxious As >>20623 mentioned, it's not even limited to C++. Rust evangelism has been annoying to people all over the place. >There's a new kid in town and he ain't going away any time soon He ain't going away, but he ain't going anywhere too fast either. And unfortunately it looks like he's gonna keep being an annoying brat.

>>10 I recently followed this tutorial to make a DOOM-style fire effect, but implemented it in Rust: https://fabiensanglard.net/doom_fire_psx/ Here's my code (It's only a graphics demo, so it's one file in the src folder): https://github.com/ricardoaiglesias/doom-fire-rust Any suggestions? Currently, it's very slow for things larger than 100 x 100 pixel-sized windows (though this might be more of an "SDL Best Practices" question).

>>5354 Well, probably a "quick and dirty" project probably won't benefit from Rust safety in first place. But if your program is critical not to seg fault then maybe Rust will be appropriate choice even if not that fun.

>>20636 >You know what costs time? Wrangling with the borrow checker to create anything useful yet not trivial and then suffering through the overly long compilation times every time you want to test something. Seriously, what a waste of time. IME the borrow checker isn't usually much of a problem once you're proficient in rust. You learn to recognize and avoid situations where it would complain. Anyway, is anybody here a wizard in unsafe rust? I still haven't been able to resolve my problem >>20525 >>20526. Any help would be greatly appreciated.

>>20576 >Sure, as long as you're willing to sprinkle a little of that unsafe keyword everywhere (but then, why not just use C instead). That's not what "unsafe" does in Rust. It's for building safe abstractions over unsafe operations - if you're just throwing it around in your code then you're writing garbage.

>>20647 You can write a blog about literally anything involving Rust and be front page on HN. I would say people use Rust almost entirely for the sake of blogging about Rust. The pinnacle of achievement in Rust is still just a grep clone, which was a solved problem, frankly.

>>21009 People talk about rust because it's still relatively new. It's like how everyone was obsessed with Java in the 90s and early 2000s.

>>21009 >Caring about what HN thinks kek

>>21037 Was that the case? I remember forums and social media being much more primitive then. Astroturfing was probably not nearly as streamlined as it is today. Java lore is that Sun just marketed like crazy, but hype led to buy-in because the language was an improvement over C++ for a large number of use cases. A reasonably consistent (not beautiful, consistent) programming model, GC, and adequate performance would have been pretty appealing pre C11. Just like scripting languages have become popular after Java because you have fewer technical concerns and good enough performance for many use cases. You can write in a few hours in Python what takes all day in C# and all week in C++. C++ has only recently become a more reasonable choice for applications programming for non-experts. It’s actually pretty exciting. Rust developers (or at least the people who took it from Grayson Hoare) want a better C++, but C++ has already become a better C++. At this point the value proposition of Rust is that A few 20-30-something effete men spend hours a day convincing the internet that Rust is the fashionable choice. You can’t JUST market technology. There must be at least some value add to retain users. Even Go, after Rob Pike famously belittled its target users, is practically mainstream because of it’s value proposition: simple, consistent, batteries-included, easy-deployment with a very usable concurrency model. Junior devs can write applications that would have been too challenging in C++ or Java. Rust offers a weaker C++ with the addition of crude linear types (lifetime annotations), static analysis as a compilation step with no opt out, obnoxiously academic design, and builds that are less complicated only if you had refused to use a professional IDE, like an autist. That’s an incremental improvement; not a game changer.

>>21039 >At this point the value proposition of Rust is that A few 20-30-something effete men spend hours a day convincing the internet that Rust is the fashionable choice. And, of course, rewriting things in Rust even though such programs don't need Rust's few unique offerings. Because RUST!

If only there was a Rust version of openFrameworks. Nannou is too barebones but the features Rust took from fp are very useful for graphics programming

(TL;DR at the end) I'm sorry for stirring up the conversation again but here are some things to note: >Mesa is considering Rust as a viable option for drivers >Linus didn't immediately defenestrate the person who came up with the idea of in-tree Rust >Tor endorses Rust >Firefox has Rust >Rust-only hypervisors and operating systems exist (not 100% Rust-only as ASM is required in these fields) >Rust-only malware exists >et cetera The question of "Can Rust succeed?" has been mostly answered and some of you are still trying to tell the people around you how Rust is just a small group of nerds forcing it down everyone's throat.. If it is in fact just a small group forcing it down everyone's throat, they are pretty fuarrrking good at it, are they not? There have been many good arguments about why it is and why it is not a viable option and yet you still defend the idea that Rust is soykaf and the only reason why it's successful is because it is well advertised. Some of you have tried comparing it to C++ -- sometimes you did a good job and actually pointed out the shortcomings of Rust and I applaud you for that, but then when someone else points out the shortcomings of C++ in comparison to Rust, you reply with the same amount of toxicity and smugness as those you're criticizing. Constructive critique is very important for anything that tries to accomplish something. Maybe some of you have tried arguing in good faith but ended up exhausting your patience and eventually started drowning in your passionate opinions. Maybe, just maybe, you are one of those easily deceived people who see "lol trannies" once and then spam it fuarrrking everywhere, but if you are not (and this is what I presume), please be more patient and look around before even touching your keyboard. And the same goes to all the people who defend Rust, of course. My advice is to be as aware as possible when you argue. If you want to complain about the language itself, blaming the Rust community for being too obsessed with it ("Rewrite it in Rust") is dumb. And the other way around, if you want to complain about the community, why blame the language itself for being bad? I understand that a lot of the time you complain about the language in general (ie., both the language and the community), in which case go ahead but don't forget that you're digging a grave below your very own feet -- Python has newbies, C/C++ has elitists, Java has the burnout-capable corporate demeanor, JavaScript has developers who believe that buttons on their web page should be an application, etc. And yet, to this day, all of those languages persist. I understand that anonymous boards and forums and whatnot can turn into clusterfuck easily because you're never held responsible for the bullshit you spread. And exactly for this reason, if you want to argue, complain and convince other people, perhaps talking about it here is not a good idea. All sides, defenders and attackers alike, have to realize that as long as they're discussing it here on Lainchan, they should either take everything with a grain of salt (or a whole salt mine) or further inform themselves on what they just read or are about to write. TL;DR: Rust is (likely) here to stay and you shouldn't waste your time polemizing about whether it will die or not. Nor should you waste your time convincing other people to turn away from it -- you're somehow hurting everyone around you, including yourself. >this post is like kicking dead whales down the beach. >i'll rewrite it in rust eventually.

>>21096 Rust is like Lisp and Ada: its an academically proven language that is fun (for some users) to program in, but isn't used a lot because it doesn't really provide anything that other more successful languages don't already have. That said: its advocates will defend its worth with their life. Yes, there are Rust raytracesrs; because there are Ada raytracers, because there are lisp raytracers, and given enough time there will certainly be brainfuck ray tracers as well. Endorsement of a language is no measure of its success. Rust can succeed, the question is if it will succeed or fade into obscurity. [code] fn main() { println!("I kind of hope it does though. Have a great evening lainanon!"); }

>>21096 >Firefox has Rust Didn't Mozilla drop further plan of introducing more Rust™ into the browser? I don't like Rust™ for its bad trademark policy inherited from Mozilla, which makes it hard to modify without removing all trademarks from the source code. https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedom_flaws I also don't like the syntax, because it is unintuitive and too complex. If the trademark problem was resolved, I would have nothing against using or learning Rust™. The current trend in the Rust™ community to rewrite everything in Rust™ is also a bad thing - dropping mature solutions just to rewrite something in Rust™ makes the rewritten software prone to other bugs, not necessarily related to memory safety. You can't replace over 20 years of development just by rewriting something in Rust™. Instead of this, already existing mature solutions should be improved by using static analysis and some other tools.

>>21105 >The current trend in the Rust community to rewrite everything in Rust is also a bad thing - dropping mature solutions just to rewrite something in Rust makes the rewritten software prone to other bugs, not necessarily related to memory safety. You can't replace over 20 years of development just by rewriting something in Rust™. >blaming the Rust community for being too obsessed with it ("Rewrite it in Rust") is dumb. And the other way around, if you want to complain about the community, why blame the language itself for being bad? I understand that a lot of the time you complain about the language in general (ie., both the language and the community), in which case go ahead but don't forget that you're digging a grave below your very own feet -- Python has newbies, C/C++ has elitists, Java has the burnout-capable corporate demeanor, JavaScript has developers who believe that buttons on their web page should be an application, etc. And yet, to this day, all of those languages persist.

>>21108 I read what you wrote before, I just think the trend affects ecosystem of the language itself - trying to rewrite something they'll never be able to catch up with is a waste of time. The community, to keep the Rust™ ecosystem strong, should instead focus on writing new things and innovating, instead of for example trying to rewrite LLVM in Rust™. The language won't be a viable alternative, if the community will focus on unimportant things fist. If a language has a bad ecosystem, advantages of the language itself won't help much.

>>21111 I'm >>21108 but not >>21096. That aside, fair point.

>>21101 You hit the nail right on the head. Rust, IMO, is generally a better language than the ones it's trying to replace, but not an any sort of major ways that would actually get people to switch.

>>21105 Mozilla fired all of their Rust developers. Firefox also has more CVEs than any other software. Firefox is also a “privacy” oriented browser that hands its users over to Google, which is the main threat to user privacy. They’re completely full of soykaf. They just put a hipster vibe on top of it. Hell, Rust WAS a good language until all these phDs at Mozilla decided a useable, fast, applications language wasn’t cool and making everything as much like C++ as possible is cool. Their whole strategy is to paper over weak products with media flacks. Steve Klabnik is literally a flack and has been since his Rails days. The hottest rust application is still a reimplementation of a grep, and everyone fans Andrew Gallant’s balls over it. Meanwhile, any swinging dick who worked through the examples in any of Zed Shaw’s books has done just as much. People only care because of who Gallant associates with. Another great example, look at the commit history for Lemmy. Unironic-Castro-poster opens a repo in February 2019. It’s a federated Reddit. Gets hundreds of stars within about a week. Trending on Github. However there wasn’t even a MVP of a federated back end until 2020, and it had to be done by someone else! The guy had a JS-framework-cancer clone of Reddit, and there was only stub code for the server, and it was a trending repo and marketed on Rust blogs for nearly a year! Everything in the ecosystem is like this. You peel back the headlines and look at actual source and commits, then you see what a joke it all is. >libcurl to use hyper HTTP to make the web safe >literally thousands of invocations or unsafe in hyper’s dependency tree. How is this an improvement? If you’re going to skip statically verifying your lifetimes, play cowboy with memory with pin and open up a world of soundness holes, then why didn’t you just use C which at least has some good analysis tools to tell you if you’re really as clever as you think you are? Remember “Rails is a Ghetto”? Zed Shaw was an autistic prick, but it’s hard to argue with his take on the Rails community. All talk. Full of charlatans selling snake oil. Preys on the gullibility of junior devs. And here we are living it all over again. Most of the people haven’t even changed. Yehuda Katz, Steve Klabnik, the whole gang.

>>21268 >The hottest rust application is still a reimplementation of a grep You lost me immediately and you're going to lose many more if you stay like this. Maybe you make some decent points but your ignorance, to most people, ultimately renders them worthless of consideration. Also, for some reason you have decided to ignore >>21096, which is what >>21105 refers to. Either that or you have misunderstood it drastically?

>>21288 Firecracker VM is a toy Servo never demonstrated real improvement Phillip Oppenheimer’s OS is a toy and a pretext for a blog Redox has yet to prove any usefulness at all Lemmy is vapor ware. There is no Rust in the Linux kernel. It’s just not officially forbidden to keep the purple-haired hipsters from sending Linus hate mail. Yeah, a few (<10) developers at major companies insist on using rust for a couple of harmless internal projects so they can blog about rust and get the free attention. So what? Simon Marlow insists on using Haskell, so FB lets him use Haskell. Sometimes appeasement is the best strategy for management. I knew a director of solid waste who brought his dog to work. Yeah, HR didn’t want him to, yeah it’s against policy, but how easy is it to find a PE with 20 years of solid waste experience willing to relocate to a mid sized city with high crime? Exactly. They let him bring his dog. Once you look past the headlines, the entire ecosystem is amateur hour. Instead of being cool and upfront about it, paid flacks spout off nonsense about how this programming language is empowering minorities and bringing balance to the force. Then, ignorant junior devs blog about how Rust is their secret sauce on Medium to pad their resume and market their name between gigs. Just like they did with With Node circa 2015. Just like they did with FP circa 2010. Just like they did with Rails circa 2005.

>>21268 >>21298 I think you care too much about ecosystems. Rails died because Ruby died, and Ruby died because it had nothing to offer. It was just Python but slower. FP remains relatively niche because it's not very practical for most problems. The only big functional languages I can think of are Ocaml and Lisp, and neither are fully functional languages, since they allow mutable variables. Node died because it was a pile of soykaf that got eaten by Go. A bad ecosystem can definitely hamper a language, but it can't really outright kill it.

>>21300 Different poster here, but I think ecosystem of a programming language is what drives the language, so it is valid to discuss Rust's ecosystem. If the community won't prove their language is usable, it will never be adopted outside of meme toy projects.

>>21300 Libraries are tremendously important. Unless you’re satisfied with only trivial problems, then at some point you need to delegate work to other libraries. I don’t want to roll my own TCP stack and UTF-capable string type to use a REST endpoint. Common Lisp isn’t “dead”, but there are many good reasons not to use it for most cases. I don’t care if Rust is alive or dead, but the cloud of lies around it needs to go. It’s a hobby project. That’s fine. Nim is another great hobby language. Odin, too. Same with Zig. Nobody is publishing empty-headed articles about how Microsoft is switching to Zig or how Linux needs to be rewritten in Nim.

>>21302 Calling it a language a 'hobby project' because it doesn't set the world on fire is too demeaning imo. It implies that they're unsuited to solving any real problems, which isn't true most of the time.

>>21301 I argue that the language itself is what sets the seeds for the ecosystem. In Rust's case, everything is a rewrite of something already written in C++ or C because Rust itself is basically just a tidier version of C++.

TL;DR: Just don't read it. Many people are to come and they won't read it either, so what will it change? We'll all die anyway and I don't want anyone to take the risk of regretting their choice of spending hours arguing with some strangers on the internet. >>21298 You interconnect your opinion of the community and the language itself so much it becomes very hard for other people (or me at the very least) to understand what you really mean. And, also please remember, there are lots of people who have written stuff in Rust and haven't regretted it. I know a guy who has, among other fuzzers, written a couple hypervisors/kernels just to fuzz stuff, some of my friends and I have written a target-dependent polymorphic malware. There's a lot of relatively great things out there that you don't see, or even can see, and you won't change the opinion of those people. In other words, none of us have complained about the language. And sure, maybe we shouldn't have used Rust for the worm, but as I said, no regrets. You could argue that we are just an obscure group, but one of those hypervisors was (and still may be) used to fuzz the Windows kernel by several people (and given the fact that he works at Microsoft, you could, though should not, say that it's used by Microsoft?) and have you seen anyone write a blog post about how they found 0days with it? I haven't (but they did tweet it out). Community around a language is one of the worst possible arguments I can think of. Sure, it may be important to some, but it means absolutely nothing to someone else. If you are one of the "some", then I am that "someone else". Blaming the language itself for being bad is a much, much better argument. >>21302 Libraries are important, I agree and if I disliked Rust's libraries (which I sometimes do so I end up rolling with my own) so much, I would probably try to put some critique out there. At this point I don't praise the language, but if I had to choose, I would rather praise it unconditionally than hate it mindlessly. And if you find the language itself hard to complain about, I'm not going to scold you for that either. In fact, my own complaints about the language aren't exactly about the core language itself. (They are mostly subjective -- I don't really like cargo, for example.) With all honesty, and to my knowledge thus far, the only people who have a somewhat decent reason to hate the language for existing in the first place are those who use Gentoo (https://forums.gentoo.org/viewtopic-t-1118522-highlight-librsvg.html). But if they dislike it, it was their decision to compile everything in the first place. If you want to compile something, you need a compiler for that. If you want something that is written in an obscure language, you will need an obscure compiler (relatedly, bless the Gentoo devs for rust-bin). So really, saying that Rust shouldn't be used, that it should die and trying to force other people into using other languages is not it. You can complain about the community, though, that would be completely valid. Go ahead and do that (even in an "All things Rust." thread), but try not to poison non-related discussions. I'd like to thank you in advance but I don't presume that I can rely on you. This is possibly the greatest problem when it comes to discussions, especially argumentative ones: we misunderstand each other. You could have two people arguing for years and years just because one is talking about the core language, the other about the language and everything around it, but both only ever seem to mention "a language" and not explicitly what they mean by it. So remember, whenever I talk about Rust, I talk about the core language itself -- not the community, not the libraries or cargo, but only what is given to you by the standard library and the language alone. And if you reply to someone else, think about whether you're fighting the right battle.

>>21302 >Common Lisp isn’t “dead”, but there are many good reasons not to use it for most cases. Library-related, or something else?

>>21311 >In Rust's case, everything is a rewrite of something already written in C++ or C because Rust itself is basically just a tidier version of C++. In fairness, most programs written in Rust and other recent languages are rewrites of C or C++ programs, because absolutely every kind of program has been written in C or C++ at some point in the past 3-4 decades. >>21300 >Node died because it was a pile of soykaf that got eaten by Go. One of my favourite "crush their soul in an instant" tech demos with Node fanboys is to innocently ask them how to do the equivalent of a goroutine. After they give a blank stare, I show them what it is and how it works. And almost every time, they go quiet and get this thousand-yard stare when they realize how much time they've wasted trying to somehow shoehorn genuine concurrency into javascript. It's great fun.