Rust Thread

>inb4 tranny language not gonna bother Why is there no Rust thread yet? I have taught it myself after Go and to me it feels like it allows me to write concurrent code much easier and giving me more control over how I wanna implement it (threads, channels or async). The learning resources also feel like the best I've ever dealt with, there's an official learning book, there's "Rust by example", the standard library docs always provide examples too and there's a million more good things I can say about it. Up until now I haven't ran into any significant problems with the language unlike Go (https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride) and I think in the future it will entirely replace C++. Has lainon tried Rust yet?

can you compile rustc without rustc yet

>>31826 > The learning resources also feel like the best I've ever dealt with, there's an official learning book, there's "Rust by example", the standard library docs always provide examples too and there's a million more good things I can say about it. Rustlings is a great resource as well. Nice to do the exercises while you read the official book. > Has lainon tried Rust yet? Giving gamedev a try using bevy, slowing getting the hang of developing using ECS. It just feels like there's a big focus on getting things right in the Rust ecosystem. A bit anecdotally, but most people that come to Rust already have experience with other languages (unlike python of JS), so the quality bar for code and discussion feels much higher. You don't see posts of people asking how to print stuff to the screen, it's usually something like "how do I run this super complicated algorithm concurrently". I think just learning it will teach you all the ways you can fuarrrk up in languages like C++. So it will make you a better programmer.

I'll wait until it's stabilized and with actual standards you can target (and that actual crates target). Lack of keyword arguments and the C++/Perl tier syntax are still a pain for me. https://lobste.rs/s/odvpbd/gcc_rust_approved_by_gcc_steering https://fasterthanli.me/articles/when-rustc-explodes (which shows the C++ template tier insanities you get in the "real (aka crate) world").

>>31827 We have to wait until 2013 to do it bro

>>31835 It would be funny if some lainons didn't give the impression that they still live in 2010

>>31826 it's glitterboys like the guy in the thumbnail that will make the language die like a failed rocket launch. it's cancer sjws like ashley williams that will make the language die like a failed rocket launch. it's webshitters thinking it's a good idea to use a systems language for webpages that will make the language die like a failed rocket launch. rust actually does seem like a decent language, but the people misuse and abuse it instead of using it to its full potential. rust could've been a lot more mature if actual C/C++ devs were to switch the rust rather than webshitters adopting it.

>>31880 >rust could've been a lot more mature if actual C/C++ devs were to switch the rust rather than webshitters adopting it. This is true, the community seems to have this collective belief that they're competing with javascript. Embedded development with rust is still a lot harder than it has any right to be. That said, rust definitely won't die any time soon. There is a lot of corp money behind it at this point, mostly because they see it as a good alternative to go in the space of languages that you can write a decently fast web server in without wanting to shoot yourself.

>>31826 disgusting language, even the syntax is disgusting, you can't even implement linked lists without unsafe, you've to rely on the standard implementation instead. lifetimes are the most retarded thing to the point that even top rust sh*lls have to admit that it is like kicking dead whales down the beach (90% of programs aren't concurrent), the compiler is ridden with unsolved bugs (which are related to lifetimes lmao), the most complex things made with rust are rewrites of programs that no one asked for (how is servo doing?), if you want to do async programming you need to rely on an external library, rustc binaries are bloated, the rust team refuses to support other build systems than cargo, etc. I can continue. btw, I still remember when they marketed rust as a replacement for C, they had to lower the bar to C++ when zig appeared (zig is like kicking dead whales down the beach too)

Rust is great. As far as the procedural languages go, it's the best. I plan to keep using it for the foreseeable future.

>>31903 What's wrong with Zig?

It is humorous to me that you basically can't talk about rust on the internet without someone trying to start a flamewar about the "tranny language". If not for them, it would be yet another research language that was only used by a small group of evangelists. The hatred seems to only make rust stronger.

>>31903 And all of their original programs are below versio 1.0, which just shows how damn immature Rust is. Rust, even though a systems language, literally relies on C/C++ to run on microcontrollers.

>>31903 Everyone loves bitching about Rust, but what's the alternative lmao? C lmao? I love writing three pages of boilerplate to open a text file lmao! Or how about C++, where it's three languages in one, all of which are bad lmao?

>>31918 >C lmao? I love writing three pages of boilerplate to open a text file lmao! Isn't it just three lines (FILE*, fopen, fclose)?

>>31907 From me: no named arguments, no closures, syntax is quite janky just to attract C/C++ people or to be as explicit as possible (@ for builtins is quite disgusting, for example). Also, camel case is garbage. I also wonder if comptime can replace real (i.e. not cpp/m4) macros.

>>31903 >you can't even implement linked lists without unsafe If you believe this, you clearly have a very uninformed opinion of the language.

> The learning resources also feel like the best I've ever dealt with, ive literally seen glitterboys say this about their favorite languages 100 times for each language

>>31932 >No, rust has had closures for a long time. The post they were replying to was asking about zig, not rust

>>31918 C, Go, Limbo, ALGOL, LISP and many others

>>31928 >C Fun activity: go to Rosetta Code, look up the C example for any given program, and compare it with literally anything else. You'll notice that the C code is like four times as long for no good reason. >Go Garbage collected. No thanks. >Limbo What the flying fuarrrk is that? >Lisp See Go

>>31929 >Fun activity: go to Rosetta Code, look up the C example for any given program, and compare it with literally anything else. You'll notice that the C code is like four times as long for no good reason. I won't say that's completely wrong, but compare line lengths too. And there can be inconvenients to code golfing, mainly readability. Anyway, Ada should have been mentioned (lacks macros, though).

>>31915 >Rust, even though a systems language, literally relies on C/C++ to run on microcontrollers. Eh? This used to be true but building without the standard library is now a stable feature. >>31925 >no closures No, rust has had closures for a long time. >syntax is quite janky just to attract C/C++ people it's a lot less janky than C/C++ in my opinion. Is there any reason why we needed to put parentheses around the arguments to an if statement?

>>31925 >I also wonder if comptime can replace real (i.e. not cpp/m4) macros. no, definitely not. Macros are able to work on the AST level, comptime can't.

>>31935 >>31934 I remember the summer I went from fooling around with Rust to actually *getting* Rust was the summer when they had an intern rewriting all the error messages. The Rust team deliberately invests in making its errors and documentation readable and it does show. My only gripe is that by encouraging every crate to be fully documented it's tougher to tell if the crate you're depending on is actually a complete project. In other languages incomplete libraries are likely completely devoid of documentation other than a readme, in Rust incomplete libraries are documented to tell you all of the developer's hopes and dreams for the future and at a glance oversell the functionality.

>>31950 >but it's currently the least bad one out there Only if you must absolutely avoid any form of GC (including low latency like Go).

That is a great thing about rust, it's bringing life to the systems programming community with it's popularity and good docs. In languages like C and C++, almost every learning resource is outdated and people don't feel like getting used to it, it's just hard to get into because of the low resources.

>>31959 This is genuinely true. Trying to get into C or C++ purely from books and online guides just flat out is like kicking dead whales down the beach. There's just too much soykaf to think about or learn specific to it, (cmake, premake, meson, choosing a package manager soley for C/C++) that rust seems pretty much like a no-brainer with crates, rustc, and good documentation.

>>31958 >must absolutely avoid any form of GC Why do we accept the pervasive pessimization of GC everywhere? Imagine how much faster everything would run, and how much RAM and electricity we'd save, if we just stopped using the GCed languages.

>>31961 You do garbage collection in every language, just sometimes it's computationally cheap (manually calling free() or calling free() when an object goes out of scope). Sometimes automatic garbage collection is good just because it allows the programmer to avoid implementing their own.

>>31826 rust >unstable APIs >slow compile times >no safer than modern C++ >only vaporware projects are written in it >not used for any major projects used in production across many enterprises (servo was a fuarrrking disaster, firefox's code base has been fuarrrked to hell with half implemented rust) >gui frameworks in rust are a joke or nonexistent >all "fast" rust projects either use unsafe all over the place or are just getting their speed elsewhere (such as the GPU, could get same fast speed in a slow lang on the GPU) >the """standards""" are controlled by a consortium of rich companies >95% of new code written is already memory safe (written in a GC language) >rust is trademarked, another iceweasel disaster waiting to happen >cant even generate random numbers without bringing in a crate fuarrrk rust, literal cancer language that brings nearly nothing to the table. it's use cases are so minimal to near nonexistent, and if it ever becomes industry standard it will take 50 years of work to rewrite all of the C and C++ libraries. im not going to wait half a century to get a fuarrrking stable and mature GUI library also, i have noticed that everyone who seems to "love" rust either has never actually programmed in it, or is in their first month, and has only made toy projects with it. change my mind, if someone here has actual experience using rust for multiple years, and multiple years using modern C++ prior, please refute my points and explain why im wrong. im willing to commit more time to rust, i just dont see a true use case yet or possibly ever

>>31963 >also, i have noticed that everyone who seems to "love" rust either has never actually programmed in it, or is in their first month, and has only made toy projects with it. Prove me wrong Nick Mathewson, one of the early members of the tor project, did an interview with the Rustacean Station podcast a few months ago about Arti, the Tor implementation in Rust. With his 20+ years experience of C, he still seems to be excited about Rust and enjoys using it. In the interview, he says he can't think of an instance where he would start a new project in C or C++ over Rust.

>>31971 Then he's a fool. Rust is mostly better than C++ since that's what it's designed for, but you can't directly compare it with C. Why? Because: 1) Compiler size and complexity matters in some high assurance scenarios, and Rust doesn't have something like compcert. When Linus screams about a bug in gcc/glibc, remember g++/libstdc++ and clang++/libcxx are orders of magnitude worse; and I bet you rust (LLVM + frontend + standard library) is even worse. 2) No standards and no stability yet. The ecosystem is just too immature to rely on it without having to track breaking API changes and deprecation by competition in the crate space. 3) You can teach programming using C to students (even with all the problems of C; which will harden the students against the suckiness of modern programming and highlight the need for rigour), but with Rust, there are simply too much concepts that needs to be taught before the students can understand what's going on without becoming a "push button get banana" code monkey. Ada really should be the wise choice when wanting to replace C/C++, for now.

>>31972 >Then he's a fool. The reason for mentioning him specifically is that the post in question (>>31963) asserted that no rust fans have real programming experience or experience building "real" rust projects. His appearance on that podcast is mentioned just as a verifiable counterexample to that assertion. I don't think anyone is going to disagree that there are use cases where C is better than Rust. His statement was made in a podcast that mostly focused on his field of work and personal interests; it should be clear it's not as a blanket statement for every domain. >You can teach programming using C to students (even with all the problems of C; which will harden the students against the suckiness of modern programming and highlight the need for rigour), but with Rust, there are simply too much concepts that needs to be taught before the students can understand what's going on without becoming a "push button get banana" code monkey. I disagree slightly with this. I think C is one of the best choices for a first language for students, but I don't think Rust is so complex that it can't be taught to students. I wouldn't recommend Rust as a first language, of course, but the learning curve really isn't as bad as people make it out to be.

>>31980 Rust is unironically a reference to Zersetzung (literally corrosion) https://en.wikipedia.org/wiki/Zersetzung COINTEL death by 1000 cuts designed to make you crazy. Coding in Rust seems exactly like this IMO, like you start writing something inside a Kafka trap, begin arguing with a borrow checker, and if you win the argument it's like you've solved some fuarrrked up cache 22 that never needed to exist, just to pacify a paranoid compiler that people are actually out to get. The community covenant (what the fuarrrk is this political soykaf that even OP has to pre-deflect? It's Stasi soykaf? An ex-KGB divide and conquer psyop now missing its head) carries out the objectives of old Stasi / KGB demoralization campaigns using Rules for Radicals tactics - namely holding the [no bad] target to strict yet selectively enforced rules in order to remove political opponents (not 100% on board with whatever-the-fuarrrk-ism) from their curated ecosystem. So, yes, rust users are fools. They wouldn't willingly use a language that was an implementation of Zersetzung - Increased cognitive load for no real benefit is one of their go-to operating objectives. Disrupt, Degrade, Destroy. It's all part of the multi-headed hydra of critique. Think about it as if it were a Critical Theory weapon - critique C++ et. al. as being "unsafe". Sew division among programmers. That's what Rust is.

>>31979 >I disagree slightly with this. I think C is one of the best choices for a first language for students, but I don't think Rust is so complex that it can't be taught to students. I wouldn't recommend Rust as a first language, of course, but the learning curve really isn't as bad as people make it out to be. I'm not talking about learning curve per se, but automagic concepts that most experienced programmers just gloss over because they're simple to them. For example, smart pointers/reference counting may be simple to you, but to someone who has never programmed, it's a case of "wat". Forget RC, forget GC and forget RAII, malloc means "give me memory" and free means "give it back" is something everyone can start with (bonus: it's very easy to explain a naive version of malloc that just searches a gap big enough in a table). PS: I just read https://pcwalton.github.io/2013/03/18/an-overview-of-memory-management-in-rust.html and what the fuarrrk is wrong with the Rust people? ~ and @ operators that applies both to lvalues and rvalues instead of a clean and readable malloc/new? fuarrrk, I hate this retarded language.

>>31979 C, at least to me, has too many sharp angles to work well as a beginner language. The technical details distract from the important bits like math and logic. In general, I don't think beginners should be using anything even close to as low-level as C. I personally started with BASIC before later stepping down to assembly. Knowing the former game me a good "mental map" for the latter, and having something like that is important. >>31981 Whatever you say man. >>31982 To be fair, most C family languages have fuarrrking retarded syntax.

>>31982 That article is from 2013, before Rust's first stable release, and does not reflect Rust's actual syntax.

>>31984 >To be fair, most C family languages have fuarrrking retarded syntax. Except the horrible type specifiers and the statement/expression divide mandating stuff like ternaries, I don't particularly dislike C. I find it has a nice text/symbol ratio.

>>31984 >To be fair, most C family languages have fuarrrking retarded syntax. No, it makes a lot of sense. int f(int x); is significantly better and more readable than fn f(x: int) -> int

>>31992 Not >>31984, but I think that `fn f(x: int) -> int` and `someParam: fn(x: int) -> int` make more sense together than `int f(int x)` and `int (*someParam)(int)`.

