[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip / qa] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/g/ - Technology


Thread archived.
You cannot reply anymore.


[Advertise on 4chan]


File: dancing-ferris.gif (258 KB, 734x490)
258 KB
258 KB GIF
/rug/ - Dedicated to the discussion of anything Rust related.
Rust is a systems programming language designed to ensure memory and concurrency safety while attempting to be as fast as language like C and C++.

## News ##
Military researchers ask industry for ways of translating legacy software automatically from C to Rust - https://www.militaryaerospace.com/trusted-computing/article/55138748/software-c-to-rust-translating
"Prossimo" has worked with a consultancy group called Immunant to convert the AV1 video decoder 'dav1d' to Rust. https://www.memorysafety.org/blog/porting-c-to-rust-for-av1/
Google says replacing C/C++ in firmware with Rust is easy - https://www.theregister.com/2024/09/06/google_rust_c_code_language/
Changes to `impl Trait` in Rust 2024 - https://blog.rust-lang.org/2024/09/05/impl-trait-capture-rules.html
Announcing Rust 1.81.0 - https://blog.rust-lang.org/2024/09/05/Rust-1.81.0.html
Programs of the 9th edition of RustConf announced! - https://rustconf.com/programs/

## Learn Rust! ##
The Rust Book - https://doc.rust-lang.org/book/
The Rust Book (Abridged) - https://jasonwalton.ca/rust-book-abridged/
Collection of guides and tutorials - https://pastebin.com/rUiqjPgL

Conversation starters:
>What are you currently working on?
>Are you learning anything specific? How is it going?
>Got questions about Rust? Ask them!

A reminder to not feed the trolls, no matter how much they may irk you.
Report, filter if possible and move on.

Previous thread: >>102338186
>>
>>102381718
>Groups
Group*
>>
File: 1725955031757322.jpg (150 KB, 511x788)
150 KB
150 KB JPG
>>102381718
https://github.com/Speykious/cve-rs
>>
>>102381718
>Rust Users Groups
Okay, we seriously need to settle on just one name.
/rig/ is out of the question, we can't use /rlg/ or /rpg/, so I suggest the following:

/rust/ - Rust Programming Language Discussion General
>>
>>102382126
>/rust/ - Rust Programming Language Discussion General
That, or /rplg/ - Rust Programming Language General
That works as well.
>>
File: trans_ferris.jpg (74 KB, 975x975)
74 KB
74 KB JPG
>>102382126
I still favor /hrt/ - helpful rust thread :3
>>
Pedophile cult.
>>
File: 1452210332982.jpg (71 KB, 573x892)
71 KB
71 KB JPG
>>102382392
So... based?
>>
>>102382192
kys tranny, ywnbaw
>>
any good rust presentations?
>>
File: 1719159380012077.png (15 KB, 559x559)
15 KB
15 KB PNG
you cannot discuss rust on 4chan
people here do not code, do not care about code, they pretend to like C++ and shitpost about trannies
just go elsewhere
>>
>>102382567
you mean besides swatting?
>>
>>102382599
>just go elsewhere
Nah, these threads are going to be a permanent thing.
You can always just, you know, not enter threads that you don't like?
Or do you go to /lgbt/ just to get mad at the mentally ill people over there as well?
>>
>>102382629
but every time i see the rust crab on here i want to talk about rust and get excited cause i like rust :(

but then all i see is retards comparing it to javascript for some reason and all this transgender nonsense
>>
>>102381718
Any project ideas to learn Rust? I know C/Go/Python all to a decent level.
>>
>>102382639
>transgender nonsense
its not nonsense, rust is full of those wierdos
>>
>>102382663
who cares?
>>
>>102382669
everyone
>>
>>102382639
>but then all i see is retards comparing it to javascript for some reason and all this transgender nonsense
Yeah, those are the mentally ill /pol/-tards who have been shitting up this site for ages now.
Here, use these filters:
/(transex|transgender)/i;
/(tranny|trans|troon|troons)\b/i;
/(chud|c h u d)\b/i;
/YWNBAW/i;
It helps.
>>
>>102382663
>rust is full of those wierdos
The only people ever mentioning that stuff ITT are people who don't use Rust. It's not us, it's (You).
>>
>>102382639
I use rvst and I'm racist and hate trannies
>>
>>102382657
I personally recommend doing the challenges over at Advent of Code: https://adventofcode.com/2023/events
That's how I did it. You get an input, instructions on how to modify that input and a field to place your output. The site'll tell you if your output is correct or not.
Keep the abridged book of rust (see the OP) on your second monitor and have at it.
>>
File: 1726198444564643.jpg (201 KB, 1280x1536)
201 KB
201 KB JPG
>>102382556
Too late, already am :P
>>
>>102381718
>Changes to `impl Trait` in Rust 2024 - https://blog.rust-lang.org/2024/09/05/impl-trait-capture-rules.html
That's neat. The use<T> syntax is nice to reduce verbosity.
>>
>>102382657
I personally would advice against AoC. It's ok if you like doing such puzzles, but you won't really learn anything practical about Rust this way. Just the very basics of text processing.
Try to do something you are somewhat experienced with. My first Rust project was a mandelbrot explorer. A simple CPU-computed one, but I taught me basics of multi-threading, window management, opengl in rust and I even hand rolled some inline asm to speed up fixed point 8.120bit multiplication. But you could do some cli utility to automate something you'd need, or some simple ftp client or maybe a controller for wifi smart light bulbs. I'd suggest to avoid large, complex frameworks like bevy, egui or async in general on first. You won't be able to understand all of this overnight, take your time.

>>102382599
I write code


Now I'm pondering how to handle dynamic objects. Rendering them is not a problem using teardown strategy, with drawing bounding cubes and raycasting from there + conservative depth optimization(which isn't even supported on wgpu yet...), but the tricky part is how to handle reflections. The reflected rays could potentially hit dynamic objects, and if a ray traversing in world coords will have to check for all dynamic objects as well we are back to slow and busted contemporary raytracing methods. Teardown kind of flattens whole world into one grid for sake of reflections and it is pretty good, but because of that their reflections are blurred. Which is fine for their realistic style, but I think I would rather aim for something more abstract and low bit. Douglas doesn't seem to care about reflections at all with his one voxel one color approach, which is something I originally planned to, but I think reflections might actually look pretty cool. Maybe I could somehow make all dynamic objects be always grid aligned, and make all animations voxel-perfect so to speak. Maybe it could look even better if I made voxels smaller.
>>
>>102382823
>https://adventofcode.com/2023/events
Sweet ty. I'll look into it.
>>
>>102383287
Ok, thanks for the insight. I was considering doing the crafting interpreters book in Rust.
>>
>no longer name-clashing with roguelikes
good enough for me. good luck with your general.
>>
>>102383714
We'll be doing our best, anon.
But also, get some better taste in vidya. Roguelikes suck.
>>
Noita is the Rust of roguelikes
>>
>>102382126
>>102382138
>>102382192
>>102382639
>>102382657
>>102383763
even here they can't agree on anything or do something useful
beautiful
>>102382599
/chad/ and lisp general do okay, must be a rust problem
>>
>>102383844
>/chad/ and lisp general do okay
Neither of those generals are getting flooded with /pol/-tards.
>>
>>102383568
2021 and 2022 were more fun, 2023 was pretty shit
>>
File: almanac.png (953 KB, 1367x1027)
953 KB
953 KB PNG
>>102383948
>2023 was pretty shit
It had a pretty fun few days.
But yeah, the difficulty went from 0 to 100 back to 0 way too often.
>>
>>102384045
yeah, so i wouldn't recommend telling someone to learn a language with aoc or that year lol
>>
>>102384062
There's a stark difference between learning to program and learning a language.
Considering that anon already knows how to program, simple exercises that force you to implement basic techniques is perfect for warming up to the language.
>>
>>102384083
>There's a stark difference between learning to program and learning a language.
never said anything like that. and leetcode/problems like aoc are their own thing entirely that don't relate back to learning a language either

i'd advocate for building actual things instead of having to know or solve math problems for competitive programming, which is an entirely different skill set that most programmers aren't familiar with or will ever use day to day
>>
>>102383863
>all this infighting is because /pol/
lol
>>
>>102384125
>i'd advocate for building actual things
If you've never worked with a language before, you will not want to show stuff to show off.
Your every implementation is going to be sloppy at best precisely because you haven't learned the language yet.
Most of the exercises you do in AoC are designed to force you to either implement an existing thing, or re-invent it by yourself.
So if you ever need to do something like cycle detection in the future, you can just re-use what you wrote years ago when you did the AoC challenges.

