File: 1_ZXZjjbAcdUzsG9EMj0uFsQ.png (461 KB, 1400x780)

461 KB PNG

>>108947387
Post the c/c++/go equivalent of this

>>108947422

package main

import "net"

func main() {
    ln, err := net.Listen("tcp", "127.0.0.1:8080")
    if err != nil {
        panic(err)
    }
    for {
        conn, err := ln.Accept()
        if err != nil {
            panic(err)
        }
        go process(conn)
    }
}

>>108947387
the same types who jump on all the new languages hype and end up spending their life rewriting codebases for no reasons

>>108947430
Side note: it bothers me how little it is documented which errors can Accept() return.
In C the accept syscall can return ECONNABORTED which can be triggered by client and you should not abort the server because of it.
No idea if either Go or Rust return it as an error. Not ever mentioned in docs. Similarly reads and writes to connection can return ECONNRESET. In C this can be a bit of a maze on which errors you should handle and which can be ignored. Not all are mentioned in manpage of that syscall, for sockets it mentions that it can return an error of underlying protocol. Go or Rust don't even list the possible errors, let alone of all are fatal.

>>108947387
The shitty syntax guarantees that I will never ever use this language.

Any language that does var some_var: type instead of type some_var belongs in the trash. And type inference is of the many harmful features this lang has.

For functions it's especially bad. The return type should be the first thing in a signature, not the -> last one.

Zig and go are also unusable because of the syntax alone.

>>108947387
Provide a syntax critique that doesn't involve changing semantics and goes beyond "I don't like this or thatsymbol"

>>108947483
Anon you a literally just babyducking

File: 1780220085367.jpg (507 KB, 2132x1599)

507 KB JPG

>>108947483
This.

>>108947490
>it's just personal preference!
No it's not. All these new programming languages are made by and for retards. It's so fucked up. Rust enums are not even enums, that's a misnomer. This language needs to die asap. It's a cancer that is spreading quickly. A decade of propaganda is finally paying off now that beginners are largely taking rust propaganda as facts.

If you do enough research you can even find a few select people from the rust cult that have incessantly lobbied both governments and existing projects to port everything to this shit language.

>>108947387
the more I see retards like you bashing this makes me actually want to use it since obviously it is not intended for retards but instead for intelligent people

peace be with you saar

>>108947534
>a cope of nothigness
You forgot to stick your HRT patch up your ass today, good sir

>>108947524
who are you quoting? I think you've replied to the wrong post, I was just asking the OP what's so "Terrible, stupid, over-engineered" about the syntax

>>108947490
Im a rust chud, i would say
1. Doing -> instead of : for return types
2. Fucking turbofish
More subjective, but 'pub' 'mut' and the #derives are really ugly
I am sure i missed some other things

>>108947561
They should just slap C-style syntax on top of rust and call it a day
(Evem then nobody would use it as daily driver)

File: 1779020162058964.jpg (7 KB, 225x225)

7 KB JPG

>>108947422

>>108947561
To add i think every syntax fucking sucks
C++ syntax is attrocious, go looks similar to rust but worse, typescript cant decide on what a fucking const is, and dont get me started on python
C# is the only lang thats c style and decent
>>108947574
No and no, i dont think c style is the issue, and i dont believe becoming widely popular for codelets should be the goal.

I think someone should just take typescript and make a proper compiler for it

>>108947483
Are you serious? What kind of programmer can't handle such a minor deviation in syntax? Are you going to have an aneyrism if you had to touch ALGOL derived language with end-keyword in subroutine definitions?

>>108947606
>typescript
Hell naw
It's like python 2.0

>>108947616
>Being sarcastic because of facts
>just accept the terribleness
Why should i when C# exists ?

>>108947626
Syntax is like the least of your worries when it comes to a language. You should be thinking about the features it provides. Being married to C-like syntax severy hinders your ability as a programmer.

>>108947619
Typescript is zased though
If i had time i would try a compiler for typescript to llvm
Would probably have to remove a lot of features which would make it non compatible, but you could still probably take a big portion of the js backend market

>>108947561
-> is used instead of : for returns because they mean different things. : means "is", but -> means "will evaluate to when called". Just like in lisp (+ 1 2) is 3, a number, but '(+ 1 2) is a list that's a structured parameterless function that yield a number after it is evaluated

turbofish makes sense conceptually and is required for proper parsing
<args> is the syntax for passing type parameters
:: is used to access associated items, Foo::bar accesses the bar associated with Foo, be it a function, type or a constant
this is a problem when Foo is generic, there's no longer one bar associated with Foo, there's possibly an infinite amount of bar's because there's possibly an infinite amount of Foo's
so you need to narrow it down to one specific Foo, hence
Foo::<args>::bar
access a specific Foo from the set of all Foo's, then access bar of that Foo

the C++ alternative is lazy name resolution aka sfinae which necessitates shit like
Foo::template bar<U>
which to me is 100x worse, an identifier with a fucking space in it

>>108947495
And you are updooting. Why change something that works perfectly fine? Why do you HAVE to reorder things?

Would you describe Farmer Joe as person Joe: Farmer?

>>108947606
>C# is the only lang thats c style and decent
Every single c style language is beautiful no matter if it's a good or bad lang. You forgot Java and JavaScript. TypeScript looks like shit because it deviates from the only objectively correct way of specifying types.

>>108947616
If you accept the fact that type inference is evil because it is, then the initial "let" or "var" becomes useless and it's just clutter. So int variable; turns into the only sane syntax.

But most importantly, having types on the left makes reading significantly easier because it's perfectly aligned to the start of a line. It's the most important thing. Why should the most important thing not be the first word?

Code should always be optimized for reading, not writing. Programming is 80-90% reading, debugging and thinking, not writing code.

>>108947616
anon CS is like one of the most popular academic disciplines in the world
It's filled with brainlets who can barely make it past the syntax portion of C with it's staggering 32 keywords, got filtered by lab day 3 of DSA and now their tiny little heads are at capacity so they need to defend what's in them
In a more just world they would be labourers
Thankfully AI is "fixing" it, instead of learning anything they can now just commission a chatbot to make them a todo tracker

>>108947708
>having types on the left makes reading significantly easier
Tell me you haven't wrote anything more complicated than a hello world without telling me.

>>108947708
>having types on the left makes reading significantly easier because it's perfectly aligned to the start of a line. It's the most important thing
no it is not
you have a NAME of a type, which is quite frankly, useless
for example, you have a type TaskQueuePool, what can you do with it?

>>108947708
>then the initial "let" or "var" becomes useless and it's just clutter.
Except when the language uses the descriptor for the kind of variable, like const in js. The examples of var and let denote global variable and locally scoped variable in the same language even. I guess you'd prefer to denote that kind of property in some different way, or maybe even think it's an useless feature?

>>108947708
Compare
>MyPackage::MyType<MyTemplate> myVar = MyPackage::MyType<MyTemplate>()
and
>let myVar = MyPackage::MyType<MyTemplate>()
Having the name of the type in front of the variable doesn't add any more information because you still have to call the constructor/factory/function to get the thing you need. It's just clutter.
Also, kind of unrelated, but I fucking hate that the functions get their own keyword like special little snowflakes, and it's usually something stupid like "fn" or "fun". Variables are basically functions that take 0 arguments, just slap "let" in front of every declaration and be done with it.

