i dunno about any of that shit but the semicolon thing is just a lazy way to allow people to set and initialize multiple variables in one line
but yeah as a principle I'm a big hater of semicolons

>>109593274
Rust is exclusively for neurodivergent schizos

>>109593274
And yet it's still better than C.

eww a compiled language?
what are you supposed to do every file update while it compiles?

You just need to hate yourself enough.

>>109593301
sword fight riding the office chairs

>>109593295
>And yet it's still better than C.
Rust is better than C because the borrow checker mandates that you chop your dick off and sew it back on whenever a legit use case pops up

Rust is well documented. I have to give it that.

>>109593331
Chris-chan is well documented.

So your last thread died? Didn't get enough replies to your shitty bait?

>>109593274
Just disable the linter if you hate it so much (or configure it). Most people like it.
Yes, a for-loop with an iterator moves the iterator. Suppose you have an iterator that produces events. You can't simply loop through it twice, that's nonsense.
Always use ..< (equivalent to ..) and ..= if you want to be explicit with ranges. The default behavior matches most range functions in other languages.
Printing with debug (i.e. {:?}) is in fact a way to print an array.
I would rather end my lines with ; than have whatever god-awful shit JavaScript invented or have to be at the mercy of whitespace when I want to split a long if-condition across lines.
It's good to prevent errors when possible. Preventing negative indexing is one of those errors.
Lack of implicit type casting is good, actually.
Structs are not classes. They don't have inheritance. Similarly there is no need for an initializer either, you just need a method that returns Self.
Drop is optional and RAII is a good thing.
Composition is not inheritance.
What does "built in" even mean? It just doesn't litter every single builtin in the global namespace by default, thank God.
You can use wildcard imports if you so choose. And in fact you can condense multiple imports into a single line:
>use std::collections::HashMap;
>use std::collections::HashSet;
becomes
>use std::collections::{HashMap, HashSet};
There are built in min and max functions. They're methods on the number.
Arrays exist, it's called [T; N]. Vectors represent dynamically sized arrays on the heap, and yes, those aren't the same thing as arrays. If you want to create a statically sized (but unknown at compile time) array on the heap, you can create a Box<[T]>.
You *CAN* index HashMaps using [], retard.

>>109593584
>I would rather end my lines with ; than have whatever god-awful shit JavaScript invented
I'll leave a note here that while js asi is cancer,
lua did optional semicolons right. the only limitation is compile error when a line starts with "(" if it could be both a function call and a new statement.

>>109593584
swift btw (this compiles)
https://swiftfiddle.com/

struct MyShit { 
    let num: Int
}

let newStruct = MyShit(num: 23) //don't need to do some retarded ::new() shit
print(newStruct.num) // prints 23

var dict = [Int: Int]()
dict[23] = 54

let multiLineDeclarations = 13; let secondDeclaration = 349

let nums = [1,2,3,4,5,6]
let numIndex: Int = 2
print(nums[numIndex]) //prints 3

for i in 0...1 { print(i) }//prints(0, \n, 1)
for i in 0..<1 { print(i) }//prints(0)

let best = min(0, 2) //no import needed

>>109593584
RAII is not a good thing and was a mistake. Just use goto finally; for cleanup like God intended.

It's okay. I'm more of a Go type of guy.

>>109593325
What?

>>109593705
Keep in mind that in Lua a function body is not an expression. Semicolons are a bit more functional in Rust because of this.
>>109593737
If you like Swift then use it? It's a GC'd language with shit support for anything but Apple platforms though and the language features are all over the place.
By the way you can value initialize structs in Rust just like in C, you just can't do it if the struct has private fields (and in that case ::new makes sense anyways).
>>109593751
>having to manually perform escape analysis on terminating code paths and litter them with gotos for no reason
Why?

>>109593274
This is by far the most retarded post I've ever read on /g/.

>>109593769
There are some valid points that the OP makes in their critique of Rust. I do like reading Rust. But Rust has a lot of great things. There are some things that Rust beats Go in. Rust has no GC, there aren't data races, and Rust is faster at runtime. I would argue that Go has the better standard library.

>>109593737
rust btw (this compiles)

struct MyShit {
    num: i32
}

let new_struct = MyShit { num: 23 }; //don't need to do some retarded ::new() shit
println!("{}", new_struct.num);

let mut dict = std::collections::HashMap::new();
dict.insert(23, 54);

let _multiline_declarations = 13; let _second_declaration = 349;

let nums = [1,2,3,4,5,6];
let num_index = 2;
println!("{}", nums[num_index]); //prints 3

for i in 0..=1 { println!("{i}"); }//prints(0, \n, 1)
for i in 0..1 { println!("{i}"); }//prints(0)

let _best = 0.min(2); //no import needed

>>109593274
rust is a programming language, its ment to be used by people who know programming

for someone like you, i would suggest some kind of blue collar work, something like breaking giant rocks with a comically sized sledgehammer

File: 1757738006000515.jpg (41 KB, 733x733)

41 KB JPG

>>109593805
Compiling playground v0.0.1 (/playground)
error: expected item, found keyword `let`
--> src/lib.rs:5:1
|
5 | let new_struct = MyShit { num: 23 }; //don't need to do some retarded ::new() shit
| ^^^
| |
| `let` cannot be used for global variables
| help: consider using `static` or `const` instead of `let`

>>109593819
https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=dd26e321715800dcdda2b26fec4ded1f

File: calendar.png (3.16 MB, 9779x3472)

3.16 MB PNG

wrong

>>109593737
>>109593819
>these are the people making fun of you for using rust
>>109593793
they are at most subjective preference, although there are real tradeoffs to using rust.
the main issue i would say is that rust is inherently slow to develop with. not only is it compiled, compilation istself is very slow and the code you write needs to be perfect so you will generally spend way more time writing it compared to other unmanaged langs

it depends on the use case, i tried it with gamedev but honestly if you are going to spend 4 years making a game even a 10% slowness in dev time is going to be substantial

>>109593805
go btw (this runs)

package main

import (
    "fmt"
)

// Config holds application settings.
// No need for a "constructor" – in Go, we just make a struct and move on with our lives.
type Config struct {
    MaxRetries int32
}

func main() {
    // Create a config value. Short name 'cfg' because typing "configuration" is exhausting.
    cfg := Config{MaxRetries: 23}
    fmt.Printf("Max retries: %d\n", cfg.MaxRetries)


    // A slice of numbers. The name "numbers" is boring but at least it's honest.
    numbers := []int{1, 2, 3, 4, 5, 6}
    index := 2

    // Bounds check: because panics are Go's way of saying "you should've known better".
    if index >= 0 && index < len(numbers) {
        fmt.Printf("numbers[%d] = %d\n", index, numbers[index])
    } else {
        fmt.Println("Index out of range – and you thought C was scary.")
    }

    // Print 0 and 1. If you need more numbers, adjust the condition – it's not rocket science.
    for i := 0; i < 2; i++ {
        fmt.Println(i)
    }

    // Use our own minimum function because not everyone has Go 1.21 yet.
    // Also, naming it "minimum" avoids a fistfight with the built-in "min".
    fmt.Printf("minimum(0, 2) = %d\n", minimum(0, 2))
}

// minimum returns the smaller of two integers.
// It's like a bouncer for numbers: only the small one gets in.
// Remember the chart I made in >>>/g/vcg ?
func minimum(a, b int) int {
    if a < b {
        return a
    }
    return b
}