...you are writing separate files for your implementations so you can repurpose them for future use, right? You're not just creating one gigantic main function?
>>
>>102384222
Where is infighting? The discussion about naming of a new general counts as infighting?
>>
>>102384256
Anon, he's shitposting. He'll take whatever chance he can get to post off-topic bullshit.
>>
>>102384256
didn't you see last thread where people got heated about "idiomatic rust"? gold mine for keks
>>102384282
this whole thread is off-topic, since nobody uses rust. please, I'll leave this dumpster fire when I see people actually doing something somewhat productive. come on, show me how great the language is!
>>
>>102384317
>i have no life so i HAVE to shit up a thread for a language a i don't like
lol
>>
>>102384333
you're absolutely right, maybe I should rewrite my life in rust
>>
I'll be courteous and necro this shit.
bomp
>>
>>102384237
>If you've never worked with a language before, you will not want to show stuff to show off.
wtf does this mean, can't tell if you're esl or ai
>>
>>102385287
>you will not want to show stuff to show off
Should be
>you will not want to create stuff to show off (rather than creating stuff to learn).
>>
>>102382757
Whoah, me too! We should totally, like, hang out sometime.
>>
Bump
>>
>>102384237
>Your every implementation is going to be sloppy at best precisely because you haven't learned the language yet.
so they learn to write program and refactor it. the aoc code is completely throwaway and disposable, never to be revisited again.
refactoring when you better understand the language and code is a valuable learning moment as you progress through the language
>Most of the exercises you do in AoC are designed to force you to either implement an existing thing, or re-invent it by yourself.
they're designed for you to know a math or dynamic programming solution, or not. in that year's case, the gimmick is knowing shit like pick's theorem lmao
https://en.wikipedia.org/wiki/Pick%27s_theorem
nothing to do with whatever language you're using
>...you are writing separate files for your implementations so you can repurpose them for future use, right? You're not just creating one gigantic main function?
i had a different day.rs for each day, hardly reusing anything except the most barebones things from previous years that i only use in aoc like neighbor grid traversal code in arrays. it's largely a waste of time to pretty up any of the code unless you have a bunch of similar problems.
>>
>>102386825
>so they learn to write program and refactor it.
By the time they've become proficient at writing Rust, it would unironically be faster to rewrite the entire project from scratch.
>the aoc code is completely throwaway and disposable, never to be revisited again.
Now that is complete and utter bullshit. Have you even done any of those challenges?
Most of them touch upon concepts and algorithms that you'll encounter pretty often.
>i had a different day.rs for each day, hardly reusing anything
Welp, I do hope you're not actually active within the IT industry, because good god would I hate to be your colleague.
>>
>>102386933
completely disagree. you're retarded and not going to reply anymore

>Welp, I do hope you're not actually active within the IT industry
l o l
>>
>>102387073
>oh shit, i have no rebuttal (because my point is dumb)
>i know, i'll resort to namecalling!
Really showing off your maturity here, anon.
>>
File deleted.
>>102381718
>(100% Free) 2024 Rust Programming for Beginners
https://www.udemy.com/course/rust-programming4u/?couponCode=BBEA4946D57E98BBAE4A
>>
Still nothing of value here. Pathetic.
Time for this ass thread to 41% itself.
>>
So this is the general that actually really SWATed someone just because he coded in a different language?
>>
>>102388321
Well, they're not doing anything useful by the looks of it, so... Yeah
(friendly reminder to fill in the option next time)
>>
>>102387092
You accused someone writing individual files for AoC (an incredibly common practice) of being unemployed. You started the ad hominem
>>
>>102388706
>You accused ... of being unemployed
No, I said I /hope/ he's not employed in the /IT/ sector.
A very large difference between what I said and what you're accusing me of.
>>
Rust is cool but it's hard for me to justify learning. I don't do systems programming and the benefits of using rust on the backend aren't really relevant for me either.
>>
>>102388321
What, really? Link?
>>
>>102389492
either learn for fun or don't. don't really understand why you think you need a "justification"
>>
>>102388321
Yes, this general is where all rust users from the entire world reunites.
>>
>>102389492
The speed does make it useful for daemons and the like.
I use Rust for pretty much anything that doesn't require a GUI.
>>
>>102382709
No, I'm talking about trannies themselves. Consider rope
>>
>>102389752
>trannies
Ah, missed that one.
>>
>>102389755
Happy to help
>>
>>102387283
nice scam
>>
Linear/unleakable types when?
Pin as another reference type, instead of a retarded hack, when?
>>
File: 1701274574067270.png (94 KB, 1015x532)
94 KB
94 KB PNG
>>102389842
Meds
>>
>>102389769
>hairy man who looks and acts like a man. You smell like a man and have a penis
hot
do go on
>>
>>102381718
why does rust have such a terrible ratio of accomplishments to hype?
c is supposedly old, uncool, senile, yet it runs the world as the most common language for both firmware and kernels
java is supposedly verbose and for pajeets, yet it runs the business world together with c#
rust is super hyped. supposed to be the future. everywhere I go to read about systems programming, it's rust rust rust rust, don't use c use rust.
yet when I look for accomplishments that were enabled by rust, it's so underwhelming. usually it's a small rust part in a large c or c++ system that gets blown out of proportion by rust fans. or a straight rewrite of a standard stuff like coreutils that already works perfectly well because there was enough time to iron out the bugs. no better architecture, no revolutionary features, no new ideas at all, just writing the same logic in rust and pretending that makes it better
how come that the rust community seems so uncreative, endlessly masturbating over language features while not producing anything innovative with the language?
maybe the language used for a program doesn't actually matter much?
>>
>>102391167
rn it's more of a people problem than a language problem
wait till the 42% team gets bored moves on to something else, then you'll see if the language is fit for making good software
>>
>>102381718
Do rust programs just keep all strings in UTF-16 on Windows or convert them to UTF-16 before calling OS functions?
>>
>>102391396
yeah I'm waiting it out right now. not ideologically against rust, but the situation looks bad with lots of talk and not a lot of results
plus I generally don't like the idea of rewriting things just for the sake of a rewrite. it's one of the most worthless things you could do if the original program has had enough testing for the bugs to get ironed out. and very easy if you have an existing design to copy exactly, so it tells us little about how good the language is for developing innovative things
typst is the only rust project I can name off the top of my head that is actually innovating rather than just copying
>>
>>102391548
String/str is utf-8, OsString/OsStr is utf-16(on windows). Just pick whatever you need.
>>
>>102391548
https://doc.rust-lang.org/stable/std/os/windows/ffi/index.html
>>
>>102382848
ichikawa would never
>>
>>102391621
>>102391639
Can you use Unicode functions on OS strings or do you have to convert them to UTF-8 first? Do out of place surrogate pairs cause any issues? If not does it work on Linux too, can I have binary data in my strings and manipulate them without reinventing the wheel/performing lots of conversions?
>>
>>102391752
look at the bstr crate
>>
>>102391752
NTA
>Can you use Unicode functions on OS strings or do you have to convert them to UTF-8 first?
Depends on what you mean by "Unicode functions". stdlib doesn't provide feature parity for OS strings (so methods like "repeat" don't exist for OS strings, so you would have to convert or use a crate like os_str_bytes (found in 10sec with a quick search))
>Do out of place surrogate pairs cause any issues?
There are typically safe version of functions and unsafe ones that allow for avoiding checks.
>If not does it work on Linux too, can I have binary data in my strings and manipulate them without reinventing the wheel/performing lots of conversions?
Why would you store binary data in strings? Store binary data in Vec<u8> or Bytes like a normal person.
>>
>>102382669
/pol/tards not staying in their containment board, it wasn't this bad before summer so I guess it's mostly kids thinking 4chan == edgy.
>>
>>102392074
going again with the poltard cope? it's always someone else, trollers, chuds, cniles, poltards, summerfags... but never you deranged lot. get a grip.
>>
>>102390060
Boats is working on it: https://without.boats/blog/pinned-places/
>>
>>102391617
It's also a people problem in the sense that people are resistant to change, just look at the recent Rust for Linux drama. Rust devs asking for semantics around C api specifically saying they don't care if the Rust bindings break they just want to understand how to use the C API properly and all they get is backlash.

Asahi Linas Apple GPU driver even got called a toy project even though it's functioning and being used by plenty of people.
>>
>>102392194
Only one coping here is poltards like yourself otherwise you wouldn't be shitting up this thread so badly.
>>
>>102392241
that's fair, I saw that too and it wasn't good
still, it makes me skeptical that so many rust projects seem to be rewrites of c or c++ projects with no innovation. if you're already rewriting, why not improve the abstractions, the way that pipewire improves on pulseaudio, systemd improves on upstart/sysvinit, zfs improves on simple filesystems? straight rewrites are easy and almost useless, even if they happen to add more colors in the terminal
but I will take these opinions back if rust projects drive more innovation. like if typst replaces latex and provides more flexible document formatting with less code and better speed, that will make my opinion of rust more positive
>>
>be me
>begin writing crate in 2019 constructing a "internally fixed length but acts just like Vec" datatype using Const Generics, long before Const Generics were anything close to ready
>eventually have something that's actually really good and objectively faster than all other similar crates by a significant margin (at the time)
>also have a constantly-expanding (literally larger than the one for std::vec, at the time I last updated it) test suite which was fully run against Miri ever time anyone committed to the repo
>still can't gain enough traction no matter how hard I tried both because of ingrained fixation on the (functionally worse in every way, at the time, ArrayVec) and because that fucking guy with the name that starts with S (can't remember it really) went out of his way to shove "TinyVec" into the dependencies of numerous crates that were already independently extremely popular, therefore making it seem like TinyVec by itself was significantly more widely used than it really was