>>31992 Considering int fun(int x) and fn fun(x: int) -> int . A function's name is more important than its return type. I would like to know it before what knowing what arguments it takes and what it returns. It's easier to search for a function named fun as you are doing a fixed-string search for fn fun instead of who-knows-what-it-returns fun . The function signature looks awful in languages that support generics. SomeClass<int, float> fun(SomeOtherClass<int> x) You cannot use the return-type-first syntax if your return type depends on the types of arguments. See decltype in C++.

>>31996 C-style declarations also make type inference a pain in the ass. See C++'s auto . Rust's way of doing things is a lot more sensible; you can slot the type specifier in pretty easily if you need it, but otherwise it defaults to figuring things out for you.

>>31882 >Won't die >Has zero adoption That which never lived can never die

>>32020 Rust sees a pretty good amount of use considering it's a new-ish language in a pretty crowded niche. I say give it another 5-10 years before making a call like that. I could easily see it ending up in the same limbo as something like D, but at the same time, it's got a much stronger marketing push than most "C++ killers", and as history shows, that can contribute a lot to a language's sucess.

>>31969 If GTK is your example of a high quality GUI framework then you're kind of proven his point. Something I noticed that he didn't mention but I will. Rust claims to be a memory safe language but doesn't have a formal memory model. In addition unsafe is globally unsafe instead of locally unsafe. Meaning an unsafe block could corrupt memory anywhere without much of a restriction or even a way for programmers to know that it is corrupted. Rust defenders are quick to dismiss the second point - because it defeats the point of their language. Pottering pointed this out recently and the usual blue haired freaks came after him.

>>32022 >In addition unsafe is globally unsafe instead of locally unsafe. Meaning an unsafe block could corrupt memory anywhere without much of a restriction or even a way for programmers to know that it is corrupted. What would "locally unsafe" even mean? That you can only create an invalid pointer to certain chunks of memory? So you have to restrict pointer arithmetic. >Rust defenders are quick to dismiss the second point - because it defeats the point of their language. No, it doesn't. The point of 'unsafe' is that it makes the programmer aware of where memory problems can originate from. Even if rust had no safety guarantees, I would prefer rust over C/C++ just because it's more ergonomic to write safe code. It is very rare that I need to dereference a pointer in rust.

>>32023 Something like Vale, I suppose. See https://verdagon.dev/blog/fearless-ffi

>>32023 Yes, unsafe should be restricted to just the local area. Otherwise there is no point to memory safety outside of unsafe. The safety claims made by rust fans are overstated. As I mentioned before, rust doesn't have a formal memory model and it doesn't support formal validation. Saying rust is more safe than C++ is just an opinion. Pointing out that Mozilla, Google, and the Linux foundation have either abandoned the language or confined it to restricted areas isn't an opinion

Why does Rust make people so assmad? It's impossible to start a conversation about it without it throwing people into an autistic rage. It's not like it's COBOL or PHP levels of awful or anything; it's just kind of there. And I keep hearing about these mystical "Rust fanboys", even though I've seen way more people bitching about them than actually witnessing them for myself.

>>32033 >Why does Rust make people so assmad? A few reasons. Rust makes people have to program in a constrained way, some people hate that. Rust is often used as a tool to critique C and other languages, some people hate that. Rust has a highly left wing and corporate surrounding, some people hate that. >And I keep hearing about these mystical "Rust fanboys", even though I've seen way more people bitching about them than actually witnessing them for myself. They mostly swarm reddit and things like that I think, they're less common on image boards and the like. Hackernews, reddit etc. is full of people speaking of how great rust is and speaking of rewriting things in rust.

>>32031 >Yes, unsafe should be restricted to just the local area. how do you define "the local area"? A certain small offset? How can you know for sure that the pointer isn't going beyond that offset at runtime without a performance hit? Can you name a language that does this?

>>32052 > But when someone points of the obvious deficiencies with the language you pull out this bullshit about "Rust isn't trying to be safe". Which is obviously a lie Something can be impressive while simultaneously not being the defining feature. Rust's main goal is "A safer and modern alternative to C++", which it does well. C++ as a standard is incredibly bloated, and there are major hurdles to cross in the standardization process that make it almost impossible to fix or add anything. Look at some of the stories of what people had to go through for even a chance of something being considered for the standard. The objective of Rust is something less bloated with modern features and comprable speed, more safety is one of those features; unfortunetly, it's being touted as the landmark feature and the main reason people should use it when doing an elevator pitch, which leaves people with the impression that it's safer than it is. >Then there is no point from the perspective of "safety" to moving to rust and C++ still dominates. If Rust was a perfect language to every developer alive, C++ would still dominate; not because it is the superior product, but because there would be measurable time it would take just to move away from it. C++ has decades on Rust, even if everyone agreed to move now, you're talking about potentially months for people to even agree on what libraries and APIs to use. There is nothing now and will not be anything in the future that will simply dethrone C++ like languages did in the days of yore, it will be a steady decline of C++ followed by the rise of it's competitor. See: PHP. Usage of Rust is increasing, and as the language and it's tools get better, that increase will be faster, and more people will be trained with it, slowly overtaking the king. Don't forget how long it took for Python to explode in popularity. Rust is not the king of safety nor is it attempting to be, but Rust is currently the best bet for the future. The benefits of Rust are an energetic and supportive community, a much faster evolution process for the language, and modern ammenities in a fast and low level language. Also, not OP.

>>32036 >Rust makes people have to program in a constrained way, some people hate that. Rust is often used as a tool to critique C and other languages, some people hate that. Rust has a highly left wing and corporate surrounding, some people hate that. You are right on point. One time somebody was asking what they should learn for getting into embedded systems. I pointed out they should learn C, just to be interrupted with some troll telling it is "deprecated" and to learn Rust instead. Well either troll or uninformed, as I never saw a microcontroller on the wild running on Rust, and would rather stay away from folks like this, thus also from the language itself. I think it is the same breed of people who hate on Perl just because Python exists.

>>32054 It's funny because despite demonstrating that one of my reasons why rust is hated is correct I don't fully agree with your hatred (though I mostly do). If your definition of embedded technology includes things like routers and tvs, which nowadays host full minimalist operating systems etc. then Rust actually is a good choice, since those are mostly programmed in C++. If you only mean microcontrollers with like 16k of ram then yes, Rust and C++ are both terrible choices. I think you're right to disagree with people making that claim but it's worth considering it isn't entirely insane.

>>32054 > One time somebody was asking what they should learn for getting into embedded systems. I pointed out they should learn C, just to be interrupted with some troll telling it is "deprecated" and to learn Rust instead. Sounds like trolling, where was it? There are a lot of people who call c/c++ deprecated and say "rewrite it in rust" to meme/troll. Embedded systems in Rust isn't impossible but I don't think the people involved with it currently recommend it for anything other than hobbyist programming. It's sort of like the "install gentoo" and "i use arch btw" memes.

>>32052 >you pull out this bullshit about "Rust isn't trying to be safe". That's a pretty gross simplification of my post. Rust is specifically trying to be safer than C++. And like it or not, for the most part it is.

>>32078 >safer Just write better code.

>>31929 >What the flying fuarrrk is that? Place unbabtized toddlers go when they die according to roman catholic doctrine. Also a name for one of few programing languages designed in Bell Labs somewhere around the time of designing and implementing Plan9 Operating System. >>31930 >Anyway, Ada should have been mentioned (lacks macros, though). Macros are just preprocessing. Nothing stops you from using M4. t. not an Ada fan

>>32079 "Write better code" feels an awful lot like argument from principle. I'd much rather have the language itself take care of the grunt work rather than writing out every bounds-check and memory deallocation. The Real Programmer approach takes more work, leads to ugly unreadable code, and in the real-world (as opposed to benchmarks with limited scope) results in binaries that are basically the same as if they were written in a language like Rust that automates the obvious. >>32085 I take it you've never used Lisp?

>>32091 Not the guy you're replying to but I think your arguments against C++ are based on personal taste over actual logic. Modern C++ removes all the grunt work you talk about through techniques like RAII, smart pointers etc; It's mostly write once nowadays. Meanwhile in rust you will always have to please the borrow checker in everything you do. I am not experienced enough with rust to have 'gotten used to' the borrow checker but I know it certainly makes some common things like writing games a pain in the ass. I don't know if it could be objectively proved but I think modern C++ takes less work to write than rust and is nearly as safe. A place I used to work at had a no raw pointer policy for its C apis too, they were always wrapped to be safe via modern pointer types.

>>32096 Yeah. So how can you confuse text based macros with "actual" macros working on ASTs?

>>32104 Not him, they're still preprocessing, lisp macros remain at compile time. Unless I'm misreading you also just stated 'macros' not lisp macros. I'd argue most meaningful macros don't need the power of lisp macros to perform their job anyway.

>>32105 >Not him, they're still preprocessing, lisp macros remain at compile time. Yes. >Unless I'm misreading you also just stated 'macros' not lisp macros. Yes, my mistake. I meant macros better than cpp/m4 because those are soykaf. >I'd argue most meaningful macros don't need the power of lisp macros to perform their job anyway. Now we can disagree. I can't even imagine building something like loop in something else than Lisp.

>>31918 >C lmao? I love writing three pages of boilerplate to open a text file lmao! I unironically do because that means I have more in depth control and can optimize better. + it's really not hard to write a function if you want the whole text file as a single character array in memory.