>>108947776
>denote that kind of property in some different way
Yes, obviously? And you can still use const? Like const int some_var. Local variables by default, you can declare "globals" inside a function with something like static but that's pretty shit code desu.

The only reason JS has "let" in the first place is because "var" made everything global by default, probably an oversight because it was rushed and not a serious language when it was first created. No JS code written in the past decade uses var anywhere, it's pretty much deprecated in practice.

If you are going to use global variables then at least have the decency to declare them at the top level, not inside random functions. Nothing stops you from using static/var though.

>>108947836
This is unironically a bandaid solution to other shitty features like namespaces or whatever they're called in your preferred shitlang.

Remove namespaces and suddenly typing Dictionary<string, string> twice in a single line doesn't seem so bad. And abusing templates too much with complex parameters will always result in shitty code and bloat regardless, the let/auto just hides the problem away from you for longer.

It's really funny how name collisions were never ever a problem in C, yet new languages insist on namespaces. Namespaces are a solution in search of a problem, not the other way around. Nothing stops you from prefixing publicly-exposed functions in C.

>>108947463
Rust's impl returns an error: https://doc.rust-lang.org/std/net/struct.TcpListener.html#method.accept

The ? operator is just shortened hand for if error then return error.

>>108947430
Rust's is more beautiful and cleaner.

>>108947836
> $myVar = [foo => bar]
I KNEEL for php supremacy

>>108948240
And dont forget echo $this->myVar['foo'] :)

>>108947387
I use it and you are wrong on pretty much every points you tried to make. It seems despite using it for month you only touched the very surface of language.

>>108948224
are you responding to the right comment?

>>108947534
the funniest thing about /g/eet tards forever kvetching about "muh syntax" before pulling the "oh yeah, YOU'RE A TROON" move like your average idiot 12 year old, is that if Rust syntax was actually bad, a language with alternative syntax would have popped up, which is something that happened to the very language rust was originally implemented in. but of course /g/eets don't even know such things exist. and the hilarity is compounded for those in the know considering what syntactic changes are actually considered desirable by actual coders lol.

>>108948311
You said
>No idea if either Go or Rust return it as an error. Not ever mentioned in docs
And he posted link to TcpListener::accept method. That method returns io::Result, which contains io::Error on failure.
https://doc.rust-lang.org/std/io/struct.Error.html

>Go or Rust don't even list the possible errors, let alone of all are fatal.
This is not possible. ECONNABORTED you are talking about is just a linux/posix thing, it might not make any sense in other architectures. Every OS can have different set of error codes or an entirely different error system. ErrorKind is a cross platform generalization of IO errors and it contains the variant you are looking for:
https://doc.rust-lang.org/std/io/enum.ErrorKind.html#variant.ConnectionAborted
But of course it's not an exhaustive list nor you will and any exhaustive list of all possible errors a random io function can return because that varies from OS to OS or even across OS versions.

>>108948330
Rust syntax is fine generally speaking, you can see influence of Ruby/smalltalk aesthetics and functional languages. That is, it's fine until you get to <<<<<<A<B<C that troons love. But of course the biggest issues is the borrow checker preventing you from actually designing a readable architecture and/or experimenting with it. Screw this shit, normal people want the discovery process when writing code and Rust insists they should focus on safety long before it matters.

>>108948330
It's always the same thing
>hurr Rust syntax is so ugly
>so what would you change it the syntax
>uhh, I would remove feature X and change semantic of Y and added feature Z... <list continues on with 0 syntax change suggestions>

It's also funny how they all seem to judge things superficially based on looks alone acting like literal woman, yet claim it's other people who are troons kek

>>108948450
>the borrow checker preventing you from actually designing a readable architecture and/or experimenting with it
I have been using Rust for a nearly decade now and never had any issues designing a readable architecture and/or experimenting with Rust because of borrow checker.

Care to share an example of code where readable architecture is impossible due to borrow checker?

>>108948452
obsessing over tranny dick is THE premier pass-time manly men

>>108948450
Also, I'm personally dislike languages that insist variables must be immutable. No, they must not, that's why they're called variables stupid. And then of course it follows with the constant/immutable autism and all that stuff. Literally, like I don't have other problems tha to think about which variable should be immutable, fucking compiler should figure it out for me.

>>108947483
potent bait

>>108948472
>No, they must not, that's why they're called variables stupid
That's why they are called bindings, not variables.
Why are you arguing over language design on the grounds of semantics anyway?

>fucking compiler should figure it out for me.
It literally can't. Ever heard of halting problem?

>>108948509
I bet what you're talking about, but my point is that these ideas that Rust has are unnecessary. Look at what Rust is used for: most of the things it's used for are some CLI utilities, which care neither about memory safety, nor about how much memory they generally need, because they run and exit. The there's Helix text editor for example - I can tell you for a fact Rust is unnecessary for it, because I'm writing a text editor in D and there's like zero reason to write a text editor in a non-G language. The people also write webshit in Rust, which is like why do you even want to do that. The actual low level stuff that might require solving those memory safety issues is not the primary use of Rust and even there you could just write it in C or Zig and ask LLMs to check for memory safety issues if you're unsure. Rust solves a problem literally no one has and they only reason it became popular is because it does sometimes feel nice to write in it due to some cute syntax and people felt like it was le serious language with cute syntax (again, until you start seeing the really ugly parts of it).

>>108948547
Having said that, it's fine of you're a Rust enjoyer. Everyone should enjoy doing whatever they want, so long as it doesn't hurt others. I'm going to say something many people have said before, but it's still true: Rust community aggressiveness towards "but why is it not written in Rust" is the one thing that makes it so unattractive. Every time I go to HN or Lobsters and read about some new piece of software (example: TyepScript compiler rewrite) there will of course be comments like "but why isn't it in rust" as if authors owned something to the Rust community.

>>108948330
I love trans people. I hate Rust. Ugly syntax is barely scratching the surface. Rust is a shit language and ecosystem created by Mozilla and historically there have been strong ties with certain prominent lobbyists and propagandists who spread false information and engage in constant fear mongering. It's all public information. One of those guys literally lives in Washington D.C. and worked for the government lmao you can't make this shit up.

>if Rust syntax was actually bad, a language with alternative syntax would have popped up
Source for such baseless claim? That's not how any of this works.

>coders
Yeah ok I can tell you're just a cult member who probably doesn't even write real code. Only nocoders and vibecoders use the word coder.

>>108948547
>my point is that these ideas that Rust has are unnecessary
It is very beneficial for the code readability and expressing intent. In practice vast majority of bindings you make in Rust are immutable. Having to specify "const" on every would be a bothersome so many programmers would not care or would not want to clutter their code with consts and then some of the intent behind variables would be lost. This is why to this day Linux keep getting patches that do nothing but add consts that people missed.