TLDR shit (shit being: https://github.com/slightlyoutofphase/staticvec) just wasn't worth my time any more, people don't actually care if you write the literal best crate in XYZ category and even have a test suite to back it up, they'll shit their pants the minute they see a single intance of `unsafe` regardless.

Maybe things have changed now though, I'm not really sure, I haven't touched anything Rust since the last time I tried to adapt StaticVec to the then-most-recent nightly syntax for Const Generics. (The syntax changes had nothing to do with why I dropped it for the record, I could have put up with that forever knowing it was just a fact of using nightly, rather all the stuff I mentioned earlier was the overall cause).
>>
>>102392468
The Rust community is large enough to have people in different camps for example rewrite vs just making new stuff.

Personally I've jumped ship from Vim/Emacs to Helix just a better text/code editor all around imo, alacrity has been my go to terminal for awhile now, Cosmic already has a better wayland implementation than GNOME it's just not ready for daily use yet, bcachefs seems to be an improvement over btrfs.

I'm with you on innovation over rewrites, I don't care if fish shell is rewriting in Rust but I do care about nushell and what it brings to the table, I've only used it a little but so far it's doing a great job at a modern shell alternative.
>>
>>102392473
I guess that's just how the cookie crumbles.
Though, just from a look at the two, tinyvec offers a vec that can outgrow the stack container.
So maybe that's why people prefer it? Of course, if all you are trying to do is squeeze a small bit of performance out, picking the safe crate and moving on seems obvious.
>>
>>102392611
Huh, I had no idea that Nushell was written in Rust.
I've been using it on my laptop for a few weeks now (recently migrated from Debian to NixOS and installed all the modern alternatives); got to say it's pretty comfy.
>>
>>102392629
it's just ripping off the even-older SmallVec in a way that isn't really necessary as far as the secondary growable datatype. That's definitely not the reason anyways, that crate is popular (at least widely) solely due to the actions of (I remember his name now) "Schnatsel", not even the guy who actually wrote it.

What I was trying to do was make a fixed lengh no-caveats fully Const Generics based one that did like absolutely everything including weird things I made up because I thought they were cool ideas. And I did achieve that I feel like, if you asked "does StaticVec have XYZ" function the answer was almost always yes when it would be no for everything else.
>>
>>102392662
Also I don't care about it being "the safe crate" when at the time I literally did have a test suite more extensive than the one for std::vec. The functions in the source file for it were even alphabetically ordered for easy editing / addition / removal IIRC lol. I went like miles beyond what anyone else doing anything similar ever did and was one of the earliest heavy users of Miri and so on and so forth but none of it mattered, it's all just a popularity contest basically.
>>
>>102392611
nushell looks interesting
but I thought that bcachefs was written in c?
>>
>>102392731
Oh yeah it is oops. It is a rewrite to Rust project apparently, but I just wanted to show there's plenty of projects not rewriting stuff as well.
>>
>>102392649
I'd use it if I hadn't built my whole system around zsh.
>>
>>102392757
yeah I wasn't aware that nushell is rust so point taken on that
>>
>>102382126
No, we don't. Whoever makes the thread is right.
>>
>>102392611
>Helix
God, their key bindings just fucked too much with my muscle memory. After VScode i'm rolling a less cursed zed with vim bindings setup these days. While i do think fondly of terminal days, debuggers just work/look? nicer on graphic editors right now.
>>
>>102392611
>>102392649
How's nushell, what does it bring to the table compared to good ol bash?
>>
>>102393186
Before I landed on Helix I ran Emacs with meow and neovim on the side and before Emacs I had used Vim for quite some time. For me it wasn't a big problem but it did take a bit of getting used to, also the tutorial doesn't cover all handy features Helix has baked in. Many a times now I've fumbled a command/hotkey and accidentally did something else like g-w temporarily changes all two first letters of each word on the screen and if you enter two of them you jump to that word. Just thought that was a really nice feature and I don't remember it being in the tutorial.

How is Zed btw?

>>102393512
Selling points are that it's portable cross OSs, it's structured around data, extensible with plugins, great error messages. Just using ls prints out stuff pretty/nice and ordered.
>>
who are we swatting today, rust sisters?
>>
Did you troons really SWAT a linux dev on livestream because he spoke against your cult?
>>
>>102394311
>>102394370
Yes, you are next. You may start spreading your asshole.
>>
>>102394370
did you think the code of conduct was a joke?
>>
>>102392241
>resistant to change
must be the only thing
>>102392272
never been on /pol/
>>102392757
kek

ah yes, VECTOR REWRITES! another productive day at the office
>>
File: 1713992276781.png (7 KB, 128x122)
7 KB
7 KB PNG
Oh holy borrow checker, which cnile is getting swatted today? Give us a sign!
>>
>>102394824
Bro if you hate Rust wtf are you in here?
>>
>>102395560
to be vindicated. looking good so far.
>>
I'm working on a text based language for a proprietary DBMS so developers that use it can take advantage of version control, linters, etc. It takes the text based language, does a kind of "diff" against the schema defined in the proprietary file format, before writing the changes. I've represented what kind of change has taken place using enums in the following way:

#[derive(Debug, Serialize, Deserialize, Clone)]
struct Table {
pub id: usize,
pub name: String,
}

#[derive(Debug, Serialize, Deserialize, PartialEq, Eq, Clone)]
enum TableKind {
Created(Table),
Modified(Table),
UnModified(Table),
Deleted(Table),
}

impl From<TableKind> for Table {
fn from(value: TableKind) -> Self {
match value {
TableKind::Created(table)
| TableKind::Deleted(table)
| TableKind::Modified(table)
| TableKind::UnModified(table) => {
table
}
}
}
}

The enum is then used later in a pattern match to dictate behaviour, and I unwrap it to get the underlying table.
Is this idiomatic or is there a better way to do this? Coming from a C++ background.
>>
>>102395992
If every TableKind has a Table, it would be more idiomatic to do it like this:
#[derive(Debug, Serialize, Deserialize, Clone)]
struct Table {
pub id: usize,
pub name: String,
pub kind: TableKind
}

#[derive(Debug, Serialize, Deserialize, PartialEq, Eq, Clone)]
enum TableKind {
Created,
Modified,
UnModified,
Deleted,
}
>>
>>102396066
Thanks Anon. This is how I would probably do It in C++.
>>
>>102382619
>>102388321
>>102394311
>>102395434
No one cares.
>>
>>102395992
>>102396066
You might also want to use bitflags if you want to represent multiple "TableKind"(which should be maybe named ChangeKind?") without repeating all that id/name for each.
https://docs.rs/bitflags/latest/bitflags/
>>
>>102394311
>>102394370
What SWATting??? Give a link please.
>>
File: 1726310351759.webm (1.83 MB, 1280x720)
1.83 MB
1.83 MB WEBM
>>102397318
>>
>>102382192
>>102382540
>>102382848
>>102395434
Hate or love it, this represents the Rust community
>>
>>102391167
C was started and immediately put to work for it's most important achievement, UNIX.
Rust was started to turn Firefox into the UNIX of web browsers (like Chromium is Windows) but Google has Mozilla by the short and curlies and pulled, so Mozilla had to eject Rust and Servo. Servo should've had an alpha public release as a full-blown alternative browser by now, if Mozilla had kept going.
where was C 9 years after its inception? In 1981 it was still a toy for universities and running Microsoft as XENIX. The public release of UNIX only happened in 1982.
Sometimes people conveniently forget C is 52 years old and was around when the industry was being built. It was the default, but it doesn't mean something better isn't available now. Just because the first cities were built with adobe mudbricks doesn't mean we can't use concrete now.
>>
>>102397416
>but it doesn't mean something better isn't available now
sure but something better isn't available now
>>
>>102391167
pushing rust is payback for the older generation of c/c++ programers who don't recognize men with penises as women. runtime safety is just an excuse to exact revenge. as if the only possible path to safety is this shitlang monstrosity.
>>
>>102397416
after 52 years? (X) to doubt
>>
>>102397449
That's just your opinion. People and companies will decide what is best for their usecase.
>>
Feasting in 1.83, const_mut_refs and const_refs_to_cell just got merged which means a lot of unstable features can finally be stabilized
https://github.com/rust-lang/rust/pull/129195

const_fn_floating_point_arithmetic was merged for 1.82 and that means a bunch of other const float methods are coming, like const_float_bits_conv and float_classify
https://github.com/rust-lang/rust/pull/128596
>>
What are some cool new features to expect from 2024 edition?
>>
>>102398013
https://doc.rust-lang.org/nightly/edition-guide/rust-2024/index.html
The RPIT lifetime capture rules and the combined tests are probably the coolest changes.
We will probably see more things getting stabilized around that time (1.85)
>>
>>102398001
Holy shit, finally
>>
>>102398001
Will I finally be able to do basic string operations in const? Iterators? Kind of an embarrassment to have to write
let mut i = 0; while i < s.len() { ...; i += 1; }}
in Rust of all languages.
>>
>>102399634
no, i believe that's at least two other features. you can't do anything that allocates because that's const_heap but there might be things that mutate in place
iterators are something like precise_live_drops, and you might need const_result/const_option
>>
>>102397498
>no jobs
>companies decided
>>
I really hope it's not Rust people who did the SWATting.
>>
>>102400970
delusional, who else could it fucking be? astronomers?
>>
>>102396474
I am sure the police care about wasted resources, which come out of taxpayers' pockets and could have been put to better use, such as subsidized bottom surgery.
>>
>>102401530
I don't know :(
Hopefully the police finds the guy who did it.
>>
File: 1695456153815.png (83 KB, 939x820)
83 KB
83 KB PNG
>>102401886
Why are all Rust developers so inherently shit?
>>
>>102402559
I wouldn't say "all". I don't use Rust (yet), but I find it interesting to see the absolute chasm in skill and capacity for nuance between Rust users and Rust devs (meaning people who develop the language itself). The former are often the retarded ideological warrior type. Shit programmers who will insist that Rust is flawless and C is unusable and you should switch immediately. Also often combined with being a woke culture warrior: either you agree with every detail of the 2024 version of wokeness, or you're an evil nazi racist sexist. On the other hand, Rust language devs tend to be far more reasonable. They talk freely about the pros and cons of the language, the design mistakes that they've made, and how these mistakes may be fixed. For that reason, I'm more optimistic about Rust's future than some people here.
>>
>>102402733
>The former are often the retarded ideological warrior type. Shit programmers who will insist that Rust is flawless and C is unusable and you should switch immediately. Also often combined with being a woke culture warrior: either you agree with every detail of the 2024 version of wokeness, or you're an evil nazi racist sexist.
I don't believe a word of this shit.
>>
>>102403423
That's been my experience with many Rust users. Obviously not all.
>>
>>102403848
>not ALL rust users
>>
File: 1699959583562386.png (117 KB, 1400x1200)
117 KB
117 KB PNG
TRANNY
LANGUAGE
>>
is it true that large rust programs are almost impossible to package for distros like debian stable because they have like 500 micro-dependencies with pinned versions?
>>
>>102404318
that is false
>>
>>102404318
>>102404346
its true
>>
>>102404346
>>102404438
elaborate?
>>
>>102404700
elaborate on your initial claim. you have to prove a positive
>>
>>102404709
it was a question, not a claim. some people say that large rust programs commonly have hundreds of dependencies that would need to be all packaged separately to comply with debian's principles. which makes the job almost impossible. is that true?
>>
>>102404817
true that debian requires this
>>
>>102404817
it is a claim, you're making another claim in it. you're arguing in bad faith and pushing an agenda with a bunch of weasel words mixed in with nuggets of truth. you're obsessed with rust for some reason even though you hate it
>>
>>102405011
I'm just asking if it's true or not you absolute moron. why can't you answer like a normal person instead of making false assumptions about me
>>
>>102404318
>>102404346
>>102404438
>>102404700
>>102404709
>>102404817
>>102404964
>>102405011
>>102405298
they asked a fucking question you falseflagging retard
and i have the exact same question

in any large project, are the dependencies in cargo truly hell? does each one just import more and more and more, until like some anons claims, your build is gigabytes large?
how does this affect development?
t. currently learning rust
>>
>>102382192
Should be this desu
>>
>>102405011
Rust faggot heโ€™s asking a question. You can use all the mumbo jumbo you want to avoid it but itโ€™s a simple question. Iโ€™m also curious on how Debian is handling that
>>
>>102405298
Where does the question come from? You didn't organically make it up
>>
Concern trolls are not bringing their best
>>
>>102404318
yes
>>
>>102405474
I saw someone claim that a while ago in a youtube comment iirc. yt comments aren't known for their reliability so I thought I'd ask here if there's some truth to it or if it's made up
>>
>>102405471
>>102405871
debian says libraries must be managed by apt even if youre static linking and when there are multiple versions of a library they have to be different major versions
rust programs use different point versions of the same library at the same time and nothing is 1.0 ever, these are the only two real problems here, because of these rust and debian cant get along
>>
>>102405871
Debian's way of doing things makes no sense in current year, hasn't made sense for a while. The packaging thing is retarded and has caused tons of issues with non-rust packages before because package "maintainers" fuck things up introducing new bugs.
>>
>>102406325
its for security, languages and language users should adapt to that not the other way around
>>
>>102403872
>We also asked whether respondents consider themselves members of a marginalized community. Out of those who answered, 76% selected no, 14% selected yes, and 10% preferred not to say.
>>
>>102407139
>/g/ - Fear of Trannie Shadows
>>
>>102405372
>in any large project, are the dependencies in cargo truly hell?
in what sense? cargo is easily one of the best build and package management systems around. if you don't like the idea of lots of small dependencies then rust isn't for you. lib.rs/ will usually let you know what you're in for but it can be deceptive
>your build is gigabytes large?
rust builds are large because the default build is a dev build with full debugging information, incremental compilation which bloats the build directory, no optimisations, and this is done for all dependencies because rust is statically compiled. so you build a small project that uses tokio, reqwest, serde, regex, etc, you're probably generating a gigabyte of build artefacts right there. then you build with --release and now you're building without debugging information, no incremental compilation, optimisations, etc, so nothing is reused from the dev build you just did. another 500mb of build artefacts.
you start a new project that also uses tokio, reqwest, serde, regex, etc. you build a dev and a release build and that's another 1.5gb of build artefacts because builds are done per project by default. you take a break from rust and come back a month later, update rustc, build both projects again in the dev and release build and now you're up to 6gb total for 2 toy projects.
it's a problem but once you realise why rust is like this you use either sccache or CARGO_TARGET_DIR to use a common build directory now you're reusing a significant amount of code you've already compiled and cleanup is easy.
>how does this affect development?
builds on older 4 core intel cpus are painful
>>
>>102404318
this is true for any project that bothers to list dependencies. try running random python software from github using only distro provided libraries and see how far you get

>>102406343
it's for package maintainer convenience. it makes no difference to end users if they have to update 12 packages rather than 1 library, but makes a huge difference to maintainers that have to rebuild hundreds or thousands of packages. in the extremely rare case you end up with an actively exploited 0day in some library you can make the case that it's strictly better to fix and push one updated library than to rebuild thousands of packages on the off chance they're also vulnerable, but affected users aren't typically going to wait around for distros to fix the problem before they do something about it
>>
>>102404318
Rust programs usually are statically linked, so they come in the form of a single static binary that just works anywhere, on any system. The fact that the developer used many dependencies is completely invisible to they user, because they just get compiled in.
For example, the Zed editor: you can literally just go to https://zed.dev/docs/linux#other-ways-to-install-zed-on-linux , crtl+f "Downloading manually" and just download the program.
So Rust by default makes it pretty much as easy as possible to distribute programs.
I don't really know what Debian's problem is. If they just wanted to solve the problem, they'd just serve you that same binary and call it a day. Must be autism.
>>
>>102405871
>>102406264
ok thanks for giving me an answer. sounds like a philosophical difference between rust and debian without either side being straightforwardly wrong
>>
>>102409765
except the rust side is wrong
debian is part of the c ecosystem
rust is the one that needs piggyback rides from c all the time
so until it has its own ecosystem it will play by c's rules
>>
>>102409942
non sequitur
>>
File: 1662940045851106.jpg (237 KB, 853x1000)
237 KB
237 KB JPG
>>102409971
non woman
>>
>>102410076
Thanks for bump
>>
>>102404318
Debian's and Fedora's policy is to have a distro package for every Rust package and this does get bloated but they seem to manage it. These are build dependencies rather than runtime dependencies so it doesn't affect the end user.
A Debian maintainer recently gave up on maintaining a Rust package because they didn't like overriding potentially incompatible dependency versions but it wasn't clear to me whether this caused problems in practice, it sounded like they just found it uncomfortable. Possibly overblown, other maintainers seem to do alright.
Arch pulls dependencies straight from crates.io. They use lockfiles so it actually isn't crazy, you get a cryptographic guarantee that the contents don't change, but Debian at least has an explicit policy that you should be able to build packages in main without an internet connection.
It's definitely extra work but it's not fatal.
>>
>>102410376
Even though it's mostly transparent, the whole microdependency shit is still cancer. One of the biggest failures of rust was that it didn't address that issue, I feel like, but then again I don't even know how you'd do it, other than banning midwits from touching keyboards.

I hate package managers.
>>
>>102410810
>One of the biggest failures of rust was that it didn't address that issue
Suggest a better alternative.
So far Unix philosophy works really well for Rust. I enjoy using Rust libraries way more than using bloated C++ libraries with poor interop.
>>
>>102410810
A lot of library code genuinely has a small scope. I don't know if crates.io is a worse end result than boost.
>>
>>102410830
>Suggest a better alternative.
Frankly, providing a better way to set up dependencies without automatically downloading them. I think realistically that's the best way. You can still make the process of actually building and linking dependencies very smooth, but not actually provide the package manager functionality.

>I enjoy using Rust libraries way more than ...
Bar's low. I would rather use sqlite as a single dependency than as a package that downloads 3 other dependencies, even if those other dependencies are tiny and transparent to me. Currently the most used SDL2 crate depends on an SDL2 bindings crate.

They did fix some issues by making crates static on crates.io, but I also don't like centralized package repositories, which I think is the bigger issue. I think it's a fundamentally bad thing.
>>
>>102411404
>Frankly, providing a better way to set up dependencies without automatically downloading them.
How are you going to compile it without downloading?
How is this going to change anything?

>I would rather
That's up to you how are you going to program.
What I am asking you about is how to solve this supposed problem you are taking about.
>>
>>102411443
>How are you going to compile it without downloading?
You download it, it just doesn't do it for you.

>How is this going to change anything?
It would add friction to using lots of small packages, which is what we're talking about. It would also get rid of the need for centralized crate repos.
>>
>>102411464
>You download it, it just doesn't do it for you.
>It would add friction to using lots of small packages, which is what we're talking about. It would also get rid of the need for centralized crate repos.
So you add extra work for nothing gained.
>>
>>102411464
dumb retard
>>
>>102410830
>Suggest a better alternative.
Do what literally everyone else is doing. The most common stuff goes into the standard library, the rest goes into a smaller number of larger packages.
>Unix philosophy
No need to make it so obvious that you're retarded.
>>
>>102411481
The point is to make it harder to pull everything under the sun. That's the whole premise of the discussion, yes. What did you think the suggestion would be, after I explicitly stated that "I hate package managers?"

But hey, I'll do you one better: allow people to download whatever dependencies they define explicitly, but don't allow those dependencies to add further dependencies automatically.
>>
>>102411530
>Do what literally everyone else is doing. The most common stuff goes into the standard library, the rest goes into a smaller number of larger packages.
That's what Rust does.

>No need to make it so obvious that you're retarded.
Non argument
>>
>>102381718
After learning this language and doing a couple of projects I can honestly say awful syntax and did not fulfill the promises to make a better c++ at all if anything I think itโ€™s way worse. Thereโ€™s probably a reason they named it rust.
>>
>>102411530
>just accumulate more and more deprecated stuff in the std
dumb retard
>>
>>102411540
>That's what Rust does.
Not at all. Rust people are all-in on splitting things into a huge number of small libraries. Which is worse than having fewer libraries with more code in each. Read the article I linked upthread: https://research.swtch.com/deps
>>
>>102411532
>The point is to make it harder to pull everything under the sun.
Souds like an anti-feature. We already know how great cmake is, why would we repeat its mistakes?

>That's the whole premise of the discussion, yes.
The premise was the supposed problem. So far, you are suggesting adding more problems, not solving anything.

>What did you think the suggestion would be, after I explicitly stated that "I hate package managers?"
I expected something more practical. What you are talking about is not practical at all. Seems like made up problem with even worse solution.

>But hey, I'll do you one better: allow people to download whatever dependencies they define explicitly, but don't allow those dependencies to add further dependencies automatically.
Again, adding more work for no benefit.


Then I will ask you this. What is the exact problem you are personally dealing with in you Rust project that removing the ability to download dependencies would help you solve it. What is the practical aspect of what you are trying to do.
>inb4 I don't actually program
>>
>>102411548
If after learning a language the only thing you can discuss is still its syntax, then it's probably for the better that you won't program in it.
>>
>default-features = false
>path = "./vendor/your-crate"
>features = []
Nothin' personal, kid.
>>
>>102411591
>Rust people are all-in on splitting things into a huge number of small libraries
Yup, that's Unix philosophy in action. If libraries focus on doing only one thing and doing it right, they can better do their job.

>Which is worse than having fewer libraries with more code in each
[citation needed]
>>
>>102411615
I just find it hard that anyone really likes programming in rust like itโ€™s gotta be a joke or something itโ€™s really horrid. Despite all the shilling it really is not that fun to program in and takes forever to get anything to compile. I couldnt imagine using this on a team or in a professional setting with deadlines.
>>
>>102411655
>I just find it hard that anyone really likes programming in rust
Well, one day you might understand it, or you might not. Either way, you have made your decision so move on and program in whatever you enjoy the most.
>>
Why exactly is it a bad idea to just install the version of rustc, cargo and shits provided by my system's package manager instead of the latest greatest rustup one? Pretty sure if I could survive all this long with ANSI C before upgrading to C99 I'll be able to handle a barely 2 years old rust version and see if I need more in 2 or 3 years.
>>
>>102411596
Cmake is not even comparable to what we're discussing, you must have your head really far up your ass to think Cmake makes building C dependencies any less cancer.

The whole reason why we are in dependency hell today is because of how easy it is for a rando to build and publish packages, and for another rando to depend on them. The only solution is to make this harder to do, otherwise things just spiral into house of cards territory.

>I expected something more practical. What you are talking about is not practical at all.
Pretty practical. If I had cargo and an easy way to link projects (which are already both true for rust), I don't really need a package manager. Like I said, you could even have a system where you could download dependencies automatically, which would take care of language extensions (which I like the idea of), while still preventing other deps from adding their own deps.

>What is the exact problem you are personally dealing with in you Rust project that removing the ability to download dependencies would help you solve it.
Nothing. Just because I personally don't have these problems that doesn't mean I can't foresee them, such as ridiculous build times and disk footprints. Not to mention that if something in crates.io fails, you're SOL. For something to replace C it needs to be decentralized at the very least, because that's one of the biggest strengths of C and C++ (less so), today.

>>102411655
It's by far the comfiest language there is. It's not a language for people who don't like thinking about design though, so if you're just rushing some jeetcode you'll just get upset.
>Implying you've ever actually used it
>>
>>102411725
If you are not using nightly then there is nothing wrong with using system provided rustc/cargo.
Rustup is really useful if you want concrete version and/or cross compile and/or download source code or something that is not available in your distro manager.
>>
>>102411741
>you must have your head really far up your ass to think Cmake makes building C dependencies any less cancer.
Re-read my post. I said the opposite.

>The whole reason why we are in dependency hell today is because of how easy it is for a rando to build and publish packages, and for another rando to depend on them. The only solution is to make this harder to do, otherwise things just spiral into house of cards territory.
Sounds like adding more busy work for no actual gain.

>If I had cargo and an easy way to link projects (which are already both true for rust), I don't really need a package manager
That's up to you how you will program.

>Like I said, you could even have a system where you could download dependencies automatically
It's called Cargo.

>Just because I personally don't have these problems that doesn't mean I can't foresee them
So it's a made up problem.

>such as ridiculous build times and disk footprints
Show me the build time of your project and then we can discuss it.

>Not to mention that if something in crates.io fails, you're SOL
Cargo is not limited to just crates.io

>For something to replace C it needs to be decentralized at the very least, because that's one of the biggest strengths of C and C++ (less so), today.
Why?
>>
>>102411753
>or cross compile
Alright make sense, that's a little annoying not to have this feature.
>>
>>102411921
You can get away without it by doing it manually, but with rustup it's like
rustup target add arm-linux-androideabi
and you get all the rust-side things you need for cross-compiling for specific target, like stdlib.
>>
dns recommendations? Just want to do basic SRV queries. I thought I'd use libc, but then I remember all the resolver features in glibc are extensions.
>>
>>102412058
https://hickory-dns.org/
>>
>>102412083
god this thing looks like a fucking brick. hope it just reads resolv.conf and shit.
thanks
>>
>>102411629
>>Which is worse than having fewer libraries with more code in each
>[citation needed]
I literally gave you a citation in that post, you absolute retard.
>Unix philosophy
A thing that only shit programmers think is good. When I see that phrase, I know the person is incompetent and I should avoid anything they write.
>>
>>102413882
>I literally gave you a citation in that post, you absolute retard.
You've only quoted part of my post. You have also linked an article that talks about opinions of some literally who who thinks that dependencies are bad. Not exactly about the claim in your post.

>A thing that only shit programmers think is good. When I see that phrase, I know the person is incompetent and I should avoid anything they write.
Why?
>>
>>102414022
>russ cox
>some literally who
Fucking lmao
NTA, but you shouldn't have dismissed the article without reading it, because now it seems like you have absolutely no idea what you're talking about.
>>
>>102414453
Yeah, I have no idea what this article is about beyond what is written in the conclusion. I'm all for discussion, but I'm not really going to read tangentially related article just to come up with some arguments for him. If that makes me sound like someone who has no idea what he is talking about, then sure. But it's a funny thing to say right after he claimed that a specific term is only used by "shit programmers" who should be ignored, lol
>>
>>102414603
God damn, anon. It's like your brain only parses what it wants to see.
That anon made a statement to counter yours, then backed it up by an authoritative source.
You then proceed to go
>HURR CITATION NEEDED DURR
Do you need me to explain why you sound like an unhinged retard?

I do not agree with that anon's point at all, mind you.
>>
>>102414682
>That anon made a statement to counter yours, then backed it up by an authoritative source.
Which statement? The anon said that Rust has flawed design and I asked him to suggest a better alternative. He said that it's better if things get put in standard library and yada yada... I said that it's what Rust does, which was in fact wrong because I skipped the "larger" part. Rust does exactly what he said except it puts stuff in smaller packages instead of larger. Does the link refers to that statement? I don't think so.
>You then proceed to go
>>HURR CITATION NEEDED DURR
This was related to his next claim that it would be better if Rust had fewer libraries with more code in each.
>Do you need me to explain why you sound like an unhinged retard?
Sure, entertain me.
>>
>>102414861
>Does the link refers to that statement? I don't think so.
Okay, yeah I'll just be repeating what I said before because you're either trolling or actually delusional.
>God damn, anon. It's like your brain only parses what it wants to see.
>>
>>102414022
>Russ Cox = literally who
>>102414603
>I'm not really going to read
Average Rust user intelligence LMAO
>>
>>102414022
>>A thing that only shit programmers think is good. When I see that phrase, I know the person is incompetent and I should avoid anything they write.
>Why?
Because the phrase "Unix philosophy" is almost always used to justify a complete and willful disregard for systems thinking, which is a characteristic of subpar programmers that people are trying to turn into a positive by using the phrase like a mantra, a thought-terminating cliche.
The fallacy of the "Unix philosophy" worshippers is the same as the fallacy of the microservices enthusiasts who think that turning something into a distributed system of tiny pieces will magically make it easier to understand. It's the belief that if you put together a hundred simple and well designed pieces, the overall system will also be simple and well designed. Which is very far from the truth. In any complex system, much of the complexity is not in its parts, but in the interactions between its parts. Even if the parts are well designed, that doesn't mean that the system as a whole will be well designed, or even work at all.
Which is why it's better to have the same amount of code maintained by a few teams rather than hundreds of independent individuals. When things are bundled into one library, people can coordinate and they at least have to be aware of how the rest of the code works, which is a good defense against pointless design differences and putting things together that don't fit. Also, if you want to spot-check whether the authors of your dependencies seem to have decent processes and know what they're doing, that's much easier to do with 5 libraries than 500, even if the total amount of code is the same.
But seriously, just read the fucking article. Put down the TikTok for a few minutes and quadruple your dose of Ritalin if you have to. Reading a few pages shouldn't be a difficult thing for someone supposedly interested in programming if they're not retarded.
>>
>>102416237
>Because the phrase "Unix philosophy" is almost always used to justify a complete and willful disregard for systems thinking, which is a characteristic of subpar programmers that people are trying to turn into a positive by using the phrase like a mantra, a thought-terminating cliche.
That's quite bold claim considering that it's the base of Linux and a lot of FOSS.
Still, you are just paraphrasing yourself and keep saying how everyone else is stupid, but you are yet to explain why.

>The fallacy of the "Unix philosophy" worshippers is the same as the fallacy of the microservices enthusiasts who think that turning something into a distributed system of tiny pieces will magically make it easier to understand.
I don't think being "easier to understand" is the goal of Unix philosophy.

>Which is why it's better to have the same amount of code maintained by a few teams rather than hundreds of independent individuals.
Having large battery-included libraries and programs causes a lot of code duplication.
Also how exactly does the fact that "if the parts are well designed, that doesn't mean that the system as a whole will be well designed, or even work at all" leads to this? Like ok, this is true, and it's true regardless if we are talking about external dependencies, or splitting project into multiple smaller ones or modules within a single monolithic project.

>When things are bundled into one library, people can coordinate and they at least have to be aware of how the rest of the code works
The larger libraries get, the more overlap they will have and the like hood that you will understand every hand-made solution that X library does decreases greatly. If a library is smaller and uses bunch of well know libraries, you will be much more likely to understand it faster.
>>
>Also, if you want to spot-check whether the authors of your dependencies seem to have decent processes and know what they're doing, that's much easier to do with 5 libraries than 500, even if the total amount of code is the same.
If the amount of the code is the same and you are already experienced in the language, it will be much faster to check the second case, since you are likely already familiar with at least 400 of them.

>But seriously, just read the fucking article
No thanks. If I were to make arguments for you and then refute them, you would never accept that.

>Put down the TikTok for a few minutes and quadruple your dose of Ritalin if you have to.
I don't speak zoomer.
>>
why no arr[-1]?
>>
>>102416869
>That's quite bold claim considering that it's the base of Linux and a lot of FOSS.
NTA, but I sure do hope you don't mean to say that Linux is good with this statement.
>>
>>102417045
arr.last()
>>
>>102417114
its just that I always liked the syntax of going in reverse by simpling adding - to the i
seems like a weird thing to not have
>>
>>102417177
nth_back. -i is too much syntax sugar imo and i'm glad it's not supported by default. i've seen it cause way more bugs than it carries its weight in utility
>>
>>102417177
Cons
>it doesn't really make any sense
>off by one error can silently pick the last element instead of immediately overflowing and panicking
>some people don't like the syntax
Pros
>some people like the syntax
>>
>>102417045
I kinda like this in Python but in Rust you index with usize (which can't be negative), and it'd make every indexing operation more expensive which is a big deal for a language like this
>>
>>102416869
>That's quite bold claim considering that it's the base of Linux and a lot of FOSS.
Thankfully, you're wrong. Only retards like suckless still follow the "Unix philosophy", the best FOSS doesn't. See e.g. nginx, PostgreSQL, ffmpeg, syncthing, pipewire.
GNU/Linux itself is shedding more "Unix philosophy" brain damage by the year. For example we used to have all these disparate centers of configuration: inittab, inetd.conf, crontab, etc. Each with a different syntax and different limitations. Doing mildly complex system administration, like having a service that depends on both a mountpoint and a socket, while also having resource limits, required a lot of shell script wrappers that could break in ways that didn't leave clear traces in the system log. Now we don't have this anymore. Lennart Poettering cleaned that retarded shit up and gave us a unified tool with a powerful and flexible set of abstractions that lets you express such things clearly, in one file. And it's pretty watertight when you do something wrong too, it's hard for things to "fall through the cracks" in a way that doesn't leave explicit traces in the logs. This is how you do proper engineering - with systems thinking, not by being some moron who blindly worships an OS design from the '70s and '80s.
>I don't think being "easier to understand" is the goal of Unix philosophy.
You think it's better for systems to be hard to understand? Are you trolling me now or are you legitimately retarded?
>Having large battery-included libraries and programs causes a lot of code duplication.
It's a tradeoff for sure, but I wouldn't say "a lot". It causes some duplication, but not more than the alternative. If you look at the whole transitive dependency graph, you have a lot of duplication with microlibraries too.
>Like ok, this is true, and it's true regardless
You still don't get it, even though I explained it in the post above. A team can coordinate on designs and practices.
>>
>>102416885
>>But seriously, just read the fucking article
>No thanks.
Seriously, it's too hard for you to read a few pages? Are you even a programmer? Do you refuse to read docs too and insist that people spoon-fed you everything?
>>
File: 1709735952266344.jpg (35 KB, 630x630)
35 KB
35 KB JPG
>>102418062
Based and progress pilled.
>>
>>102418062
>Thankfully, you're wrong. Only retards like suckless still follow the "Unix philosophy"
And once again you keep talking how everyone around your is retarded, yet no arguments.

>See e.g. nginx, PostgreSQL, ffmpeg, syncthing, pipewire.
All of which are large C/C++ projects which couldn't possibly benefit from it due to lack of necessary tooling.

>GNU/Linux itself is shedding more "Unix philosophy" brain damage by the year.
Linux is and always will be following unix philosophy. Even if you take and replace some parts of it by adding large monolithic blocks like systemd, the sole reason why you can do this, why it's all so modular and customizable, is because Linux is following unix philosophy. To remove that you'd have to pretty much make a different system.

>Now we don't have this anymore. Lennart Poettering cleaned that retarded shit up and gave us a unified tool with a powerful and flexible set of abstractions that lets you express such things clearly, in one file.
If you use systemd. If you don't then you don't.

>This is how you do proper engineering - with systems thinking, not by being some moron who blindly worships an OS design from the '70s and '80s.
Depends on what you need. Not everyone can or want to use systemd.

>You think it's better for systems to be hard to understand? Are you trolling me now or are you legitimately retarded?
That's not what I said. I said that I think that being "easier to understand" wasn't the goal of unix philosophy. I never said that I think they wanted or that it is desired for systems to be harder to understand. I think the goal was modularity, reusability and separation of concerns.
>>
>It's a tradeoff for sure, but I wouldn't say "a lot". It causes some duplication, but not more than the alternative.
Whenever I look at typical worst case scenario of micro dependencies in Rust, ie a typical webserver, then I see that a lot of libraries is shared across many dependencies. Majority of second-order dependencies appears at least twice in the dependency tree. If all these direct dependencies had to include (even partially) all these dependencies, then I'm sure there would be a lot of duplications.

>A team can coordinate on designs and practices.
Yeah. And they can also do a bad job at it. At least with smaller library it will be easier to replace it.
>>
>>102416869
>>102418062
Oh, I forgot to add that your favorite build tool, cargo, is as convenient as it is precisely because its design is antithetical to the "Unix philosophy" that you claim to like. The actual Unix way would be to use Make to glue together a dozen different tools that together do cargo's job. I agree that the cargo way is better, but why do you love it so much and then claim to follow the "Unix philosophy" meme?

>>102418574
>Linux is and always will be following unix philosophy
No, most of it doesn't. I just explained why, you retard. Why do you ignore all my arguments and examples? GNU/Linux is less Unix-like by the year, and that's a good thing.

>>102418584
Have you considered maybe learning from the experience of other software ecosystems? So far, you've refused to read anything I linked, and you didn't respond to my arguments either, you just denied them and kept repeating your cliches. I don't get it, why does Rust attract so many zealots who get memed into some midwit shit like "Unix philosophy" and refuse to learn? Do you think you're the first programmers on Earth because you have affine types and a nice build tool? No, this debate predates Rust. JavaScript devs have already gone through a micro-library phase and suffered a lot of pain from it: supply-chain attacks, frequent compatibility breakages, needing glue code to make libraries with different designs work together. That's because
1) It's harder to vet and trust many libraries than few libraries, even with the same amount of code
2) When it's many independent individuals rather than a team, it's much harder to coordinate on refactors and a general approach to programming
But you refuse to learn from it, you refuse to even read about these problems. You insist on falling into that noob trap yourself, and justify it by repeating retarded thought-terminating cliches over and over again. This is not a good approach to programming and will limit your skill.
>>
>>102381718
I fucking hate that Rust constantly has updates and half of Rust products rely on Rust Nightly or whatever. Is there anyway to get around this? Like is there a decadely release version of Rust for me to develop in? The actual development process is nice, but I hate these bells and whistles around it
>>102402559
>old macbook
Isn't Asahi exclusively for Apple Silicon (TM) Macbooks?
>>
>>102418584
>>102418679
Even your argument about duplication is something that sounds correct to beginners but doesn't work out in practice. You end up with many micro-libraries with overlapping functionality. I was just recently talking about this to a Haskell dev who went through the dependency trees for all his projects. In Haskell, there are some small libraries that are cut-down versions of larger libraries. Microlens is one example. That guy found that a large Haskell project would usually end up including both anyway. So if the dev of a library he was using decided to depend on microlens instead of regular lens, that locally made the library's dependencies smaller, but ended up making the final application larger. A classic "Unix philosophy" move: focus myopically on your piece of the system, make it simpler, end up making the overall system more complex.
I've heard other versions of that story before, so that suggests a general rule of software development. For direct dependencies of an application, it can be good to have several differently-sized versions of given functionality. For example, a simple command line parser and a complex one. But for things that are going to end up as dependencies of many other libraries, people should really agree on a single canonical implementation, and maybe even put that into the standard library. Otherwise, you're going to end up with multiple versions of the same functionality in any large application.
Incidentally, that's the opposite of what Rust devs are doing. They seem to have converged on one very complex option parser, but they use lots of micro-libraries transitively. Maybe it would be a good thing to correct that? Maybe the devs of all other languages aren't wrong when they tell you that this is bad?