>>32107 >Now we can disagree. I can't even imagine building something like loop in something else than Lisp. I initially wrote that I couldn't see any of those macros being objectively cleaner or more meaningful but I thought more and I actually agree. My initial stance was that I also couldn't see loop being done in C++ macros, but that such macros were useless. After thinking more, whilst still niche list comprehensions satisfy all the requirements I'd want for the superiority of lisp macros. So yes I do actually agree, you are right that there's a value to lisp style macros I didn't consider. The main thing that changed my mind was actually reading over the list comprehension implementation in a stackoverflow post when trying to find them implemented in C++ (which I couldn't): https://stackoverflow.com/questions/267862/what-makes-lisp-macros-so-special

>>32145 That SO loop example is particularly disgusting. Try comparing ;; Original (loop for x in (range 10) if (= (mod x 2) 0) do (setq divisibleByTwo (append divisibleByTwo (list x)))) ;; Idiomatic (setq divisibleByTwo (loop for x below 10 if (evenp x) collect x))

>>32147 Whoops, read the post more carefully, and it's to match the ugly and featuless Python list comprehension. Anyway, loop is clean enough that you don't even need such contraptions.

>>32147 I'm compelled to optimize that: (SETQ DIVISIBLE-BY-TWO (LOOP FOR INTEGER BELOW 10 BY 2 COLLECTING INTEGER))

>>32149 I understand, but that's not semantically the same anymore. In the pursuit of code-as-sole-documentation, I'd use the one which describes best what is to be done, not how.

>>31963 This is basically covers it. >>31981 But I like this angle better It's been over a decade, and the magnum opus of Rust is a grep clone. Mozilla leveraged the social clout of a shameless, paid evangelist, Steve Klabnik, who framed the language as a progressive crusade to save twenty-first century programming from the ghost of C++98. Oh, and they ousted the Graydon Hoare from *his own damn language* so they could twist it into C++-like mutant with pedantic yet highly arbitrary opinions on syntax and the least-interesting parts of ML . . . also without the benefit of the millions of man-hours invested in C++ libraries. People dabble in Rust because they're terrified of admitting a sunk cost or because they want to be noticed as someone who dabbles in Rust. Rust is the Aral Sea of programming.

>>32164 rust is taking advantage of the incoming wave of "trusted" computing. (like pluton) All this talk about "safety" is from organizations that want to lock down computers. Its riding the wave of marketing for "safety" and also pushing the idea that "safety" in computers is "critical" and civilians & programmers without a security clearance can't be trusted or allowed to have low level control of computers. Instead everything has to be managed, and access only provided through limited interfaces that make the machine a black box. If the internet requires a real world ID, signed OS, signed web browser to use, then corporations won't have to bother securing their horrible servers anymore. Web services can be made as stupid and incompetent as possible and no one will be able to take advantage of it or complain about it. >>32052 Its motte-and-bailey sophistry. They argue programmers shouldn't be trusted or allowed to directly modify and manage memory, and only "safe" languages should be permitted, and that rust is "safe" because the compiler prevents "unsafe" code from compiling. Then they argue its fine to be "unsafe" sometimes. But you can and should do the exact same thing in C anyway - limit the places you allocate and free memory for better performance, organization, and ease of debugging.

I'm sick of every Rust thread being about the culture surrounding it rather than the technical merits of the language itself. >>32130 At that point, you should just use Forth. It's lower-level and more powerful. Teaches you way more than C to boot. >>32166 I can guarantee you've never used Rust in your life.

>>32169 >Forth low level Bad meme. A typeless stack PL isn't low level when used on register based µarchs.

>>32170 There are extremely simple processors which use forth as their assembler language. That's probably the main use of forth in real-word applications. With the exception of transports triggered architectures, I doubt you could get lower level than that.

>>32166 For years I've wondered why Google had its trust-fund-baby Mozilla pay hipsters to hype Rust and spread all kinds of FUD about C and friends. Boring, albeit real and tested, solutions to these problems, like formal methods, were never part of the conversation. I couldn't figure out how Google was using this to make money or do evil. Now I know, but I wish I didn't.

>>32166 If you really want to speak to the computer, write directly in assembly, and if you're too much of a pussy for that then STFU. C is a very broad-strokes representation of the underlying hardware. The only reason people call it "portable assembly" is because it's fast and dangerous. But Rust and Ada are just pretty much just as fast and a whole lot safer. And no, I don't care about differences in memory use or whatever. C's a much bigger resource hog than its fanbois think it is. Pretty much any case where Rust or Ada is going to be too much is also going to be too much for C. Also, unsafe is a thing. You know that, right?

>>32179 I agree with anon. Don't bother with using C nowadays, it's hard to use and mostly a waste of time. Only people who are really good at it know how to write decent code, and that's as far as "writing efficient code" goes. Try opening hello world in gdb and you'll see what a huge fuarrrking runtime dependency libc means. Rust and Ada's atleast give you the advantages and not just 2 megs of boilerplate to allocate stack memory that isn't even used. Assembly is not worth your time either. Consider C and ASM curiosities that you should only look into if you're writing compilers or doing whatever work that needs to be done at the lower levels.

>>32166 >rust is taking advantage of the incoming wave of "trusted" computing. (like pluton) >All this talk about "safety" is from organizations that want to lock down computers. Its riding the wave of marketing for "safety" and also pushing the idea that "safety" in computers is "critical" and civilians & programmers without a security clearance can't be trusted or allowed to have low level control of computers. >Instead everything has to be managed, and access only provided through limited interfaces that make the machine a black box. None of this is true. >If the internet requires a real world ID, signed OS, signed web browser to use, then corporations won't have to bother securing their horrible servers anymore. >Web services can be made as stupid and incompetent as possible and no one will be able to take advantage of it or complain about it. This has nothing to do with rust >They argue programmers shouldn't be trusted or allowed to directly modify and manage memory, and only "safe" languages should be permitted, and that rust is "safe" because the compiler prevents "unsafe" code from compiling. What, you trust every executable you run to arbitrarily access any memory on your system? 30 year old DOS era malware called, it wants you to type cookie. Or do you just mean access within the program's own memory? Because Rust allows you to do that even without the unsafe keyword in most normal use cases. There are just compile time checks to ensure you're not using-after-free or mutating things the program expect to be unmutable, and other checks that make you less likely to shoot yourself in the foot. >Then they argue its fine to be "unsafe" sometimes. Yeah, sometimes you know more about what's safe than the compiler does. So what? That's not the "ha gotcha!" argument you think it is. >But you can and should do the exact same thing in C anyway - limit the places you allocate and free memory for better performance, organization, and ease of debugging. For allocating and freeing - why would I choose C over Rust? I don't want to deal with the boiler plate of allocating and freeing memory when Rust handles that at zero cost. If I want to free memory early in Rust, I can do that too (without using unsafe) and the compiler will notify me if that introduces a use after free error. Versus C where you do all of that by hand and in 3 years someone tweaks the control flow slightly, forgets to update your carefully placed free calls and introduces a crash or vulnerability. >>32169 >I'm sick of every Rust thread being about the culture surrounding it rather than the technical merits of the language itself. And people who clearly have never written Rust making incorrect claims like >>31982 who criticizes syntax that doesn't exist and >>31903 who thinks linked lists need unsafe.

>>32183 At that point, you're not really talking to the computer though; you're talking to C. I've written a good amount of code in both, and I can say from experience that the difference between the two is vast.

>>32189 You're not talking to the computer in user land asm programming much either, you're mostly talking to the OS when it comes to key actions. C's platform independence effectively emulates programming on the raw hardware, it removes the bullshit inserted inbetween by the OS that makes you focus on interacting with it rather than the computer.

>>32190 If you're actually writing userland asm you're probably only using it for inner loops or SIMD instructions where the compiler doesn't optimize well. If you actually write a syscall in asm instead of just using a C library you're doing it wrong.

>>32192 Except for kernel development

>>32193 Where you could use C++, Ada, Rust, or Zig instead, all of which are more convenient and offer basically the same performance (in Zig's case it actually outdoes C!). And in the cases where that .01% of extra speed really does matter, you should use Assembly.

>Bottom line, C is worthless. It doesn't teach you how the computer works It depends on where you're coming from. Someone who has only programmed in languages that hide pointers and memory allocations will learn a little bit more about the stack, heap, addressing in general, possibly even about cpu registers if they're exposed to register variables. Assembly exposes you to much more for sure, but C isn't without any educational merit. As an aside, my first major experience with C was at the end of a course on Assembly language, where we learned a little C and disassembled it and played around with that. The two in combination are better educational forces than either alone. >in pretty much every situation where Rust or C++ is too much so is C. There are some microcontrollers which don't have good rust support yet, but also are performant enough that handwriting assembly isn't necessary. C++ is usually available for those, but if you're not going to use C++ features, C is fine for them. >it's a massive pain in the ass Yeah, but it's not nearly as much of a pain in the ass as assembly is. It's also not nearly as fun to write as assembly. Anyway to be back on topic, Rust is nicer than C, but C still has its uses, and assembly is fun and the most educational but inconvenient for most projects.

>>32202 >the primary pain of C++ is that you can't look back at code and have any guarantees that code represents "good" or idiomatic code. This gets worse and worse the older a codebase is. I currently work with a large codebase that has code which was probably never idiomatic, but its currently version-locked by a key library which updated its iterators to a more C++11-friendly format.

OP here. >>31829 Valid point. >>31880 The best people in Rust seem to be distributed systems majors or just really good programmers coming from a selection of old programming languages including Ruby. >>31903 https://rcoh.me/posts/rust-linked-list-basically-impossible/ >>31906 And so is it for concurrency. Making an imageboard in Rust right now, got a little confused about whether I should use Pool or Connection for my async but it seems like the latter requires a mutual exclusion lock while `Pool` is made with multithreading in mind by the PostgreSQL team. https://git.catgirl.cloud/avdb/tokichan-rs >>31924 use std::env; use std::fs; fn main() { // --snip-- println!("In file {}", filename); let contents = fs::read_to_string(filename) .expect("Something went wrong reading the file"); println!("With text:\n{}", contents); } >>31928 The Gopher fears enumerated types, proper error handling and a strong type system. Trust me, I've made quite a bit of Go software and I'm RIIR some of them and it feels like Rust's syntax is a million times at showing what the code does. >>31934 Rust compiler is extremely verbose about errors and even makes good suggestions on how to possibly fix it. That was not the case with C/C++ if I had error messages to begin with. >>31958 Learning how to make the borrow checker will learn you a lot about static/dynamic types and their traits. Traits are one of the biggest strengths in Rust since it makes it very easy to understand the properties of objects and the implementations it inherits. >>31963 >also, i have noticed that everyone who seems to "love" rust either has never actually programmed in it, or is in their first month, and has only made toy projects with it. No. I have a friend who's running a company using a NixOS + Rust stack with 10 years of programming experience, he used to be a Ruby developer but jumped on the Rust train because having tried a million languages I prefer this one the most as it's a beautiful combination of C++ (procedural/object-oriented( and Haskell (functional). >>31981 Didn't make a single point about why the language is bad. Opinion discarded retard. Try to say something intelligent next time you post Gendo Ikari. >>32079 Just waste months of time trying to find a nasty deadlock in your API, sounds sweet. >>32097 C++ has a lot of historical baggage and outdated documentation. Its error messages are also not that good (I remember always getting errors about operator overloading even though I didn't even know what that was at the time) and in general it feels like it's still hard to make good software with it that doesn't segfault during runtime >>32166 Ignore Rust is dystopian technology schizo. I suppose that's it, have a nice week Rust hackers and remember to keep advertising the language in all your social circles. We will bring an end to a century of terrible memory management practices.

>>31826 >>32217 >Rust I agree that C and C++ is like kicking dead whales down the beach, but tell me why I shouldn't learn Go or Ada instead (or just further my knowledge of Python)? I don't know Go (or Rust) yet, but isn't the comfy and easy concurrency one of the main selling points of Go? I also like the fact that there are 2 Go compilers ("regular" Go and GCC-go). > We will bring an end to a century of terrible memory management practices. Already fixed with Java/C#, Python, Ruby, Go, etc. (they all are memory safe but data races can happen in these languages, however). Also, Ada is another memory safe language where data races can't happen. >inb4 garbage collection bad No, it's not (for most of programming tasks). This misconception comes from old and naive implementation of GC. Modern GC implementation are better than managing memory by hand (like in C or C++) in some cases (I guess this is because the lifetime of an object is not clearly defined in non-trivial programs). The only place where you can't use GC is embedded systems development and real-time systems (and possibly FPS games and OS kernel development).

>>32218 Not that lain, but while Go is nice, I find that Rust's borrow checker and other compile time checks makes it easier to write concurrent code that won't break. Go is fairly minimal as far as language features go too, which can make some things less fun to write, versus Rust's type system, pattern matching, and generics (I think Go has generics now though? I might be out of date on that). >Modern GC implementation are better than managing memory by hand (like in C or C++) in some cases (I guess this is because the lifetime of an object is not clearly defined in non-trivial programs This can be true, but Rust's memory management is zero cost, so why incur the gc overhead at all? And it is designed as a systems language where gc is less desirable. I'm not against garbage collected languages, but I've had a couple terrible times where gc bugs and oddities have resulted in strange errors that are very difficult to track down, even in recent years. When the choice is manual memory management, garbage collection, or neither st zero cost, I'll take neither.

>>32217 >The best people in Rust seem to be distributed systems majors or just really good programmers coming from a selection of old programming languages including Ruby. Not my point. My point is that Rust is mostly adopted by webshitters and glitterboys, rather than actual system developers. Also, a lot of the major Rust crates are 0.xs, which is obviously extremely unattractive if you are interested in building a large project in Rust. Other than these two points, Rust isn't too bad, and I'm probably gonna learn it at some point. But C++ will always be around because it's more powerful.

>>32219 Rusts memory management is also not formally proven and requires unsafe blocks to implement doubly linked lists. I don't see a safety advantage there

>>32221 >Rusts memory management is also not formally proven There are fornal proofs for subsets of the language >requires unsafe blocks to implement doubly linked lists. Entirely false.

>>32222 C++ has a proven memory model. I'm guessing none of those subsets include unsafe which is able to corrupt any memory in the program even outside of the unsafe block >Entirely false Can you implement a doubly linked list in Rust without using unsafe? Curious to see if it can be done with a true doubly linked list. XOR lists and similar tricks don't count. I'm pretty sure the borrow checker won't allow such behavior

>>32223 >which is able to corrupt any memory in the program even outside of the unsafe block Why do anti-rust activists keep acting like this is a big deal? Are you actually so retarded you can't write 5 lines of code that doesn't corrupt random memory? Or are you so retarded that you think it'as as easy to write 5 lines of correct code as it is to write 50000 lines of correct code?

>>32224 I guess it's because other languages, like Golang and Java, don't allow such memory corruption (and memory safety is one of the main selling points of Rust).

>>32224 So you lied in your previous post about being able to implement doubly linked lists that way?

>>32223 Some of them account for unsafe and have been used to verify unsafe code within the standard library and popular crates doesn't violate memory safety. >Can you implement a doubly linked list in Rust without using unsafe? Yes, implementing a doubly linked list is trivial with smart pointers provided by the standard library. >>32226 That lain isn't me. >>32225 You can corrupt memory in Java or Go using the Unsafe class or unsafe package respectively. Java also has some interesting things you can do with reflection and runtime bytecode generation that are not very safe. Unsafe isn't unique to Rust.

>>32194 See point 1 & 2 of >>31972

>>32229 >Yes, implementing a doubly linked list is trivial with smart pointers provided by the standard library. As a frequent rust user, I disagree. You would need to fuarrrk around with RefCells and Rc's at the very least, and there's no way it would be as fast as an unsafe implementation. Making your own data structures is an example where unsafe is good. Small, simple unsafe functions encapsulated with a safe interface.

>>31826 >Has lainon tried Rust yet? I have! It has been great, I even got a job in Rust, etc. But lately, using Rust has felt... off. I started to notice more and more things that I don't like about it. One of the biggest things has been how huge the language feels. There's all this complexity that keeps me from being productive, not counting the borrow checker, which made me reach for simpler languages whenever I programmed lately. The community (read: mostly developers) being so seemingly against the idea of a standard, introducing new features left and right and, although being vocal about a standard, are almost actively working against any effort by growing the language more and more. A culture of small and unvetted packages, with up to hundreds of dependencies per library, is making me reconsider it, too. Being hosted on GitHub, a non-free proprietary platform owned by Microsoft, making it impossible to contribute without using the platform, is another thing that just rubs me the wrong way. All in all, I'm asking myself whether the safety it offers is worth the tradeoff. Maybe I'm just better off with a more simplistic language until at least some of these problems have been fixed, or forever, if I decide such complexity in a programming language isn't something for me. >The learning resources also feel like the best I've ever dealt with This is true! The Rust team is doing a great job with introducing the language to others, having overall _amazing_ code documentation and being friendly to newcomers that want to learn. Rust docs are what I've always wanted but was always lacking in other languages, with a nice search interface and a proper interface for documentation. >I haven't ran into any significant problems with the language unlike Go The article talks about fairly nieche, cross platform problems mostly, as well as dependency related problems (specifically, the number of dependencies a library has), which Rust definitely isn't immune to and has, too. Don't write software for non-free operating systems in the first place, and if you're using Windows for programming, just stop. You're just giving people a reason to use the proprietary platform that all of us so desperately want to go away. >I think in the future it will entirely replace C++ For it to replace C++ it needs a standard first, as well as alternative implementations of the standard in the form of other compilers. Rust on embedded is a soykaf show. Trust me, I've tried. For example, Espressif's IoT Development Framework[0] is being used for development with Rust by providing a safe interface for Rust programs to use[1]. The toolchain for this with Rust is worse than hideous, with the releases of these crates being worse yet, with fuarrrked up releases left and right, making a stable development environment with the newest releases impossible. Errors are impossible to debug, documentation is outright horrible, and help is only given with a "RTFM attitude", which is laughably ironic. [0]: https://github.com/espressif/esp-idf [1]: https://github.com/esp-rs >>31882 >the community seems to have this collective belief that they're competing with javascript I agree. This is one of the things that rub me the wrong way. Rust isn't trying to compete with JavaScript on any level, people are just tired of JavaScript in general and now want to throw anything at the web and see what sticks, namely nothing yet as there hasn't been a programming language that is actually targeting the client side of the web properly, and browsers seem to be slow to adopt anything else than JavaScript at best. This is a completely different class of issues though, the web is fuarrrked, almost beyond repair at this point IMO. >>31903 You're not contributing to the discussion in any meaningful way. Give sources people can read up on and to support your statements, not a half-assed attempt at sentences like >the most complex things made with rust are rewrites of programs that no one asked for that can't even be proven. At least sage your post. >you can't even implement linked lists without unsafe You lack basic understanding of the language. To form an opinion, at least read up on what you're talking about. >>32229 >Yes, implementing a doubly linked list is trivial with smart pointers provided by the standard library. I wouldn't describe it as "trivial". Not at all, actually. It's perfectly doable, but not trivial.

>>32241 I'm glad to finally see informed criticism of Rust. I have massive problems with that language, but I feel like a lot of the discourse is just "lol tranny language" soykaf from people who've barely used it (if at all).

>>32245 Everything you've said about the people and.the ethics are the reason why other people despise Rust. It will never gain any traction in the real world because of its community and their inability to listen to criticism. Your problem is that you want to dismiss the criticism because of some vague answer that the people criticizing Rust don't agree with the politics of Rust programmers and don't have the problems with C that Rust people seem to complain about. I'm sure I'll get responses proving this point. You're not going to convince anyone by waving the legitimate criticism away by saying "you just don't understand rust"

Is Rust an adequate next step for a new user? I have been crapping together stuff with shell scripts and a bit of Python without really understanding well things, and have writen PHP in the past (somehow worse than shell at times). I don't really have an economic incentive behind that decission RN, but some people say that C++ may be more appealing just in case i change of opinion because is everywhere under the hood.

>>32247 If you want to make dough: no, learn C++ If you want to have fun programming: no, use a lisp-like. Racket is my favorite. If you want to make a certain thing: maybe. The only domain I can think of where I would actually just recommend rust is high-performance network programming. >>32246 >I'm sure I'll get lots of responses proving this point Congratulations!

>>32247 Both C++ and Rust are very complex languages. I think C++ has better tooling but there isn't a package manager (apart from your OS package manager). I'm currently trying to decide what language to learn as well. I think I might learn Golang, since it's simpler and has easy and simple concurrency features. I think Python (and other scripting languages in general) is a good first language. > I don't really have an economic incentive behind that decission RN, but some people say that C++ may be more appealing just in case i change of opinion because is everywhere under the hood. It's definitely easier to get a job as C++ programmer. But if you want to make money, you should learn Java/C# and further your Python skills. For learning C++, I recommend reading PPP2. >pic Cute doll.

>why is there no rust thread yet? There have been several, they always devolve into mudslinging like this one. For all I enjoy the language (mainly for reasons you stated) I still wouldn't use it for anything serious. Too many things are unstable and standardization/specification is not good enough yet.

Thanks for the advise gals >>32248 >If you want to make dough Sorry, what does this mean? Cash? Libraries? Either way i am stupid for now so i'd say is mostly for self learning and maybe help to report bugs someday. >>32249 Haven't considered Golang, but it looks allright. I've heard that external dependencies on C++ can be a special challenge as well. Meh, at my level it shouldn't matter much for now.

>>32246 >Everything you've said about the people and.the ethics are the reason why other people despise Rust. That's just... wrong. There's no other way to put it. Most people criticising Rust are like >>31903, pure ignorance to the language, to the point of actually believing that linked lists can only be implemented in unsafe Rust. If they are talking about the people and ethics behind the Rust language they should argue that way and not spew incoherent sentences about how the language works without knowing anything about it. And no, >tranny language is not an argument against the Rust programming language. I'm sure there are people like the ones that you are describing, and I'll be glad to listen to them, but that's not the reality. >Your problem is that you want to dismiss the criticism because of some vague answer that the people criticizing Rust don't agree with the politics of Rust programmers and don't have the problems with C that Rust people seem to complain about. Now you're just being rude and assume what I'm thinking. I'll stop replying to you here. Stay in your bubble if you'd like, but don't bother everyone else with it. >>32247 >C++ may be more appealing just in case i change of opinion because is everywhere under the hood. C++ is around more, that's true. If you want to go the safe way, by all means, go ahead and learn C++. Otherwise, think about learning Rust!

>>32249 >I think C++ has better tooling but there isn't a package manager (apart from your OS package manager). Wrong, see conan or build2. >I think Python (and other scripting languages in general) is a good first language. Good if you want to stay a chump. Going from system programming like C/C++/Ada/Rust to Python is very easy, but the opposite isn't, as the amount of jank to bear and rigour requirements hit you all at once, and you can easily give up since you already know a PL.

>>32256 That the core team, as compared to any other language development team, has overwhelming over representation of male-to-female trans with dyed hair is objectively true. And all that apologetics doesn’t change that the only thing anyone has done with rust is duplicate the effort of grep.

Is Cargo package manager secure the way my distro package manager is? Does Cargo check signatures?

>>32247 If you've only ever used scripting languages, I recommend something higher-level like Go. Rust is a very strict low-level systems language, basically the opposite of Python and especially PHP. >>32261 More importantly than anything >>32256 said, that's only tangentially related to the language itself. The Lisp thread isn't about how all Lisp programmers are snobs using a long-dead language, it's about fuarrrking Lisp. That should also be the case for Rust. Even if you're making factually correct statements, they're completely unhelpful for the purposes of this thread, especially when they've already been said multiple times.

>>32261 The core team has zero transwomen: https://www.rust-lang.org/governance/teams/core >lol ripgrep There are examples in this thread of other successful projects in Rust. One second on a search engine will lead you to plenty of articles about big name companies that use rust in production as well: https://careerkarma.com/blog/who-uses-rust/ Everything you've stated is objectively false.

>>32267 >Rust as a whole certainly is a trannyfest, What isn't nowdays? C might not be, but the only reason is because it's a dinosaur language at this point. Everything new, no matter how good or bad, will have troons in it's community. Everything related to tech nowdays has them. It's pointless to say that.

>>32268 >What isn't nowdays? Everything that's not too popular is usually "OK". CL, Ada, C, Fortran, etc... And I don't mean the lone troon, because the open source world is more and more "filled" with them, but an eyebrow-raising proportion, like Rust has; and more importantly, official positions on the matter.

>One of you Janissary-collaborators deleted the photographic evidence that was posted in this thread. those three pictures of random trans people? Yeah, what overwhelming evidence you have.

>>32276 >Much like dying your hair some unnatural color and posting programming socks lewds on your ‘gram Someone is clearly upset that they're old now. >Cut your losses and sling Java. Ah yes, perpetuate the idea that a language that doubles as a boat anchor is the only way forward. Java will be the next PHP within the next ~10, legacy projects and nothing else, powered by an ecosystem as ancient as the language itself. I've heard some people mention a new language called Python, looks okay but you better learn Java and C, it's just another new language that will never catch on, just for edgy people who probably dye their hair some unnatural color and script kiddies to post something on their MySpace. It's perfectly okay to be skeptical of newer languages, but eventually the reaper is going to come for languages developed before most people on this site were born. In the last 20 years, computers have advanced at an incredibly fast rate, and the languages we use will also have to evolve accordingly. If everyone thought like you, we'd still be writing C and FORTRAN for everything because it would be better to "cut your losses and not take the chance it'll take off". Just like real life, a small portion of the population wants to keep the world in the past so that they understand it and feel safe. It's funny that people who don't want to use a language because of who is a part of the community surrounding it are also the same ones who try to derail, brigade, and strawman any community interested in discussing the language, as demonstrated in this thread. >One of you Janissary-collaborators deleted the photographic evidence that was posted in this thread. If a single photo is your primary evidence for almost anything, you didn't have a valid argument to begin with. >>32276 is the last sane lainon in this thread. To get back on track: What's everyone's opinion on using Rust for embedded or as a backend? Benchmarks between Rust and Go as a server seem incredibly close in performance.

>>32278 >What's everyone's opinion on using Rust for embedded embedded: it still has a ways to go, by all accounts. I'm not exactly an embedded developer but I've tried to learn with C in the past, it seemed to be overwhelmingly the case that to code productively you need some libraries which are often supplied by the CPU manufacturer and probably a customized linker. Those don't seem to be there in rust yet. However a lot of key libraries that one might want to use are no-std compatible these days, which means once embedded rust becomes more mature there will be plenty of libraries to use. >or as a backend? it depends what kind of backend you're making. There's obviously no reason to prefer rust over go unless you need really high performance or you just know one or the other better. I've used tokio to write an HTTP reverse proxy before (just a personal project that I abandoned due to lack of time), I found it to be overall pretty good, it was easy to paper over the headaches of parsing HTTP with a few libraries. I'm also writing a UDP server at the moment, I need absolutely minimum latency and it's not a headache to write performant code. I may need to write some sections in raw assembler though, just because LLVM isn't good at auto-vectorization. The fact that rust's error handling isn't crap is also a big plus. > Benchmarks between Rust and Go as a server seem incredibly close in performance. which ones? https://www.techempower.com/benchmarks seems to have all go servers at #22 or lower (and surprisingly a javascript one in fifth place! Must have a really good tracing JIT) on throughput, though they're clearly competitive on latency. Although, I suspect these contrived benchmarks wouldn't be truly representative of the performance of a real program. I suspect a well-designed rust program would be very slightly faster than a well-designed go program, all things considered. The question is which is easier to write a well-designed program in. I'm always a little wary of garbage collectors because they usually have edge cases where they can magically introduce performance drops if you're not careful, and they may need tuning to work well. It's possible to accidentally write performance killers in rust too but they're usually easy to spot and clean up if you know what you're looking for.

>>32286 Java is not a good language for just "getting things done". Its main asset is the JVM (a platform it shares with other, better languages). Outside of that, it's a dated product of the 90s OO craze, and an incredibly inconvenient language to program in. It tries to be Smalltalk and C++ at the same time, and for the most part it fails at both.

>>32291 I don't think you understand the concept of a get-things-done language. C is a get-things-done language. Nothing fancy, and nothing that gets in your way. Good library and platform support also. Yet people will all call C dated, or say it's missing feature du jour, or complain that it is inconvenient to program in. Getting things done is about being convenient to program in. If you have to write 30 lines of code where you might use one in another language, that is fine. Typing you see, was never the hard part about programming, and people who get things done know this. They will sit there and type those 30 lines because that's what they need to get things done. They also understand that one clever line of code is a lot more effort than 30 stupid ones. This is why FP fails. You can design a good program, and the language might tell you that it isn't, make you expend some mental effort to fix it. That same is true for Rust. As well as expending effort solving problems, you must expend effort circumventing the restrictions that have been put in place. Java is a tool box and Rust is a prison. Any complaints about missing tools don't stack up to the more fundamental issues of Rust.

>>32292 C gets in my way a lot though. Having to perform memory management and saftey checks manually introduces a whole new class of bugs that I wouldn't have to care about in a language that automates these things. That aside, I get your point but I disagree. Getting something done =/= getting it done well, and the latter matters a lot more than the former in the long-run. I've worked with enterprise Java codebases before, and it's always the same story: "we want to do x, it would be extremely valuable if we could do x, but because of bad design choice y we can't do it without basically rewriting everything from the ground up". And I get that every large program written in any language has a bit of that, but "get things done" languages are overwhelming prone to it, as anyone who's used PHP or Cobol can attest.

>>32293 >we want to do x, it would be extremely valuable if we could do x, but because of bad design choice y we can't do it without basically rewriting everything from the ground up Now imagine you are using Rust, and this change affects lifetimes in some unforeseen way. Or, worse still, you are using Haskell, and this change requires you to introduce some state into a function deep in the call stack. At best you will need to re-write every function that calls that one, recursively up the stack. At worst you will need to re-design the entire data-flow throughout your program to account for this small change. I'm not going to pretend that there can't be a better language than Java, or a more concise one. I'm not going to act like C is perfect by any means, because it isn't. The better language I imagine would have many of Rust's features (for it is a superficially appealing language) but it would not be Rust, and it has not yet been created. Even once it is, there can be no guarantee that it will be popular enough to warrant use, or that something else not related to its design will make it a bad value proposition.

>>32295 Meh. You underestimate how quickly things can change. I'm also not a huge fan of the idea that pragmatism should be the only thing that matters in CS. Most of the important innovations were made by academic types. If it weren't for them, we'd probably all be programming in Cobol.

OP back. You don't need to ever create a linked list in the first place since there's a 100% safe implementation in the standard library, or at least I've not been able to find any unsafe blocks. https://doc.rust-lang.org/src/alloc/collections/linked_list.rs.html#50-55

>>32316 impl<T> LinkedList<T> { /// Adds the given node to the front of the list. #[inline] fn push_front_node(&mut self, mut node: Box<Node<T>>) { // This method takes care not to create mutable references to whole nodes, // to maintain validity of aliasing pointers into `element`. unsafe { //...

>>32295 >Now imagine you are using Rust, and this change affects lifetimes in some unforeseen way. Or, worse still, you are using Haskell, and this change requires you to introduce some state into a function deep in the call stack. I can't comment on Rust, so I'll address your point about Haskell. Firstly, it is hard not to notice that the programmer in your example is most likely doing something wrong if he needs to introduce state deep into the code. However, you people were talking about cleaning up after bad design, so I will abide by your example rather than counter it, which would be unfair. You implicitly propose two scenarios that differ only in the language used (Haskell in one, and an unnamed imperative language in the other), to show how the awkwardness of doing X in Haskell puts it at a disadvantage. Is such a scenario plausible? What about the hours not spent chasing type errors, hunting down race conditions or possibly patching up memory leaks in the Haskell case? Have they been spent doing something else, and if not, what's wrong with spending them on refactoring? Another weakness of your point, in my view, is that it presents the topic as a matter of speculation, but it needn't be - some people have used Haskell for big and serious stuff, so why not check out what they have to say? Famously, seL4 uses Haskell for its specification and verification; and John Carmack of Quake fame had some good things to say after reimplementing a classic game in Haskell [1PhArSujR_A; benefits of functional purity discussed starting at 18']. But i could also counter your thought experiment with another: if OCaml allows the whole range of programming styles from C++-like to Haskell-like, why is it less popular than Haskell?

>>32340 > OCaml allows the whole range of programming styles from C++-like to Haskell-like, why is it less popular than Haskell? If Rust lets you do both, why is it more popular than Haskell? Haskell is famous for doing pure FP, not necessarily for that making it easier to program in. >What about the hours not spent chasing type errors, hunting down race conditions or possibly patching up memory leaks in the Haskell case? Rust pretty much proves that you don't need to ban state to eliminate any one of these bugs (beyond memory leaks, but those are relatively rare to begin with). In fact you can do it by just forcing global variables to be threadsafe (Arc/Mutex/RwLock). So those hours, for me at least, are 0. Even indulging the idea that pure FP leads to good outcomes (there are almost certainly cases where state needs to be interlaced throughout the code), there is nothing stopping you from writing in a pure FP style in a language that supports state. Then when the issue arises that needs state, you can introduce it and treat it as a sort of technical debt. What purists of any paradigm don't seem to understand, is that technical debt (the absence of purity) exists for a reason. There are instances where the short term is important. Banning it completely is clearly a much poorer solution to technical debt than monitoring it carefully (as you might with something like Rust's unsafe). It is just another example of the reading vs. writing issue. FP is a lot easier to read, and accordingly much harder to write. This may even reflect some deeper symmetry about writing and reading programs. >I can't comment on Rust I suppose after thinking it over, Rust isn't as similar as I thought in this case. FP's failings are abstract and fundamental, whereas Rust's tend to be much more due to a lack of expressive power in general.

>>32340 >>32342 This is a Rust thread, let's talk about Rust. >>32342 >whereas Rust's tend to be much more due to a lack of expressive power in general. Rust is designed to be used in large projects with lots of programmers of wildly varying skill levels. It needs to keep bad programmers from hurting themselves while still letting the good ones get work done. This puts an upper limit on how expressive and flexible it can be, since, again, that would leave too much room for mediocre to bad programmers to fuarrrk things up.

>>32286 I'd argue Rust's problem isn't that it's too niche, but that it's trying to appeal to a niche that's already occupied. Rust isn't competing with a subset of C++, it's competing with the entirety of Ada; a language that's existed since the late-70s, and is by far the most popular Pascal descendant for real-world use. That language has demonstrated its ability to be both fast and safe in literal war. Rust is used in some of Firefox.

Ok Rust folk, why would I want to learn Rust instead of C++? Is learning Rust harder than learning C++? In my opinion, Rust seems even more complicated than C++. I already Python and basic C programming (I know malloc and pointers, but not POSIX). Also, link some resources for learning Rust (I'm aware of the online version of The Rust Programming Language book). I have already chosen a book for C++ (PPP2). And are Rust packages good/well maintained in general?

>>32271 The C and C++ community doesn't bow to trannism the way that the Rust community does. C and C++ don't and really can't have a COC like Rust does either. These are selling points to the language.

>>32366 C++ has more stable libraries (Rust crates are mostly 0.xs, and therefore not stable). C++ also brings food on the table; you're significantl more likely to find a job in C++. C++ is also more flexible and powerful, but you shoul be careful.

>>32366 Concurrency is much easier in Rust, writing memory safe code is much easier, Rust's type system, pattern matching, and expression-based syntax makes for a nicer development experience. However, that nicer development experience comes at the cost of being a little unfamiliar. But once you get used to it and understand it, it is very nice. >Is learning Rust harder than learning C++ Rust makes you learn more before you can write certain things, but it's really not very bad. The biggest hangups people have are smart pointers and the borrow system, but if you can't understand those, you're going to write insecure C++ code. C++ additionally has much more baggage regarding best practices and secure coding practices, and you'll have to learn different tools for building, testing, dependency fetching, linting, and documentation, which are not standardized. Rust has all of that standardized and working right out of the box, and usually in a nicer to work with format. >>32369 If you're worried about jobs, just learn enough of both to throw them both on the resume. >C++ is also more flexible and powerful, but you shoul be careful. Rust is as powerful as C++.

It surprises me that people think rust is "unexpressive" or "easy to screw up" but I find it to be the exact opposite.

I should've deleted this thread for the poor opening post, but didn't. Try to cease discussing trannies in the Rust thread. Also, look at Ada, which does most everything Rust claims to do and more.

>>32383 Your highness, I make a motion that this and all rust threads be expunged from this imageboard. The language and ecosystem are performative exercises in attention seeking antithetical to the hacker's spirit. Also, it gae.

>>32386 Seconded >>32373 >Rust is as powerful as C++. Weird how one of these languages has a memory model and that isn't Rust. C++ can also implement advanced data structures like doubly linked lists and binary search trees without throwing around the keyword "unsafe"

>>32391 >oh no, I have to use a keyword to use a language feature!

>>32366 >Ok Rust folk Speaking >why would I want to learn Rust instead of C++? The rust compiler has more helpful error messages than any major C++ compiler I've used, and if your program compiles then it probably will not ever segfault. Plus some of the syntax is more pleasing to the eye (though this is subjective) >Is learning Rust harder than learning C++? The learning curve of rust is very steep but it plateaus quickly. C++ on the other hand is pretty easy to get started with, but takes a long time to master. I've been semi-professionally coding C++ for 5 years and I still don't feel like a competent C++ programmer. >And are Rust packages good/well maintained in general? Generally for any common programming task such as networking or generating random numbers, usually there are a few good packages and a lot of unfinished/undocumented ones.

>>32393 >missing the point about using a 'safe' language in the first place

>>32391 >C++ can also implement advanced data structures like doubly linked lists and binary search trees without throwing around the keyword "unsafe" Rust can do this as well, with an additional benefit that the smart pointers provided by the standard library can ensure the nodes of the list or tree won't be accidentally freed from memory without being removed from the data structure first.

>>32404 Which happens so frequently, you should just throw out open standards and use a language where the only people with commit rights are Google employees or proxies.

>>32426 Postscript: https://github.com/rust-lang/team/pull/671

>nooooo you are not allowed to use numbers! https://github.com/rust-lang/rust/blob/master/src/tools/tidy/src/style.rs#L318

>>32491 I... Excuse me? This can't be real. >it's real

Yet another piece of technology claimed by the fake "culture war". Pretty soon Americans won't be able to soykaf without shouting their allegiance to one party or another.

>>32491 I like rust but this is fuarrrking funny. They all spell stuff like boob in hex, what a dumb thing to check. Is there any reason why it's checked? Are they problematic as in like oh no they mention tits or as in they might be put in as a joke? It's such a weird bit of code.

>>32491 Thank you for the laugh

>>32491 >>32492 To be clear, the tidy tool is used internally to enforce coding standards in the rust lang repository itself. It has no effect on people using rust. >>32505 The pr that changed it also changed a bunch of instances where 0xcafebabe was being used, can't find meaningful discussion about it. Probably it's just a matter of it being unprofessional for a language to ship with boobie constants. Pretty funny though.

>>32491 this commit makes me question something you are a rust maintainer. your job is reviewing pull requests and make sure those do not contain stuff like "system("sudo rm -rf / --no-preserve-root")", can't you also check for 0xb19b00b5 style numbers too or are you too lazy for that?

>>32634 Considering the adoption of Tor this really just re-enforces the (100% accurate) statement about rust being used to write software which isn't used. Between the Tor Protocol and the work that Null has done to write a message board backend, the KiwiFarms software stack is literally the largest user base for Rust application software. I find this absolutely hilarious.

>>32634 This is pretty cool. I would say it's impressive they got the project to release-ready state in just 2 ish years but honestly they have multiple people working on it full time, and the rust crypto libraries are some of the most mature parts of the ecosystem. I'm surprised it's so limited at 1.0 release. >>32699 >considering the adoption of Tor you mean that Tor is a massive project and they apparently plan to completely replace the C implementation with rust eventually? >rust being used to write software which isn't used. Yeah I guess nobody uses firefox (about 10% of all SLOC in the firefox source tree is still rust, and a significant amount of firefox complilation time comes from compiling rust packages) or signal (the core signal library is written in rust and called via FFI from java). Dead projects that nobody uses.

>>32699 ...is this some weird egocentrism? Tor and Firefox are both used extensively worldwide. Same with the Linux kernel. I can't help chuckling.

>>32761 >>Dead projects that nobody uses. >Like FireFox. Dying browser being deprecated by Chrome and Brave. Someday Ladybird maybe. weird, firefox is the only browser I would willingly use.

>>32761 I don’t think being successful is an objective for Mozilla. They are basically a sock puppet Google subsidizes so that when Google wants to pollute the internet with another one of its schemes, Mozillians can use all their progressive social clout to convince the ignorant that said scheme is actually good and fashionable. WHATWG is an example. Firefox is now just a hobby project whose maintainers’ salaries are effectively a retainer for marketing services.

>>32761 <5% market share sounds small, and by some metrics it is, but it's a lot bigger than you'd think it is. If we lowball it and say that firefox only has 4% of the market share, that's still 1 out of every 25 people using it. Multiply that out by the total number of people using the internet period, and you have a much more respectable userbase than that percentage would lead you to believe. At the very least, it's sure as fuarrrk got more users than kiwi farms. Also, its odd that you'd bring up brave, considering it's market share is low enough to get lumped in with the "other" catagory on most charts I've seen.

>>32785 Well no, since virtually every statistic that includes Brave just puts it into the Chromium category

>>32847 Most normans have never heard of Brave, most have heard of firefox. The vast, vast majority of net users are normans. Also https://www.ctrl.blog/entry/brave-market-share.html This is data measured on a technical blog, so it's probably highly skewed towards Brave.

What functional languages can fast and efficiently be called from rust? I found https://crates.io/crates/ocaml a crate for ocaml that looks decently adopted, plus I already know this language and the ml syntax is idiomatic with rust. I'm not so familiar with lisp but I'd be willing to learn it if binding to it would be possible as well. In my case I'm trying to find a "modding language" for my game that just takes a series of inputs and returns some struct, usually with rp flavor text of some sort. For that reason, I think a functional language would be well suited to this task provided it has a fast runtime, but I don't think that will be an issue with this logic. Also could be a good way to expose somewhat technically literate normans to functional languages in a task it's designed for. What do you guys think, am I being retarded? Maybe I should just use rust closures when the language has match anyway

>>32872 Last time I checked there were major problems with mixing Rust and Guile specifically because Rust uses setjmp/longjmp for end-of-lifetime destructors and Guile uses the same for a whole lot of it's core implementation so interleaving one with the other is prone to break things.

>>32874 That's terrible to hear. I never actually tried that crate - I looked it up for a project, but ended up picking another language over rust for it. Looks like I dodged a bullet.

Working through the Rust Programming language rn, feelsgoodman. Rate my fibonacci. fn fibo(n: i128) -> i128 { let mut numbers_tuple: (i128, i128) = (0, 1); for _ in 1..n { numbers_tuple = (numbers_tuple.1, numbers_tuple.0 + numbers_tuple.1); } numbers_tuple.1 } fn main() { let sequence_number = 184; let res = fibo(sequence_number); println!("{} is number {} of the Fibonacci sequence", res, sequence_number); }

>>33111 It doesn't have multiprecision arithmetics out of the box?

>everybody knows Go doesn't have generics Outdated.

What is the current state of Rust? Will there be any standard? Is Rust trying to take C or C++ place? I know C and want to learn C++, but may give Rust a try if it's the second case(taking C++ place) and if there is no chance of any code I make today will be unusable in the next commit on Rust github.

>>33839 Is it unfortunate that there's no standard? There's a de facto implementation and it's the only game in town. I guess that's limiting but one of the things I like about Rust is that it's a monolith. There's no Microsoft Rust, GNU Rust, or random vendor Rust compiler toolchain which mostly complies with a standard but is still like going to a foreign country.

>>33843 >I like about Rust is that it's a monolith. Funny, that is the reason I'm avoiding Rust so far.

>>33844 >It doesn't have a standard!!! https://blog.m-ou.se/rust-standard/ >While this comes down to a definition question, standardization is usually associated with the work done by a “standardization body” such as ISO or ECMA: an organisation that takes responsibility for the coordination of the evolution of a standard. These organisations have processes through which stakeholders from all over the world can participate in the evolution of the technologies they standardize. >However, in the Rust Project, we already have an open process for evolving the language, based on RFCs, team consensus, and unstable experimentation. Handing off the responsibility to a standards organisation means giving up our control, with little to no benefit. We’d lose our ability to shape the processes the way we think works best, and we might no longer be able to guarantee an open and inclusive environment that’s up to our standards. >>33815 The only way code can break in newer versions up until now is keyword changes (say you had a method called `await` and this was later added to the standard). See https://doc.rust-lang.org/reference/keywords.html. >[...] but we do try very hard never break anything in a new version of Rust. If your code no longer works in a newer version of Rust (and you didn’t use unstable nightly features), we probably did something wrong. (There are a few unfortunate situations where code can break. For example, adding a new item can change how a name is resolved in some cases. But we’re working on ways to minimize those situations.)

>>33850 Interesting. I may give it a try. I use C for rom hacking, so I hope Rust may make my job easier for this.

>>33936 This is why we code im hermetic environments with generic username

>>33938 I see this a lot. When you criticize something, most Rust (and also Go) fanboys will start screaming "It's not really an issue!" or "You don't actually need it!" or something similar. The behavior is not documented and the fact that xyz does it too doesn't make it acceptable.

>>33949 Ah yes >X has no problems, so you should switch to it! . >X does [or doesn't do] Y; seems like that might cause me some problems. .. >I don't think those should count, so why are you so unfair to X? You just want to resist the change to X because you're jealous that it has no problems! This is why I wouldn't, for example, fault anyone for not wanting to use Go even though I despise C++. This attitude is mostly dead now around C++ so projects can get done without making honestly discussing trade-offs a political campaign. I just want to write software, not babysit a fanatic who's going to weld themselves to a crossbeam and need rescuing. Perhaps this environment is where Rust's "tranny language" reputation grew out of? I don't know.

>>31903 >you can't even implement linked lists without unsafe Wrong https://rtoch.com/posts/rust-doubly-linked-list/

>>32362 Ada is also a horrorshow of a programming language. My friend has to write it for work and he absolutely despises it (he's an assembly programmer by trade). The Ada standard is a gigantic, sprawling mess. Besides that, I would argue rust is actually *not* aiming for the high-reliability niche. As many many idiots have pointed out in this thread, you're allowed to do unsafe things!!! Of course in reality this is because it was decided that it is better to make all the safety features opt-out, so that you can have finer control in situations where you need it. Rather I think Rust is mainly aiming to be a replacement for node.js. Look at which high-level libraries are the most mature, they are mostly HTTP servers.

>>34216 >IIRC there's a growing amount of Rust code in the Linux kernel, which I think is a good sign. What are the chances it will last? It's been said many times that it's effectively on probation, and if it turns out to be a worse fit than C, it will be removed

>>32220 Rust is infested by webshitters and trannies because webshitters were the entry point of LGBTQ+ to invade programming spaces under the guise of inclusion. They forced their way in by playing up the importance of a11y and l18n as a means of "inclusion" and it became every web devs job to do 10x the work for the 0.2% of people who might benefit from the extra a11y soykaf. They got footholds in the W3C due to this and Mozilla was bullied into accepting a ton of them and eventually it was infested enough that they ousted their CEO for making a small donation to an anti-trans charity *years* prior. Though he denies being ousted and claims to have "stepped down". It's such a bald faced lie given the vitriol his former employees speak of him with. Rust was born at Mozilla and when the language was made public it came with a Code of Conduct (CoC) which the LBGTQ+ love to bully people with because they love to shove CoCs down throats to out people they don't like or to help them take over the space by having something to push people they don't like out of the community. So LBGTQ invaded webshit and because Rust was born adjacent to webshit it was infested from its birth. It's almost unfortunate that it is an actually good language but it would be even better if the webshitters and queers could fuarrrk off. A lot of great devs are too autistic or not PC enough to interact with queers without accidentally offending one. So the best move is to not play and instead stay as far away from Rust as possible to avoid ruining their careers for offending some glitterboy on accident. > Also, a lot of the major Rust crates are 0.xs, which is obviously extremely unattractive if you are interested in building a large project in Rust. Largely irrelevant. Most of the 0.x crates are stable as fuarrrk or haven't been touched in years. Crate devs are largely scared of 1.0 releases because Rust will never have a 2.0 so they feel like they shouldn't either. The Min version is treated as Major by basically every Rust dev.

>>34493 >They forced their way in by playing up the importance of a11y and l18n as a means of "inclusion" and it became every web devs job to do 10x the work for the 0.2% of people who might benefit from the extra a11y soykaf. Calling bullshit. Colorblindness alone affects something like 8% of men. Web accessibility is important even for the dreaded cisgender heterosexual white male. What is the alternative supposed to be? Blinding people to punish them for having fuarrrked up eyes?

>>34516 >a11y is when colors contrast I can see you don't actually work in web dev. I get more legitimate traffic from Tor users than I do blind people using screen reading software. Yet you never see the Diversity & Inclusion teams pushing to make the site more accessible for Tor users or a required EasyLlama course on being inclusive to users who care about their online privacy and the importance of making a site of static content accessible without Javascript. WCAG is only given lip service in the industry because of troll attorneys in New York [0] filing mostly frivolous lawsuits with a few legitimate issues sprinkled in. There are different kinds of colorblindness and the only commonly accommodated one is Deuteranomaly (2.7%) and if you're supporting users with Tritanopia that's only 0.016% of people. You have to add each kind of colorblindness up and completely ignore an entire gender to reach your 8% figure. There are enough overlaps for color blindness but to properly accommodate for each of them you must greatly restrict your color palette which often means not being able to use your brand colors or you need to create multiple color palettes and triple the amount of work to test that each color blindness setting have reasonable contrasts. A company isn't going to let you ignore their brand colors so guess what - you don't get to limit your color palette but now you have to maintain multiple palettes and test that they all work as expected for a small, small fraction of users. If my vertical is female fashion wear - guess what? I don't give a single flying fuarrrk about colorblind men and the number of colorblind women is so negligible that it is cheaper to lose their business than ensuring the site is accessible to 0.25~0.5% of women. I refuse to support any negligible percentage of users in the same way that I don't support IE6. Oh - and the requirements are based on math instead of reality [1]. What is mathematically the more accessible option and is the requirement by law when adhering to WCAG standards is not necessarily more accessible. So it isn't actually about accessibility because actual accessibility isn't the actual goal for these people. [0] https://www.boia.org/blog/web-accessibility-lawsuits-dramatically-rose-in-2021.-heres-why [1] https://www.bounteous.com/insights/2019/03/22/orange-you-accessible-mini-case-study-color-ratio

Is Rust getting telemetry? > Right now, it’s really hard to know even basic things, like how many users are encountering compiler bugs in the wild. We have to judge that by how many comments people leave on a Github issue. Meanwhile, Esteban personally scours twitter to find out which error messages are confusing to people. We should look into better ways to gather data here. I’m a fan of (opt-in, privacy preserving) telemetry, but I think there’s a discussion to be had here about the best approach. All I know is that there has to be a better way. https://smallcultfollowing.com/babysteps/blog/2023/01/20/rust-in-2023-growing-up/#more-insight-and-data-into-the-user-experience

>>34524 It seems unlikely. post too short

I don't care about whatever the hell you guys are arguing about, I just want to write computer code. And so far, my experience writing computer code in Rust has been pretty damn fun. It reminds me a lot of how it felt when I was first learning to code, where it's almost like solving a puzzle. Everything seems like arbitrary nonsense at first, but eventually it all clicks into place and begins to seem completely obvious. Of course, you always have a bit of that when trying to learn a new language, but it's especially pronounced in Rust, since it's way stricter than most languages in the same catagory, and the high performance makes it feel all the more rewarding when you finally do find a solution.

>>34849 >I just want to program This is surely a lie. If you were just programming, I doubt you would find anything to do with transgender people. There's been nothing in all the books, manuals, and READMEs that I've looked at.

https://news.ycombinator.com/item?id=28513130#28513656 This whole thread is interesting but Pauan's post is definitely the most illuminating. Its pretty obvious from the overabundance of trannies that there are underlying social agendas in the Rust language, and this kind of crap ALWAYS leads to drama and infighting. Klabnik isn't a tranny but he is a textbook Twitter leftist and they're just as bad. These people are severely mentally ill and insufferable.

>>34851 >years later and it still hasn't been forked. 100% absolutely ideologically backed. This is an easy fix but it would upset who appears to be "maybe the wrong person". I wonder what dirt Ashley has on people that people don't just work around her.

>>34851 >“In fact, if you were a white dude and you wanted to talk at the conference, your chances were basically nil.” On stage, too, fuarrrking hell lol. Who could have predicted such tragedy? Can't wait for all the "I bet you just hate transsexuals" itt to pivot from "Nothing's happening" to "You better believe it's happening and here's why it's obviously a good thing, bigot". As is tradition, the backchannel is the message. https://status451.com/2017/05/18/the-backchannel-is-the-message/ Polite sadge but come on lol. This well-known, publicly available info makes maybe a third of this nine-month thread a joke. And this is just *the one* disastrous excuse for a human being on the core team. Not hard to extrapolate what happens when you start digging into ich/herr's enablers.

>>34878 Sage. It's sage. It's always been sage. This obviously isn't twitch. What am I doing? My neuro-retardedness strikes again. I need to remember to proofread more. (Notice how I don't mention myself, especially my issues, until it becomes unavoidably relevant, and put at least as much effort into improving my impact on the project as I expect others to make to improve their impact on me? Amazing how uncomplicated it all is when you care about things.)

>>34879 >Notice how I don't mention myself, especially my issues, until it becomes unavoidably relevant, and put at least as much effort into improving my impact on the project as I expect others to make to improve their impact on me? Amazing how uncomplicated it all is when you care about things. You know, you didn't have to include this part of the post. Hell, you didn't even need to make the post period. it's an anonymous imageboard; you don't need to save face for forgetting to sage. Nobody cares, and even if they did, so fuarrrking what? I hate this faux-humility soykaf, where people go out of their way to tell you how "humble" they are. It's incredibly hypocritical and frankly pathetic. And in this case, a waste of a post. Also bumping because fuarrrk you.

>>34889 You know, I think you might be onto something. Trying to save face on an anonymous board indeed doesn't make any sense! I wonder if there's anything we can possibly conclude from this information.

LOL even the biggest fanatic of Rust (guy in OP) has had enough: https://youtu.be/gutR_LNoZw0 The offending legal/political document >docs.google.com/document/d/1ErZlwz9bbSI43dNo-rgQdkovm2h5ycuW220mWSOAuok/edit Not quite as bad as Oracle since it doesn't seem to be a clear money grab but the Rust Foundation is getting there. I guess they inherited this busybody politics from Mozilla Corporation. Some reactions >developers.slashdot.org/story/23/04/09/2143212/rust-foundation-solicits-feedback-on-updated-policy-for-trademarks >old.reddit.com/r/rust/comments/12e7tdb/rust_trademark_policy_feedback_form/ I wish I didn't have to learn Rust (it makes C++ look like it's made for kindergarteners), I'm only learning it because of Ruffle https://github.com/ruffle-rs/ruffle

>>35086 Dude funny drama LOL LOL LOL! I'm laughing out loud, can't you tell? It's so hecking funny that I just have to laugh! If you don't like Rust you don't have to use it. One project isn't worth learning a massively complex and incredibly strict low-ish level language that you already know you hate. You'll be much happier contributing to projects written in languages that you actually like.

>>35090 >If you don't like Rust you don't have to use it. If you don't like rust drama you don't have to post here.

>>35141 I was being serious. Drama about a language you don't like isn't worth much. It's good for a funny haha if you like that sort of thing, and it's probably cathartic if the people making Rust offend you, but in the long term it doesn't get you anywhere. I'm not saying criticism is verboten by the way. Rust definitely isn't my favorite. I just think it ought to be constructive and productive. "Trannies lol" is a big fat waste of bandwidth.

>>35086 He's the most annoying glitterboy in the world, and an admitted redditnigger. And reddit is exactly where he got his (invalid) opinion from.

Would Rust be a good language to write a Web Browser in?

>>35141 >If you don't like Rust you don't have to use it. There is growing corporate pressure to adopt Rust. If you write C++ then management is probably working on ways to force Rust on you because the more idiot proof a language is the more (cheap) idiots they can hire.

>>36237 Funny argument because rust famously has a really steep learning curve at first. Honestly from what I've seen, almost all the corporate pressure to use rust comes from the programmers themselves. Management generally doesn't understand the difference between rust and C++ and doesn't want to rewrite anything or restrict themselves to a language that fewer people know.

>>36239 >Honestly from what I've seen, almost all the corporate pressure to use rust comes from the programmers themselves Look at the linux kernel. They rushed to mainline rust support without having anything even resembling production ready rust modules. My last company, C++ firmware for medical devices, decided to adopt rust despite none of the developers knowing it and paid to put everyone on a course. This is all getting pushed by corporate interests. Rust has an obnoxious cult following of useful idiots but they are not in charge, not by a long shot.

>>36241 At my old job they refused to rewrite any of our decades-old C++ code even though it was riddled with bugs. The few things they did deign to rewrite were rewritten in JavaScript. Let's not make this an argument of "my anecdote is louder". "Corporate interests" can mean a lot of things, including senior engineers who genuinely prefer rust. The idea that they want it because it is easier to write or they can hire dumber people to write it is obviously incorrect, considering they had to send you through a training course. I'm pretty sure in this case "corporate interests" is a dog whistle for Jews though. I guess Israelites want to make you deal with reference borrowing for some reason.

>>36242 >Let's not make this an argument of "my anecdote is louder". I also cited the linux kernel as an example independent of my personal experience. >The idea that they want it because it is easier to write or they can hire dumber people to write it is obviously incorrect, considering they had to send you through a training course. It's just the Java argument again. Instead of hiring experienced developers who understand how to handle pointers safely you use a language where the compiler takes care of everything for you. Except this time Rust has comparable performance to C++. >I'm pretty sure in this case "corporate interests" is a dog whistle for Jews You're playing the "everyone who disagrees with me is a nazi" card? What a joke of a person you are. >>35086 >the logo cannot be edited >the logo must be smaller than your company's logo >you cannot imply endorsement from the rust foundation >you cannot use rust in your domain name >... You tell me a gang of highly paid corporate lawyers didn't spend weeks drafting this legal policy. Maybe Rust was a mostly community driven project in the past but those days are definitely over.

i've been reading rust documentation lately, trying it out (it's my first language after python). what does lain think of it? i'm really enjoying myself so far.

>>36257 the only worry i have, is that i am understanding the memory aspect of rust pretty well, but i fear that i'll get used to how ownership works and won't be able to learn other languages as easily. it this possible?

>>36258 That is a stupid thing to be worried about.

>>36258 Extremely unlikely as memory management in garbage collected languages pretty much is "just remove all references to what you were using when done". You really don't have to think manually about memory most of the time in that kind of languages.

>>36258 >but i fear that i'll get used to how ownership works and won't be able to learn other languages as easily On the contrary, it should make using other languages easier since you'll have a better mental model of object lifetimes. >>36257 The main (unique) feature of Rust is lifetimes, which allows writing code with performance comparable to C, C++ ... while avoiding issues with UB. >>36261 >but that's because rustc makes a bunch of safety checks or whatever IIRC most of the time is spent on monomorphization and LLVM, which is why some people try to use trait objects as often as possible. >rust is never going to compete with javascript It sortof is with WASM, though it's more as a complement than direct competition. >they seem to be going in the right direction nowadays The foundation is trying to police "wrongthink", see the draft of the trademark policy for example. It shouldn't be an issue unless you're well-known though.

Have any of you written anything in Rust with more than 10,000 lines of code? I'd doubt it...

>>36283 has anyone on lainchan written anything with more than 10,000 lines of code?

>>36285 Lainchan users are very smart (for programmers atleast).

>>36236 No, why would you even consider that? It's completely unfit for that kind of code

>>36319 I can't tell if you're joking, but Rust was first used in the Firefox browser (Servo as experiment, now other stuff) Chromium also has some scripts to support Rust, though it doesn't seem to actually have any Rust source code

>>36283 Probably somewhere around that

>>36285 I see no good reason why any single system should have ten thousand lines of code. I’ve designed novel programs and authored every required library, and even then the finished program isn’t five thousand lines. It’s a failing to have such a large system. I write programs, and rewrite them, to see them grow smaller, not larger, over time. It’s not unacceptable for a set of systems to have such a size, but it should be a set of modular pieces. Programs should be as small as they can be, within reason, and no larger.

>>36320 >Chromium also has some scripts to support Rust, though it doesn't seem to actually have any Rust source code It's funny how many people are pretending to use rust just for political reasons. >>36327 >I see no good reason why any single system should have ten thousand lines of code. He obviously means 10k loc in total across all projects you have worked on. Which is not unreasonable for a professional developer. It's a bullshit way to defend rust though. It's like saying you're not allowed to hate anime unless you've watched 10k hours of anime.

>>36328 >He obviously means 10k loc in total across all projects you have worked on Oh, in that case I have definitely written more than 10k loc of rust, although I'm really not understanding where you're getting that from.

soydevs can't write proper code without syntax sugars and babysitting language "features". anyone that is bullshiting that c is verbose or unproductive should look into some plan9 code. rust, like other "new" languages brings nothing new. in fact those convinience features will definitely encourage soydevs to write seemingly simple but actually horrible code. the most common types of programming errors are of logic in nature, in fact those "safety" features might hide some of these errors.

Lainpill me on Rust I have a natural rejection to the bandwagon effect so I have always overlooked it. From what I gather it seems at the level of C/C++ but with more built-in functions to make development faster. I can understand that some people don't want to waste time thinking about dealing with memory and it could be convenient to have a few things out of the box. Am I missing something? Is it that good? I'm inclined to think there's no need to reinvent the wheel just because. I always wondered if people can't live without objects then why not create a header file in C to address this rather than creating a new language (C++)? String operations in C were supposedly painful until someone created string.h, not creating a programming language named "CStrings". I'm also not advocating for endless library dependency hell like modern Javascript, no horse in this race, just curious. I hear you Lain.

>>36283 Yeah I've worked on a project that uses rust and is much bigger than 10k code. Rust is fairly horrid all things considered, for small and big projects.

>https://github.com/rust-lang/rust/issues/76785 >350MB-long type name regression this_is_the_future_you_chose.jpg

>>36434 In fairness, strings in rust can also get pretty wonky since they're UTF-8 so you have to deal with graphite clusters and soykaf. Still, I'd rather deal with that every once in a bluemoon than deal with all the pitfalls of C strings again. I'd add >no null >good support for functional programming >exceptionally well written compiler errors To the list.

>>36435 >graphite clusters grapheme* that's what I get for phoneposting

What's the deal with Rust's licensing? I've seen people grumble about its inclusion in the Linux kernal for this reason, but I can't actually find anything objectionable myself

>>36716 From what I recall there had been some brouhaha regarding a trademark policy proposal around Rust's branding (i.e. not the language itself), which might be what the complaints were about; see >>35086, though I'm not sure on how that ultimately went down

What would be the best project to get familiar with rust? I don't like learning languages by tutorials and I prefer just building something in it (like I did with Golang). I was thinking of writing a simple GUI for pacman, are there are any other cool ideas?

any project will naturally raise questions, which will be answered by doing research to execute the project. This should not be a thread in itself, there is a beginner questions thread for this exact purpose.

I'd recommend something that will force you to deal with smart pointers like RefCell, rc, arc, etc.

>>37098 I learned rust by writing a lisp runtime in it. Id link to it but I already posted about it in the LISP general. My first approach leveraged a lof of Rc, RefCell, etc. if you snoop around the repo you can actually see the functional state of that design before I ground up reimplemented everything. I would recommend actually staying as far away from INTERIOR MUTABILITY as possible. It is an antipattern in rust code, and quite frankly an antipattern everywhere. If you find yourself using Rc and RefCell I think it is a sign that you are architecting a C++ app with Rust code.... or worse. My opinion is that when learning Rust one should focus on learning all the wonderful ins and outs of Result, Optional, and Rust's very cool enum system. These are Rust features that led me to write more idiomatic, safe, and elegant code, and also bolstered the effectiveness of the rest of control flow.

>>37093 CONTRIBUTE TO SERVO LITERALLY THE ONLY REASON RUST SHOULD EXIST THEY'RE SO FAR FROM A VIABLE RELEASE CANDIDATE fuarrrk

>>37155 We have ladybird which seems more constructive

>>37093 >i made this project so i can learn this n that while implementing it [and fuarrrking everything up} literally how foss ecosystem exists

>>31826 i wanna learn rust, should i learn c++ first to understand it better or can i dive right in?

>>37173 Why do you think you need to learn C++? It's not a prereq at all.

>>36735 the trolls ultimately failed.

>>37173 Learning to write your own memory allocators & array structures in C (or C with templates & maybe struct member functions) would be more useful. That would actually give some context for what the rust memory model is and why (& how memory is used in programs in general), the vast majority of c++ is not relevant to this and not that useful.

>>37179 This guy genuinely used to make good videos and streams, but the fame and money has obviously gotten to his head.

>>37181 I know, I can see through to the core of what once was before the persona was tailored to mass appeal. But it does not forgive the damning evidence I have just provided.

>>37182 Oh I agree. This guy is lost, he's literally become the least appealing person in the YouTube programming world.

>>37183 That top right rustrover thumbnail kept appearing at the top of the youtube mainpage. It caused me to hide his channel. That psychopath zombie overgrown infant soy face is shamelessly intolerable. Soulless. A grown man ought to know better, and have something within which would prevent him from allowing whatever team he has managing this kind of thing, from doing anything remotely close to that. Ever. There is no excuse. I mean they're all pretty bad, but the hiring one and that are just on another level. There's also just something weird about the whole thing.

>>36716 >>36735 I remember before the "rust foundation drama" reading on /g/ around the Linux update that "the license totally is like kicking dead whales down the beach" and that youre running random, bloated libraries and Mozilla have too much control. Could just be fud. It has a weird double license, one of which is the same as Java's (Apache 2.0), but it looks pretty opensource to me. This chain makes me think that the "rust foundation" drama might be to hide this... simulacra or fud i dont know

I would like to write a simple GUI project for Linux to learn Rust. I was thinking of making a minimal pacman frontend, similar to octopi but even more limited, just to learn the language. Which GUI framework/library is the best for such type of stuff in the Rust ecosystem?

There is already a rust general, and ontop of that a thread you already started. As a lainon in that thread said "This should not be a thread in itself, there is a beginner questions thread for this exact purpose."

>>31828 I'm a beginner programmer and when I tried to learn using python I didn't understand anything, then I dropped the idea of ever learning to programme. A few years into the future and I retook the idea of learning, chose rust because I liked the logo and so far it's been very comfy to learn.

>>37304 Did you use the official The Rust Programming Language book? I was thinking about learning a bit of Rust. I already know basics of Bash, Python and C (but only just enough to understand K&R book), and I learned some x86 assembly and C# a long time ago. I feel that C doesn't come with enough "batteries" and I think that C++ is too complex (Rust was my 3rd candidate for system programming and UNIX-like programming).

Uni student who's written a bit of Java, C and Python for various classes. Golang for my personal projects. Now I'm looking to get into a "deeper" language and am trying to decide between Rust and C++. I'd like to be able to write desktop applications, as everything I've done up til now has been command line or web based. Vulkan seems interesting too.

>>37315 What do you mean by deeper language. All of the listed (both used and wanting to learn) languages belong to the ALGOL family, so what you'd end up learning is likely 1. For Rust: some borrow checker specifics (not even linear types, which it is derived from) 2. Some memory management 3. For C++: RIIA 4. For C++: a lot of C++ specific kludges The d2d programming besides the memory management issues aren't too different. If you want to learn something deeper about the field it would be good to branch out of the ALGOL family of languages. These families include: 1. Lisp (Common Lisp) 2. Smalltalk (Pharo, Self etc.) 3. APL (APL) 4. Erlang (Erlang or Elixir) 5. Forth (GForth if on *nix) 6. ML (SML, OCaml, Haskell) 7. Hoon (hoon) and more not listed, but all of these typically change how one views programming. For the languages mentioned Rust is a mix between ALGOL, with a bit of ML DNA in it. Whereas C++ is ALGOL mixed with the bastardization of OO DNA through simula. However both are clearly in the ALGOL family, and the daily interaction loop goes down to the same rhythm

>>37318 >What do you mean by deeper language. What I mean by that is based on impressions and feelings, so I can't provide specifics. My impression is that experienced developers are familiar with concepts I have little to no comprehension of. Probably related to memory management, but maybe other things too. A lot of the software I admire is written in C++, like 86box, DOSBox, Cavestory and NP2. I want to write software like that, but as I am now, I wouldn't even know where to begin. I care more about writing software than theoretics, so academic languages don't interest me. I've dabbled in Racket and Red and concluded those type of languages aren't about writing useful software first and foremost.

>>37319 > A lot of the software I admire is written in C++, like 86box, DOSBox, Cavestory and NP2. I want to write software like that, but as I am now, I wouldn't even know where to begin. I care more about writing software than theoretics, so academic languages don't interest me. I've dabbled in Racket and Red and concluded those type of languages aren't about writing useful software first and foremost. I don't see how useful software relates to the language here much. A language like Common Lisp was made for industry use. It was used in writing Operating systems, flying software etc etc etc. Forth was made for embeded systems, and is in use today, as it's the easiest language to implement. In fact unlike C, often the Forth Compiler lives on microcontrollers and you can reevaluate code live and play with hardware interactively. A language like racket is a bit more academic sure, but it's still used in some places. The main use is the library ecosystem if it comes in handy for a particular task, however the library ecosystems of language like Common Lisp and other language are enough to get practical work done. Further I'd argue due to the amount of barriers in writing code in Rust, it's much less Productive than any of the langauges I've mentioned. Using rust has been mostly been pure pain, esp if you come from being able to play with programs interactively and iteratively building software.

>>37320 Technically possible is different from practical. I have no interest in embedded programming and even if Forth could be used to write the kind of software I want to, there will be fewer libraries, fewer helpful people and fewer examples of Forth being used in that way. Same for Haskell and "hoon". None of the software I consciously use was written in CL. Why do you think that's the case? Since Rust is unproductive, are you recommending C++?

>>37321 > Technically possible is different from practical. ???? If there exists library for doing XYZ in A, then A may be practical for the situation. is what I'm claiming. The main benefit of a language like python is the library ecosystem, the language itself, is subpar, but is useful due to libraries. This argument then implies to better designed languages and systems. Namely languages like Common Lisp are image based, meaning you can hot reload things live. I.E. If you wrote a game engine in lisp you'd be able to see examples of hot loading logic live without restarting the game. See a random video I have taken from baggers [1]. The plethora of examples aren't particularly useful, as if you mean just basic questions, then yeah there are stack overflow questions, if you mean reading existing projects, then translating code isn't much of an issue. I've done allocation code in factor, translating over the `c` code into Factor using the CFFI for binding to mmap and malloc. It's not a particular hard thing to practice in doing. What matters for big projects is being able to play with the code. Something like C++ or Rust is inherently less interactive, so trying to gleam facts from it is harder, however if one wants to study those programs it can still be done even without intimate knowledge of them. > None of the software I consciously use was written in CL. Why do you think that's the case? Popularity has nothing to due with usefulness of a language. Business strategy mattered more back in the day that led to the deaths of much more productive languages like Smalltalk to the hands of Java. the AI winter and Unix rising killed a lot of interactive systems in the 90's. Lots of people using X is only really useful for libraries and maybe sometimes stack overflow. Common Lisp in particular is a language which is alive, but is more behind the scenes these days. It's just not very popular after the winter. Common Lisp exists in many places one wouldn't expect though. Enough libraries are there to do certain tasks, I use it myself for normal programming unless it's unsuited for some reason (compilers like SBCL tend to spit out decent enough code, with a compiler that can be tweaked) CL-USER> (declaim (optimize (speed 3) (safety 0) (debug 0))) NIL CL-USER> (declaim (ftype (function (fixnum fixnum) fixnum) foo)) (FOO) CL-USER> (defun foo (x y) (+ x y)) FOO CL-USER> (disassemble #'foo) ; disassembly for FOO ; Size: 6 bytes. Origin: #x5377BE16 ; FOO ; 6: 4801FA ADD RDX, RDI ; 9: C9 LEAVE ; A: F8 CLC ; B: C3 RET NIL > Since Rust is unproductive, are you recommending C++? No. Both are fairly horrible in their own way. C++ is a mess as well, and people who use C++ find Rust to be a breath of fresh air, they are already used to long compile times (though C++ build tools do seem to cache better, so compile times are likely more reasonable). I just have used rust professionally and it's a mess, in part due to the language, in part to the very batch experience slowing down trying to get things done. [1] https://www.youtube.com/watch?v=CtL61gsqjnw

>>37319 >>37315 Disclaimer: I don't know Rust but I know C (from K&R), Python and basics of C# (it's very similar to Java). You can use Python or Java for desktop applications if you want to (but where Python shines is automation and small tools, and Java is great for business CRUD applications.). I think you mean that you want a lower level programming language. Both Rust, C++ and also C provide low-level access. Both Rust and C++ are pretty complex languages. C++ is going to be easier to learn for you because you are familiar with Java and C. Also, I think C++ has better ecosystem of high-quality and well-maintained libraries and it's more ingrained with UNIX/Linux ecosystem. But note that C++ doesn't have a standard package manager or a standard build system, unlike Rust. There are some attempts at making a package manager for C++ but those aren't in very wide use. The commonly used build systems for C++ include cmake and Meson. I recommend using either one (but in my opinion, Meson is better). You should also consider what projects are you potentially interested in contributing to (if there aren't any Rust projects that you are interested in, then C++ might be better choice in this regard). I think Rust is going to steal some market share from C++ in the future (But that being said, C++ or C aren't going anywhere in a long time). I think it's mainly due to unsafe stuff being separated and isolated within unsafe{} blocks and because the Rust compiler catches more errors. The borrow checker is also great but C++ has RAII that also automates memory allocation. Generally, you don't want to use malloc() and friends in desktop applications because it's too error prone and you don't usually gain much by managing memory by hand. In embedded systems where memory is scarce you actually gain by sticking to manual memory management (you usually use C or C-like C++ in embedded systems). For more discussion, I found this blog post: https://www.thecodedmessage.com/posts/raii/ For learning Rust, I think the official and freely available book is a good choice (I would be interested in knowing more Rust learning resources. I also know about Rust By Example and Rustlings). The last time I checked, the official installation instructions told you to pipe curl to bash ( curl xyz | bash ) but that's not recommended because it's potentially insecure. You should either use your distro package manager to get Rust and Cargo (or Rustup) or download the Rustup script, use less to quickly examine it and then run it. For learning C++, you should read either PPP2 (if you don't know OOP) or C ++ Primer by Stanley B. Lippman et al. But C ++ Primer is better if you already know some OOP and know how to program (but don't necessarily know C++). Knowing basics of OOP from Java or Python is enough to understand C++ Primer, so I recommend reading it instead of PPP2. I recommend using either g++ compiler or Clang++ (even on Windows). But if you want to learn a programming language to become better programmer overall, you should pick a language that's different from the ones you are familiar with: >>37318

>>37322 If nothing else, I've enjoyed using procedural, ALGOL languages more than anything else I've tried. Wasn't a fan of Java, have no interest going back to Racket or trying another Lisp, would not recommend anyone use Red. Doing coding exercises in those languages was fun in the same way solving a puzzle was(except Java), but the whole process felt like intellectual masturbation and I want to move on from that. >I use it myself for normal programming Have you written a desktop application with a graphical front-end in CL? Have you used Vulkan or OpenGL with CL? How'd it compare to doing those things in C++ or Rust? >>37323 I've started reading A Tour of C++ because it's short.

>>37326 > Have you written a desktop application with a graphical front-end in CL Not particularly, I've done some MCLIM guis in CL, but I don't typically do gui work. However it seems the openGL lib just binds over openGL in CL, and thus it'd be the same as doing it in C++ or any language that binds over. The main advantage of using LISP there is that you can load the code live without having to restart the application to make minor modifications. > Doing coding exercises in those languages was fun in the same way solving a puzzle was(except Java), but the whole process felt like intellectual masturbation and I want to move on from that. You don't have to engage in minimizing all your answers, if you can break answers down into transformations it tends to read better in general. This style is the same no matter the language. Like it's considered good style in most languages to break a loop into maps, and folds, and filters. etc etc etc. In Rust this is esp true, and people in modern C++ use boost to get the same functionality. I typically use lots of HOF myself. I assume this is what your mentioning. The only other thing I could maybe think of, is that you don't care to learn other ways of thinking about algorithms, oleg has a nice post about this that I posted on another thread [1]. I vastly prefer group 1 answers, however if you look at it, most languages are the same processing wise, all the group1 and group2 solutions aren't vastly different, just replace function names. From this you can sort of see why languages don't matter too much. Systems tend to matter a lot more than languages, and only a few languages (CL, Smalltalk, etc) have systems that enable such programming. [1] https://okmij.org/ftp/Algorithms/grasping-all-apples-at-once.html

>>37308 Yes, but I also watched a youtube videos series.

I'll be honest: At first I had my doubts and thought it was just hype.... But I was absolutely wrong; I have completely fallen in love with this language. It's not just the language itself, but the tools it provides so you can focus on the main problem and not on fighting with the system where you are developing. The compiler, the documentation and even the code formatting tool gave me a very pleasant experience while learning Rust. Many say that it is difficult to learn, but, at least for me, many things clicked almost immediately (although perhaps this was because I have programmed before). The truth is that the people who wrote Rust's book did a phenomenal job; I also include the people who document and make it possible for the language to shine. I don't pretend to say that other languages are “inferior” (that's arrogant to my taste), but it's been a while since I had a good time programming. Frankly, I don't know what project to start with to put Rust to good use, but I'm anxious to get started. Maybe it will be the first time in my miserable life that I'm encouraged to contribute to Open Source projects. Thank you lainchan for always allowing me to express the ideas I have in my crazy little head.

>>41083 I must be honest... I'm always on that phase. I've literally tested like 50 programming languages, but the most impressive things I've ever did were a badly-done ChromeDIno game clone but with a blue dog with JavaScript and a crappy (emphasis on that word) pseudo-game-engine with Python using Pygame and Pymunk. I'm aware that, at best, I'm mediocre (and with that sentence I'm unnecessarily boasting); I'm honestly a fraud... That's why I don't like criticizing other people work; you know, saying things like: "<x> language is garbage", "<x> tool is useless", "<x> person is a bad programmer"... I am not one to speak ill of others. ...I already started writing my nonsense here. Sorry about that.

>>41081 >It's not just the language itself, but the tools it provides so you can focus on the main problem and not on fighting with the system where you are developing. If you lurk on the Rust forum you'll notice they'll use language such as "teaching" the compiler to do certain things, and I believe this mentality contributes to tools being designed to be helpful instead of being all too eager to break your code. Contrast it with e.g. C compilers who'll follow the standard to the letter to maximize performance but are nigh hostile to the user when it comes to producing actually functional (let alone correct) programs. >Many say that it is difficult to learn, but, at least for me, many things clicked almost immediately For me getting an intuition for affine types took the longest (though just a week or two IIRC). Few languages have good support for affine types, so if you're used to being able to move objects around freely it might be a hindrance at first. >The truth is that the people who wrote Rust's book did a phenomenal job Indeed. It's the best introduction book for a language I've read so far. I think its high quality is because it is written by many people who may have a deep interest in specific aspects of the language, so they go very in depth when writing the book.

>>41081 >>41081 It has been four months, lainon, what have you built?

As someone who never used Rust but is interested in replacing C/C++ with it, I discovered that Rust inherited one of their crappiest issue instead of following their other main inspiration (ML): the expression/statement divide. They even managed to make it worse, because the semicolon is now more than a simple grammar element: `1 + 2` is an expression but `1 + 2;` is a statement (which just means "ignore the return value of this"). Honestly, except the NPM tier dependency tree issue due to a too small stdlib (R5RS all over again...) and the lack of keyword parameters, I think the syntax made specifically to appease baby duck syndrome is the only truly bad part.

>>42269 >replace C >rust ownership You'll have to write equivalent code with unsafe suffix everywhere, maybe it's easy than proper learning of C tooling.

>>42267 Nothing interesting, actually (well, nothing an A.I. couldn't do in 1 minute). I'm starting to wonder if I am suitable for doing computer stuff in the first place, ha, ha. My passions are Mathematics and Linguistics, but I got into coding to feel useful and pretend to be productive. Thanks for the textual slap in the face; self-analysis serves me well.

Beginner here. Will I encounter more problems if I use the Rust toolchain from my distro's package manager instead of using Rustup? >>31826 I'm looking for learning resources. I know that rustlings exists. Basically, it's a collection of small programming exercises that require you to modify the example code so that it will pass tests. Are there other similar projects? Does anyone know if there is free (or cheap) Rust MOOC/online course? Are there any books that teach Rust through small projects?

>>42309 Rust toolchain from your package manager should work, but rustup is better if you need to use a package that relies on the latest compiler versions (let alone nightly). >I'm looking for learning resources. If you already have some programming experience then I suggest the official book https://doc.rust-lang.org/stable/book/

>>42269 Can you please talk without some weird 4chan buzzwords? I've seen this "baby duck syndrome" spam all over /g/ and it's annoying me that even here people talk like this. What do you mean by this? I'm curious what it means for a programming language to "appease baby duck syndrome". What makes it different from another language that doesn't "appease baby duck syndrome".

>>42602 Not OP, but it's not a "4chan buzzword". It's a psychological principle in HCI, basically just meaning that users "imprint" on the first UI/syntax/etc they learn and use; then judge everything in comparison to that instead of attempting to gauge it through a more objective lens. I'd recommend a simple search query next time you don't understand terminology.

I used Rust professionally (i.e.: for money) from 2015 to 2025, so 10 years. For private projects, I really can't be bothered. As others have mentioned, the package system is npm-tier, and what is even worse, no one seems to question or doubt it. People pull 130+ crates into their small application without even thinking about it. The language itself is fine, I think. But what the community has made of it is horrible. Everyone writes overly complicated code, piling layer of abstraction over other layers of abstractions that are not needed. It reminds me of the difference between plain Java and "enterprise Java". Debugging this code is impossible most of the time, especially when iterators are involved. Trying to step through is not possible - the current instruction mark jumps all over the place. Not that debugging would be needed if the idiots would have kept the code simple, without all the useless abstractions.

>>42604 they advertised rust as idiot proof and attracted with that bad coders limit testing the safety til collapse, doomed by design from the start. Im legit afraid of seeing rust in kernel because that means idiots will start touching something they previously were afraid to touch cause they were smart enough to understood C is dangerous and they shouldn't be there.

>Hear that rust is the up and coming language >Lots of big projects are evaluating it and some have even adopted it (linux) >Decide to research using it at work >Company has a few repos labeled "rust" >Those repos haven't been updated in literal years >Try reaching out to the person who created those repos >He hasn't worked here in years >Start asking questions >Turns out he was fired for not delivering projects on time So 4chan was right and this language was DOA after all

Decided to learn it a bit everything is inverted to existing language standards. Like default variable is const and you have to define it nonconst. Function parameters are "name datatype" instead of standard "datatype name" There is no reason to make everything opposite of industry standard which makes me believe they intentionally made it hard to switch from rust to other languages to vendor lock in their users. This also explains why rust users are so crazy in championing their language - its a genuine pain for them to switch.

>>42672 Name datatype is an extremely common way of doing things outside of C-likes, and even within the C family, it isn't unique: Go and Scala also do it this way. It makes the language's grammar easier to work with from an implementation perspective, especially when there's type inference. Immutability by default encourages code that's easier to reason about, since it makes it easier to enumerate the number of places where changes in state might be causing errors. If you find Rust's syntax insurmountably difficult to work with, you probably shouldn't be programming at all

>>42682 >go scala >soykaf nobody uses does it too brilliant and inverting standard practices makes nothing easier, if const makes sense people use const already. You just defending your garbage practices cause you using it clearly.

>>42683 >and inverting standard practices makes nothing easier, if GOTO makes sense people use GOTO already. That's what you sound like, but even stupider, because you're soykafting yourself over minor syntactic changes. And said changes were not arbitrary; I already explained their rationale, but if you're unwilling to listen then there's nothing I can do to help you. >You just defending your garbage practices cause you using it clearly. I've actually just started learning Rust. My background is primarily in C/C++, so it's definitely been a bit of an adjustment period. But I can tell you right now that I adjusted to the declaration syntax pretty much immediately. If something that small trips you up, you deserve to be filtered.

By the way, as >>42684, I want to say that if you're trying to get into Rust, the very first thing you must do is get C++ out of your head. Don't get me wrong, the influence is obviously there, but by and large, I would say that Rust owes most of its DNA to Haskell and especially OCaml. People describe it as a low-level systems language, but it really isn't. Its type system in particular is much more concerned with the high-level shape of your data than it is the way it corresponds to low-level hardware, and if you try programming in a way where you do think about low-level details, you're probably going to hate it. As a comparison point, in C++, an enum is a way to declare a bunch of constants. In Rust, it's an abstract data type where enum tags can also hold arbitrary value, and is handled with high-level pattern matching.

>>42695 its not just C++, ive used java&c++ mostly among static typed with opengl,cuda for gpu. Swapping is easy due same syntax but still some mistakes because you forget about minor differences. I've also used python, lua, js. They arent explicit with data types but they still follow the const convention. And now you have some new soykaf that works opposite. The potential to make mistakes simply grows the larger the gaps you have to bridge as you forced to frequently operate in different languages. This is like learning 5 european langauges with latin roots that are all similiar and then getting chinese.

>>42702 >This is like learning 5 european langauges with latin roots that are all similiar and then getting chinese. I'd say the better comparison is that it's like learning 5 European languages with Latin roots and then getting English, which looks Latin but is actually Germanic. Rust has enough superficial similarities to C-family languages that your natural instinct is to treat it like C++ or Java. But the actual core of the language comes from the ML-family, especially OCaml, where a lot of the "backwards" parts of Rust are actually pretty normal. But, again, if your brain is so calcified that it can't adjust to writing "mut" before mutable bindings, I wouldn't want you within 50 feet of any project written in any language.

>>42704 >just adopt soykafty ideas or you not good no u support retarded ideas that need to be stopped

>>42706 >>just adopt soykafty ideas or you not good I didn't say that. I certainly don't think it. Let's say, for the sake of argument, that default immutability and identifer type declarations are indeed strictly worse than C's way of doing things. That still wouldn't matter. Plenty of languages have weird, questionable bits. Lua, for example, defaults to global variables and has 1-based indexing, both of which are objectively bad and highly unusual. And yet, you don't see people's minds melt when they're asked to write Lua scripts, and it's because, in the grand scheme of things, both design choices are fairly minor when you're actually writing a program. There's a lot of places where one could take issue with Rust. It's an extremely complex language that is difficult to learn and often unintuitive to use. But if you're getting hung up on fuarrrking declaration syntax, you're retarded, and there's no two ways about it.

>>42707 lua was designed as an addon and not a main language, the usecase is you glue it to other languages and do some rapid development scripting fast results. Global scope poisoning is not a concern when you write small code and if you want to write a larger codebase then you can have nested tables to hold variables in global scope without clashing aside from local variables. Its a legit feature that makes it easier and faster to get things done. The whole design is focused on quick results over security. Though its not that crazy unsafe either because its all contained within the lua context. Your main code wont destroy itself if your lua code fails.

>>42708 And Rust was designed to be easy to debug. Putting mut in a declaration signals to the programmer that something will change over the course of its lifetime, which means it's harder to reason about the value of at any given point in a program's execution and as such more likely to be the cause of a bug. It's a legit feature that makes it faster and easier to get things done. The whole design is focused on security over quick results. Though development times aren't that long either because it is so easy to track down bugs. Your main code will refuse to compile before it fails, making it unlikely that it destroys itself.

>>42710 lua made a architectural design choice. In other words one is a feature with benefit and drawback while flipping syntax doesn't add any functional difference. The safety advertisement is just being conceited you can trick bad coders into using const by making it default when they can just get annoyed and declare everything mut...

>>42711 >lua made a[sic] architectural design choice. Not really. It's just syntax, the presentation layer of the language. A version of Lua that defaulted to locals would, as far as I'm aware, run identically to the Lua we actually have. >you can trick bad coders into using const by making it default when they can just get annoyed and declare everything mut... Maybe. But this requires more work, and thus is less likely, than a bad coder forgetting to mark immutable bindings as const in a language like C. This is especially true because Rustc emits warnings for variables declared mut that don't actually mutate.

>>42717 Other languages dont have global tables by default. You would have to manually reimplement it as a variable and manually drag it across your entire codebase. That's why its a architectural decision they made and not just syntax.