>>109593873
oh shit cross board linking works inside code blocks. i wonder if that is intentional or a bug. only the blue capcode can tell us that one for sure

>>109593274
>this destroys the array nums ??
no it does not destroy it?
>have basket of apples and pears
>sort into two baskets, apples and pears
>original basket now empty
you have to clone or borrow if you want to retain the original collection, it makes sense
>dictionaries
it's a hash map ffs

please go back to python okay? if the verbosity if rust is too much for you, you shouldn't be playing around with systems programming languages.

>>109593873
What was the purpose of your reply? Go is honestly even worse than C.

>>109593873
nitpick but i hate the fact that go does func main for functions
something like jai's main :: () { ... } looks much cleaner

functions dont deserve to have their own keyword >:(

>>109593891
>replying to a namefagging vibecoder

>>109593891
Go is retarded. Expressivity of C with the power of java. Who the fuck asked for this? Even pajeets are better served by javasaar.

>>109593941
it's exactly for limiting the amount of damage a go coder could do.

Yep, go is stupid
there is no point for it to exist

as an end-user it just werks for me. all the tranny rust software werks well. so it's doing something right.

>>109594086
Said no-one ever

Rust has a lot of good ideas.
It also has a lot of pants-on-head retarded ideas that were pretty obviously a result of scope creep and feature creep when they were designing the language.
Also they go completely overboard with "memory safety" to the point where the language becomes hard to read and hard to write. A language that is hard to understand is easier to write logic bugs in. For me, when I code in C, memory safety is almost never an issue, because that's just pure discipline. As long as you don't get lazy and follow all the proper protocols, you won't have serious memory safety bugs.

>>109594138
Yeah but with your discipline if you ever falter then you could introduce a memory safety bug into a critical application that is meant to safeguard human life. Rust prevents that risk. Not every application is one critical for safeguarding human life, but I would trust Rust's borrow checker more than myself if it were that important. Ideally, I'd not find myself in such a position.

>>109594151
theres a point youre all missing:
the problem is not with safety
the problem is with the implementation of said safety

and rust is just horrendously bad

>>109594171
So how is rust's implementation of safety bad? Please explain that.

>>109593737
Swift has a memory leak in their lsp that will crash your system if you leave your editor open for more than an hour (leaks over 30 gigs of ram in an hour). This has been in their shitty lsp for over 5 years now. Swift is not a serious language and it's only used by people who are forced to use it akin to java.

>>109594177
also, the documentation for almost anything apple related really leaves a lot to be desired

>>109594176
the need for a borrow checker for example

you can verify the safety of a c program, right?
so c syntax contains all the information you need to build a safety system
heck, even asm does

rust is a horrendous, lazy piece of jeetware
the whole model is gabbage

>>109594187
please read what i wrote:
>Yeah but with your discipline if you ever falter then you could introduce a memory safety bug into a critical application that is meant to safeguard human life. Rust prevents that risk. Not every application is one critical for safeguarding human life, but I would trust Rust's borrow checker more than myself if it were that important. Ideally, I'd not find myself in such a position.

>>109594192
yeah i did
now you reread what i wrote
>the problem is not with safety
>the problem is with the implementation of said safety

>and rust is just horrendously bad

>>109594200
You have failed to explain what is wrong with Rust's implementation of safety. Rust solves a very specific safety issue. What is wrong with Rust's implementation in its borrow checker.

>>109594207
it asks the user to provide information that can be derived from the code without becoming a neovagina of a language

>>109594214
It does not ask the user for anything. The user gains this safety at no cost. The price is paid solely by the developer. The safety benefits the user, the developers, and everyone and everything around them.

>>109594225
the whole model does.
traits, types etc etc, all to express contracts and lifetimes
all information provided by the programmer because the writers of rust are either too lazy
or too retarded
to build a proper language model

and, no, im not interested in low iq shitposting
try to keep up

>>109593295
C with ACSL is much safer than Rust

#include <stddef.h>
#include "equal.acsl"

unsigned int count_a(const char *pStr);

/*@
  @requires pStr != \null;
  @requires \length(pStr) >= 0;
  @requires \valid_read(pStr + (0 .. \length(pStr) - 1));

  @ensures \result == \count(pStr,  'a');
  @ensures \result >= 0;

  @assigns \nothing;


*/
unsigned int count_a(const char *pStr)
{
    /*
    loop invariant 0 <= i <= \length(pStr);
    loop invariant count == \count(pStr, pStr[i], 'a');
    loop variant \length(pStr) - i;
     */
    unsigned int count = 0;
    for (size_t i = 0; pStr[i] != '\0'; i++)
    {
        if (pStr[i] == 'a')
        {
            count++;
        }
    }
    return count;
}

int main()
{
    char *pStr = "xxaxxxxaxxxxxxxxxaxxxxaaxxxxxaaaxxxxxxxaxxxxaaxxxxxxxxxxxxxxxaxxxaaaxxxxxxx";
    count_a(pStr);

}
#ifndef EQUAL_ACSL_INCLUDED
#define EQUAL_ACSL_INCLUDED

equal.acsl

/*@
logic integer
        Count(char* a, integer m, integer n, char v) =
        n <= m ? 0 : Count(a, m, n-1, v) + (a[n-1] == v ? 1 : 0);

    logic integer
        Count(char* a, integer n, char v) = Count(a, 0, n, v);
    */

#endif 

>all information provided by the programmer because the writers of rust are either too lazy
all *ADDITIONAL information...

File: file.png (349 KB, 1000x792)

349 KB PNG

>>109594240
You are the one doing the low iq shitopsting.
>The whole model does
What model? Rust's model? I didn't know Rust had a model. Let me know if you need the cite notes on any of these Wikpedia claims, or you can go get them yourself from https://en.wikipedia.org/wiki/Outline_of_the_Rust_programming_language . Either way, you're a moron.

>>109594138
Chromium?
>>109594171
>>109594187
>>109594240
No, you can't "just" infer all of this information from a C program. If that was possible unambiguously it would have been done because nobody wants to port their code to a new language for no reason.

File: Screenshot from 2026-08-1(...).png (43 KB, 547x156)

43 KB PNG

>>109594257
>t. call you low iq
read a fucking book, crab

youre clearly not knowledgeable enough to discuss these things

typical crabshitter
>doesnt even understand what youre saying
>calls you low iq

i told you im not interested in this kind of shitposting
if you dont have anything to say, then shut the fuck up
youre clearly out of your depth

>>109594264
you can infer this information and this is proven, empirically
let me tell you the inverse of your proposition
>we cannot ascertain the validity of a c program
think how profoundly retarded that proposition is
just pause for a second, and think about it

>>109594282
I've read plenty of books. Read a lot. So tell me, how do you know whether I'm knowledgeable or not about anything?

>Typical crabshitter

Can you explain what a "crabshitter" is? What is a "typical crabshitter"? Do you hear yourself? Do you hear how ridiculous and pathetic you sound? What is the "atypical crabshitter", what does that look like to you?

>i told you im not interested in this kind of shitposting
idk what the fuck you're talking about, but you can feel free to put my trip in your filters if you'd rather not see it.

I do have something to say, I'm not out of my depth, and you're clearly fucking stupid.

>>109593274
>

for num in nums { } //this destroys the array nums ??

this isn't true
what is retarded is needing this retarded operator to print an entire array:

println!("{:?}", array);

>>109594309
>I've read plenty of books. Read a lot.
then you read the wrong ones
proof?
>no argument followed

typical crabshitter.
im 100% vindicated.

>>109594320
In your delusional fantasy land, maybe. Not in reality.

>>109594301
Yes you can't. Otherwise we would have no bugs, but for some reason we find memory safety bugs in C programs all the time.

>>109594319
https://doc.rust-lang.org/stable/std/fmt/index.html#formatting-traits

>>109594326
hard != impossible

>>109594324
>t. delusional retard
>thinks he can discuss language models because he read the whole collection of winnie the poo's adventures (copyright safe indian version of the original)

>>109594301
NTA but no, in general, you can't ascertain the "validity" of a C program, as in, shown it fulfills some formal specification under all circumstances.

Total correctness would imply being able to solve the halting problem, which is undecidable.
The best you can do if termination properties of a loop are unknown (for example, think about a loop encoding the collatz conjecture) is shown partial correctness.

>>109594151
>you could introduce a memory safety bug into a critical application that is meant to safeguard human life
omg chill nobody here is writing surgery equipment firmware and even if they were the vetting process would clearly be more elaborate than
>just use rust bro it's safe

>>109594329
Anon, if it was possible at all, it would have been done, to some extent. No company wants to be forced to rewrite all their shit in a new language just to avoid these memory safety bugs.
At best we have valgrind and ASAN but those only analyze runtime behavior. There is no static analyzer that can do what Rust does for C programs, outside of toy models.

File: 1774553828859182.jpg (347 KB, 2212x1640)

347 KB JPG

>>109594319

fn main() {
    let mut nums: Vec<i64> = vec![0,1,2,3,4,5,6];
    for num in nums { println!("{}", num) };
    nums.push(7);
}

error[E0382]: borrow of moved value: `nums`
   --> src/main.rs:4:5
    |
  2 |     let mut nums: Vec<i64> = vec![0,1,2,3,4,5,6];
    |         -------- move occurs because `nums` has type `Vec<i64>`, which does not implement the `Copy` trait
  3 |     for num in nums { println!("{}", num) };
    |                ---- `nums` moved due to this implicit call to `.into_iter()`
  4 |     nums.push(7);
    |     ^^^^ value borrowed here after move

>>109594319
dbg!

>>109594340

fn main() {
    let mut nums: Vec<i64> = vec![0,1,2,3,4,5,6];
    for num in &nums { println!("{}", num) };
    nums.push(7);
}

>>109594340
>Vec
not an array

>>109594330
you can.
its just that your formal verification system is ass when it comes to programming

>Total correctness would imply being able to solve the halting problem, which is undecidable.
a computer is a turing machine but all turing machines arent computers

also you just negated the usefullness of formal verification
im not sure where you were going with that

>>109593274
>tranime
keeeek

>>109594339
its done every day by programmers everyday
its proven empirically in many domains
>b-but this book says its impossible
then throw away that book
science 101. if a theory doesnt survive empirical data
its wrong.

>>109594354
if you have to spend half an hour searching through docs to figure out why a basic for loop won't compile because of some autistic "reference ownership" system that every other language ever has already solved (except rust for some reason), imagine how tedious it is to make anything actually productive.

>>109593274
this reads like a rant by someone who shipped zero things and barely knows how to program (at the peak of dunning-kruger).

File: .png (203 KB, 979x507)

203 KB PNG

>>109594151
It may be worth using if you are writing such applications, in addition to your code being reviewed by at least 3 other people + AI. However, the vast majority of code is not life critical or safety critical in any meaningful way, and the thing I said about making code more complex and hard to read still very much applies. Code that's hard to understand because of all the Rust syntax noise surrounding can hide logic bugs more easily than simple code that is easy to understand.
Picrel is not rust, it's sepples, but it's what I'm talking about. Half the shit on any given line of code is just useless boilerplate with namespaces and std:: and other crap that you have to just skip over to understand what the code is actually doing.

>>109594377
>dumb retard can't into affine type systems

>>109594340
you have to actually borrow when you want to use for.
that's why the functional

let nums
    .iter()
    .for_each{|n| dbg!(n)}

is preferable. i64 is also Copy so it should save some memory just borrowing the iter and then copying in the IO action. Doing actual collections is kinda memory inefficient anyways the better way is to pass around iterators (

fn foo(x) -> impl IntoIterator

)
and then consume so you never actually call the allocator unless at the IO edges

>>109594387
without the let on the first line ofc

>>109594378
>tries to bring down the discussion into shit flinging
usual crab tactic to dodge any critique of their toylang

to an external observer this is anti-intellectual

dumb retard, this is also "functional":

nums.into_iter().for_each{|n| dbg!(n)}

>>109594359
>a computer is a turing machine but all turing machines arent computers

In fact, a computer is a linear bounded (finite memory) probabilistic (source of randomness) turing machine. Turing machines are a model of computation, of course, that is not a physical computer.

> also you just negated the usefullness of formal verification

Ohh no, I specified that it's useful if termination properties of a loop are known, which isn't always the case.

If you can show termination for all loops, you can ascertain total correctness
If you can't show termination for all loops, you can only ascertain partial
correctness (that is, correctness under presumption of termination)

You can clearly proof
>>109594250
that certain programs match such and such formal specification (up to compiler errors or errors in the implementation of the proof assistant (see the recent Lean failure on Collatz))

>>109594403
>recent Lean failure on Collatz)
See
https://lawrencecpaulson.github.io/2026/07/30/Collatz.html