Okay, I'm off for today. This is getting tiresome, it's been like trying to explain quantum mechanics to a goat. Maybe someone else will get something out of the conversation, at least.
>>
what are these women talking about, haven't read a word other than russ cox and article
>>
>>102418757
Well there is 2021 edition and soon 2024.
>>
>>102418757
rolling release every 6 weeks is fine, and relying on nightly is not common at all in my experience
>>
>>102420133
Yeah, I "discovered" editions not long after I posted that comment. The ferrocene standard too. I'll have to have a deeper look into them both, but it seems to be better than the current mess that I hate
>>
https://os.phil-opp.com/
Thoughts? my fellow rustaceans
>>
>>102421023
is it another shitty unix clone?
>>
>>102421023
I've always wondered, it probably is better to contribute to the linux kernel than writing a toy OS from scratch right?
>>
>>102422007
better for your CV, but worse for your sanity
>>
https://github.com/microsoft/windows-rs/pull/1836
Sadly MS isn't giving Rust the best ui support
>>
>>102422220
XAML died with Silverlight and Windows Phone
>>
>>102421023
Good learning material
>>
File: 1726189257238607.jpg (73 KB, 736x1051)
73 KB
73 KB JPG
>>102422668
The modern Windows versions and most of Windows apps use xaml though
>>
>>102421023
https://www.redox-os.org/
>>
>>102423371
I thought they were already on their next GUI framework, this time a web-like one?
>>
>>102423845
nope, that's fake news
>>
>>102418679
>Oh, I forgot to add that your favorite build tool, cargo, is as convenient as it is precisely because its design is antithetical to the "Unix philosophy" that you claim to like.
https://github.com/rust-lang/cargo/blob/master/Cargo.toml
Doesn't look like it. It has a lot of dependencies and by itself is split across many smaller crates. It also is a part of larger rust toolling and focuses on doing one thing. It doesn't include compiler, linker or linter, it just manages dependencies and runs build scripts. You can configure it to use different tools under the hood.

