/tech/ - Technology★

>CVE-2018-1000810 rust: Buffer overflow in str::repeat function in the standard library

>Buffer overflow

>Rust

I thought the whole point of Rust is to prevent such problems at compile time. Not to mention that this was written by developers of the language who supposedly know it inside out. How do you expect average developer to catch such issues? Rust is even more dangerous than C. You believe that you're safe but in reality if you don't understand what you're doing nothing will help you. You only blind yourself from reality by thinking you're somehow safe.

Shitty language found to have a shitty toolset last year. News at 11.

>>1026654

This guy gets it, knowing things can be unsafe is 100% better than a sense of false security. Especially considering the average thought a code monkey puts into his work.

Imagining things being 100% safe is stupid anyways, the common architectures we use nowadays do not give us that security. Where there's code run, there's always a risk. You should never treat it differently.

it's just C++ with lipstick on

>>1026659

>so let's just go with 0% safety aka C/C++

Funny thing is: C is safer than Rust. There is CompCert a formally verified C compiler, then there is MISRA, CERT-C and other standards that help with software safety. There is also Ada if you don't like C. I don't really see how Rust is relevant here. Planning software architecture, manual verification, testing in real world, code reviews by security experts and not being a pajeet will yield greater results than forcing people to use a meme language which fails both in terms of usability, readability and safety kek. Good thing the industry tells you to learn C or GTFO. Rust is too complex to be used in real safety critical systems, but I guess it's probably okay for web apps.

>>1026665

I was contemplating writing a serious reply but why should I bother? Everyone here is just LARPing (you included).

>>1026667

>telling the truth is LARPing

I don't need to be a certified Java expert to see why C works and Rust doesn't. Planes fly, cars drive, medical devices keep people alive, PLCs run machinery that cleans our water, run our power stations, transfer shekels, serve this web page... C just works. Yes, there are flaws but isn't it better to fix existing systems than reinvent everything with all the mistakes from the past?

>Often when code is thrown away and rewritten people realize during the rewrite or afterwards that they did not understand what the old code was doing and why it did it that way. I have seen many examples where the argument for the rewrite was some "crazy complicated" algorithms used in the old code. The new code then failed in some "rare cases" and in the end the new code was changed to use the same "crazy complicated" algorithms because they work in all the needed use cases. Who doesn't learn from history,...

>>1026667

>Everyone here is just LARPing

https://youtu.be/FzJJbNRErVQ?t=2137

Link above answers your questions.

>>1026672

>because it somehow runs out of registers

top kek.

>>1026667

Rustfags love to brag that the compiler stops them from acting like a retard, the solution? Don't code like a retard, retard.

>>1026671

Holy shit. He's right.

Oh my G*d, so this safer language I vehemently hate because of political reasons has some vulnerabilities. Better shill my shit language with no security because muh SJWs and fee-fees!

>>1026682

Learn to read and watch >>1026671 It answers your questions about memory safety and Rust.

>Rust has a memory access bug

it's inside an unsafe {}. Look for those, found your bug.

>C has a memory access bug

Here's all the forests on all the planets in the galaxy: one of the leaves on one of the trees is bad. Hey man, I narrowed it down to a galaxy for you :^) For an example of this, check out modsec 2.x (3.x is a C++ rewrite). Every single memory allocation is explicitly allocated from a memory pool. There are many memory allocations. One of them mishandles the memory pool. Result: Apache later tells libapr to clean up its pools after an exec -> libapr tries to 'clean up' a circular list -> Apache is stuck in an infinite busy loop and uses 100% of CPU.

Pretty shameful display from the Rust people, but they forgot shame when they accepted a dining philosophers example using a bunch of Communists.

The memory pools are an implicit feature of the language in Ada: you can't accidentally break them. Overflow checks + the culture of defining your own types would discourage Rust's math/API error. Rust's unsafe { go fuck yourself } vs. only-provably-safe-code dichotomy encourages memory errors like this: there's no reasonable automatically-checked-cause-not-proven intermediate state.

>>1026688