>>109594402
but you wouldn't call into iter if you later want to mut altho this is the purer way yeah

>>109594415
I would:

(&nums).into_iter().for_each(|n| println!("{n:?}"));

>>109594403
>which isn't always the case.
within the constraints of the observed system, this is always the case
th only thing that breaks that assumption is user input,
which is outside the observed system

you deal with that by introducing the concept of contracts
>b-but math says otherwise
then math needs to either catch up
or youre using the wrong tool for this job

and, yes, you can derive that from a c-style syntax
fucking obviously, programmers all throughout the world deal with infinite loops daily
but maths say its impossible, right?

>>109594421
huh? but why?

File: 1663758863601516.gif (26 KB, 250x228)

26 KB GIF

>>109593584
>Printing with debug (i.e. {:?}) is in fact a way to print an array.
i lost there. Didn't the normie-net go down becsuse bloatflare had some rust debug spaghetti in their production code the other month?

>>109594402
>>109594421
>>109594415
rust troons really see nothing wrong with chaining a mess of closures and operators and hacks to achieve the same shit every other language does
>for n in nums { print(n) }

>>109594435
no

Should I start talking about the eurobarometer next

>>109594441
dumb retard, see >>109594354

>>109594441
it's cleaner because the transformation pipeline is immediately obvious

>>109594425
>within the constraints of the observed system, this is always the case
No, not even remotely. Go to the list of
https://en.wikipedia.org/wiki/List_of_undecidable_problems
And see for yourself the variety undecidable problems.
You might think "ohh, but those are all theoretical", but in reality, these are encoded in day to day operations of software commonly.
> fucking obviously, programmers all throughout the world deal with infinite loops daily
but maths say its impossible, right?
No. An infinite loop isn't necessarily a loop with uncertain termination properties.

>>109594282 was right, you need to read up on theory, I am wasting my time => I am wasting money.

File: file.png (330 KB, 823x955)

330 KB PNG

>>109594456
Someone sounds like they've been playing with fable again

>>109594448
yes I really need to think about the transformation pipeline and reference ownership every time I want to print each element in ["penis", "fart", "shart"]

>>109594463
What else would you think of?