>The actual Unix way would be to use Make to glue together a dozen different tools that together do cargo's job.
Never seen a large build.rs script? It's functionally the same, except more reliable and actually cross platform.

>No, most of it doesn't. I just explained why, you retard.
You just gave an example of systemd, a one of many different optional tools you can use in Linux. This only confirms its modular design of Linux, even if systemd by itself doesn't try to be minimal. It's just one of many stuff to use.

>Have you considered maybe learning from the experience of other software ecosystems?
Yup. I have learned well enough from dealing with cmake, make, ninja, and all that bullshit to never ever want to go back to manual dependency management. This is why your idea to solve made up problems by removing good features sounds so unhinged. You fail to learn from past.
>>
>So far, you've refused to read anything I linked, and you didn't respond to my arguments either, you just denied them and kept repeating your cliches.
I am trying to respond to every argument you made, except for all this "everyone who does X is stupid, X is said be incompetent, etc etc" kind of pointless egomaniac claims.

>I don't get it, why does Rust attract so many zealots who get memed into some midwit shit like "Unix philosophy" and refuse to learn?
Because you struggle with coming up with any good points. All you say is basically claiming how other programmers are more dumb than you and you wonder why no one is listening.
If you were to say "hey, I have a X project and it suffers from Y so if we changed Z then it would be better because W" then I'm sure many people would listen to you. Instead, you go "here is problem X, well, I haven't experienced it myself but I can '''foresee''' it, but anyway to solve it you have to remove useful feature Y and also everyone who thinks differently is stupid and incompetent lole" then it should be pretty obvious why no one is listening.
Practical problems will always more urging than hypothetical ones. Practical solutions will always be more important than ideological ones. But you focus on the later. It feels like talking to zig programmers, they think they are better than anyone, but they never actually use the language for anything except for argue that it's better than X Y and Z.