>Look at what Rust is used for: most of the things it's used for are some CLI utilities, which care neither about memory safety, nor about how much memory they generally need, because they run and exit.
Memory safety is important in CLI utilities. A vulnerability in a CLI program can expose your entire system, like it happened with shellshock.
Also I use Rust for embedded development and libraries, these thing require memory safety. Everything requires memory safety really.
Also having variables be immutable by default has nothing to do with memory safety.

>about how much memory they generally need, because they run and exit
Memory safety is not related to memory leaks. Leaking resources is memory safe. Memory safety is about things like ensuring that a malicious payload won't corrupt your heap and execute arbitrary code.

>The there's Helix text editor for example - I can tell you for a fact Rust is unnecessary for it
Well, then tell me. I never used Helix before so go ahead and make your argument about Rust as a language by this very specific example.

>The people also write webshit in Rust, which is like why do you even want to do that.
Agreed. Rust is pointless for IO-bound applications. NodeJS, Python or even Java are much more suitable.

>>108948547
>The actual low level stuff that might require solving those memory safety issues is not the primary use of Rust
Why? Rust is the best language for embedded systems I have ever used.

>ask LLMs to check for memory safety issues if you're unsure
This is not even comparable to provable memory safety. What the fuck are you talking about lmao.

>Rust solves a problem literally no one has
It solved a lot of problems I had with C++. This sentiment is shared across many programmers and companies that use Rust.

>it became popular is because it does sometimes feel nice to write in it due to some cute syntax and people felt like it was le serious language with cute syntax
It became popular because people have been begging for C++ replacement for literal decades. Rust is the first one that delivered and it delivered way more than people were asking for. You can read countless articles ranging from hobbyists to largest corpos talking on why they embraced Rust and what things they found useful in it.

>>108948604
>I hate Rust
>continues to talk about everything but Rust

>>108948597
>about some new piece of software (example: TyepScript compiler rewrite)
Could you share some details about this?
Or did you really just took one of like hundreds comments under the announcement asking on why they used Go instead of Rust as proof that Rust community is aggressive about things not being written in Rust?

trannies who thing system/technique/science can overcome body and sex in the domination of nature also think by having the right "system" you can overcome bugs in software

>>108948604
>Source for such baseless claim? That's not how any of this works.
lmao

>>108947606
java is superior (or was before the retarded modern stuff)

>>108948654
> Memory safety is important in CLI utilities.
> Memory safety is not related to memory leaks.
What I was trying to communicate is that cli utilities that run and exit either don't need memory management (basically just use memory and it will be only freed on exit by the OS) at all or would be just fine using a GC language.

>>108948654
> Well, then tell me. I never used Helix before so go ahead and make your argument about
> Rust as a language by this very specific example.

The argument is that a GC language is just fine for a text editor. Also I find it very nice to have the option for OOP for some of the cases in my codebase for the text editor. I'm not arguing text editors should be written like VScode, with fucking React and and Chrome, but I think there's some middle ground for complexity vs convenience, because text editors are complex enough as they are for me to suffer language complexity. I mean maybe if I felt super confident in Rust and really enjoyed it, I'd use it, but it's if I had to pick between Rust vs Go or Rust vs D or Rust vs I don't know, Crystal (assuming I didn't know any of those languages), I would never pick Rust.

>>108948774
Go back to durgasoft.

>>108948793
>don't need memory management at all or would be just fine using a GC language.
They would be, unless you actually need performacne. Which happens in CLI programs as well.

>>108948823
>The argument is that a GC language is just fine for a text editor.
Would you say them same about editors made in C or C++?

>I find it very nice to have the option for OOP for some of the cases
Everything OOP lets you do, you can archive with traits in more general way. At worst you can use macros for some.
OOP adds a ton of complexity to the language that doesn't really let you do anything new. Just look at the absolute state of C++ classes and inheritance nuances. It's just not worth it.

>>108948849
Probably the single most retarded nocoder post I've seen in a long while.

>>108948849
I'm not arguing that sometimes that's the case. I'm arguing that more often than not it's not and a GC language is fine for most things. However it's understandable that people just write those things in Rust because they want to and are more familiar with it. It's just that re-writing it when the original thing just werks makes zero sense. The argument that "but what if there's another vulnerability somewhere in there" is stupid, it's easier to just find it than be rewriting the whole thing, but some folks just like to suffer.

>>108948878
Not an argument

>>108948872
> Would you say them same about editors made in C or C++?