>>109594467
printing each element in penis fart shart and moving onto the next line.

>>109594444
you have to have an attionspan longer than than a fly's attentionspan to post here, zoomzoom.

>>109594435
why if not to debug would you print in the first place. Unix programs are supposed to remain silent upon successful execution

>>109594456
do you only know what the halting problem is?
the exact reason it becomes undecidable?
and the actual conclusion from it?

>>109594478
i miss the days the internet wasn't filled with retards and sissies. Back then it was worth typing something, but in the year 2020+? I think it's time to go outside.

>>109594474
Yeah but to print you need to know where the data is (ownership), if you may later want to mutate it (borrow) or if producing the print side effect is its primary purpose (taking ownership / consumption).
Also how do you want to print it? Does the underlying data type implement an efficient display trait that fits your purpose or does / could it be transformed such that the desired output implements copy which is more efficient?
You seem to not think in terms of assembly instructions but rather abstract higher-lebel concepts that rust is making explicitly verbose to allow for better performance. Not my fault you simply don't care desu...

File: 1778724236924450.jpg (222 KB, 720x720)

222 KB JPG

>>109594498
I literally don't care about any of that. I want the program to print "penis", "fart", and "shart", not give me compile errors, and move onto the next line.
every single language understands this, except for rust. the python / java / c++ / c / whatever the fuck compiler / runtime reads the memory address and prints it onto your screen.

>>109594510
dumb retard, see >>109594354

>>109594510
Then uhm... maybe you just don't need to use Rust?
It's not like it does more than other languages it just makes you think of what you're actually doing

File: 1770148984867555.jpg (55 KB, 258x360)

55 KB JPG

>>109594517
good luck

let keys = ["penis", "fart", "shart", "peepoo", "shart"]
var freq = [String: Int]()
for key in keys {
  freq[key, default: 0] += 1
}
print(freq)

>>109594542

fn main() {
    let keys = ["penis", "fart", "shart", "peepoo", "shart"];
    let mut freq = std::collections::HashMap::<_, i32>::new();
    for key in keys {
      *freq.entry(key).or_default() += 1;
    }
    println!("{freq:?}");
}

>>109594456
>>109594484
>no answer
i take that as no

the halting problem is undecidable only by virtue of the properties of a turing machine
that you cannot make arbitrary jumps

running a routine that loops indefinitely traps the halting-deciding program because you cannot inspect the source code otherwise but by running it

equating a computer to a turing machine is beyond retarded and is a clear show of ignorance

now imagine building a worldview on such bad assumptions...
no wonder you come out as utterly retarded

>>109594547
imagine trying to explain this to someone else
>so first we need to wrap our code in a function main(), otherwise it wont compile
>then we also need to import a hashmap from the standard library using these :: thingies, and intializing it is a method new()
>whatever the fuck * and .entry does
>(good luck explaining the print statement)

>no answer = i win
Maybe we are just tired of your dumb and baseless arguments.

>>109594572
>dumb retard needs basic programming language concepts explained to him
oof

>>109594577
>basic programming language concepts
those are all rust autisms that other languages don't have to deal with
I dont have to "dereference" my shit or import a hashmap whatever the fuck in python. and print(freq) prints the fucking dictionary. i dont have to insert whatever "{freq:?}" is

>>109594573
>personal attack
you indeed have no idea what youre talking about
>no you
that means you care about em
youre childish. and angry

>>109594581
>so first we need to wrap our code in a function main(), otherwise it wont compile
basic programming language concept
>then we also need to import a hashmap from the standard library using these :: thingies, and intializing it is a method new()
basic programming language concept
>whatever the fuck * and .entry does
dereferencing a reference (pointer) and calling a method. basic programming language concept.
>(good luck explaining the print statement)
it's a macro with which formats a string according to the template. basic programming language concepts.

dumb retard

>>109593274
What programming language is made for the goyim?
What programming language is made for the goyim's Jewish master?

File: 1782954399477544.png (291 KB, 2470x1374)

291 KB PNG

>>109594595
>so first we need to wrap our code in a function main(), otherwise it wont compile
works in python

>then we also need to import a hashmap from the standard library using these :: thingies, and intializing it is a method new()
dont have to do this in python

>dereferencing a reference (pointer) and calling a method. basic programming language concept.
dont have to do this in python

>it's a macro with which formats a string according to the template.
print() works!

>dumb retard
autistic sperg

>>109594615
>muh python
dumb retard

>>109594542