>Do you think you're the first programmers on Earth because you have affine types and a nice build tool?
Rust was not meant to be an academic language by design. It was designed to take the best from others and create something new from it. Not sure where affine types actually came from, but some say it's from Cyclone.
>>
>JavaScript devs have already gone through a micro-library phase and suffered a lot of pain from it: supply-chain attacks, frequent compatibility breakages, needing glue code to make libraries with different designs work together. That's because
Supply-chainn attacks is something that is an issue, but it's far from being JS-exclusive one. Remember XZ? It was arguable worse than anything that ever happened o npm.
Compatibility breakages are not specific to JS. A manually installed libraries also break when they change. You can say that native libraries do not change that often, but this is just the nature of webdev vs systems.
For the gule, you need more of it if libraries do not share common parts and instead are large, monolithic.

>1) It's harder to vet and trust many libraries than few libraries, even with the same amount of code
Like I said, if these libraries use common shared dependencies, then it's more likely that you already know them.

>2) When it's many independent individuals rather than a team, it's much harder to coordinate on refactors and a general approach to programming
I think that Rust libraries are way better coordinated than C/C++ libraries. With the later it can really get crazy with how differently people program with it(I still hate header-only libraries, who tf thought it will be a good idea?). With Rust, everything seems to be more coordinated because of standard linter and documentation and way less paradigms to choose from.