I would say people choose languages they're most familiar with for non-trivial tasks. That's fine. What I'm saying is that yes, given that I'm not familiar with any of the languages and I had to pick one for a text editor, I would pick a GC language with more powerful abstractions like classes (although the latter isn't a deal breaker).

>>108948884
>It's just that re-writing it when the original thing just werks makes zero sense
(Re)writing simple CLI utils is a good way to learn or practice any language. And sometimes, you might end up with something that suppresses the original, like with ripgrep.

>>108948872
> Everything OOP lets you do, you can archive with traits in more general way.

I'm sure that's true, but I would have to suffer through Rust and that's not something I'd want to do.

>>108948900
Yeah, that's also true I'll give you that. And I do use rg and fd and thing they're superior. Rewriting is a good way to learn, however for some unknown reason Rust community became notorious for rewriting just because, something I don't see in Go or any other language to the same extent.

>>108948900
>>108948918
>ripgrep isn't faster than grep in every use case. For example, if you're searching a bunch of files on disk that aren't actually in memory, then rg and grep are likely going to perform similarly because the limiting factor is actually reading from disk. rg, in all likelihood, can't be faster than grep in that case.

The real reason they rewrite in rust and that's the only thing they're known for is because rust is a thoroughly unproductive language unless you have a previously fully defined spec to work from. That is because if you make even the slightest deviation to any structure anywhere, like merely adding a field, chances are you have to refactor the entire program. This is discussed in
https://loglog.games/blog/leaving-rust-gamedev/
which is itself discussed on linked reddit and orange reddit threads which overall agree with what the devs here allege.
In practice, rust devs use reference counting to bypass the borrow checker, thus real-world rust programs that aren't based on an immutable predetermined spec always end up slow.

File: 1742677024738474s.jpg (8 KB, 235x229)

8 KB JPG

>>108948434
"it" refers specifically to ECONNABORTED.
And it's not just linux thing. Afaik pretty much every BSD and darwin also use ECONNABORTED. winsock2 has the same just differently named (WSAECONNABORTED and that lastError() instead or errno).

The posted Rust snippet propagates that error from server loop. Regardless if it's from main - which is pretty much equivalent of aborting.
Go snippet just panics on it. Reading the codebase, it just wraps syscall error into struct and propagates it.
Both are taken from examples from official documentation.

My point was that this is bad handling since misbehaving client can easily trigger it and thus crash the server. And neither docs mention which of the returned errors are ignorable.

>>108947422

  const std = @import("std");
  const net = std.net;                                                     

  fn process(conn: net.Server.Connection) void {
      defer conn.stream.close();
      // ...
  }

  pub fn main() !void {
      const addr = try net.Address.parseIp("127.0.0.1", 8080);
      var listener = try addr.listen(.{ .reuse_address = true });
      defer listener.deinit();

      while (true) {
          const conn = try listener.accept();

          // Process each connection concurrently.
          const thread = try std.Thread.spawn(.{}, process, .{conn});
          thread.detach();
      }
  }

>>108948970
Dis nigga got STDs!

>>108948970
>const addr = try net.Address.parseIp(...);
wtf

>>108948938
>thoroughly unproductive language unless you have a previously fully defined spec to work from
From my personal experience this is false. It usually comes from people inexperienced in Rust and writing awkward code that is hard to maintain and refactor.

>That is because if you make even the slightest deviation to any structure anywhere, like merely adding a field, chances are you have to refactor the entire program.
This is just straight up lie. If you add a field to struct you add field to struct. The only thing you might need to change is to just add that field to any place you explicitly creates struct literal like

Foo { a: 1, b: 2, newField: 3 }

>This is discussed in
>https://loglog.games/blog/leaving-rust-gamedev/
This is the game in question btw: https://store.steampowered.com/app/2331980/Unrelaxing_Quacks/
He spent several years writing a shitty vampire survivors clone and then blamed language for this.

>thus real-world rust programs that aren't based on an immutable predetermined spec always end up slow.
This is wrong and an another sign of inexperienced Rust developer.
In my Rust programs there is barely any reference counted values.

>>108948953
>And neither docs mention which of the returned errors are ignorable.
Because that's platform dependent.

File: 1673005144059528.jpg (1.23 MB, 1942x1200)

1.23 MB JPG

>>108947463
the reason I dont like go is that you cant put the brace on a newline like god intended

>>108949008
>people who have literally created the language are less experienced than me because... it just is ok
stopped reading there lmao

>>108949039
You did not created Rust.

>>108949057
And I did not quote myself with the evidence I used. Back to india, ESL pajeet.

>>108949037
I thought you were a fool thinking that go needs gofmt to work, but it's actually a compilation error.
Why is go so fucking inconsistent with small bullshit like that?
Another small annoyance is how unused variables is compilation error, but unused parameters isn't.

>>108949037
I really don't get the aesthetics of putting a brace on a separate line. It looks retarded, but that's not something I will judge harshly because I can see myself liking that style under different circumstances.

>>108949087
Correct. You just made a claim and when I said that you are talking like an inexperienced Rust developer, you altered my quote to point out that it's impossible for a person who created the language to be less experienced than me. Although this is true, it also implies you are the creator of Rust which is extremely unlikely.

>>108949143
> le inexperienced rust dev
Retarded argument overall. Yes, obviously less experienced Rust devs would write worse Rust code. However, there are languages which easier to master for a variety of reasons and they don't necessarily compromise anything either. The complexity vs actual payoff for Rust is not very favorable.

File: 1763098004337.jpg (100 KB, 800x596)

100 KB JPG

>>108949165
>don't necessarily compromise anything either
There is no language that is both as fast and safe as Rust.
>The complexity vs actual payoff for Rust is not very favorable.
Its users disagree. There is a reason why you see all the major IT companies integrating Rust in their codebase.

>>108949189
> There is a reason why you see all the major IT companies integrating Rust in their codebase

The reason is troon infestation, buddy.

>>108949216
[citation needed]

>>108949224
> There is no language that is both as fast and safe as Rust.
> There is a reason why you see all the major IT companies integrating Rust

Whatever the reason is, it's not business viability. Companies want to move fast and shit out new features constantly. Rust may be fast to run, but it's not fast to develop in. Also, who gives a fuck about safety if your software is run internally for the most part and isn't even open-source? Common sense tell us that even if there is some sort of vulnerability in it, it will take a million years to discover it, because code is not open source and runs behind 15 firewalls.

So yeah, I'm almost certain the reason for Rust adoption are a few vocal autistic troons who bully everyone into using it. Maybe troons are especially good in helping VCs launder money and pay kickbacks, like I'm sure is the case with the Zed editor.

>>108947422

#include <boost/asio.hpp>

using namespace boost::asio;
using tcp = ip::tcp;

awaitable<void> process(tcp::socket socket) {
    // ...
}

awaitable<void> main_task() {
    auto ex = co_await this_coro::executor;
    tcp::acceptor listener(ex, {ip::make_address("127.0.0.1"), 8080});

    while (true)
        co_spawn(ex, process(co_await listener.async_accept()), detached);
}

int main() {
    io_context io;
    co_spawn(io, main_task(), detached);
    io.run();
}

>>108949261
>it's not business viability
>it's not fast to develop in
>the reason for Rust adoption are a few vocal autistic troons
Wrong.
https://blog.google/security/rust-in-android-move-fast-fix-things/

>who gives a fuck about safety
Every large IT corporation

>troons are especially good in helping VCs launder money and pay kickbacks
[citation needed]

>>108947422
>>108947490
>>108947534
>>108948276
enjoy your compiler backdoors, troon

>>108949143
>clinically retarded
>no argument
>pre-bunked
>can't read
>can't write in English either
>>>/i/ndia

>>108949326
>advertisement blogs are proof
>actual developers giving their professional experience about actually developing in rust are not valid
the absolute state of bangalore

>>108949326
>> who gives a fuck about safety
> Every large IT corporation

If they did, they'd be using and developing capability operating systems, not playing with a difficult to use and slow to develop in programming language where the community are mostly alphabet letter people.

>>108949281
wow! More readable than rust!

>>108949361
>>advertisement blogs are proof
>>actual developers giving their professional experience about actually developing in rust are not valid
>the absolute state of bangalore
This post is written by Jeff Vander Stoep, an actual professional engineer at Google.

>>108949375
>If they did, they'd be using and developing capability operating systems
Well, go sell them your billion dollar idea. They are a big company that puts a lot of trust in its security systems. If you can improve it for them, I'm sure they will be willing to pay a ton of money for that.

>>108949351
Not an argument

>>108949395
>do not redeem the paid advertisement saar
Can't make this shit up

>>108949406
Your argument being?

>>108949395
> Well, go sell them your billion dollar idea.
> They are a big company that puts a lot of trust in its security systems.

You are naive if you think big companies somehow know better and are more competent. At big companies it's mostly about office politics, who can push their own pet project / pet language / fetish and get funding for it and who can launder money more effectively.

>>108949436
>naive
That guy has proven he's profoundly retarded, not merely naive.

>>108949436
>You are naive if you think big companies somehow know better and are more competent
They definitely seem more believable. Unless you know, you provide some better arguments for your claims. They have data, what do you have?

>>108948232
It's not.

File: code.png (1.06 MB, 1394x7438)

1.06 MB PNG

>>108947422
just for completeness

Rusts stdlib is a bad, arguably worse than C's. No complex numbers, no random number generation - all are 3rd party packages which in turn rely on more 3rd party packages. It's a security disaster waiting to happen. Even meme langs like Zig and Odin offer these things as part of their std lib and these languages have less than $1mil a year to operate on and < 5 full time devs working on the respective projects. Meanwhile Rust is given millions every year by big tech and they seemingly they waste it on marketing and other bullshit that has nothing to do with the language, last I checked they didn't even pay a wage to one of their main compiler devs. Rust is not a serious programming language, it's a social movement disguised as a programming language.

>>108949679
Calling it a social movement is an insult to social movements. It's a cult.

File: Screenshot 2026-05-31 at (...).png (81 KB, 892x778)

81 KB PNG

>>108949679
>No complex numbers, no random number generation
How often do you use complex numbers in your programs?
Which random number generator would fit majority of usecases?

>It's a security disaster waiting to happen
So, when will it happen?
XZ was the biggest dependency related vulnerability in a long time, and it primarily affected C/C++ software.

>Meanwhile Rust is given millions every year by big tech and they seemingly they waste it on marketing and other bullshit that has nothing to do with the language
Why are you lying? You know that their finance reports are publicly available, right?

>last I checked they didn't even pay a wage to one of their main compiler devs
All the core team developers are paid.

>Rust is not a serious programming language
It is a programming language for sure, and it seems a lot of serious people and companies use it.

>>108947387
I started learning it to keep my mind occupied after bottom surgery. It really helped during the recovery process.

File: 7EBCD958-C085-4F0B-9DBC-0(...).jpg (807 KB, 1009x1431)

807 KB JPG

>>108949679
You could go way farther than that. You are sugar coating it. Rust was (so the fairy tale goes) “invented” to fix some guy’s elevator because he “knew” it was a C++ memory error that was causing it on the embedded system. Lazy, stupid, fat fuck couldn’t make it up the stairs. That’s your god.

Did he ever fix that elevator? Was the story a lie?

> it’s a real language
Just fucking look at it. It’s almost entirely copied from C++ … they copied all the worst syntax and misfeatures. It’s just obfuscated C++ code.

99.99% of all rust code was brought into rust with a c2rust translator from C (remember, it was invented to replace C++ not C) so they gave set their sights a lot lower by trying to compete with what is essentially a high level assembler.

> > look how fast I can make a web server
> I don’t know the difference between a language and a library

>>108950000
> How often do you use complex numbers in your programs?
Tell me you never graduated from high school without telling me you never graduated from high school.

#include <cuComplex.h>

>>108950262
nobody beside high-schoolers and mathheads ever touches them. it's just math obfuscation for 2D vectors.

>>108950262
I was taught Pascal in high school. I never had to use complex numbers there. I am not sure I even had complex number introduced in HS desu.

>>108950192
>dat pic
Someone's been doing too much shrooms. No wonder rust's design is so deranged.

>>108950262
this is the level of rust haters, jesus

>>108950000
>XZ was the biggest dependency related vulnerability in a long time
how much of a liar can you possibly be? are you at least getting paid for lying this much? it was a nothingburger, precisely because there's no built in "push a button and possibly get malware from 100-1000 promiscuous packages" feature unlike cargo/npm. the net impact was very small if not zero, and this was after literal years of effort and social engineering. the code -> end user pipeline is much more robust when you don't engage in promiscuous dependency management a la cargo/npm

meanwhile npm has supply chain attacks pretty much every few days, it's become the norm, just google it. the entire point is that, because npm installs/updates are run very frequently and nobody reviews every single update, especially for projects not yet in production, it massively increases the likelihood of pulling malware. there's also typosquatting etc

the *only* reason this is not yet that common in cargo is because it's orders of magnitude less popular than npm. npm was relatively safe back in the day too but now it's genuinely a security nightmare and not just because of supply chain attacks, that's just ONE security issue

ofc people come up with shitty bloated bandaid solutions like dependabot but the real fix is to not engage in promiscuity in the first place

>>108950484
He didn't make a single lie. You're the one sugarcoating what was one of the worst vulnerability ever discovered. We're lucky that microsoft postgres maintainer caught it on time, otherwise that single supply chain attack would be worse than all NPM related vulnerabilities that will ever be.

The blast radius was only limited because of a convenient providential event where a postgres maintainer caught unusual latency while benchmarking on a minimal alpha release of debian.

So yeah, XZ WAS the biggest dependency related vulnerability in a long time.

>>108950587
>He
Nice try, india.

>>108950616
>He
The C++ community is more trooned than the rust community, go to any C++ conference and see for yourself.
I honestly don't understand your criticism of C++ and by the tangents the people of this forum take while trying to argue against it, you sound like disingenuous pricks.

>>108950670
>I honestly don't understand your criticism of Rust*

>>108950587
>one of the worst vulnerability ever discovered
wow the worst vulnerability ever... that did not even make it to any stable distro and was caught very quickly?

>We're lucky that microsoft postgres maintainer caught it on time
you mean diligent maintainers from many different distros actually TESTED shit before instantly deploying malware to everyone? shocker. that's not luck and you know it.

a large portion of end users don't use rolling distros, and of those that do, not many of them autoupdate or install updates asap, and this was a potential backdoor rather than an automatic "get fucked" kind of malware that is possible when engaging in promiscuity. the odds of getting actual, blatant malware with the robust way that distros handle dependencies is nearly zero

>>108949460
It is

>>108950697
>wow the worst vulnerability ever... that did not even make it to any stable distro and was caught very quickly?
Because of a feat of providence and luck

>you mean diligent maintainers from many different distros actually TESTED shit before instantly deploying malware to everyone? shocker. that's not luck and you know it.
wasn't a core linux kernel developer but a postgres maintainer testing it on debian alpha that out of curiosity ended up following that pipeline, if it was left to the kernel devs, it would've shipped to prod

Also, we got lucky because the way that malware was engineered added a whole 500 millisecond of latency on SSH, that was a very loud tell for a malware of that nature. If it wasn't, (and i'm assuming there are a bunch for backbone dependencies that don't leak such signals and are already compromised by now) we probably never would have ever known

>>108949468
>not using edge-triggered epoll
>accept + fcntl instead of accept4
>epoll instead of io_uring/dpdk

>>108947490
functions should be constant static variables, like they are in reality at runtime, instead of abstracted symbols.`

imho, the syntax should be something like

/* TBD */ fun = |var1: u32, var2: String| {
  ...
}

the || makes sense because functions do capture their environment (which is the global namespace in this case)
although, that would not apply to nested func decls, that still capture the global ns, but not the one they are declared in.
type for arguments should be mandatory (as opposed to regular closures)

I put TBD for the declaration, because rust forces static to have an explicit type (cannot be inferred), this is a constraint that cannot be lifted because of how static works in rustc. But ideally there would be a workaround/sugar to make this nicer to use than having to re-declare the function prototype in it's type.

The biggest issue with that syntax is that Rust does not yet support parametrized closures, so that syntax would have to be a sugar around the current syntax, instead of unifying closures/functions. It is a planned feature though.

>>108950323
it is not.
your electrician uses complex numbers on a daily basis, because their use is very widespread in electricity, mechanics, fluid dynamics, radio comms etc.

in CS, they are often used in rendering software for quaternions. linear programming also uses them because they are very nice to work with. Signal processing has complex numbers all over the place. mp3, jpeg are both based on the FT which uses complex numbers.

complex numbers are not 2D vectors because vectors can't be multiplied and they encode different informations. Vectors encode a translation, while complex numbers encode a rotation and scaling operation. To transpose complex numbers to vectors, you'd need to use a 2x2 matrix, which drastically slows down computing speed when you don't need the sheer component

>>108951033
> the || makes sense
Can’t wait until rust needs a special “memory safe” font for their 20 year old “grown” from internet randos’ ideas.

> closures
Let’s all wait another 20 years while the rust zealots slowly discover cs101 concepts that are available in designed and theoretically sound languages already in use since the 60s.

>>108950484
I have a parsing crate of which I'm the sole maintainer published on cargo. I've stumbled upon middle sized open source projects that were using my crate. I can literally just pull an update that adds a vulnerability inside of my crate and exploit it in these projects.

My crate builds parsing DFA from NFA (like the thompson construction), it has as lot of unsafe code because it builds an automaton meant to run in some sort vm runtime (but it is not virtualized). It takes one line of code to skip validations and allow potentially unsafe memory access.

For a while my crate didn't pass it's own tests, but that didn't stop people from using it. They probably never read the README about it being a WIP because cargo doesn't automatically shows the git content. That didn't stop morons from using it.

>>108951161
is that you: https://burntsushi.net/regex-internals/

>>108947387
>C++ is more usable/secure/robust
what a garbage low effort shitpost from a nocoder lmao

>>108951215
That's not mine, but crates like that can be exploited to create vulns. It just takes a simple logic/parsing bug -- harmless on it's own, to generate incorrect bytecode that can then make the runtime do bad memory access.

But regex are widely known for being problematic as they can be exploited to make DOS attacks. Rust regex crate tries to mitigate it by disabling look-arounds (which can't be expressed into a DFA)
https://blog.securityinnovation.com/cloudflare-dos-blackout

Though, the rust regex crate is well studied and is generally considered safe. There are other crates, like serde that do shady stuff, like skipping compilation and downloading a pre-compiled blob (which has often been non-reproducible)

>>108951074
You clearly haven't graduated high school yet. None of that is even remotely true.

>>108951260
I work in EE and rust is unusable for us because it lacks tooling. We must validate timings, halting, longest possible code paths, etc.

C/C++ have such a long history and large number of available tools that we consider them safer than rust for that reason.
Since rust is built on top of LLVM, we have tried LLVM-based tooling, but it still struggles on rust code.

For instance, if we need to make sure that a function NEVER exceeds 1000 cycles, and that a loop ALWAYS terminates under a given time constraint then we are stuck using C/C++ because they have the correct amount of tooling available (although we strip a lot of features from these languages)

>>108951265
take a look at
https://docs.rs/rustfft/latest/rustfft/
https://fftw.org/download.html

and tell me complex numbers are useless

>>108951296
Forgot to mention that rust still struggles when using the RTOS scheduler, or with cooperative multitasking in general. The language was designed for modern OS that always enforce preemptive scheduling. In cooperative scheduling, locks, data races, race conditions take a whole different shape, making the rust provided primitives (RwLock, Mutex, Arc, etc..) pretty much useless

>>108950192
>Did he ever fix that elevator? Was the story a lie?
Did Stallman ever got FOSS drivers for that printer?

>>108950963
io_uring is a joke and dpdk is a total meme for a webserver
>>108949468
>single-line "helper" functions
>useless keepalives
>not using accept4
>not ignoring SIGPIPE
>EPOLL_CTL_DEL immediately followed by close
>calling close at process exit
>struct epoll_event events[1];
Slop. Real programmers wouldn't make any of these mistakes.

>>108951308
Retarded or merely pretending?

>>108950484
>how much of a liar can you possibly be?
It's not a lie. XZ was pretty much the worst dependency related vulnerability in many years. And it did primarily affected C/C++ programs.

>"push a button and possibly get malware from 100-1000 promiscuous packages" feature unlike cargo/npm
Except, that's exactly what happened in XZ. Someone pushed an update and 100s of programs became vulnerable. And the worst thing is that there was nothing in place that could have prevented it on the developer side. No matter how much auditing you'd do to your dependencies, you wouldn't find any because it was retroactively added to already existing software.
Something like that wouldn't happen in Rust because Cargo pins dependency versions. If you audit them once you can be pretty sure no one will sneak a malicious code into your program unless you explicitly update dependencies.

>much more robust when you don't engage in promiscuous dependency management a la cargo/npm
Not really. They didn't use cargo and still got the vulnerability. But if they did used cargo, they'd be pinned to the old version and the attack would not succeed.

>>108950697
>you mean diligent maintainers from many different distros actually TESTED shit before instantly deploying malware to everyone? shocker. that's not luck and you know it.
No maintainer of any Linux distro found XZ exploit. It was all accepted and ready to be released to the entire world.

>>108951033
How would you make function generic?

>>108951161
>I can literally just pull an update that adds a vulnerability inside of my crate and exploit it in these projects.
In Rust they probably pinned your library version. So you updating your lib will not have immediate effect, and someone else who wants to use your lib could have audited it in the meantime and uncover your malicious code.

>but what if they don't audit
Then it's no different than just uploading your malware to github and waiting for someone to download and run it.

>>108951074
If I am writing a graphical software that uses quaternions, matrixes and linear programming, then 99% chance I am using some linear algebra library that will definitely come with complex number implementation(and one that is more complete and useful). So having complex numbers in stdlib brings no advantage and could even be detrimental because their implementation might not be optimized for what that library is doing.

>>108951335
>Forgot to mention that rust still struggles when using the RTOS scheduler
This is wrong, but why would you need an RTOS scheduler in Rust, when Rust comes natively with async/await? You can write your own async runtime and get everything RTOS gives you and more, faster, more elegant and take several times less flash space.
In my own embedded project, by moving from RTOS to embassy, I reduced binary size from 1.4MB to 70KB. That's 20x less precious, embedded space!

>cooperative multitasking in general
It doesn't struggle with it. It excels at it.
https://tweedegolf.nl/en/blog/65/async-rust-vs-rtos-showdown

>The language was designed for modern OS that always enforce preemptive scheduling
It wasn't. Rust has core subset which is completely agnostic to this.

>In cooperative scheduling, locks, data races, race conditions take a whole different shape,
That's true! That's why you bring your own synchronization mechanisms in embedded, which are way flexible than any mutexes or locks in any standard library of any general purpose programming language.


Why lie so much?

>>108951369
> stallman, foss
Good point! Rust is FOSS too! It’s like a cult of cults built on lies.

>>108951471
you can pin crates, but dependabot (used on many projects) will automatically try to update crates and run tests. as long as updating doesn't break tests, dependabot can make an automatic pr to update a crate's version.

for my specific crate, I can simply make a 'bogus' pr that doesn't break anything, just bypasses a safety check than I can then use to exploit. my crate wouldn't have any malware in it. also in the future there may be other crates that bundle my crate into their dependencies, making it more likely someone would use it without knowing about it

>>108952222
>dependabot can make an automatic pr
Anyone can make PRs. PRs must be approved.

>I can simply make a 'bogus' pr that doesn't break anything, just bypasses a safety check than I can then use to exploit
You can do that in every language.

>>108951033
>>108947836
There are reasons functions get a special syntax instead of being lambdas in global scope
Mainly, functions are innately named so they can be recursive without any tricks. In other words, the identifier of the function is valid within it's own body. Closures are innately unnamed and only get a name once you bind them with the move operator. But for the move operator to be resolved it needs to resolve the RHS first, aka the closure being bound.
Also, functions are not just constant static variables. Functions, unlike closures, can be generic. Generics are semantic constructs that don't exist until they are actually monomorphized. So you also need to add extra syntax to lambdas to provide type parameters (and bounds...)

>>108951527
Your article doesn't show how to get rust to work on RTOS. We use extensive libraries developed primarily for RTOS. We're not going to rewrite them (some codec code is under patents) so that they run on another runtime. We could rewrite some portions of the code, ones that are scheduling agnostic, e.g linear processing logic, to rust, but the costs might not be justified.
The main reason we keep using RTOS is because we have tools to help us prove halting and ensure code finishes under a given number of cycles, not to mention the debugging experience, which lldb is still far above rust-lldb. Other runtimes may prove efficient in the future, but the cost of switching greatly outweigh the benefits.
The embedded world moves very slowly, especially when your code may impact people's life directly. Using a recent runtime without many industry expert/consultant to get our contractee to audit our code could simply put us out of business (if not worse).

>>108952262
I tried to address that in my post. Currently rust closures can't be made generic.
There have been discussions in the past to make it possible:
https://github.com/rust-lang/rust/issues/44265
https://github.com/rust-lang/rust/issues/81823
However, that would require a lot of work, which the developers don't want to prioritize right now.

C++ monomorphization (although using different rules from rust), has added an easy way to make recursive closures, based on how closures are really defined:

auto fn = []<typename Self>(this Self& self, size_t idx) -> void
{
    if (idx < 10)
        self(idx + 1);
    std::println("{}", idx);
};

fn(0);

Sadly, closures without captures in C++ are still functor objects, not functions.

Rust has stricter rules for monomorphization, and allowing what C++ allows would break some of the core invariant assumed by the BC. There is currently a project (maybe dead) from rust org to make a BC that would properly validate traits with GATs:
https://github.com/rust-lang/polonius
Explained in details here:
https://blog.rust-lang.org/2022/10/28/gats-stabilization/#traits-with-gats-are-not-object-safe

>>108952331
Sounds like your problem isn't that rust is bad at coop multitasking, but that you already have a ton of other code you would need to interop with
Also "the embedded world" is not one thing. I'm embedded too, but on quite good machines. Tomorrow I could add a component in rust to the next release, but unless it's doing something extremely self-contained I would need to write a ton of interop

>>108947483
type before name is the ultimate C baby duck

>>108952474
face it, less typing is better.

>>108952474
RAX 64 bit int
EAX 32 bit int

Type before. It’s always been that way.
And, soon, ZAX, for general purpose 128-bit ints.

>>108952479

main(…

Default return type should always be of type ‘int’ as it was in C89. The last “known good” version of C.
Saves keystrokes.
It’s the same with undeclared external functions, it assumes int as a return.
Do likewise, gents.

File: out.mp4 (2.77 MB, 1734x1080)

2.77 MB MP4

>>108952331
>Your article doesn't show how to get rust to work on RTOS
You never asked for instruction on how to get rust to work on RTOS
In general you don't need to do anything fancy. You just link it as you'd do in C/C++. In practice you'd use some framework from the hardware provider. For example in ESP32 I used to use this: https://github.com/esp-rs/esp-idf-hal/tree/master it runs on top of rtos
However it seems even Espressif removed mentions of this from their official docs because it literally makes 0 sense to include all that bloat in Rust when you have async/await and core subset.

>The main reason we keep using RTOS is because we have tools to help us prove halting and ensure code finishes under a given number of cycles, not to mention the debugging experience, which lldb is still far above rust-lldb.
That's reasonable. But that just means you are locked into that ecosystem.
I personally had to develop my own tools to profile embassy and memory usage and I'm pretty happy with it. I connect via USB-JTAG interface which supports multiple RTT channels. One I use for general logging(defmt is amazing), but I have another binary, blocking channel where MCU dumps performance related data when I press hardware button on the devkit. Since rust async await is all in rust, I could just make my own Future type that tracks every time it returns back to the scheduler(there are embassy hooks for premptive scheduling too but I didn't need them). The presentation window was really simple to write with egui.
The JTAG also supports debugging but I didn't had any reason to use it yet.

>>108952539
> only 17 FPS
C and C++ can do 244 FPS

>>108952493
those are registers you fucking retard not types

>>108952479
> less typing is better
That’s where Rust excels.
We don’t comment anything, and we don’t need to write tests or test anything because the compiler guarantees that it’s bug free and correct every time (obviously only if it compiles). That is why it takes slightly longer to compile our code—the tests are done at the compile phase.
We’re working on a rust interpreter now which will offer the same guarantees as the compiler, but not compilation overhead… it starts immediately.

>—
>…

>>108952479
where you place the type doesn't mean more or less typing

>>108952575
It does if you add a colon for no good reason.
>>108952526
Throwing out necessary information is not what I meant and you know that, faggot.

>>108952591
adding a colon has nothing to do with type first or name first

>>108952596
>int foo
>foo: int

>>108952623
>int foo
>foo int

>>108952625
>>108947483

>>108952675
you're ignoring the point that you dont need a colon

>>108952679
Then why do all the languages with type either have a colon or an extra keyword?

>>108952736
beats me

>>108952679
Rust parser is stupid.
You need the colon for stupid parser.
Just like you need to put “fn” in front of functions. C parser doesn’t need. Rust parser stupid. You work for Rust parser.

>>108947387
Who pays you to shitpost about it all fucking day? It's just a programming language, you retarded yokel freak.

>>108952736
> all
In fortran, you simply *use* a variable that starts with ‘i’ and the compiler correctly assumes it’s an integer like god intended. NO fucking declarations needed. If you like meaningless verbosity, you can write

integer i

if you really like impressing chicks if you can get them to come over to see your fortran 77 collection.

>>108952493
Clinically retarded or merely pretending?

>>108952571
Kek. Is that why rust programs are buggy as fuck all the time? Looking at you rustdeck and bevy.

>>108952736
It makes parsing far easier, allowing using simpler algorithms while maintaining efficient parsing. This is actually important because it makes adding errors and reasoning about the parse process infinitely better as you don't have to rely on a parser generator to write the parser for you.

>>108947708
>Why should the most important thing not be the first word?

The identifier is more important than the type.
But ultimately the order is irrelevant.

>>108950963
>>108951409
>single-line "helper" functions
>accept + fcntl instead of accept4
>EPOLL_CTL_DEL immediately followed by close
most of this is artifact from also having a mingw+winsock2+wepoll windows implementation
windows doesn't have accept4, the helper functions contain all #ifdef _WIN32 branches, and wepoll recommends delete before close.
>useless keepalives
a bit of a stretch to call keepalive useless. but admittedly if server isn't quiet then keepalive never triggers
>calling close at process exit
shows up on sanitizers otherwise

File: 1767609772918278.jpg (53 KB, 573x574)

53 KB JPG

>>108947495
>literally
As opposed to what, figuratively baby ducking?

>>108954376
Well he babyducked in text as opposed to imageor video he could also put in his post

>>108947387
>>restrictive compiler made for morons (maybe a good thing with jeets in tech)
I'll take the bait but as someone who was just writing python and lua shitscripts before, having the compiler catch my retardation as soon as I type it has been incredible in actually learning how to do stuff properly. In python I'd just deal with runtime errors as quickly as I can because I would feel that if I am running the code then "it should work". That + crates like anyhow, clap, tokio and i really don't know why rust is not recommended as a beginner's language.

>>108951409
daily reminder, io_uring is the fucking disaster that is a kernel level libuv-esq library bringing the unix "thread all the blocking disk io" mentality into the kernel instead of simply providing a real async interface.

troonix continues to prove itself hopeless and beyond repair.

>>108955208
>I am a tech illiterate nocoder jeet that OP was talking about
>this proves that it isn't only liked by tech illiterate nocoder jeets
Lmao

>>108954031
>windows doesn't have accept4, the helper functions contain all #ifdef _WIN32 branches, and wepoll recommends delete before close.
>>useless keepalives
>a bit of a stretch to call keepalive useless. but admittedly if server isn't quiet then keepalive never triggers
>>calling close at process exit
>shows up on sanitizers otherwise
made up/invented issues

>>108954031
>most of this is artifact from also having a mingw+winsock2+wepoll windows implementation
half of that nigger babble is completely irrelevant. next time just say you're too retard to use WSASelectEvent in place of epoll_ctl

>>108955230
and you're a tech illiterate nocoder jeet that happens to hate rust or you wouldn't be here

>>108955208
i mean you were literally using fake languages before, what did you expect? why do you think most js developers now switched to typescript? dynamic typing is a proven failure. you don't need rust for static typing

the crates thing is exactly why retards like you are attracted to this garbage lang though. same with js back in the day, pretty sure js only got massively popular outside the browser because of npm, so retards could glue together 300 libraries that do 90% of the work except now everything is a broken, buggy, unstable, bloated mess

"dont reinvent the wheel" has been the single most damaging, utterly wrong, harmful advice to ever come from stackoverflow. that road leads straight into promiscuity

>>108955208
>i really don't know why rust is not recommended as a beginner's language
Because of incredibly steep learning curve.
Something like C#/Java or even Typescript would probably be much simpler to teach and still show you the advantages of static typing. To properly utilize the powerful type system Rust gives you, you need to be at least somewhat experienced programmer and go through the difficult phase of learning all the lifetimes, generics, traits etc that Rust requires before you can even start using it.

>>108955256
Whatever helps you sleep at night pajeet.

>>108955264
I am pretty sure that your own reinventions would come of as "broken, buggy, unstable, bloated mess" when compared to the commonly established libraries, like the ones mentioned by that anon.

>>108953982
>It makes parsing far easier
it actually doesnt, theres no reason you can't simply parse identifier then type without the colon

>>108955297
>that anon
Who are you trying to fool, pajeet?

>>108955309
There is no shame in not knowing anything, anon, but in that case you really have a duty to read up and inform yourself instead of shitting up the thread with the absolute most retarded anti-real take the world has ever seen. Next you'll say there's really no reason for water to not be dry.

>>108955311
?

>>108955316
I have literally made a fully-featured programming language that parses the identifier then the type without a colon

>>108947387
Rust is tranny language.
Zig is white man's language.

Zig Heil.

File: 1760044324618-9fc525a3-60(...).jpg (57 KB, 750x750)

57 KB JPG

>>108955379
Zig creator

>>108955333
Obviously not, otherwise you would know how parsing works, and you have repeatedly shown you don't even begin to understand.

>>108955432
I do know how parsing works, that's why I'm telling you there's no issue in omitting the colon
Surely if you're so smart you can tell me what parsing issues arise from not having a colon between the type and the identifier?

>>108955443
>I know how parsing works which is why I'm telling you I have no idea how parsing works even at the 101 level

File: code2.png (122 KB, 1860x928)

122 KB PNG

>>108955458
Can you tell me why parsing this is difficult? Can you tell me how having a colon would make it easier?

>recursive package management
truly not CIA coded

>>108955483
looks beautiful
what language? PascalCase and that begin and end positioning, perfect all around.

>>108955496
doesnt have a name yet, im open to suggestions

>>108955512
Does it compile to native code? what is the backend? You are gigachad if you use in house code generation backend like FreePascal instead using LLVM.
No idea, Buttress, I guess. It's a rock solid foundation found in Medieval Cathedrals.

>>108955512
And I would like to use your code in prod, I'm dead serious. It looks nice to read and type, instead symbol slop like C++ and unfortunately C# now.

>>108955528
No I'm not writing my own backend, that's a huge project unto itself and I won't be able to create anything better than LLVM

>>108955531
That's nice to hear, hopefully I can release it soon, it's pretty close to ready but life conitually gets in the way

>>108955547
Good luck, please shill again here if you released the thing. I really want to try it.

>>108955571
i will

>>108947483
godly bait

File: king-of-the-hill-hank-hil(...).gif (350 KB, 165x126)

350 KB GIF

>>108947387
AI does, and all code is written by brown people vibe-coded using AI.
You're finally understanding that the point of safety is that machines can make the code and it's far less likely to break. It was never about C or C++ being unsafe, it was about AI not being able to shit out a billion lines of C code without the guarantee that it was reliable C code.

/g/ fell for the world's biggest tech industry grift and the entire open source community wrote its own death certificate to AISlop controlled by their own mortal enemies.

At least you 'owned the luddites' though, right? Enjoy Poopbeep and his clan becoming the sole maintainers of every project.

>>108947430
YOU CAN'T IMPORT THE NET LIBRARY even though i do that through my cargo cult, it's...... ******LEBAAAAAAAD****** and.... *****LEUNSAAAAAAFE***** when you do it, i can't hear you through my coconut headphones

>>108955483
Read a book, retard.
https://dl.acm.org/doi/pdf/10.1145/322344.322350

>>108956212
Why do I need to read a book when I've literally written the entire parser for the programming language already?

>>108956479
Because you don't know shit about parsing. You're like one of those noobs who think you can write an infix forth by just adding arg count at the word definition site and counting arguments forward in call sites.

>>108956703
>Because you don't know shit about parsing.
I've written an entire parser for a modern programming language
Whereas you think that parsing name - type is harder than type - name
Neither of these require any lookahead

File: image.png (111 KB, 986x802)

111 KB PNG

don't worry guys, supply chain attacks are not real, cargo is not bloated and doesn't need gigabytes of ram and storage to compile a simple hello world, it doesn't need to pull an entire index of millions of crates on first use, we need every program using the same bloated packages that try to cater to every possible use case in existence. just one more library and framework guys this time we will finally find the perfect abstraction that catapults humanity with all the extra time saved

>>108951457
Dynamic dispatch + JIT.

>>108956980
We are talking about syntax, not implementation.

Also
>JIT
>in systems programming language
wut

>>108948232
It’s not but Go is also disgusting