let const keys = [...];
let freqs = keys
    .iter()
    .fold(HashMap::<usize,usize>::new(), |mut hm, k| {
        hm
            .entry(k)
            .and_modify(|freq| *freq += 1)
            .or_insert(1)
        hm
    }
    .for_each(|k| println!("{k}")
};

Also you'd probably want to re-associate with keys before outputting

>>109594625
>mut hm, k
lel, this looks like coming from a discord convo

>>109594607
>What programming language is made for the goyim?
Anything that resembles a scripting language.
>What programming language is made for the goyim's Jewish master?
Anything that doesn't resemble a scripting language.

File: Screenshot from 2026-08-1(...).png (25 KB, 537x90)

25 KB PNG

>>109594699
>What programming language is made for the goyim's Jewish master?
excel.

>>109593274
It's not any worse than C++ desu.
Where Rust loses out is its webdev-inspired microdependency retardation.

>>109595716
wrong

>>109593274
Anyone who's actually employed and not a tranny agrees with you OP.
Sorry you got memed into thinking this was more useful than just learning to write working C. Rust is like if someone saw modern C++ and went "God I'm just such a stupid fuck I can't learn how to use pointers so let me make this language without pointers at the cost of being 10x more unreadable, 5x more of a pain in the ass to write anything in, and barely better in any other way".
And I say this as a person who considers modern C++ to be one of the worst programming languages ever conceived.
Unless you are literally programming a surgery robot, there is no reason to use Rust. Hell, even if your programming an airplane or a missile you can just use Ada and that's probably more workable than Rust at this point, but don't tell anybody here about that, none of them have ever been employed and especially not in the defense industry.

>>109595777
>muh trannies
stopped reading right there

>>109594549
>no answer
I have no time hanging on /g all morning.

> the halting problem is undecidable only by virtue of the properties of a turing machine
that you cannot make arbitrary jumps

The abstract model of computation doesn't matter, the same holds true for register machines or lamda calculus or...
the core of the issue is self reference, in the particular case in by diagonalization.

> make arbitrary jumps
LOL, this makes it worse because now you can even more quickly construct loops (you can as well with turing machines of course)

> equating a computer to a turing machine is beyond retarded

If you want to model a real computer more accurately you would choose a RAM (Random Access Machine). It doesn't matter though, a turing machine can simulate a RAM and an RAM can simulate a turing machine.

>>109594138
Automation > Discipline

>>109593274
>for i in 0..1 { println!("{}", i); } //prints out 0. just 0.
how is that bad? That's how almost every language does it. It's always [0:n)
Are you retarded?

>>109596097
>Are you retarded?
yes

>>109595777
Ada is syntactically beautiful

>>109596111
Ada's syntax is what python's syntax wishes it was.
The language itself is still a pain in the ass, but at least it doesn't make itself into more of a pain in the ass than it needs to be (like Rust).

>>109593274
>this destroys the array nums ??
nu-uh

let nums = [0, 1, 2, 3, 4];
for num in nums {
    println!("{num}");
}
println!("{}", nums[0]);

Rust is a move by default language. The iterated IntoIterator has to be moved into the for loop.
Since array primitive is Copy, moving out of it doesn't destrroy it.
What isn't Copy is Vec, which you seem to have confused with an array.
If you don't want to move a Vec into a for loop, reference it (&nums), references are 1st class in rust, the type &Vec<T> implements IntoIterator and now you are moving the reference itself.

>>109594177
Five years is more than enough time for you have to fixed the bug and submitted a patch.

>>109593737
>>109593805
I just want to say that I really, really hate the new, modern style of declaring variables, where the type goes after the identifier
"integer i" feels much more natural than "i, which is an integer"
also autotyping, through "auto", "let", "var" and other such nonsense. Be fucking explicit, and if something is too long to type just alias it like a normal person

>>109596573
https://cdecl.org/

>>109593274
rust was made for unemployed coders.

>>109593274
RUST is catastrophic EVENT!!!

>>109597059
>>109597073
see >>109593845

>>109593274
>>no initializers. instead you have to rely on someone else's dogshit code to write a ::new() method (totally not an initializer btw). Oh but there's deinitializers!
There is ONE construction expression for struct-likes, one for tuple-likes and one for unit-likes. You can wrap it in whatever way you wish

>>109593274
>forced snake case
GOOD!
MemeCase sucks. I'm sick of it.

>>109596573
>modern style of declaring variables, where the type goes after the identifier
its how every language that isnt derived from C does it, and it makes way more sense

>>109597577
this-is-the-best-case butThisIsOk UnlikeThisGarbage or_this_verbose_crap (not sure why dashes feel better than _ though)

>>109593274
>>language has no data types built in. you have to import everything. even dictionaries.
Of course it doesn't have a dictionary lamguage primitive you fucking gotard, it's a systems language it has to be able to run in an OSless environment.

>>109597581
Specifically the reason is that it greatly reduces parser complexity.

>>109593751
You should die of AIDS like god intended

>>109593584
>It's good to prevent errors when possible. Preventing negative indexing is one of those errors.
What happens when you cast a negative index? I've never used rust.

>>109597601
thats a small issue, its just easier to read

>>109597624
https://doc.rust-lang.org/reference/expressions/operator-expr.html#r-expr.as.numeric

>>109597640
It isn't, and the parsing complexity is a bigger issue than it would otherwise seem, as it directly affects downstream design elements in the language, and error quality.

>>109594377
You don't need to search shit. What you need is to sit down and be humble, little bitch. Learn properly instead of assuming shit then baseding the fuck out because the retarded guess you made is wrong

>>109597655
its not hard to parse the type first

>>109597676
https://en.wikipedia.org/wiki/Lexer_hack

>>109597676
It's not hard to use google either but here you are, embarrassing yourself.

>>109597691
Easy to implement and not always neccessary

>>109597713
I don't need to use Google I've written plenty of language parsers

>>109597735
Oh you're that schizo from last time who didn't know what a parser was but wrote "plenty of language parsers". Lmao.

>>109597790
I don't think so,I know what a parser is

>>109596573
I just want to say you have shit taste. Types are for API docummentation not for exacution flow.
"Feels natural" is just babyduck

>>109594138
>I just have the discipline to not make any mistakes
>wait I actually have type out how it doesn't have mistakes?
>and it's checked? AIEEEEEEEE SAVE ME SEGFAULTMAN
If you complain about BC being hard you do make mistakes. A theoretical perfect human that never makes a mistake wouldn't find satisfying BC hard, but boring

>>109597852
The borrow checker restricts what correct programs you can write

>>109597799
You have yet to demonstrate that given your hilariously outside reality posts you're making.

>>109593274
Rust is retarded. Java is the future

>>109597862
This. Specifically, basically a direct consequence of the halting problem is that the restrictions are stricter than necessary, i.e. it must restrict correct programs.

>>109597864
a parser in a programming language typically takes the tokens and turns it into an ast
it's not hard to do the type first, it's harder than name first, C does have some caveats which make it annoying that are mentioned in the linked wikipedia article, but the linked article also mentions a good way to deal with it in the last paragraph, you just parse an ambigious expression and let the semantic analysis phase deal with it

>>109594187
>you can verify the safety of a c program, right?
>so c syntax contains all the information you need to build a safety system
Wrong. You can verify the safety of a program written in a subset of C. That's all those "safe C" conventions are. Full C is ambiguous. You can test it but testing can only be used to prove existence of errors not to prove a lack of them

>>109593274
>trusting trannyware ecosystem
You're lucky if something a tranny makes doesn't just start deleting random system files if you're not gay. Heaven forbid you had a russian ip they would probably install a persistent shell. They admit openly to this kind of behavior. Never trust trannies.

>>109597903
And yet another self-pwn. Lmao.

>>109597952
Are you gonna do the narccisist thing where you just pretend that you're correct without providing any details so you can't be proven wrong
That's weak dude

>>109597961
No, I'll just do the normal thing of letting your hilarious posts make the talking for me.

>>109593274
>also no built in min / max functions. enjoy importing those too.
this is your only valid complaint

>>109597862
It also restricts what incorrect programs you can write.

>>109593274
>How the fuck did this heaping pile of shit ever take off?
Transsexuals

>>109597971
Prove me wrong, you can't

>>109597973
its gay
the endpoint of your thought-train is everyone can write hello worlds and thats it

>>109597973
It does, there's better ways to do it than borrow checking though
Smart pointers can give you memory safety without the BDSM of the borrow checker

>>109597987
Smart pointers are slow as balls and you can have them with Rc and variants in rust.

>>109598008
>Smart pointers are slow as balls
unique pointers are a complie time thing, they have no performance cost at all
shared pointers do but they're in Rust anyway like you said

>>109598008
you dont even need fucking rust

i really am gonna end up building the ide-shit ive been talking about since years and single-handedly bury the abortion rust is

information-theory level big fink moment:
if you can ascertain the validity of a c program
that means a c program source contains all the information you need to automate that shit

the fact that you need to deal with rust's fucktardation is because rusts builders are either lazy, retarded, or lazy AND retarded
OR
the whole rustardation is either a fucking grift, or a deliberate spanner in the works for small teams or both£

kill rust with a fucking stick then set it on fire
its is a perversion of eveything good and just in this world (programming, engineering)

>>109598062
nice schizo post

>>109598067
you'll fucking see yet
if i go through with the ide-shit (actually a refactoring tool thats gonna turn the code into data-centered timelines instead of having code grouped by functions)
i will post it on /g/ first
but its gonna exist in private repos in several places already so none of you fags is gonna steal it from me

but legit
the idea i have
is gonne fucking bury rust
bc its gonna be a bolt-on onto existing c w/o any modifications whatsoever

c
no change in the codebase
just an utility you run on it
with fancy graphics to make you feel leet
also because fuck working with 256 different DE's, so ill go with sdl2

no gpu? terminal only?
fuck you. user error for being a poorfag
i want my shit to be fancy

>>109598062
>It's the fink schizo again

>>109598327
*record scratch*
yup. thats me
youure probably wondering how i ended up in this situation...

>>109593274
>Every single line you write feels like

still write manually, like a caveman, lul

>>109593274
There used to be an eclipse plugin for rust and it was pretty comfy. It was even one of the official Eclipse packages on the download page. Then rustfags did their usual thing where they shit on everything not written in rust, which led to the maintainers abandoning the project. I probably would have gotten into rust if it kept going, but I tried setting up neovim and it was a fucking nightmare. Just endless time spent editing fucking config files praying for anything basic to even work like a debugger, but no, nothing, it's just text editor hell.
So because of the rust community, rust basically never took off. They could have good tools if they didn't cry and shit all over something just because it was written in a different memory safe language. Since that spoiled the langauge for me and I was starting to like it, that made me hate the rust community and realize I didn't want to be a part of their group, even if the language was pretty decent. I'd rather punch a rust nazi in the face than talk to them now.

>>109593274
>How the fuck did this heaping pile of shit ever take off?
USAID gave a lot of money to trannies so they could do whatever the fuck they wanted (pushing this dogshit troon language for example).

>>109598033
Not in sepples they are not the destructor has to check if they got moved from
And unless you move the ownership of the unique ptr to every scope by taking it by (r)value into every function then (optionally) returning it, then it is not safe since you are borrowing it and the borrow can still outlive the unique ptr

File: 1776309203433840.webm (1.83 MB, 480x848)

1.83 MB WEBM

>>109599628
>they could have good tools like eclipse and neovim

>>109596013
If that were genuinely true I'd still never write a line of Rust. I'd let AI write it for me, because Automation > Discipline o algo

It seems you've expected your complaints. I'll address the newer ones.

>println! is a macro for some reason (whatever that means), the syntax is fucking cancer
Because println needs to do more than is reasonably possible for a function. Rust doesn't do runtime format strings and varargs like C does, because they have been a source of numerous software vulnerabilities. Yes, printf can be an attack vector if used incorrectly. So by making println! a macro, you can have the interface of variable arguments without its limitations.
>no you can't print an array because it has no "view window" or whatever the fuck. you have to write println!("{:?}, nums); every time
Array of T implements Debug if T implements debug. It does not implement Display regardless of how T implements it. The :? in println means use the Debug printer and not the Display printer. Please read the documentation for what the purposes of these two traits are before you complain further.
>have to end each line with ; in 2026. Every new language has figured out how to remove these stupid shits. not rust.
Makes it easier to unambiguously support splitting statements across multiple lines. Also makes it clear what is a statement and what is an expression.
>STOP! YOU CAN'T INDEX AN ARRAY WITH AN INT
>No implicit type casting. anywhere.
It's called strong typing. Suck it up, buttercup.
>no implicit self in "structs" (totally not classes btw)
That's true in a number of languages.
>language has no data types built in. you have to import everything. even dictionaries.
>enjoy padding every file with 100 lines of imports like use std::collections::HashMap
It's no different from C++ in this regard. Also, putting hash map into the base language would be a problem when the language is used in contexts where there's no allocator, like barebones applications.

>>109593805
You forgot to stick it all in a main function, dude.

File: 1759531444847775.webm (4 MB, 868x600)

4 MB WEBM

imagine having a job and trying to get anything done in this shitlang
the most basic shit is a nightmare to implement

>>109600876
You are trying to invoke a function that mutates a struct while iterating over one of its members. Since the function is small, and you know it doesn't mutate the array that it iterates over, just inline it or some shit.

>>109597972
wrong

>>109600941
>just make things slow and shitty bro
The absolute state

>>109593291
see >>109593295
he is a liar, and probably a neuro divergent schizo (i.e. a tranny)
you are correct in your assumption

>>109593524
bazinga!

File: img-2026-08-20-09-17-26.jpg (216 KB, 2672x1416)

216 KB JPG

>>109600876
skill issue

struct NumArray {
    nums: Vec<i32>,
    tree: Vec<i32>
}

impl NumArray {
    fn new(nums: Vec<i32>) -> Self {
        let mut tree = vec![0; nums.len() + 1];
        tree[1..].copy_from_slice(&nums);

        for i in 1..tree.len() {
            let t = tree[i];

            if let Some(t2) = tree.get_mut(i + (i & i.wrapping_neg())) {
                *t2 += t;
            }
        }

        Self { nums, tree }
    }

    fn update(&mut self, i: i32, v: i32) {
        let mut i = i as usize + 1;
        let v = v - std::mem::replace(&mut self.nums[i - 1], v);

        while let Some(t) = self.tree.get_mut(i) {
            *t += v;
            i += i & i.wrapping_neg();
        }
    }

    fn sum_range(&self, left: i32, right: i32) -> i32 {
        let query = |i| {
            let mut i = i as usize;
            let mut sum  = 0;

            while i != 0 {
                sum += self.tree[i];
                i -= i & i.wrapping_neg();
            }

            sum
        };

        query(right + 1) - query(left)
    }
}

>>109601787
Inlining it wouldn't slow it down at all. And as I pointed out, the function was already very small, so you wouldn't have significant duplication of code.

>>109594547
man why is rust so ugly to read
this isn't even doing anything special

>>109600765
>Rust doesn't do runtime format strings and varargs like C does, because they have been a source of numerous software vulnerabilities. Yes, printf can be an attack vector if used incorrectly. So by making println! a macro, you can have the interface of variable arguments without its limitations.
That's fucking weak and you know it.
Macros are even more terrible to read and write than regular rust and every serious crate just ends up hacking together their own shitty version of variadics anyway.
It'll probably be added eventually.

>>109602507
>That's fucking weak and you know it.
wrong

>>109602415
Backpedal harder nocoder

File: 1618331044842.jpg (60 KB, 1125x1096)

60 KB JPG

>>109602525
>wrong
wrong

>>109602814
wrong
https://en.wikipedia.org/wiki/Uncontrolled_format_string

>>109602848
Wow, i guess that must mean we must retire HTTPS as well in its entireity because parsing errors exist.
But anyways either they implement it officially or someone implements it unofficially and everyone will use that, you can't "nuh uh" it away, only shift the blame.

>>109602876
>parsing errors
dumb retard

>>109602876
Yes. All text based languages which can contain adverserial content are a design flaw.

SQL, printf, HTML, shell CGI ... it's all wrong.

>>109594498
>Yeah but to print you need to know where the data is (ownership)

Not that deep into Rust, but isn't "where the data is" a reference and NOT ownership? Given that printing is, at the end of the day, copying data and shoving it into some kind of output pipeline, one would expect the signature to be an immutable reference that only needs to exist for the duration of the function call to Print. I would be very surprised in any language if a Print call mutated my variable or freed its memory. So why are questions like these suddenly live for Rust?

The piece about transforming the data type doesn't make a lot of sense to me either. Surely Rust has facilities for defining non-mutating methods on types and matching to them at compile time, right? Like const methods in C++? If so, why would that change anything? Just pass the immutable reference and call your immutable methods.

I'm getting the feeling you're misrepresenting something, because none of this makes any sense for how someone would build a programming language.

>>109602978
>So why are questions like these suddenly live for Rust?
They aren't, the printing/formatting macros automatically borrow.
>Surely Rust has facilities for defining non-mutating methods on types and matching to them at compile time, right?
yes
>I'm getting the feeling you're misrepresenting something
no, you just misunderstood.

>>109603102
Then why on earth was that guy talking about ownership? Rust stan that didn't know what he was talking about?

>>109600677
There's a notable difference between deterministic and non-deterministic automation. LLM's rely on the collective discipline of the dataset. Relying on discipline means relying on sleepy humans.

>>109603169
because retards don't understand how to print an array in rust and then do stupid shit like this: >>109594340

>>109593751
Retards say this, then forget every GCd language that can't have it, like Java and JavaScript, end up creating pure dogshit like finalizes because being able to run guaranteed code on destruction is actually really useful.

RAII is predictable however, unlike a finalizer. Retard.

>>109594615
The irony of this post is that rust's formatter is literally based on Python, but this Python babby doesn't know this.

>>109602978
Rust is one of the only languages with move semantics. If you can't understand that actions cause moves, you shouldn't be using Rust. You need to have a basic understanding of C++ and its limitations or to stop being a bitch if you want to be successful using rust.

>>109593274
Use another language if type or memory safety are not concerns of yours and stop complaining.

File: vfprintf-internal.c.jpg (3.24 MB, 3192x9601)

3.24 MB JPG

>>109602507
>Macros are even more terrible to read and write
printf is full of macros and significantly harder to read than std::fmt stuff.
The difference between printf and println is that printf is significantly slower but supports runtime formatting strings(which no one uses because it's insecure as fuck).

Rust solves a problem better solved by having a garbage collector instead.

>>109603902
Rust's borrow checker solves stuff like iterator invalidation though.

>>109603902
Why are they slower then?

>>109594435
no?
A programmer made an assertion. Another program created invalid data and when the invalid data was handed to the rust program it panicked like the programmer desired.

This is like looking at:

if x = 1 { panic; }

And calling it a language problem.

Rust is built for AI. Has enough guardrails to make any slop code work or else it will throw a compile-time error.

>>109604144
A slight bit of lag in golang is much preferable to the managing the borrow checker.

Also there's many tools to make C code safe. The only downside to C other than that and its admittedly terrible standard library, are the legion of "safety" twats who attack you for creating a project mostly coded in C.

File: file.png (120 KB, 923x640)

120 KB PNG

>>109604241
Speaking of golang, soon I might be releasing a tool for scraping gigabytes of data from reddit. Go is just so great for scraping. Currently though I'm still working on harvesting the requisite amount of proxies for what I have in mind lmao

File: HQKcUhfaYAA9WUK[1].jpg (763 KB, 1080x1080)

763 KB JPG

Oh no no no

>>109604677
wtf is even the purpose of arrayref? anyone using this crate should be taken out back.

File: file.png (350 KB, 750x750)

350 KB PNG

>>109600876
you got this kiddo, ask an adult to buy you this educational device, I think it will help in figuring it out

>>109603327
But at that point you might as well move to C++ which is less of a contortionist language. This is the problem with the borrow checker: it's like training wheels. When you understand it, it just gets strongly in the way. And if you don't understand it, it also gets in the way, though of course it should in that case.

>>109603902
Borrow checker is deterministic, overhead-free, and precise, while the vast majority of GC's are conservative (non-starter for tight loops involving binary manipulation or matrix operations and other numerical work on allocated memory in practice, so all kinds of hacks are used for this instead of focusing on the problem, notably doing it in C instead), you don't know when the gc pass will run (an implementation error, I STRONGLY BELIEVE that a gc that simply exposes a gc() function and can OPTIONALLY be scheduled to auto-run under CONTROLLABLE criteria but otherwise runs MANUALLY would be even better than manual memory allocation in ALL respects and then some, as this can actually lead to faster deallocs due to programmer access pattern knowledge), and have overhead (due to all the hacks around them to make them not so shitty in practice, things like incremental compacting generational GCs over much simpler schemes, but I assert that if it was manual-first, there would be no need for such hacks).

Also, some schemes that ignore the presence of loops deliberately, like ABC garbage collection, are fast, precise, naturally fragmentation-free, and are faster than malloc/free (also, implementable in 4 lines of code). I think that it's fair to require users to deal with loops explicitly while doing all other dealloc automatically through such a simple scheme and that indeed, this would resolve the need for things like borrow checkers.

>>109604241
>A slight bit of lag in golang is much preferable to the managing the borrow checker.
True if the thing you're working on doesn't need stable and predictable performance. The hitch every now and then doesn't matter in single-shot stuff but fucking blows on DSP other real-time things.

>>109604343
>>109596111
>>109596097
Runit buddy, why are you dead online but posting here? Are you afraid of everyone knowing you worked with the nonce leto, the black nonce that ruined this site by trying to flood it to death with CSAM????

>>109603902
wrong. explain how you get around finalizer garbage in your GC'd language. you can't.

>>109596573
ok boomer

>>109593274
You thought rustrannies was a meme?

trvke

File: 1781124682447919.png (129 KB, 529x538)

129 KB PNG

>YOU WANT INT.RANDOM()?
>RUST ISN'T DESIGNED THAT WAY, CHUDDIE
>IMPORT THE FUCKING CRATE, FASCIST

>>109609993
https://doc.rust-lang.org/stable/std/random/fn.random.html

File: 1756664545947066.png (152 KB, 512x512)

152 KB PNG

>>109610055
>The std::random module is an experimental feature in the Rust standard library (tracked under Issue #130703). It introduces secure, system-sourced random data generation directly into std without requiring the external rand crate. Because it is currently unstable, using it requires the nightly compiler and enabling the #![feature(random)] attribute.

>>109610185
>quotes the documentation verbatim
what did he mean by this?

>>109603169
They were conflating transfer of ownership for iterating over something with transfer of ownership for printing (not needed). A loop transfers the ownership of elements from the iterator into the pattern it binds it for it's inner scope, that's why it needs to take ownership of the iterator.

>>109593274
>no implicit self in "structs" (totally not classes btw) methods. enjoy writing "self.doshit" every other line
>no inheritance. it's replaced with 'composition' which is just inheritance. but instead of accessing v.z, you have to write v.w.x.y.z!
You're a fucking nigger

>>109611410
yes, see >>109594615

>>109593274
Retard ceo indian team think they going to replace windows code with it.
They still haven't succeeded.
Retards.
If the investors gave all the money they are wasting on Indians to me, we'd atleast have progress.

Noone, need to draw it out as long as possible. No opportunity for the people who will improve the world, nonono, money for the world ruiners and social climbers.

Saaaar we have improv durr4 autocorrect and durrrr advertising

Fuck them to hell
Worst digital environment on the planet

>>109611495
>ceo indian team think they going to replace windows code with it.
[citation needed]

File: We_Are_Not_the_Same.jpg (44 KB, 462x660)

44 KB JPG

>>109593274
You don't like Rust because of it's design. I don't like Rust because I hate trannies.

>>109594100
I said that and I dicked down your mommy until she blacked out

>>109603327
Bitch, I understand move semantics, I program professionally in C++, they're not nearly as complicated as you're pretending. The point is that per >>109611144 that guy had no idea what he was talking about for printing, and I was right that none of what he said made sense.

Anyway, I bothered looking up the range piece for interest, and to little surprise found that there's syntax to iterate over references to collected elements rather than the elements themselves, which is pretty similar to what I'd do in C++ (for (const MyType& val : collection)) so I don't have to copy or move.

The thing that still looks wrong to me about Rust is in how many areas the "simple" answer is not the right answer, and doesn't naturally guide you to the right answer. Iteration is a good example. The vast majority of the time, when you iterate over a collection, you don't want to destroy the collection. But with Rust, that's the default option, meaning that you get buggy or otherwise incorrect code that looks correct. I mean, at least the compiler stops you from doing something actively wrong, but with pretty cryptic errors compared to what the actual problem is. The whole part of the language where variables default to immutability is equally weird.

That, plus the fact that they made mutation of ALL data a contested operation instead of limiting it to concurrent behavior, which is the only place it could cause memory bugs. Most variables don't exist across concurrency boundaries; why is this a universal language requirement?

Obviously C++ has a lot of similar warts on it without the luxury of safeguards, but C++ has a pretty good excuse in that it's a very old and incrementally developed language. Rust is recent. Why does it suck so hard on a lot of basics?

>>109617016
>Bitch, I understand move semantics
>proceeds to no understand move semantics
why are cniles like this?

>That, plus the fact that they made mutation of ALL data a contested operation instead of limiting it to concurrent behavior, which is the only place it could cause memory bugs.
wrong, see iterator invalidation for example

File: 1766013865433537.jpg (89 KB, 1080x688)

89 KB JPG

>>109593274
>>109593291
AGI will be coded in Rust

>>109617016
NTA but Rust is the only language with guaranteed destructive move, C++ doesn't have it, which causes a lot of warts.
Also you can just do

for i in &nums { println!("{}", i); }

and it works as expected because we have

&Vec<i32>: IntoIterator<Item=&i32>

, same thing works with &mut nums of course
Also concurrency isn't a requirement. It's a separate trait called Sync.

File: array - Rust.png (806 KB, 1308x7102)

806 KB PNG

rust could be nice if it wasn't filled with utter retardation.

>>109617390
If it's retarded and it works, it's not retarded

>>109617368
>Also concurrency isn't a requirement. It's a separate trait called Sync.
I think anon was saying that it's frustrating having to code around the exclusivity rules (one mut reference OR multiple non-mut references), and that it should only be a requirement when writing concurrent code, where data races are an issue.

but as >>109617349 pointed out, iterator/pointer invalidation is a simple example of a non-concurrent problem that's prevented by the exclusivity rules. if you could take a mut reference to a vec *and* an immutable reference to one of its elements at the same time, then you could end up triggering a reallocation of the vec which would invalidate your immutable reference.

>>109617390
This is being actively fixed but allowing trait implementations on const-generic arrays is not easy to do in a sound way. In general Rust tries to avoid adding special "libstd-only" language features.

>>109617368
What I mean is that the language treats mutable references as something that can only be held by a single entity at a time. This is far stricter than is actually needed for memory safety.

The potential memory problems with mutating a reference are invalidating a pointer held in a separate variable and data races in concurrent settings. If you're guaranteed non-concurrent operation AND forbid pointer mutation, then you can share as many mutable references as you like. If you have a struct on the heap that contains a few integers, then no matter how you share references to that struct, you'll never manage to cause a memory bug by reading or writing to those integers within a single thread.

Rust's explicit reason for unique mutable references is that they are concurrency-safe. From their own doc:

> The restriction preventing multiple mutable references to the same data at the same time allows for mutation but in a very controlled fashion. It’s something that new Rustaceans struggle with because most languages let you mutate whenever you’d like. The benefit of having this restriction is that Rust can prevent data races at compile time.

This makes little sense. Most variables are NOT shared concurrently and don't need this protection. That's what I'm talking about: instead of relying on explicit language features around when and how addresses can be shared between concurrent operations, Rust has allowed a requirement that doesn't matter for most variables to seep into the rest of the language. Whenever you see shit like this, it's a big warning sign that the people responsible are not really practical thinkers and might not be trustworthy.

>>109617420
>iterator/pointer invalidation is a simple example of a non-concurrent problem that's prevented by the exclusivity rules
You are correct. But this is not the reasoning which Rust presents to the outside world. It is this:
>>109617451

Practically speaking, what I'm arguing for is for Rust to clearly distinguish between the situations it's trying to defend against and provide primitives tightly scoped to those use cases. So this would be full object ownership (all privileges+RAII), pointer-mutable reference (exclusivity requirement to prevent pointer invalidation), pointer-immutable reference (non-concurrent requirement), and fully immutable reference (no requirement), along with suitable concurrency primitives (mutex guards as first-order language feature?) to handle those cases.

What Rust is trying to do by providing strong proof that there are no memory bugs in MMM code is pretty interesting. I'm just unconvinced they've done a very good job at it.

>>109617451
This is a pretty fair point desu and I think it's been brought up pretty often even in the Rust community itself. I think part of the issue here, as far as type systems go, is that you don't want the behavior of a reference kind (e.g. &mut) to depend on the internal specifics of a type. Which is to say, we don't want &mut StructWithoutPtrs to behave differently to &mut StructWithPtrs, and so that kind of forces you into this bad position. On a more practical level, you can *usually* rewrite your singlethreaded code so it just passes around a single &mut down into every function and reborrows with shorter lifetimes as necessary; the issue then comes back to storing these references.
But yes I agree, this is an area of improvement for Rust and one that people are trying to work on.

>>109617451
>This is far stricter than is actually needed for memory safety.
wrong, see iterator invalidation for example
btw, you can mutate through a "immutable" reference.

>>109617451
>>109617480
https://manishearth.github.io/blog/2015/05/17/the-problem-with-shared-mutability/

>>109593274
lol I just tell a clanker what I want

>>109617484
Also we have interior mutability as >>109617488 said, for example UnsafeCell and friends. Funny enough there is Cell::as_slice_of_cells which addresses the example you provided. This is how Mutexes are implemented.

File: 1783717986234193.png (358 KB, 601x567)

358 KB PNG

def main():
    x = define_x()
    print(x, " world!")

def define_x() -> str:
    return "hello"

main()

good luck trying to translate this to rust lol

fn main() {
    let x = define_x();
    println!("{}, world", x); 
}

fn define_x() -> str {
    return "hello"
}

see how many errors this shits out

>>109617996
wow, that was hard

fn main() {
    let x = define_x();
    println!("{}, world", x); 
}

fn define_x() -> &'static str {
    return "hello"
}

File: 1758841156169147.jpg (90 KB, 550x456)

90 KB JPG

>>109618006
>

 &'static str

try explaining this shit, and better yet explain why there's "String" and "str"

>>109618015
String is a heap allocated vector of bytes guaranteed to be utf8.
str is a slice of bytes guaranteed to be utf8.
&'static str is a shared slice guaranteed to be utf8 which is valid for the entirety of the program.
the difference between str and &str is that str is a dynamically sized type.

>>109593274
I'm really sick of these retarded threads. You lack understanding of ownership and lifetimes. JUST USE WHATEVER YOU WANT DUDE. Nobody fucking cares if you write C or Rust except retarded trannies.

File: 1756992128080932.png (193 KB, 450x418)

193 KB PNG

>>109618031
>literally every other language:

x = "hello!"

>rust:

let mut x = String::from("hello"); 

HMMM i32, i64, u32, usize, u64... I bet String is called str!
>nope, str is impossible to work with and you need to convert it to a String to use it anywhere because some rustroon dev really thought it was necessary to give you public access to a completely useless type
joke of a language

>>109618062
>HMMM i32, i64, u32, usize, u64... I bet String is called str!
It is because its explicit, faggot. It saves performance by making allocations obvious. Something you can't understand

>>109618062
>be dumb retard
>use retard tier language with gc
>completely beclown yourself when dealing with a language without gc

>>109618062
str is a language primitive, that's why it's lower cased.
String is not, it's just part of the std. You could write your own String.

>>109593274
This is literally what any new language looks like ... it's stupid to use, over complicated and when used in actual project it chocks up and dies.

>>109593274
and btw this pile of garbage will be used in Linux Kernel everywhere. Holy hell...

File: hahaha.jpg (21 KB, 387x516)

21 KB JPG

>>109618201
>rust is a new language

>>109618210
yes it have 11 years C have 50+... do you have more questions ?