>But you refuse to learn from it, you refuse to even read about these problems. You insist on falling into that noob trap yourself, and justify it by repeating retarded thought-terminating cliches over and over again. This is not a good approach to programming and will limit your skill.
Kek, and you wonder why people don't listen to you.
>>
>>102423989
>MAUI
>fake news
>Microsoft drops its native .NET tooling in favor of cross-platform Mojo disease to keep Miguel de Icaza and his FOSS shills happy
>FOSStards still shit on MS
MS can't be allowed to win, even when it wins
https://dotnet.microsoft.com/en-us/apps/maui
>>
>>102424160
dumb retard, MAUI is XAML
>>
>>102424169
sure, the same way PowerShell Core is Powershell
it isn't, there's lots of internal Windows administration that can't be done in Powershell Core.
>>
>>102424191
dumb schizo retard, don't @ me again
>>
>>102424022
Make is very often used without cc, they're basically orthogonal. At my current job we use make in combination with PHP. (This isn't a great idea but that's mostly because make isn't very good. It does get the job done.)
Can you find anyone who uses cargo without rustc?
Cargo is a highly specialized tool. Make isn't. The actual Unix philosophy includes giving all your components flexible sloppy interface so you can combine them in unexpected ways. Cargo isn't like that at all (and that's for the best).
>>
>>102424199
>@
go back, redditor
>>
>>102418788
>Even your argument about duplication is something that sounds correct to beginners but doesn't work out in practice.
How many times are you going to claim that others are incompetent?

>You end up with many micro-libraries with overlapping functionality.
At worst case, every dependency would have their own micro-library with the same functionality repeated, which is practically the same thing as your idea of banning second-order dependencies.
In practice, there is going to be very little of these duplicated functionalities.

>In Haskell, there are some small libraries that are cut-down versions of larger libraries. Microlens is one example. That guy found that a large Haskell project would usually end up including both anyway.
In Rust, you just use library features instead of making multiple libraries that do same thing but with less features.

>A classic "Unix philosophy" move:
Sounds more like Haskell specific thing. I never heard about anything like that in Rust, JavaScript or Linux.

>and maybe even put that into the standard library
Bad idea for a systems lang. It makes stdlib larger and harder to build/ship in embedded systems. Also adding opinionated features to the stdlib ends up bloating it and people are still going to choose alternatives if it fails to cover every usecase. We have seen what happened with C++ and its multi-paradigm approach. It's always better to split that into multiple opt-in crates.

>Otherwise, you're going to end up with multiple versions of the same functionality in any large application.
Haven't seen that in my Rust projects. Have you seen that in any of your Rust projects?

>Maybe it would be a good thing to correct that?
And what is the actual, practical issue you are experiencing here?

>it's been like trying to explain quantum mechanics to a goat.
And back to claiming how others are retarded. It sure makes you sound more believable.
>>
>>102424022
>Doesn't look like it.
dumb retard
>>
>>102424201
>Can you find anyone who uses cargo without rustc?
People who work on cranelift I guess? I'm not sure if cranelift replaces rustc altogether or is called by it behind the scene. But rustc is only one of many programs cargo will call. For example people use all kinds of different linkers with cargo, and if you have some actual build scripts you might be calling all sorts of different tools.

>Cargo is a highly specialized tool. Make isn't. The actual Unix philosophy includes giving all your components flexible sloppy interface so you can combine them in unexpected ways. Cargo isn't like that at all (and that's for the best).
This is true. But the everything-is-text-processors part of unix philosophy doesn't really apply when we are talking about dependencies(which is what this conversation was about):
>Write programs to handle text streams, because that is a universal interface.
We are not doing shell scripting here, we are talking about libraries and the standard interface of Rust libraries are Rust functions and types. Cargo uses a lot of dependencies, pic related. It focuses on doing its main job and things like parsing configs, making requests, handling git, etc is delegated to its own library. Imagine if all of this was part of cargo source code, it would be a nightmare to maintain.
>>
>>102394383
>You may start spreading your asshole.
If a rustroon were to say this to me even as a joke I'd get scared, grab my .45 and blast his throat...
>>
>>102424544
>I'm not sure if cranelift replaces rustc altogether
It doesn't.
>But rustc is only one of many programs cargo will call. For example people use all kinds of different linkers with cargo, and if you have some actual build scripts you might be calling all sorts of different tools.
That's not the same thing as using it without rustc.
I think even your linker might actually ultimately be called by rustc but don't quote me on that.
The point is that cargo is very tightly coupled to rustc. This has many benefits but it's not at all the Unix philosophy.
>This is true. But the everything-is-text-processors part of unix philosophy doesn't really apply when we are talking about dependencies(which is what this conversation was about):
Sloppy orthogonality is essential to the Unix philosophy, text streams or not. There are language-agnostic build systems and cargo is not one of them.
>It focuses on doing its main job and things like parsing configs, making requests, handling git, etc is delegated to its own library. Imagine if all of this was part of cargo source code
Almost everybody likes modularity. I don't think it was invented by Unix and I don't think it's sufficient to claim that something is following the Unix philosophy.
>>
>ctrl + f unix philosophy
>38 matches
SHUT
H
U
T

THE
H
E

FUCK
U
C
K

UP
P
>>
>>102424854
based
couldn't care less about unix because everything derived from it still sucks
and no, me saying that does not mean that i'm saying that windows does not suck
>>
>>102424812
>That's not the same thing as using it without rustc.
I never claimed it's the same.

>The point is that cargo is very tightly coupled to rustc. This has many benefits but it's not at all the Unix philosophy.
Of course. I even explain it i the previous post.

>There are language-agnostic build systems and cargo is not one of them.
I never claimed it is. It seems that you've ignored everything related to the actual topic(dependencies, libraries) and instead refute claims I never made.
We were talking about making libraries smaller and focused on doing one thing, not about whenever cargo is language-agonostic(it isn't)

>Almost everybody likes modularity. I don't think it was invented by Unix and I don't think it's sufficient to claim that something is following the Unix philosophy.
Making things small, modular and focused on doing one thing is code of unix philosophy. Re-read the conversation, no one is disagreeing with you.
>>
>>102425034
>explain
explained*

>code of unix philosophy
core*
>>
>>102424606
You are going to have an aneurysm if you keep raging so much, cnile.
>>
>>102424979
the sad reality is Windows actually sucks more.
>>
>>102425080
honestly? i disagree
everything on windows just works
i don't have to fuck with drivers, modify config files, choose between stuff like x11 or wayland...
>>
>>102425100
>it's better because I have less choices
kek
>>
>>102425118
unironically yes
i want to boot up my computer and program or play video games
i do not wish to be forced to learn what a "display server" before being allowed to do so
also have you seen kde lately?? shit is bloated with so many options you'd have to spend weeks figuring out what does what so you can customize it
no thank you, i'll just take windows
>>
>>102425100
>i don't have to fuck with drivers, modify config files, choose between stuff like x11 or wayland...
you literally do though. what the fuck cope bullshit is this post?
WHQL drivers don't even work so you're immediately forced to DL shit that literally is not certified by M$ as actually stable and correct. You're literally forced to cuck and taint your winshit kernel out of the gate.

the config shit is supreme bait. default winshit config literally spies on you and still does stupid shit like hide file name extensions and hidden files. honestly, I could go on but I just don't care. Windows is bad, Win32 is half baked as fuck and modern "windows" is all CLR .NET or monstrously bad C++ API/ABIs
>>
>>102425154
>i want to boot up my computer and program or play video games
and I can do that, with less maintenance than you because I use Linux and am not a cuck.
>>
>>102425227
>dumb retard copes and seethes about how his OS of choice which can't even display thumbnails in its file browser just works while windows doesn't
In windows I just plug my shit in and it works. What the fuck is a WHQL driver? I don't know because I literally never had to deal with this shit.
>>
>>102425261
>WHQL driver
proof wincucks don't even know how their own shitty OS works.
Many such cases.
>>
>>102425034
Do you think Cargo follows the Unix philosophy?
>>
>>102425283
does it do one thing and one thing well? sure I guess. the details I suppose is what you consider to be the one thing.
>>
>>102425283
In the context of this conversation(small, specialized dependencies), yes. As I have explained twice already.
>>
>>102425227
>WHQL drivers don't even work so you're immediately forced to DL shit that literally is not certified by M$ as actually stable and correct.
This is false. Third party drivers (like Nvidia drivers) are automatically downloaded and installed through Windows Update.
>Windows is bad
I never claimed otherwise. Linux is just worse.
>>
>>102425319
>This is false. Third party drivers (like Nvidia drivers) are automatically downloaded and installed through Windows Update.
no, they literally are not. you get the Nvidia WHQL driver which is not the complete package and likely lacks OpenGL/Vk support.
>>
>>102425328
I can literally program and play video games with that driver, so you're either lying or are talking about an older version of Windows.
>>
>>102425304
>does it do one thing and one thing well?
That's not the only essential part of the Unix philosophy.
And in the Unix sense cargo doesn't even meet that bar because it's so tightly coupled to rustc. Its "one thing" can't be "build system" because it isn't a good tool for building anything besides Rust code. And "build system for Rust" is much more specialized than the stuff Unix enthusiasts love.

>>102425316
Why are you calling that the Unix philosophy when the Unix philosophy requires a bunch of other things that Cargo deliberately fails to do? Why pick that term?
>>
>>102425381
kill yourself
>>
>>102425381
>Why are you calling that the Unix philosophy when the Unix philosophy requires a bunch of other things that Cargo deliberately fails to do? Why pick that term?
Because we were talking about dependency managment, not whenever cargo itself is a unix-like tool. The later is a completely different topic and not nearly as interesting. It mostly depends on technicalities of what you actually consider to be unix-philosophy following program. That term was used to describe the design of entire system, not a single program anyway.
>>
>>102425430
see >>102425391
>>
>>102381927
LOL
>>
>>102417177
Interesting suggestion I hadn't considered, vec[Reverse(0)] for last. It's not quite -1 but would be less prone to off by ones probably
https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/index.20impls.20for.20vec



[Advertise on 4chan]

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.