B-B-But Ada is old! And it was probably developed by people who have alarming views on race, privilege, gender, transpeople and are bigots. Rust==Resistance! (At least that's what I get from their PR)

This is why bloat and security aren't compatible. You can't have a libstc++ tier stdlib bloat without having bugs. Same reason using Java for security is retarded when OpenJDK makes OpenSSL looks good.

>>1026671

>>1026697

>where is ls

Stopped listening right there. ls is right here: https://github.com/uutils/coreutils/tree/master/src/ls

>but muh 100% POSIX compliance

Who fucking cares? POSIX is shit.

>but muh compiling rustc on 32-bit

Who fucking cares? 32 bit is deprecated.

>>1026719

>C version reads like classical literature, while Rust version is an essay

epic

if (S_ISREG (mode))
        {
          type = C_FILE;

          if ((mode & S_ISUID) != 0 && is_colored (C_SETUID))
            type = C_SETUID;
          else if ((mode & S_ISGID) != 0 && is_colored (C_SETGID))
            type = C_SETGID;
          else if (is_colored (C_CAP) && f->has_capability)
            type = C_CAP;
          else if ((mode & S_IXUGO) != 0 && is_colored (C_EXEC))
            type = C_EXEC;
          else if ((1 < f->stat.st_nlink) && is_colored (C_MULTIHARDLINK))
            type = C_MULTIHARDLINK;
        }
      else if (S_ISDIR (mode))
        {
          type = C_DIR;

          if ((mode & S_ISVTX) && (mode & S_IWOTH)
              && is_colored (C_STICKY_OTHER_WRITABLE))
            type = C_STICKY_OTHER_WRITABLE;
          else if ((mode & S_IWOTH) != 0 && is_colored (C_OTHER_WRITABLE))
            type = C_OTHER_WRITABLE;
          else if ((mode & S_ISVTX) != 0 && is_colored (C_STICKY))
            type = C_STICKY;
        }
      else if (S_ISLNK (mode))
        type = C_LINK;
      else if (S_ISFIFO (mode))
        type = C_FIFO;
      else if (S_ISSOCK (mode))
        type = C_SOCK;
      else if (S_ISBLK (mode))
        type = C_BLK;
      else if (S_ISCHR (mode))
        type = C_CHR;
      else if (S_ISDOOR (mode))
        type = C_DOOR;
      else
        {
          /* Classify a file of some other type as C_ORPHAN.  */
          type = C_ORPHAN;
}

>>1026656

>muh false sense of security

kys. rust is just shit, why is this surprising? memory safety still remains trivial to solve as done in Lisp and SML. you could literally implement a memory-safe PL yourself in a day and add some interop for networking and framebuffer and it will be better than any existing system

>>1026713

Because "we" (you, not including me) are retards.

>>1026723

>(you, not including me)

spotted the LARPer

>>1026723

Fuck you sage nigger. Eat a bag of dicks.

>>1026704

Ada isn't "C plus runtime checks". Even when you turn checks off, you have a better language.

Ada also performs well with checks on. Enough for non-embedded platforms. If you write an O(N^2) 'Pre' check, you might want to disable that for release.

As a practical matter, you can segments of get high performance Rust code by being really careful in an unsafe {} block. If you can get the same performance by writing Ada completely normally and then removing checks from that segment, this is also going to be the less-error-prone option.

>>1026723

>Lisp and SML

>cures for cancer

eh. SML's alright, but "segments of high performance Lisp" could have this exact bug.

>>1026738

As a practical matter, you can get segments of high-performance Rust code by not misplacing entire words.

>>1026665

Use F*.

https://www.fstar-lang.org/

Sunk cost fallacy: the language

>>1026695

Risitas never gets old

>>1026649 (OP)

>https://bugzilla.redhat.com/show_bug.cgi?id=1632932

>This site requires JavaScript to be enabled to function correctly, please enable it. [in flashing red bar]

fucking what

>>1026749

it's CSS doing that.

you don't need JS to read the page though, that's just shitty design.

Rust is just a desperate attempt by Mozilla to stay relevant. You can see how much they realize Firefox is a failure now and they need something else, and they think it'll be Rust, by how strongly it's shilled all over the internet.

>>1026659

Nothing is safe on a computer. You should never assume it is safe.

C takes safety and places it into the programmer's hands. If there's a problem with a program, it's because the programmer fucked up in one instance. Meaning if you want to find an exploit there, you have to comb through the code and find where they fucked up.

Rust embeds those problems into the language itself. Look at this, str repeat has a buffer overflow. Now you can exploit any Rust software that uses str repeat. Rust is like using defective libraries all over. And as other anons pointed out, it's all false security, so those libraries were probably made by a bunch of people going

>lmao who cares about doing anything the safe way Rust can do it all for us!

as we've all seen by the bullshit shilling that happens here and all over the internet.

Rust is an attempt to take the scary part of programming away from users, like Visual Basic, Javascript, etc. And it has the same exact problems as those languages. They are restrictive. And when there's a problem with the language or build in libraries, it spreads everywhere.

>>1026741

Interesting. How performant is it?

>>1026759

>Rust is like using defective libraries all over

And you think C is better in this aspect? libc implementations have had security issues too.

<ha ha Rust did not protect you this time

When you use unsafe blocks you are giving up the benefit of security.

>>1026700

Autistic technology oriented Jews are the best Jews.

>>1026713

We are. It's just that you're not one of us.

Rust and Go are both memes, you can tell by the amount of shills their sponsors need to hired to try to force them on the public.

Rust really is shit.

>>1026654

>I thought the whole point of Rust is to prevent such problems at compile time.

The whole point of Rust is to make Mozilla bloatware like libxul (around 100 MB stripped) more maintainable.

>Not to mention that this was written by developers of the language who supposedly know it inside out. How do you expect average developer to catch such issues?

You could say the same thing about UNIX, Linux, and Plan 9 code. UNIX bc is so full of bugs that numbers get corrupted. They managed to make a "calculator" that can't do math.

>Rust is even more dangerous than C.

Do Rust compilers delete null pointer checks and change the meaning of code it assumes to be "unreachable" because of "time travel" bullshit that has no relation to any physically possible or hypothetical machine? C compilers do.

>>1026665

>Funny thing is: C is safer than Rust.

Assembly is safer than C or Rust because you have full control over the instructions, but people realized early on that it's usually better to have programs that write programs (aka compilers) because the author of that program can do it once instead of having to write the same code over and over again. One of the things that sucks about C is that it forces you to keep writing the kind of tedious code that computers are good at handling.

>There is CompCert a formally verified C compiler, then there is MISRA, CERT-C and other standards that help with software safety.

Those "standards" are mostly workarounds for C brain damage.

https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=87152364

Simple link-time type checking solved this problem decades ago. UNIX is stuck with a linker designed for PDP-11 assembly.

>Good thing the industry tells you to learn C or GTFO.

It's mostly smart people who know C inside and out who hate C. C weenies think they know C but actually don't, which is why they can't understand all the bullshit in the standard. They learned what someone else thinks C is from books instead of learning the real language.

>>1026704

Ada without runtime checks is still a better language than C. Ada has pragma Restrictions as a standard feature to disable specific features of the language. The No_Exceptions restriction is a standard feature of Ada.

>>1026713

Weenies don't want to use Ada because it solves too many problems, like that article on hacking a computer via DNA.

>>1026759

>C takes safety and places it into the programmer's hands.

Bullshit. Assembly language "takes safety and places it into the programmer's hands" because every instruction is written by the programmer or by a macro the programmer chooses to use. C puts safety into the hands of the developers of the compiler and libraries. C compilers do all sorts of complicated bullshit to your code, which is necessary for the "speed" C weenies brag about. C is not assembly and has nothing to do with how hardware works (besides RISCs leaving out features C doesn't need and making everything else slower).

>If there's a problem with a program, it's because the programmer fucked up in one instance. Meaning if you want to find an exploit there, you have to comb through the code and find where they fucked up.

Every bug in any level of software, including compilers, is because some programmer fucked up somewhere. UNIX needs more than 60 million lines of code just to approach the usability of a Lisp machine, and UNIX is still worse. Lisp operating systems like Mezzano reduce the distinction between macros and the built-in parts of the compiler. The whole thing is a modular Lisp system where many of the optimizations (compiler macros) are kept with the modules themselves instead of baked into the compiler.

https://github.com/froggey/Mezzano/search?q=define-compiler-macro

Of -course- mail to Unix-Haters fails to blame any
particular responsible individual.  -Every- little bug or
problem is actually the responsibility of some individual,
if you could only figure out who.  The problem is that
dealing with Unix seems like a grand game of finger pointing
and pass-the-buck (without Harry Truman).  Is the real
problem that the programmer didn't check the array bounds?
Or is it ultimately the fault of the designers of C for
designing a language in which programmers must error check
array indices manually?

Eventually, you stop caring about the details that would let
you sort out who was responsible.  Recently I was unable to
use FTP on a PC to send a file to my directory on a Unix
machine because on the Unix box I use the `bash' shell.
Heaven help me, I even understand why this restriction
plugged yet another security hole in Unix, and I was able to
remove the restriction as soon as I understood what was
happening, but after enough absurdities like that, your
average user has no energy left to assign blame.  What do
all these bad experiences have in common?  Unix!  Thus, Unix
is the problem.

>>1027087

based

>>1027087

>Bullshit. Assembly language "takes safety and places it into the programmer's hands" because every instruction is written by the programmer or by a macro the programmer chooses to use. C puts safety into the hands of the developers of the compiler and libraries. C compilers do all sorts of complicated bullshit to your code, which is necessary for the "speed" C weenies brag about. C is not assembly and has nothing to do with how hardware works (besides RISCs leaving out features C doesn't need and making everything else slower).

Now remind me how your precious Lisp needing a fuckhuge garbage collector to be performant isn't a problem.

>UNIX needs more than 60 million lines of code

Nice joke.

>Lisp operating systems like Mezzano reduce the distinction between macros and the built-in parts of the compiler. The whole thing is a modular Lisp system where many of the optimizations (compiler macros) are kept with the modules themselves instead of baked into the compiler.

Probably slow as fuck.

>2GB of RAM recommended

Joke of the century, nice of you to link it.

>Lisp

Known as "how to make lambda calculus look ugly". Use Scheme for syntax purity or SML/sML for an actually usable language; dynamic typing is just a retarded shortcut to avoid the task of designing a type system while pretending that the grape is sour anyway.

>>1027109

also based

>>1027087

>UNIX needs more than 60 million lines of code just to approach the usability of a Lisp machine

Firstly, in what universe has a Lisp machine ever come close to modern *nix in usability?

Secondly, as >>1027162 said, much of the codebase is drivers. You kinda need those if you want hardware compatibility.

What's the point of rust again? Is it a containment language for all the freaks and trannies and homos?

>>1027162

>They're so fat that the sheer number of instructions is becoming a bottleneck and CPU designers have moved to emulating it on top of specialized RISC processors to get anything resembling good performance.

That doesn't even resemble what's actually going on.

The bottleneck on your modern amd64 chip is two-fold.

1. since it's an OOO machine, with a ROB that tracks dependencies and executes instructions in dependency order, it's IPC limited by the amount of dependencies and how granular said ROB can be made. 8086 and 80386 compatibility comes with an absolutely immense amount of global state and extremely strong ordering. At some (very early) point it stops making sense to just increase the size of the register file. The dirty secret of OOO execution is how very in-order it really is.

2. instruction decoding is obscenely complex, so every instruction decoder ends up being a deep variable length pipeline of nightmares. The most common instructions have to be decoded in fewer stages than less common ones, but you also need to take into account what you can issue more of concurrently. It's a mess, and it's once again because it has to be compatible with half a century of development by accretion. You stand no chance of reusing instruction decoders across reworks of anything, because it's all so intensely interdependent that everything ends up being a ground-up rewrite.

Add to that that most advancements in single-core performance is still down to changing restrictions of fab processes...

What you (wrongly) call an internal RISC machine is nothing of the sort. It's extremely CISC on the inside as well. Just because it kinda-sorta re-encodes instruction to a wide set of internal signals doesn't mean it in any way resembles anything you could conceivably call RISC. The way they actually become fast is by being about as non-RISC and doing as much speculative execution as possible.

In fact, conventional VLIW processors resemble RISC much more internally that amd64 machines do, and they still look nothing like a RISC machine and more like DSPs.

The actual amount of instructions is in no way a problem. Just look at other VLIW machines. They will usually have humongous list of instructions. Some of them very CISC and difficult to execute. The difference is that they're properly structured to require as little decoding as possible so you can issue 10s of them in a single cycle.

>>1027243

He's probably focused on the AMD K5 for this internal RISC thing. Don't know if it's still correct for modern CPUs, though.

>>1027087

Everything that hates unix and loves rust sucks nigger dick on a regular basis.

>>1027087

finally, someone who has at least some understanding of the matter at hand

What a shitty language.

>>1026667

It's not live action, stop perpetuating this shit meme. Just say RPing or roleplaying.

>>1027513

It is live action.

https://www.merriam-webster.com/dictionary/live

https://www.merriam-webster.com/dictionary/action

>>1027513

It's live action because this RP isn't happening in story form but rather by actions in real life.

>>1027569

you're wrong

anti saged btw

>>1027581

>he got mad because his thread got bumplocked so he tries to bumplock this one as well

Stay mad 0.36%. Nobody cares about you.

>>1027584

I'm not mad at all. My thread was up long enough. It served its purpose.

>Nobody cares about you.

He says while (You)ing me. Thx <3

>>1027587

>It served its purpose.

sudo apt-get remove rust* libstd-rust* cargo*

sudo apt-get remove snapd* libsnapd*

>>1027592

I use Arch GNU/Linux

>>1027592

Don't forget to sudo ln -s /bin/rm /usr/bin/rust

>>1027592

https://www.cvedetails.com/vulnerability-list/vendor_id-23/product_id-17236/Debian-APT.html

>>1027696

https://www.cvedetails.com/vulnerability-list/vendor_id-15714/product_id-32625/Sudo-Project-Sudo.html

OH NoNOnoNONo.... OHOHH NOOOONOONONO.... BAHAHAHAHAHHAHAHAHAHAHAHAHAHAHAHAHAHAAHA

Someone forked my repo <3

https://github.com/MikeeUSA2/GPC-Slots-2/

My version of GPC-Slots 2 is more popular than Mikee's. ebin

>>1027840

wrong thread srz

>>1027848

>What's your argument here? I'm struggling to see even a semblance of one.

>Oh shit, he got me here. I better use my "not an argument" card to deny the facts.

>>1027853

>>Oh shit, he got me here. I better use my "not an argument" card to deny the facts.

BAZINGA

No seriously. You just quoted a few sentences from an article about a bug in Rust's VecDeque implementation.

What is your point?

>>1027854

>What is your point?

There was a buffer overflow bug in the standard library’s implementation of a double-ended queue, but rust developers didn't file a CVE. It was added only after writer submitted it himself, so basically people were running vulnerable versions of Rust without knowing about it.

>inb4 but muh latest version

Well people don't update often and that version was still in debian's repos. It makes me wonder how many more unreported security issues are there?

So what has this to do with >>1027834 ? You posted some CVEs from two random programs as an argument against removing Rust.

<What is your point?

>Safe Rust is the true Rust programming language. If all you do is write Safe Rust, you will never have to worry about type-safety or memory-safety. You will never endure a dangling pointer, a use-after-free, or any other kind of Undefined Behavior.

>The standard library also gives you enough utilities out of the box that you'll be able to write high-performance applications and libraries in pure idiomatic Safe Rust.

>finds out that "high-performance applications and libraries in pure idiomatic Safe Rust" is bullshit and needs unsafe to not be slow as ass

OH NoNOnoNONo.... OHOHH NOOOONOONONO....

>https://rustsec.org/advisories/

>RUSTSEC-2018-0009: crossbeam: MsQueue and SegQueue suffer from double-free

>RUSTSEC-2018-0007: trust-dns-proto: Stack overflow when parsing malicious DNS packet

>RUSTSEC-2018-0003: smallvec: Possible double free during unwinding in SmallVec::insert_many

>RUSTSEC-2018-0010: openssl: Use after free in CMS Signing

>RUSTSEC-2017-0004: base64: Integer overflow leads to heap-based buffer overflow in encode_config_buf

BAHAHAHAHAHHAHAHAHAHAHAHAHAHAHAHAHAHAAHA

>>1027863

>so basically people were running vulnerable versions of Rust without knowing about it.

Everything written in C/C++ is vulnerable by default. What is your point?

>Well people don't update often and that version was still in debian's repos.

If you don't update you won't get fixes.

>It makes me wonder how many more unreported security issues are there?

C/C++

>You posted some CVEs from two random programs as an argument against removing Rust.

>argument

no. I replied to two shitposts with my own shitpost.

>>1027867

>no. I replied to two shitposts with my own shitpost.

To which I replied with yet another shitpost. This whole thread is just shitposting.

>>1027867

int main(void)
{
    return 0;
}

Where is the vulnerability?

>>1027879

agreed

>>1027880

In the compiler

https://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-960/GNU-GCC.html

https://www.cvedetails.com/vulnerability-list/vendor_id-13260/product_id-27514/Llvm-Clang.html

>>1027592

>he thinks removing the rust compiler removes compiled rust code

Peak LARPing.

>>1027883

>LARPing

>live action

REEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE

THIS ISN'T LIVE ACTION

you're right though

>>1027883

Oh I find them and remove them too.

>>1027863

>OH NoNOnoNONo.... OHOHH NOOOONOONONO....BAHAHAHAHAHHAHAHAHAHAHAHAHAHAHAHAHAHAAHA

What the fuck?

>>1027887

>What the fuck?

CVEs are funny

Look at this dood.

>>1027887

>>1027884

>he's not the star of his own live action shitposting show

>>1027087

>Do Rust compilers delete null pointer checks and change the meaning of code it assumes to be "unreachable" because of "time travel" bullshit that has no relation to any physically possible or hypothetical machine? C compilers do.

Crazy C compiler optimizers are indeed fucked up and I constantly criticize the compilers for that. However that's an issue of implementation, not language.

>>1027087

>It's mostly smart people who know C inside and out who hate C. C weenies think they know C but actually don't, which is why they can't understand all the bullshit in the standard. They learned what someone else thinks C is from books instead of learning the real language.

I do hate C but I hate every other language even more. What I hate most though is how every single language imports the entire C world into it. Because of this I've been working on freestanding programs that talk directly to Linux instead of using libraries.

I absolutely hate the C standard library. Freestanding C is a much better language just because there's no standard library in it. What I like most about C is how it generates the code I want. It compiles down to the assembly I expect, especially when using -Os.

My long term goal is to make my own programming language with no dependencies and no external libraries, not even libc. And then write everything in it.

>>1028368

Well I started liking programming a lot more after I dumped the library bullshit.

>>1028332

>programming language with no dependencies and no external libraries, not even libc. And then write everything in it.

Forth.

Zig although the compiler has dependencies the size of a planet.

But just use Ada.

>>1028494

http://vst.cs.princeton.edu/download/VC.pdf

>let's look at a simple function that gets the sum of an array

unsigned sumarray(unsigned a[], int n) {
  int i; unsigned s;
  i=0;
  s=0;
  while (i<n) {
    s+=a[i];
    i++;
  }
  return s;
}

>to verify this, we need to write a "verifiable C API"

DECLARE _sumarray
  WITH a: val, sh : share, contents : list Z, size: Z
  PRE [ _a OF (tptr tuint), _n OF tint ]
    PROP(readableshare sh;
    0 ≤ size ≤ Int.maxsigned;
    Forall (fun x ⇒ 0 ≤ x ≤ Int.max_unsigned) contents)
    LOCAL(temp _a a; temp _n (Vint (Int.repr size)))
    SEP(data_at sh (tarray tuint size) (map Vint (map Int.repr contents)) a)
  POST [ tuint ]
    PROP()
    LOCAL(temp rettemp (Vint (Int.repr (sum_Z contents))))
    SEP(data_at sh (tarray tuint size) (map Vint (map Int.repr contents)) a).

>>1028494

>>1028637

fucking LOL

>>1028637

>emulating for with while

how about

for (i = 0, s = 0; i < n; ++i) {
    s += a[i];
}

>>1028648

how about

array.iter().sum()

instead?

https://play.rust-lang.org/?gist=7c2ea621441055ba3cc473bcba196e21

>>1028648

Both while and for are synctactic sugar and social constructs, if and goto oughtta be enough for anybody.

i = 0;
s = 0;
hurrdurr:
if (i < n) {
    s += a[i];
    ++i;
}
goto hurrdurr;

>>1028653

goto statement should be still inside the if clause obviously, otherwise it's just going to loop forever

>>1028655

>unironically literally never using goto ever because of a retarded arbitrary principle

>>1028650

>that POO notation

Absolutely disgusting. Take the worst of Ruby and Perl to get Rust.

It's so shit, they have to put up advertising in the metro to try to convince you to program in it.

t. German

>>1028665

I have never seen Rust advertisements in a German metro. The only IT related advertisements I see are from retarus.com and honeypot.io.

t. German that uses the metro every work day

>>1028494

>>1028637

>write C, prove its correct, move on

>write C and move on

No it isn't a write C and move on soln, it's a write C, prove it, and move on soln.

The specs are in shit syntax because the whole thing is an EDSL in Coq. Contrast with Mozilla, who spends a fortune building tools for the not-safe-but-lets-say-it-is Rust.

But of course, you didn't mean to imply that Rust is a "write and move on" language. Or you did and have just never tried programming in it.

>>1028669

>reddit spacing

>>1028669

>The specs are in shit syntax

Not just that. It's a whole separate shit language that must be learned and understood.

In practice this is going to be "write C, wait for the one guy to prove it, and then keep asking him to update his proofs until he throws a fit and demands you make sure shit's settled before giving it to him, then--", or maybe "spend two years writing a NASA spec, then get the guy to prove it over the course of ten years, then write the C, and finally discover that the spec is buggy". Or "write tons of unverified C, and occasionally interact with some verified interfaces".

>Rust

doesn't put proving of any kind in the hands of the programmer, so it's irrelevant. What I was expecting was something more like ATS, where your code is understood by both the compiler and the proofer, and where theorem-proving mostly resembles prolog, and where you get a lot of verification without writing any theorems at all.

ATS sets a pretty low bar for "easy and approachable and not verbose", but verifiable C stumbles over the bar.

A nicer example is SPARK: https://www.cse.msu.edu/~cse814/Lectures/09_spark_intro.pdf

where you eventually get into WhyML: https://www.adacore.com/uploads/techPapers/f-ide.pdf

but again the typical experience is writing only Ada and then moving on. Yeah there's a "prove it" step there, but it mostly doesn't involve writing lots of code in a Coq EDSL.

>>1028637

How do I get started with this? Can I prove things about side effects and operating system interactions or just my own C code?

>>1028481

Forth and early Lisps are indeed great inspirations for me.

>zig

Wow I had no idea this existed. I'm checking out its design now.

Compiler complexity is of partial importance. I believe every language should have an minimal C implementation for reference and a self-hosted compiler that optimizes and everything.

>ada

Don't know enough about it to post an opinion, but they say its highly reliable. I've read articles about static memory allocation with Ada and it convinced me of the value of static allocation. We figure out how much memory we need and get that from the operating system when it loads the program into memory -- can't fail and it's just there when you need it. In fact, I incorporated this idea into my language: early bootstrapping code gets a finite amount of statically allocated memory to work with and bootstrap itself until it can make system calls and request more memory.

>>1027109

>Now remind me how your precious Lisp needing a fuckhuge garbage collector to be performant isn't a problem.

A garbage collector is a few thousand lines of code on x86, shared across all programs on the machine. On a Lisp machine most of that is done with tagged memory, so it would be even smaller.

>>1027164

>Firstly, in what universe has a Lisp machine ever come close to modern *nix in usability?

For one thing, Lisp machines are actually usable. I guess that's another instance of the "70% is good enough" rule.

>>1028331

>However that's an issue of implementation, not language.

No, it's an issue of the language because all C programs have to deal with that bullshit. Compilers are implementing the language to specification.

>>1028332

>I do hate C but I hate every other language even more.

I'm assuming you meant to write "UNIX" in front of "language." There are literally thousands of programming languages out there and "doesn't use curly braces" is a shitty reason to hate a language.

>>1028494

The problem with "Verifiable C" is that it's still C. It still sucks. Even if there was no undefined behavior, C would still suck. Fortran was able to improve over the years and run on a variety of machines because of simple and well-defined semantics, but C can't. C is so bad that it prevents 60 years of CS research from being used. The ISO committee spent the last 7 years fixing bugs in the C standard and they didn't even fix any misdesigns or flaws, just mistakes in the definition of C.

>>1028637

All that bullshit is because C has no arrays. What really sucks is that after all that bullshit, they're still broken C "arrays" with array decay and no useful features like slicing or vector operations.

https://rosettacode.org/wiki/Sum_and_product_of_an_array

>>1028733

>Compiler complexity is of partial importance. I believe every language should have an minimal C implementation for reference

Anything with binary I/O can be used to write a compiler, so you want to use a good language that makes the hard parts easier. Using C would take more work to produce an inferior, buggier compiler. Even C compilers are written in C++ nowadays.

Subject: Re: Bill Joy Golden Shower

    Signed by UNIX pioneer and Sun cofounder, Bill Joy, the gold CD
    encapsulates 32-bit power, industry-standard networking, a robust
                 ^^^^^^

That would be about eight bucks.  It will buy you enough gas
to get you far enough away from the nearest weenie power
machine to not have your brain ruined again.

>>1026695

>C/C++ is safe if you use -Wall -pedantic

LOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOL

>>1028780

You're right

>>1028781

based

>>1028781

>The problem with "Verifiable C" is that it's still C. It still sucks. Even if there was no undefined behavior, C would still suck. Fortran was able to improve over the years and run on a variety of machines because of simple and well-defined semantics, but C can't. C is so bad that it prevents 60 years of CS research from being used. The ISO committee spent the last 7 years fixing bugs in the C standard and they didn't even fix any misdesigns or flaws, just mistakes in the definition of C.

Can you imagine being so assblasted that LISP was a failure that you have to rely upon spouting opinion as fact in the meager hopes of confusing someone to waste their life so you will feel better about yours?

Dude, your life sucks because you made poor choices. Get over it.

>>1028785

>cnile has been so completely BTFO that he has to fall back on insults

C/C++ is trash. That's a fact!

It's a logic error.

>>1027087

>>1028781

A majority of the complaints found in these blockquotes seem to have to do with specific quirks that existed on the old UNIX systems used at the time of writing, and more than likely do not apply to modern implementations.

However, some of these quotes don't make sense even within the context of the book's publication date of 1994.

>The lesson I just learned is: When developing with Make on 2 different machines, make sure their clocks do not differ by more than one minute.

The Network Time Protocol, otherwise known as NTP, has existed in some form since at least 1985: 9 years before the book. In fact, NTPv3 was out 2 years before publication, so it had already had multiple revisions.

>The big ones are grep(1) and sort(1). Their "silent truncation" have introduced the most heinous of subtle bugs in shell script database programs.

SQL has existed since 1974: 20 years before the book, and the first commercially available RDBMS, Oracle, was released in 1979. Judging from https://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems there have been 25+, maybe even 30+ relational database programs that existed prior to the publishing of the Unix Haters Handbook.

>Raise your hand if you remember when file systems had version numbers.

you mean like ext2 (1 year before publishing), ext3, and ext4?

To be a bit more serious though, yes it is true that Unix and Unix-like operating systems don't have separate version numbers for the filesystems, preferring to tie them to kernel versions. Why is this a problem again? Because it's not how Multics or whatever used to do it? This isn't even a monolithic vs. microkernel argument, as even the microkernel OSes don't seem to bother putting version numbers for filesystems. And why should they?

>>1028802

>version numbers

The quote is talking about filesystems which automatically backup and version previous revisions of files every time they're changed. Unix has those too, but for most uses they're overkill and a massive waste of disk space.

>>1028792

Again, you are spouting your opinion off like anyone should believe you.

Who the fuck are you, and why should we care what the fuck you think?

>>1028806

Kill yourself, LARPer

>>1028781

>A garbage collector is a few thousand lines of code on x86, shared across all programs on the machine. On a Lisp machine most of that is done with tagged memory, so it would be even smaller.

You forgot the "performant" part. And even if do fix this problem, dynamic typing retardation will get you; just gaze into the abyss known as "optimized CLisp (with type annotation)" to go mad instantaneously.

>>1028781

>There are literally thousands of programming languages out there and "doesn't use curly braces" is a shitty reason to hate a language.

I know a metric fuckton of languages. I object to something in literally every single one of them. Even CL and Scheme. Especially Scheme. It's 90% perfect, you have no idea how disappointed I was when I discovered its flaws. The biggest flaw is the lack of a good module system. That single unfeature doomed Scheme from day one.

>Anything with binary I/O can be used to write a compiler,

Well I agree. Every language should be able to perform system calls. I'm building my language around that concept. Also it's not like there's any other kind of I/O to begin with. Opening things in "text mode" is some insane libc thing that I was happy to get rid of.

>Using C would take more work to produce an inferior, buggier compiler. Even C compilers are written in C++ nowadays.

The point is to write the smallest possible compiler in C. It's allowed to be bad and slow as fuck. The better compiler can be written in the new language itself.

The point of having a compiler/interpreter written in C is to take advantage of its ubiquitousness. Even if there's no bootstrapped language compiler, that C implementation can be used. There is no need to complicate the whole thing. Just a garbage collector, an evaluator, built-in bootstrapping code, and so on.

>>1028842

>a garbage collector

if your doing a minimal implementation, why include unnecessary things?

>>1028810

You first you piece of shit.

Look at how assblasted you are because you got called out on using _opinion_ as _facts_.

Yo, fuck you. I hope you rot in hell when you die you fucking lying ass good for nothing waste of life.

>>1028843

Because my language uses one. Writing a mark and sweep GC is really simple and there is no need to go full autist with multithreaded concurrent real time generational GC shit

During bootstrapping, the language's GC only has a fininte amount of static memory at its disposal. There's an evaluator and it runs pre-compiled code that gets linked into the binary. This code runs in this memory constrained environment and contains system call code for open and read which it uses to load in even more code for other system calls, module system, memory management and other language features. The bootstrapping code is in the memory cells managed by the GC and it just gets replaced by new loaded code at the end of the bootstrapping process. In order to allocate memory, the GC calls a language function with the amount of memory it wants and uses the retuned pointer as the memory block. I can implement the memory allocator from inside the language. Currently it just mmaps the requested amount of memory.

>>1028802

<a-at the time a s-s-solution exists

That must make you wonder why the U-weenie system administrators did not use those solutions. What gets into a UNIX weenies brain such that he uses text files instead of a proper solution.

>you mean like ext2 (1 year before publishing), ext3, and ext4?

Retard, he means that instead of being like a cassette tape where you are always writing over the actual file losing the data you had previously, you have different versions. This way if you make mistakes you can just roll the file back a version instead of hoping you can somehow recover it.

>>1028842

>Also it's not like there's any other kind of I/O to begin with

Forcing your IO to work with 1's and 0's is a poor decision. Idealy it should be able to handle reading and writing more complex data structures. Too bad most operating systems now a days are too retarded and just decide to always have the developer handle that. Even though when you have developers handle parsing files they do it wrong and cause RCE vulnerabilities.

>The point is to write the smallest possible compiler in C

You are going to have a bad time writing a compiler in C.

>>1027087

I think I've learned more about programming from the Lisp Anon critiquing C then anywhere else

>>1028936

surely you could've learned a lot more by studying all the Lisp in the AoC threads, or all the lisp in the "let's write an editor in lisp" threads.

>>1028846

write more, LARPer

>>1028898

based

>>1028938

>LISP fags can't write a text editor XDDDDD

Where is yours, Cniles? You are LARPers too.

>>1028856

>Because my language uses one

Then your language is bad, unless it is made to be used with a real low level language.

>>1029007

>hurr durr GC bad

spotted the LARPer

>>1028898

>Idealy it should be able to handle reading and writing more complex data structures.

Data structures are always encoded as 1s and 0s. Structured I/O is an insufficiently general solution to this problem.

>Even though when you have developers handle parsing files they do it wrong and cause RCE vulnerabilities.

There's lots of factors at play here.

First of all, tools for parsing are complete garbage. Nearly all dynamic languages have regular language parsers but anything above that is non existent or so fucking complicated nobody but programming language people ever bother to do it. Because of this while some protocol or format might even have an RFC with spelled out grammar and everything people will just create shitty ad hoc parsers instead.

Second, most binary file formats are impossible to parse safely. Even something straight forward like a size parameter makes the grammar not only context sensitive but also self-modifying. It's impossible to parse these things without ceding control of the parsing machine to an attacker. Size parameter in particular cedes control of your parser program's memory allocation functions to attackers.

Third, having structured I/O would simply move this layer to the operating system. It wouldn't fix the shitty file formats, just make the privileged kernel deal with them instead. That's a fucked idea. You do not want parsers in the kernel. If that's inevitable, you want as little parsing in the kernel as humanly possible. Majority of security holes happen in these input handling layers and we really don't need people exploiting them and getting into kernel space.

It's an unfixable mess.

>You are going to have a bad time writing a compiler in C.

I wrote a simple interpreter in C. The more complex compiler can be hosted by the actual language

>>1029007

My garbage collected lisp-ish language supports pointers and has access to the entire Linux system call library. I can allocate memory manually.

I'm currently trying to write a JIT compiler that can generate code for any calling convention. This way I can mmap in libraries, parse their symbol tables, obtain a link to their functions and call them with help from the JIT. It should also be able to generate system call code.

>>1029009

>massive source complexity and runtime/memory usage increase with unpredictable pauses good

>just put the bloat in the hardware, bro

>the only non GC strategy is malloc

>>1029021

Why don't you look at Carp lang?

>>1029036

>>massive source complexity and runtime/memory usage increase with unpredictable pauses good

>every single program must be written to be as efficient as possible

LARP

like this right?

https://n3t.host/mumble.html

>>1029036

I don't like carp.

>>1029142

Any reason? I'm not a Lisp user but became interested in it after adopting TCL.

Is there any real reason to use Rust?

>>1029219

Unless you want to edit Firefox's source code or make offensive video games to upset Rustniggers, not really.

>>1029209

It doesn't do things the way I want them done. Let's leave it at that. I like the idea of a statically typed, or optionally typed Lisp though.

rustfags know a lot of right things about whats wrong with C++

their solutions are making things worse thou and are like babys first solution to problem, utterly unusable in production environment

C++ always stays around because in the end, its less of a problem to deal with it than try to deal with another language that has different (often worse) set of problems

>>1026649 (OP)

why did firefox switch to this meme? theres still multiple vulnerabilities fixed in every release of it

>>1029592

Joogle. EMP yourself already for Christ

>>1029595

>just Google search anon

>so that you can find the official answer

>move over Aristotle, today we know that truth = wikipedia quoting a company employee about

a company thing

>>1029732

bulk of those things you do once, not everytime, thats why you reuse code

>>1029735

>C/C++

>reusing code

Nobody does this.

>>1029737

only rustfag would believe this

>>1029741

only a LARPer would defend C/C++

>>1029043

unpredictable pauses make GCs a pain to use for anything that's slightly close to realtime

>>1029749

Thanks Captain Obvious. Now tell me, how many programs are actually slightly close to realtime?

>>1029750

Any audio output, even a few millliseconds of pause will be noticeable if repeated frequently enough.

Any video output, all it takes is a dozen or so milliseconds to skip a frame at 60hz.

Any networked program that stays in sync thanks to determinism, depending on the cases they can not desync even with seconds of pause or they can desync with a tenth of a second of pause.

>>1029751

So the majority of programs aren't slightly close to realtime.

What's the problem with GC again?

>>1029754

day majority of programs and programmers start using it for good reasons is the day your posturing becomes relevant

>>1029755

>I'm a LARPer

yes you are

>>1029754

>So the majority of programs aren't slightly close to realtime.

By program count, sure.

By user time, no.

Your desktop manager needs to be realtime, your media players need to be realtime, every single program making use of a media player need to be realtime along those paths...

Let's not even talk about games.

>>1029757

>moving goalposts

LARP

>>1029759

>defining goals while ignoring user experience

LARP

>>1026654

>compile time

They say compile time all the time, because they assume the things that need (if they actually needed) to be checked at runtime are checked by everyone else.

>>1029754

A program that uses garbage collection as is intended doesn't run 10% slower, it doesn't even run 200% slower. Several orders of magnitude of performance and electricity are lost on this childish bullshit because "leaks are so scary" except It's just a fucking error.

"Oh I have a leak" then you search for the leak, and solve it. Done, there is no more leak. If your code didn't look like an unbearable tangle of OOP "modern" sugary vomit then perhaps finding the leak wouldn't be so hard.

>>1029782

>"Oh I have a leak" then you search for the leak, and solve it. Done, there is no more leak. If your code didn't look like an unbearable tangle of OOP "modern" sugary vomit then perhaps finding the leak wouldn't be so hard.

https://www.cvedetails.com/vulnerability-search.php?f=1&vendor=&product=&cveid=&msid=&bidno=&cweid=&cvssscoremin=&cvssscoremax=&psy=&psm=&pey=&pem=&usy=&usm=&uey=&uem=&opmemc=1&opov=1

>>1029783

>Errors exists, so I'll keep having all kinds of errors, except one kind I don't like for some reason and have 1000% less performance

I wonder how much performance would you be willing to lose to have no errors by default.

>>1029784

>1000% less performance

stop LARPing

>>1029785

stop pretending you don't enjoy when your games load alll kinds of shit on screen and it goes smoothly faggot.

You can pretend it doesn't matter all you want, but all games running on GC languages either deactivate GC if possible or do retarded juggling to skip the GC. (though there aren't many games on GC languages, who knows why =^)

It doesn't work, it's uncomfortable, stands in the way and you'll still have to fill the memory in the same fashion as you would have in non garbage enabled language.

>>1029782

Congratulations, you managed to write something dumber than the post you were replying to.

>>1029788

>muh games

I'm not talking about games. Stop LARPing

>>1029791

It doesn't matter. Your web server is more expensive because of your code. And when it fails is harder to fix because your fancy abstractions aren't actually scalable, future proof, safer nor faster to implement. The "implementation time" you're trying to save is wasted in the additional programers that are needed to mantain your rotting codebase and the endless daily meetings to make sure everyone is up to date with the current architecture.

All this effort introduces walls between you and your data that you have to hop over every time something needs to be changed. And the more idiots like you are involved in the process, the more walls are added, because your code is not special and no one wants to read it each time, so they will add another abstraction in place that nobody will want to read either but will have to be mantained either way.

You're not elegant, and what you like is the code equivalent of adding holes into a balloon to blow more air into it.

>>1029793

>It doesn't matter. Your web server is more expensive because of your code. And when it fails is harder to fix because your fancy abstractions aren't actually scalable, future proof, safer nor faster to implement. The "implementation time" you're trying to save is wasted in the additional programers that are needed to mantain your rotting codebase and the endless daily meetings to make sure everyone is up to date with the current architecture.

https://www.cvedetails.com/vulnerability-search.php?f=1&vendor=&product=&cveid=&msid=&bidno=&cweid=&cvssscoremin=&cvssscoremax=&psy=&psm=&pey=&pem=&usy=&usm=&uey=&uem=&opmemc=1&opov=1

>All this effort introduces walls between you and your data that you have to hop over every time something needs to be changed. And the more idiots like you are involved in the process, the more walls are added, because your code is not special and no one wants to read it each time, so they will add another abstraction in place that nobody will want to read either but will have to be mantained either way.

https://www.cvedetails.com/vulnerability-search.php?f=1&vendor=&product=&cveid=&msid=&bidno=&cweid=&cvssscoremin=&cvssscoremax=&psy=&psm=&pey=&pem=&usy=&usm=&uey=&uem=&opmemc=1&opov=1

>You're not elegant, and what you like is the code equivalent of adding holes into a balloon to blow more air into it.

https://www.cvedetails.com/vulnerability-search.php?f=1&vendor=&product=&cveid=&msid=&bidno=&cweid=&cvssscoremin=&cvssscoremax=&psy=&psm=&pey=&pem=&usy=&usm=&uey=&uem=&opmemc=1&opov=1

You're the LARPest of all LARPers I have seen so far on /tech/. Congratulations.

>>1029791

>please do not talk about the gigantic software industry in which my solution is of questionable value

How about no?

>>1029754

>So the majority of programs aren't slightly close to realtime.

Any program that presents any kind of user interface is soft real time at the very least. This includes stuff like video games. Quality will decrease if your deadlines are missed and will result in perceptible latency.

If your language can't be used for real time programming, it's pretty much a non-language. This is the ultimate reason why software gets shittier and shittier even though hardware gets faster and faster.

>>1029796

>>1029783

>citing CVEs is arguments now

Please!

Want to know the ULTIMATE root cause of all security vulnerabilities today? The notion that computers must be able to talk to any random ass stranger that approaches them. People literally get a computer, make it accessible to the entire internet and program it to answer to HTTP requests from any random fuck that connects to it just so they can shitpost at other randoms. What the fuck is up with this shit?

Lock that shit down with single packet authorization and its like the computer doesn't even exist on the network. It reveals itself to you and only you and only after you send a cryptographically signed packet to it. Fuck other people.

>>1029955

If you hate communicating with other people over computers so much, then why don't you fuck off of 8ch? You won't because your a faggot. My shitty rant is going to appear on you computer, and the only reason it won't hack you is because the network, os, and browser devs weren't niggers.

>>1029955

SPA will never take off because the CIA niggers have infiltrated every single OS used by over 1K people. They'd never allow it

>>1026649 (OP)

absolut'd

>rustfag has completely derailed this thread

good job tbh

>>1026669

>isn't it better to fix existing systems than reinvent everything with all the mistakes from the past?

instead of cars, we shouldve just made faster horses, am I right? no

>>1030069

>using boomer analogies

>doesn't know what the word reinvent means

I bet you think hyperloop is a good idea too.

>>1030066

>use after free

How retarded must you be to get one? I've been using C for 5 years now and I never did this.

>>1030075

>LARPing

>>1030076

>LARPing whilist calling the other LARPer

Python, C, C++ are better than Rust.

>>1029978

The point is real security is built with a network of trust. How hard is that to understand? Don't let people you don't trust have access to your computer and you will never have issues. Anything else is already compromised. This site is compromised because whatever host is serving these pages has physical access to it.

Obviously this means getting rid of mass shitposting sites like chans and social media. Make a private place for you and your friends instead. Then your friends will invite over people who they trust, who invite others who they trust, and so on. And if anyone fucks with your computer, you kick them out. They can't ever come back without the keys.

>>1029981

It works on Linux and I'm using it. I have my home computers accessible over internet. Zero faggy bots knocking on my door.

>>1039198 Python is best. C++ is second. C is third. Rust is worst!

>>1030478

>If you want systems programmers to be as retarded and braindead and frontend JavaScript hipsters then Rust rewriting everything in Rust is great. But Rust assumes people are too retarded to write good code

This is how I know you have never touched Rust. Writing efficient Rust is extremely complicated, and requires you to rethink a lot of otherwise simple data structures due to its batshit insane typing system. Types made of at least five nested generic types are commonplace, and changing one of those because you forgot to add a property is all shits and giggles.

It's the total polar opposite of JS, so I don't get why everyone is comparing them. I guess because Pajeet soyboy memes or something.

>>1030478

Javascript and Rust are nothing alike, ever seen the borrow checker?

>>1030511

>batshit insane typing system

This is why everyone hates static typing and why nobody wants to use it

>>1030524

>everyone hates static typing

Millions of webshit retards maybe.

>>1030524

Static typing is nice. Fuck, modular property-based types expand my fucking dong. Not Rust's, though. Who thought it was a good idea to compose types by nesting them?

>>1030524

Static typing is nice. Fuck, modular property-based types expand my fucking dong. Not Rust's, though. Who thought it was a good idea to compose types by nesting them? Makes sense logically, but fuck if it is unusable.

>>1030556

>I'm an OOP nigger

lol

>>1030558

What?

>>1026649 (OP)

biggest vulnerability of rust will allways be that it was made with pajeets and niggers in mind.

>>1030559

>Who thought it was a good idea to compose types by nesting them?

OOP nigger

>>1030562

OOP uses inheritance instead of composition. Nevermind Rust's nesting is not the same as OOP nesting/composition

>>1030563

>throwing around buzzwords

What the fuck are you even trying to say?

>>1030564

>the larper is getting confused

Why not google them and then pretend you knew them all along?

>>1030568

>implying his meaningless technobabble means anything

LARP

>>1030569

>>1030568

>>1030564

>>1030563

>>1030562

>>1030560

>>1030559

>>1030558

you morons.

what >>1030556 is failing to say is that he doesn't like ML type constructors. He probably likes them OK in the context of a "give me a list(string) and an array(int)"; he's probably just annoyed with having to "unwrap" shit all the time - aka overuse of optionals - aka Rust's style of error handling.

People complain about the exact same shit without ML type constructors in Go, when they complain about the repetitive "err" handling.

So you're talking about OOP and googling OOP terms, which is the worst thing to ever do, in response to a "man I wish I just had fucking exceptions" whine, from someone who thinks he's complaining about ML, which is an impossibility: ML is perfect.

>>1030603

>quoting random posts

>throwing around even more buzzwords

>man I wish I just had fucking exceptions

top LARP

>>1030606

>even more buzzwords

list them.

>>1030612

alright I'll list them for you

>ML

Robin Milner's programming language, c.f. Standard ML, OCaml.

Bad languages like Haskell and Rust put copious amounts of ML in their language so that you can't taste the poison, and so that people who aren't familiar with ML will gasp and say "wow! What a cool new flavor!"

it's the name of a programming language. It's also not a buzzword.

>ML type constructors

when your thought is "give me a list of strings" and then you work with some syntax like list(strings) or "string list".

this is intuitive. It's not a buzzword. You just don't know jack about jack.

>...

what else?

"err"?

Go?

exceptions?

There's not a single buzzword in my post. It's a bunch of precise technical terms (and OOP) that you should know.

>>applauding and promoting shitposters instead of discussion and debate

pathetic

>>1030622

Are you Mikee?

>>1030652

yes I am also Mikee.

You can take that knowledge to the bank!

>>1030603

The real truth is NOBODY WANTS TO FUCKING HANDLE ERRORS! They want their code to be clean and easy to write and read. Of course this means not dealing with 15 possible error conditions that are documented as possible results of whatever functions you're using. If you make your language force programmers to even acknowledge the existence of errors, they will resent your language and probably just subvert your shitty error system somehow.

>>1030654

yeah. or in other words, "man I wish I just had fucking exceptions"

>>1030654

>webshits don't want to deal with errors

Rust has you covered: https://play.rust-lang.org/?gist=e249386df41f35193621046d830e57dd

>>1029955

>Lock that shit down with single packet authorization and its like the computer doesn't even exist on the network. It reveals itself to you and only you and only after you send a cryptographically signed packet to it.

That's a great way to make spying on broadcasters easier.

>>1030663

>man I hate Lisp's syntax

<here's an Emacs mode that makes the parens invisible

>... and?

<the parens are gone! You no longer have to hate Lisp! Lisp has got you covered!

ok now take the parens from all the documenation, code pastes, other people's editors, code output outside of Emacs

and take Rust's actual practiced error handling out of all the code I'll ever deal with

>>1030665

?

>>1030663

>Ok()

God what a shitty language

>>1030666

What are you even trying to say? I produced an example showing that if you don't want to handle the bazillion different kinds of error a single function call can emit you don't have to.

wasted trips. how disappointing

>>1030671

hey have you heard that you don't have to have braces in C? Look man:

#define begin {
#define end }

wow! I write all my C with those and it's great. What do you think about that?

>>1030672

I thinks that's awesome. Even more awesome is that I can just dereference a random null pointer and the compiler will fuck my shit up. So fast!!!!!!!11

>>1030672

I think you should kill yourself

>>1030673

Is this thread nothing but shitposting now

>>1030675

Have you even read the OP before posting?

>>1030674

OK, great.

Now what do you think about >>1030663 as a serious way to write Rust programs?

6.5.17 Comma operator

Syntax

1

          expression:
                 assignment-expression
                 expression , assignment-expression

Semantics

2 The left operand of a comma operator is evaluated as a void expression; there is a sequence point after its evaluation. Then the right operand is evaluated; the result has its type and value.97) If an attempt is made to modify the result of a comma operator or to access it after the next sequence point, the behavior is undefined.

3 EXAMPLE As indicated by the syntax, the comma operator (as described in this subclause) cannot appear in contexts where a comma is used to separate items in a list (such as arguments to functions or lists of initializers). On the other hand, it can be used within a parenthesized expression or within the second expression of a conditional operator in such contexts. In the function call

          f(a, (t=3, t+2), c)

the function has three arguments, the second of which has the value 5. 

OH NoNOnoNONo.... OHOHH NOOOONOONONO.... BAHAHAHAHAHHAHAHAHAHAHAHAHAHAHAHAHAHAAHA

>>1030677

>>1030677

It's about as retarded as the catch(Exception e) {} faggots

>>1030678

What is your point?

>>1030690

"I read the term 'comma operator in this thread, didn't know what that meant, and then looked it up. Holy shit, this is a dumb feature that must be exclusively used by obfuscating twats."

>>1030695

>comma operator

>obfuscation

It's painfully clear what it does. It's even more clear if you're familiar with languages that don't distinguish statements and expressions. This is literally what people mean when they say C programmers should just be better. If you can't fucking understand a fucking comma operator, I doubt you can keep your malloc and free balanced.

The behavior is undefined in the following circumstances:

A shall or shall not requirement that appears outside of a constraint is violated (clause 4).

A nonempty source file does not end in a new-line character which is not immediately preceded by a backslash character or ends in a partial preprocessing token or comment (5.1.1.2).

Token concatenation produces a character sequence matching the syntax of a universal character name (5.1.1.2).

A program in a hosted environment does not define a function named main using one of the specified forms (5.1.2.2.1).

A character not in the basic source character set is encountered in a source file, except in an identifier, a character constant, a string literal, a header name, a comment, or a preprocessing token that is never converted to a token (5.2.1).

An identifier, comment, string literal, character constant, or header name contains an invalid multibyte character or does not begin and end in the initial shift state (5.2.1.2).

The same identifier has both internal and external linkage in the same translation unit (6.2.2).

An object is referred to outside of its lifetime (6.2.4).

The value of a pointer to an object whose lifetime has ended is used (6.2.4).

The value of an object with automatic storage duration is used while it is indeterminate (6.2.4, 6.7.8, 6.8).

A trap representation is read by an lvalue expression that does not have character type (6.2.6.1).

A trap representation is produced by a side effect that modifies any part of the object using an lvalue expression that does not have character type (6.2.6.1).

The arguments to certain operators are such that could produce a negative zero result, but the implementation does not support negative zeros (6.2.6.2).

Two declarations of the same object or function specify types that are not compatible (6.2.7).

Conversion to or from an integer type produces a value outside the range that can be represented (6.3.1.4).

Demotion of one real floating type to another produces a value outside the range that can be represented (6.3.1.5).

An lvalue does not designate an object when evaluated (6.3.2.1).

A non-array lvalue with an incomplete type is used in a context that requires the value of the designated object (6.3.2.1).

An lvalue having array type is converted to a pointer to the initial element of the array, and the array object has register storage class (6.3.2.1).

An attempt is made to use the value of a void expression, or an implicit or explicit conversion (except to void) is applied to a void expression (6.3.2.2).

Conversion of a pointer to an integer type produces a value outside the range that can be represented (6.3.2.3).

Conversion between two pointer types produces a result that is incorrectly aligned (6.3.2.3).

A pointer is used to call a function whose type is not compatible with the pointed-to type (6.3.2.3).

An unmatched ' or " character is encountered on a logical source line during tokenization (6.4).

A reserved keyword token is used in translation phase 7 or 8 for some purpose other than as a keyword (6.4.1).

A universal character name in an identifier does not designate a character whose encoding falls into one of the specified ranges (6.4.2.1).

The initial character of an identifier is a universal character name designating a digit (6.4.2.1).

Two identifiers differ only in nonsignificant characters (6.4.2.1).

The identifier func is explicitly declared (6.4.2.2).

The program attempts to modify a string literal (6.4.5).

The characters ', \, ", //, or /* occur in the sequence between the < and > delimiters, or the characters ', \, //, or /* occur in the sequence between the " delimiters, in a header name preprocessing token (6.4.7).

Between two sequence points, an object is modified more than once, or is modified and the prior value is read other than to determine the value to be stored (6.5).

An exceptional condition occurs during the evaluation of an expression (6.5).

An object has its stored value accessed other than by an lvalue of an allowable type (6.5).

An attempt is made to modify the result of a function call, a conditional operator, an assignment operator, or a comma operator, or to access it after the next sequence point (6.5.2.2, 6.5.15, 6.5.16, 6.5.17).

For a call to a function without a function prototype in scope, the number of arguments does not equal the number of parameters (6.5.2.2).

For call to a function without a function prototype in scope where the function is defined with a function prototype, either the prototype ends with an ellipsis or the types of the arguments after promotion are not compatible with the types of the parameters (6.5.2.2).

>>1030699

>>this thing used exclusively for obfuscation

>ha so you don't understand what it does?

No, I mean "used exclusively for obfuscation". Someone wants to put the same exact code in two lines instead of three, and instead of just putting two statements on one line, this person uses the comma operator to tuck an assignment randomly into an expression with some other value.

>>1030704

So? Do you know C? Can you read code and understand what it does?

>>1030705

Yes, my ability to understand C is how I was able to say "oh, this is the work of an obfuscating twat and the comma operator", rather than "oh wow what short code, I wonder what it does"

>>1030706

Then stop whining. There's nothing obfuscated about the code you posted.

>>1030712

>you can understand bad code so it's not bad lol

>cniles are at each others throats

That is why Rust will win. Rustaceans treat each other with respect and kindness.

>>1030715

>Rustacean

good job assuming my pronouns shitlord

>>1030715

>Rustaceans are [enormously hostile to people who express themselves directly and expect others to not easily take personal offense over technical matters]

>>1030717

>>1030719

>butthurt LARPers spotted

>>1030721

The other day a guy was recounting a personal horror story: he once submitted a Linux kernel patch, and he got personally insulted over it. Jesus showed up just to weep and pat him on the head. This guy expressed support for CoCs.

I was silent because I didn't want to get fired.

On the one hand: the guy who got insulted once and, long term, was harmed by a sense of moral superiority.

On the other hand: me being completely silent, withdrawing from all social media, and mostly communicating anonymously, because I don't want to get fucking lynched ten years from now for expressing agreement with something commonly accepted today.

Rust is excluding one of us and calls that exclusion "kindness".

>>1030726

tl;dr you nigger

>>1030603

No. What I was trying to say is that Rust enforces a stupid way to handle what they call "guarantees". Say, I want to heap-allocate something; I would have to Box it (don't know if Rust still uses Box, but you get the idea), whoch would then be reflected in the type signature. The functions, and actually the programmer who is using that Boxed value doesn't fucking care that it's Boxed, yet it is reflected in the type. That stuff mostly matters to the guy who originally wrote the original value; it is an implementation detail, not an actual valuable piece of information, and yet the functions you pass this shit to do care, because muh explicitness or something, but a Boxed integer is still an integer for any function that processes an integer. I know you will say "but Rust actually does automatically unbox some stuff", but this doesn't always work for all implementation detail types (like Rc) and possible combinations of types. This results in having to autistically define the verbose as fuck types any serious Rust program ends up having, every fucking time. This makes it so that you end up rewriting half of the program to add another pointless unwrap (because, of course, you actually don't care about pattern matching it to have proper error recovery), just because you ended up deciding you do need to have that type on the heap.

So, you wanted a vector (heap) of integer (refcounted), which could perfectly be blackboxed as a vector of integer for most applications, and you end up having a Box<Vec<Rc<int>>>, which handles like a Box<Vec<Rc<int>>>. So Rust code ends up being full of pointless unwraps, and those that are not so pointless end up not getting handled because the programmer has been insensitivized to them. Not to mention that pattern matching them may prove complicated, not to say a fucking mess.

For the record, I actually like Rust's error handling. I think it may be the only language that has gotten error handling right.

>>1030745

>The functions, and actually the programmer who is using that Boxed value doesn't fucking care that it's Boxed, yet it is reflected in the type.

Box dereferences to a reference to the boxed object.

So you can write fn foo(i: &i32) instead of fn foo(i: &Box<i32>) if you actually don't care that it's boxed.

>Box<Vec<_>>

Box is a single object heap allocation.

Vec is a multi object heap allocation.

You don't need to box the Vec.

You really don't have a clue about Rust yet you spread FUD.

Are you an anti Rust shill?

>>1030753

>I will point some technical inaccuracies to disprove his point, while completely missing his point. That will show him!

It's been three years since I used Rust. Cut me some slack, you nigger.

>>1030770

>he complains about others not being able to understand his mental diarrhea

>>1030678

>>1030704

its used in for loops:

for(i=0, j=n; i<n; i++, j--)

sometimes if statements:

if(x) a=b, w++;

never seen it used anywhere else

>>1030745

>No. What I was trying to say is that C enforces a stupid way to handle what they call "guarantees". Say, I want to indirectly pass something; I would have to use a pointer (don't know if C still uses pointers, but you get the idea), which would then be reflected in the type signature. The functions, and actually the programmer who is using that pointer to a value doesn't fucking care that it's a pointer, yet it is reflected in the type. That stuff mostly matters to the guy who originally wrote the original value; it is an implementation detail, not an actual valuable piece of information, and yet the functions you pass this shit to do care, because muh explicitness or something, but a pointer to an integer is still an integer for any function that processes an integer. I know you will say "but C actually does automatically dereference some stuff", but it doesn't, ever. You need to explicitly dereference always. This results in having to autistically define the verbose as fuck types any serious C program ends up having, every fucking time. This makes it so that you end up rewriting half of the program to add another pointless dereference (because, of course, you actually don't care about null checking it to have proper error recovery), just because you ended up deciding you do need to have that type be indirect.

I know you can do something similar for c++, if someone wants to take a shot.

>>1030789

>muh syntax

>didn't mention .unwrap()/10

try harder faggot

>>1030788

>C is bad, therefore, Rust is good

dPathetic.

>>1030459 Only faggots use Rust! Smart guys use Python!

>>1030511

You're making the anti-Rust crowd's arguments for them.

bump

Rust is like AIDS.

>>1028668

It probably depends on where exactly you live.

>>1031309

Well, I do have a love-hate relationship with Rust. I really want to like it, but fuck if it doesn't feel like every single feature has some traps you don't learn just by reading the book. Enum types are trapped and they never mention it in the manual.

>>1036036

ok, what's the enum trap?

>>1036039 A trap is a boy or man who wears girls' clothes. Japanese people call them otokonoko.

>>1036039

Using enum structs inside match expressions is unwieldy due to having to explicitly name every single thing you want to extract. It gets old after a while, so the Rust community says you are better off making separate classes, and then use them as the enum entry type. There is no mention of this tip in the manual.

>>1036080

>There is no mention of this tip in the manual.

Do you not have a brain?

Anyways this really is unfortunate. There is an RFC for this but it's very old and nobody seems to care: https://github.com/rust-lang/rfcs/issues/754

>>1030832

>C is bad, therefore, Rust is good

It's like arguing with /christian/s

>>1036091

>Do you not have a brain?

Yeah well, it doesn't sound like a problem until it is, specially if you are nesting match clauses. There is a reason it is a long requested feature.

BUMP because FUCK RUST.

Firefox btfo

>>1026682

>G*d

fuck off, jew.

After perusing this thread, it has become evident that rustfags are some of the most irritating niggers around.

Why is a """safe""" language named after the top cause of catastrophic mechanical failure? Was this intentional or are they really that out of touch?

This is why I use C, lmfao

Friendly reminder that C++ is the best programming language ever.

Rust seems to be really cool. You don't even need to mistakes, the language already does it for you.

bumping for the memes

what's Rust's defense against forking from a multithreaded application and trying to use data structures that a thread might've been halfway through mutating? Check out this four-year-old bug that caused Apache to busyloop: https://github.com/SpiderLabs/ModSecurity/issues/890

>>1045920

https://doc.rust-lang.org/std/sync/struct.Mutex.html#poisoning

Memory management is already a solved problem with GC. Insane how people want to manually do something that has been automated for decades.

>>1045941

GC sucks