[ / / / / / / / / / / / / / ] [ dir / 1cc / ausneets / b2 / choroy / dempart / lounge / mde / pinoy ]

/tech/ - Technology

Winner of the 77nd Attention-Hungry Games
/x/ - Paranormal Phenomena and The RCP Authority

April 2019 - 8chan Transparency Report
Comment *
Verification *
Password (Randomized for file and post deletion; you may also set your own.)
* = required field[▶ Show post options & limits]
Confused? See the FAQ.
Show oekaki applet
(replaces files and can be used instead)

Allowed file types:jpg, jpeg, gif, png, webm, mp4, pdf
Max filesize is 16 MB.
Max image dimensions are 15000 x 15000.
You may upload 3 per post.

File: 6ab224a5eb98333⋯.png (81.9 KB, 660x660, 1:1, rustlogobig.png)


On May 15th, 2015, Rust was released to the world! After 5 years of open development (and a couple of years of sketching before that), we finally hit the button on making the

attempt to create a new systems programming language a serious effort!

It’s easy to look back on the pre-1.0 times and cherish them for being the wild times of language development and fun research. Features were added and cut, syntax and keywords were tried, and before 1.0, there was a big clean-up that removed a lot of the standard library. For fun, you can check Niko’s blog post on how Rust's object system works, Marijn Haverbeke’s talk on features that never made it close to 1.0 or even the introductory slides about Servo, which present a language looking very different from today.

Releasing Rust with stability guarantees also meant putting a stop to large visible changes. The face of Rust is still very similar to Rust 1.0. Even with the changes from last year’s 2018 Edition, Rust is still very recognizable as what it was in 2015. That steadiness hides that the time of Rust’s fastest development and growth is now. With the stability of the language and easy upgrades as a base, a ton of new features have been built. We’ve seen a bunch of achievements in the last year:

>We have been StackOverflow’s “Most loved programming language” 4 consecutive years in a row

>We opened up a whole new area of development for stable Rust: embedded development

>Rust+WASM went from an experiment to a usable product, making rustc the first compiler with focus on supporting WASM

>We shipped a new language edition: Rust 2018

>Crates.io passed a billion downloads and has over 25,000 crates available

>There’s now over 100 meetups around the world, in 42 countries

>6(!) new conferences were spun up (RustRush, RustCon Asia, Oxidize, Rust LATAM, Colorado Gold Rust, RustLab Italy)

This list could go on and on. While the time before and after release was a time where language changes had huge impact how Rust is perceived, it's becoming more and more important what people start building in and around it. This includes projects like whole game engines, but also many small, helpful libraries, meetup formats, tutorials other educational material. Birthdays are a great time to take a look back over the last year and see the happy parts!

Rust would be nothing, and especially not winning prizes, without its community. Community happens everywhere! We would like to thank everyone for being along on this ride, from team members to small scale contributors to people just checking the language out and finding interest in it. Your interest and curiosity is what makes the Rust community an enjoyable place to be. Some meetups are running birthday parties today to which everyone is invited. If you are not attending one, you can take the chance to celebrate in any other fashion: maybe show us a picture of what you are currently working on or talk about what excites you. If you want to take it to social media, consider tagging our Twitter account or using the hashtag #rustbirthday.




Rust is really good for system programming and has a good typed system. Better than C at least.


rust has too much abstraction to be low level at least as low level as C. It wont replace alot of applications C has right now such as being used in embedded shit, control systems, and anything else. Not to say its a bad language. Comparing rust to C isnt very accurate it is more accurate to compare it to C++. I'm not sure why C is brought up when talkimg about rust so much.


Rust is a bastard child of C++ and Haskell with the disadvantages of both. Being better than C is not an accomplishment.



>I'm not sure why C is brought up when talkimg about rust so much.

Because there are a lot of Cniles that are allergic to memory/thread safety and use C for everything.



What? You have to expound on that.

Protip: You won't because you are a LARPer and an anti-Rust shill


File: 4d044d8e92d3ecb⋯.jpg (64.33 KB, 850x400, 17:8, quote-once-men-turned-thei….jpg)

File: a37a101a527af02⋯.png (1016.75 KB, 1280x1280, 1:1, failure[1].png)

File: b5fc1ac969980f1⋯.jpg (49.04 KB, 850x400, 17:8, quote-censorship-is-tellin….jpg)


The pattern matching and type-checking enforcements . Except Haskell feels natural, allows you to program what you want and doesn't ask you to type-annotate every object with mile-long types.

In Rust by contrast if you're doing anything remotely serious half the time is spent wrestling with the borrow-checker. It does nothing to make your life easier, and you have to write all the annotations yourself. What Rust allows as valid is a small subset of actually-valid code. Therefore it's disgusting to anyone who loves freedom and getting the job done over getting a stupid certification by a stupider piece of code. Some people seem to like it, but for the life of me I can't understand them.

I like being able to use GOTO in c++. Last time I used it for control-flow in an interpreter long ago. I usually shouldn't use it, and 99% of the time I don't. But whether I use it or not, 100% of the time I am allowed to use it. That is freedom. And freedom is good.



>defending Rust, the ugly and overly complex language

Use Ada, C or C++ or even Go(ck)lang instead.



>pattern matching

Haskell didn't invent pattern matching though.

>muh borrow checker

Kek. Every time.


Absolutely harmful. A high level language shouldn't have it.



<The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.

<It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical.


File: 9d23c45d66c1187⋯.gif (229.69 KB, 240x180, 4:3, PoliteTallFanworms-max-1mb.gif)


>asks for an argument

<shitposts as response

Well, my fault for falling for the bait.





Spotted the anti Rust shill. Why don't you try it with some

>muh syntax


>muh doubly linked lists


Rust is so good they fired their shills. Except OP, he does it for free.



Can we agree to disagree and leave it at that?

Frankly, until your glorious pet language makes an impact you don't have a leg to stand on. I'm just betting it won't.



If syntax doesn't matter then why are you using a programming language at all? Bust out a hex editor and write in pure machine code or get the fuck out you larper.


File: 703b891a2fb9ca3⋯.png (35.09 KB, 1200x635, 240:127, Go vs Rust.png)



<The key point here is our programmers are web developers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned JavaScript, maybe learned Ruby or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.

<It must be familiar, roughly C++-like. Programmers working on the web are early in their careers and are most familiar with procedural languages, particularly from the C++ family. The need to get programmers productive quickly in a new language means that the language cannot be too radical.



Rust syntax is pure UNIX brain damage, like the rest of the language. A big company of C++ weenies finally discovered that C++ sucked and instead of switching to a tried and tested safe language like Ada or PL/I, they decided to make their own language by bolting features from other languages onto their new not-C++. The results speak for themselves: PL/I could compile itself on a 64 kilobyte machine while Rust somehow runs out of registers on x86 CPUs, and instead of attracting C++ weenies Rust attracted JavaScript and webshit weenies. Not even C weenies can stand this garbage.

A language can be memory safe and brain damaged weenie garbage at the same time. Rust is both and must be hurled in the trash, where it can rot while real languages take its place.

My code was incorrectly printing the value of one of the
registers (r0). After I had spent a pleasant, relaxing
afternoon ineffectively trying to debug my code, and
discovered this, I remarked upon it to run a new program-,
it would be a Good Thing to separate the notion of
creating a new process from the grapevine.

I was much amused at the factory gates, I, for one, will
not be there to urge clemency.

Ever notice how most unices, the ones that don't use
MMDF, often send you half-complete messages? Ever
wonder where all those lost bits GO??

But the point of this is that it really hasn't got much to do
with MMDF, it has to do with unix itself. The problem,
see, is that it really hasn't got much to do with MMDF, it
has to do with unix itself. The problem, see, is that it
really hasn't got much to do with MMDF, it has to do that,
you might at least think that you could arrange some
kludge to optimize the common case.(1) But no, that would
be perfectly adequate to run a mailer and a filesystem. And
it would have been, too, except that the nice helpful people
who brought you unix invented this thing called the "fork",
which they then proceeded to stick - um, sorry, about to get
a little carried away, there.

But anyway, see, by employing the great unix principle of
"composable functionality", they were able to determine that
even though 99.9997 percent of the time you create a new
process you are too generous. When I was porting a Scheme
compiler to the RT, I managed to make adb -- nothing like a
fancy, source-level debugger, or anything, just dumb ol' adb --
dump core with about 6 or 7 keystrokes. Not arcane
keystrokes, either. Shit you would tend to type at a debugger.

It turned out that the machine you mention, MC, is only a poor
little Microvax 3, with probably only 16Mb of memory. Which,
you would think, would be -messy-, and unix is not -messy-.
So, kids, the way we run a new process, and -copies (and I
mean -copies-, as in moves bits around on the disk), the entire
address space of the old program into the new program you
wanted to run a new program-, it would be a Good Thing to
separate the notion of stuffing the new one-, followed, 99.9997
percent of the time, by the "exec" system call, which takes a
running program, makes a new program-, it would be a Good
Thing to separate the notion of creating a new process from
the grapevine.



>Frankly, until your glorious pet language makes an impact you don't have a leg to stand on. I'm just betting it won't.

It already has. Get fucked, anti Rust shill.


>muh syntax

spotted the LARPer


>/g/ tier image

you have to go back


This doesn't even make any sense. Nice try though, impostor.

>Rust somehow runs out of registers on x86 CPUs


memory != registers



>spotted the LARPer

The only real difference between the vast majority of real languages which are all basically clones of C, some kind of Lisp, or Pascal is, surprise surprise, fucking syntax, because you can do just about anything in any language if you are brave and autistic enough.



>The only real difference between the vast majority of real languages is syntax

LOL. Stop LARPing.

The differences between C and literally any other language are immense.



The only differences between C and any other language that isn't a scripting language or executed within a virtual machine are syntax-related. There are some small differences pertaining to the bloat factor of the stdlib and what tooling is provided or available but that is covered under "brave and autistic enough". Also rust is shit. Nim is better even if it has some stupid issues and a faggot GC.



>being this fucking retarded

Is UB and IB also just syntax?

Your retardedness is showing, anti Rust shill. Youw on't convince anyone if your spouting shit as inane as that.



>You are so fucking retarded let me show you how much smarter I am by refuting your point by comparing two things that are not programming languages!



>going completely off the rails

The absolute state of anti Rust shills.

How embarrassing.



>How dare you call me out for being wrong let me act like you are the one acting crazy!

Why did you stop avatar fagging Steve?


Rate my Rust™

fn sort_strings_length() {
let mut a = ["hello","I","am","a","sentence","please","sort","me","faggot"];
a.sort_by(|a,b| a.len().cmp(&b.len()));
for e in a.iter() { print!("{},",e);}



>I'm wrong



I improved it:

fn fn sort_strings_length() {                                                                       
let mut a = ["hello","I","am","a","sentence","please","sort","me","faggot"];
a.sort_by_key(|s| s.len());
println!("{:?}", a);



>any type can be safely cast to any other type, causing memory safety vulnerabilities in safe code (e.g., out-of-bounds write or read)

Rust everybody.




Now post the C/C++ CVEs XDDD



stop trying to associate Rust with C. you anti Rust shills are pathetic




Using the world "harmful" kinda is expected from rust supporters, isn't it? Anyone can see you for what you are. Campaign first for Rust to disabow CoC guidelines and stop shilling your shitty language.



>anti Rust shill calling a Rust shill an anti Rust shill



>Using the world "harmful" kinda is expected from rust supporters

>Dijkstra is a Rust supporter

I'm ok with that



I still don't get what's so bad about having "easy to use language that helps you write good software" as a goal itself. Most of the time the arguable design decisions of Go aren't even mentioned in these posts. Should be flagged as spam tbh, obstructing discussion and wasting time.


Rust shilling is the Baneposting of programming.



>syntax doesn't matter

but it does. syntax just isn't the most important aspect of a language as long as it's not absolutely terribad (ie rust tier bad)


C/C++ don't claim to be safe


>t. i don't understand what "goto considered harmful" means or where it originated from


well congratulations, you got yourself caught. what's the next step of your master plan?


>>1063888 (checked)

Crashing this language


C/C++ programmers

>It's fine dude just turn on every warning, make them errors, use libasan, and follow these 1000 point guidelines

>Lol Rust? Its too restrictive for no gain



Well, yes, but guidelines != bondage and discipline.




>good software


Also Go wasn't created to make good software with. It was created so that the dumb niggers Google hires can shit out code faster than Google can abandon projects.


>muh syntax

ok, kid

>C/C++ don't claim to be safe

But Cniles claim that they can write safe C/C++.

>>t. i don't understand what "goto considered harmful" means or where it originated from

I wrote that HIGH LEVEL LANGUAGES should not have goto. Prove me (and Dijkstra) wrong.








Go has a use case. Rust does not.

Go has a specification. Rust does not.

Go has a useful standard library. Rust does not.

Go has excellent profiling tools. Rust does not.

Go has trivial compilation time. Rust does not.

Go is simple. Rust is not.

Go can be learned in a weekend. Rust requires months.

Go documents its weaknesses and has tools to deal with them. Rust pretends they don't exist.

Go has been used in enterprise production code. Rust has not.

Checkmate, athiest.



ok. Now tell me how to write a generic data structure in Go.



>Go has a specification. Rust does not.

Technically speaking, without a specification everything in Rust is undefined behaviour.



Rust has been used in firefox, go has not

Rust has working types, go has not

Rust has inline assembly, go has not

Rust has been used to make a full OS, go has not

Rust teaches good memory practice, go does not

The only thing go has over rust is slow garbage collection and Google GRIDs



Rust has also been proven 10x faster than Go, with Go's C API being horrible and sluggish.



>t. i don't understand what "goto considered harmful" means or where it originated from

Any instance of goto should be replaced with a higher level control flow thing. Unfortunately Ctarded languages like C only offer you a few predetermined ones like if, while, for, etc.



Go generate. Reflect. Type assertion. Interfaces. What's the cost in compilation time for having generics which you rarely actually need? What about legibility? Don't eat so much candy, junior, you'll give yourself a tummy ache.


Firefox has more CVEs than ANY other application. It has small Rust components, which is the equivalent of a pity fuck.

If you think ADTs which you have to make a function call to unwrap every time, are some kind of godsend over multiple return types, you're an idiot. Please tell me where the Go type system doesn't "work".

GoOS exists. It's just as relevant as Redox (ie, not at all)


Rust doesn't teach you anything about memory other than convoluted rules that are only relevant to its own implementation. Rules which break down when concurrency comes into play. Did you mean GNAT?

You're out of your league. Try Hacker News or Ycombinator. Or maybe your buddies on Grindr would listen to you gushing about how a worse language is better. I would take Java, any shitLisp before Rust.


Share your benchmark, please. Benchmarksgame shows go at 1.5-3x C. Unscientific benchmarks is about 1.5-2.5x C.

Mozilla isn't sending their best.



>Please tell me where the Go type system doesn't "work".

Go interfaces are retarded. Structural typing is a shitty hack to give duck typing to a static language, and interface{} is a cancer you see everywhere due to Go's shit type system (Somebody fucking looked at old Java casting everything to and from Object and thought that looked good enough for a new language).

The fact that you can't define your own goddamn generic types is laughably retarded. The fact that Go encourages literal copy-paste over a reusable type is fucking stupid.

I'm not a rust shill, but Go is shit. No immutability declarations, no generics, no overloading, no ranging over non-builtins, fucking nullable types, terrible error handling (good error handling is something Rust actually has going for it), no support for stack-only operation making it useless for any dynamic programming, impossible to write low-level code accessing arbitrary memory addresses in any way (which isn't in itself bad, but for a programming language that purports to be a systems programming language, it's retarded).

Go is a mess. It doesn't do anything new, it's got a horrible hodge-podge design with too little power to be useful to just about anybody, the typesystem is a mess reminiscent of Java when its type system was even worse than it is, and in dozens of areas it is a step backwards in programming language design. I'm happy with people shitting on Rust, but defending Go is a step too far.



>no support for stack-only operation making it useless for any dynamic programming




You brought up Go, Steve, not me. Anyone could easily list all the ways Java or Racket is superior to Rust. Plus you don't know anything about Go that you did learn from Reddit comments. Consts exist. Rust error handling "genius" is "let it bubble up to main, XD"

which you an do in Go too, but shouldn't. Define an error type in Rust someday. The boilerplate is ridiculous. I have to explicitly implement a display trait?

You obviously spend more time jacking off on programming comment sections than writing any software. Which is why you shill this gay language with a bunch of features that sound good on paper but somehow never seem to lead to working enterprise software.



>Any instance of goto should be replaced with a higher level control flow thing.


The most-noted item ever published in Communications was a letter from Edsger W. Dijkstra entitled “Go To Statement Considered Harmful” which attempted to give a reason why the GOT0 statement might be harmful. Although the argument was academic and unconvincing, its title seems to have become fixed in the mind of every programming manager and methodologist. Consequently, the notion that the GOT0 is harmful is accepted almost universally, without question or doubt. To many people, “structured programming” and “GOTO-less programming” have become synonymous.

This has caused incalculable harm to the field of programming, which has lost an efficacious tool. It is like butchers banning knives because workers sometimes cut themselves. Programmers must devise elaborate workarounds, use extra flags, nest statements excessively, or use gratuitous sub- routines. The result is that GOTO-less programs are harder and costlier to create, test, and modify. ....

I posed the following problem to a group of expert computer programmers: “Let X be an N x N matrix of integers. Write a program that will print the number of the first all-zero row of X, if any.”

Three of the group regularly used GOTOs in-their work. They produced seven-line programs nearly identical to this:

for i :=1 to n

do begin

for j:=1 to n do

if x[i,j] <> 0 then goto reject;

writeln('The first all-zero row is ' i);


reject; end

The other ten programmers normally avoided GOTOs. Eight of them produced 13 or 14-line programs using a flag to indicate when an all-zero row was found. (The other two programs were either incorrect or far more complex.)...



Goto is a tool. A tool you use sparingly, but a tool nonetheless. Try writing a decent interpreter without goto. You can't. Any language in which a goto semantics makes sense and is compatible should support goto. A knife isn't evil because you get cut faggot.



Oh well, fucked up the formatting. Fuck.



jmp considered harmful



Fuck off, drew. Introduce some more segfaults into your WM instead of shitposting here.








>Go generate. Reflect. Type assertion. Interfaces.

LMAO. You could do the same with Java years ago.


focking BASED


>You brought up Go, Steve, not me.

He is not Steve. I am. And I did not bring up Go.


>but in this specific example the goto version is slightly short

Great argument.



>what is return

Dijkstra was wright and only braindamaged UNIX weenies argue in favor of goto.



(0..matrix.rows()).find(|r| matrix.iter_row(r).all(|i| i == 0))

Goto considered harmful.



>Plus you don't know anything about Go that you did learn from Reddit comments

I've used Go at work. Some of us have jobs, dipshit.

> Rust error handling "genius" is "let it bubble up to main, XD"

I didn't say "genius", so I don't know what you're quoting. And no, that's exceptions. Rust is "you have to either handle errors at the site of occurrence or explicitly pass them out of the function". You almost should never bubble all errors up to main in Rust either. You have the option, but you have to do it explicitly as opposed to exceptions which do it automatically, or Go which has the same problems that C does in error checking, in that it can be ignored by the programmer. Even exception throwing is better than Go's error handling.

> Define an error type in Rust someday. The boilerplate is ridiculous. I have to explicitly implement a display trait?

It's literally writing a single function that tells how to print your type. What shit programmer are you that implementing a single function that can easily be one line is too difficult?



File: 8f26c4fb006b3b3⋯.jpg (33.18 KB, 808x332, 202:83, controll_flow_graph.jpg)

File: 412edadcc5fbb10⋯.pdf (401.39 KB, A_Type_System_for_Safe_Mem….pdf)


>posts code that finds all the all-zero rows of the matrix, instead of just the one needed, missing the point entirely

I don't need goto in haskell either, faggot, but that's besides the point. If you have a low-level systems programing language (not fairy dust python or haskell) where efficiency is paramount you should have goto.

There's something called the control-flow graph of a program which can be either reducible or irreducible. Procedural programing constructs like "while" or "for" and "if" only allow us to make programs with reducible control-flow graphs. Memory, simplicity, efficiency. If you're prepared to sacrifice at least one of the three, (usually two), then you can live your life in the smugness that 100% of the time, you never use Goto. People who get things done, on the other hand, can only say that they don't use Goto 99.9% of time. Still 0.1% falls short of your dogmatic ideological purity. Rules that are made for practical reasons can be broken for practical reasons.

Rust is like that academician (not even STEM, it would be better designed and less cancerous, pdf related), like the post modern art teacher that on day goes to the construction site to tell the workers "how shit's done". Without understanding the reasons why they do shit the way they do in the first place. It won't work because workers aren't willing to jump trough 10 additional hoops just to get the art-teacher's approval. Getting shit done is hard enough without having an ideological thought-police built into your compiler.




>>posts code that finds all the all-zero rows of the matrix, instead of just the one needed, missing the point entirely



>Searches for an element of an iterator that satisfies a predicate.

>find() is short-circuiting; in other words, it will stop processing as soon as the closure returns true.

Kill yourself, you utter retard.


File: 07ff24e9a3fb688⋯.jpg (86.42 KB, 1280x720, 16:9, maxresdefault.jpg)


>One line

enum Error {




impl Display for Error {

fn fmt(&self, formatter: &mut Formatter) -> fmt::Result {

match *self {

Error::Io(ref error) => error.fmt(formatter),

Error::Parse(ref error) => error.fmt(formatter),




impl error::Error for Error {


impl From<io::Error> for Error {

fn from(error: io::Error) -> Self {




impl From<ParseIntError> for Error {

fn from(error: ParseIntError) -> Self {




Everything you have said is false. You are the Prince of Lies, and Steve Klabnik is the king.



>hurr durr

You have a lot of different ways to do errors.

1. Do what you did

2. Do it he Exceptions way: Panic instead of returning Results. Panics can be catched with https://doc.rust-lang.org/std/panic/fn.catch_unwind.html

3. Do it the C way

4. Use Box<dyn Error> as your error type

5. Use a library (https://docs.rs/snafu, https://docs.rs/failure, https://docs.rs/error-chain, https://docs.rs/err-derive, https://docs.rs/err-ctx)

sage negated btw



>Fortranfags and PL/Ifags are UNIX weenies

Fuck off poser.

The fits significant blow to PL/1 was from made in early 70th by religious
fanatics connected to the "structured programming" dogma and,
especially, Edsger W. Dijkstra inspired "verification frenzy". Now it is
difficult to comprehend how almost the whole computer science was
hijacked by this primitive religious doctrine. But it was true and has
demonstrated quite well that the virtues ascribed to academic scientists
are way overblown. Heretics who are ready to be burned on the stake
defending the truth are as rare in academic community as among
commoners. May be even more rare. Complete corruption of academic
economics, conversion of the majority of them into intellectual defenders
of interests of financial oligarchy that we observed since 1980 say this
pretty load and clear. And computer scientists are not that different
those days. They also depends on grants and want tenure at all costs.
Which requires certain compromises.

Edsger W. Dijkstra inspired "verification frenzy" was mostly related to
bogus mathematic masturbation called "correctness proofs". The idea
was "simple, attractive and wrong" and due to this it soon became
more fashionable that drunks fights in pubs in England. It attracted
huge amount of verification snake oil salesmen and "computer science
crooks" who often flooded computer science departments and eliminated
useful research. While there was a positive component if structured
programming movement (it did helped to introduce richer set of
programming control structured in the language and PL/1 was again
pioneer in this area) but most affects were creation of some unrealistic
expectations (that number of errors in a program without goto statements
is less then for the program with many goto statements; but in reality if
not presence of absence of goto statements, but the usage of structured
control statements that matter and if some are not available in the
language they should be emulated using goto statements) or simply

Edsger W. Dijkstra played the role of a fervent Ayatollah. This
controversial character has the religious zeal of Luther, but was more
misguided. At the height of his delusion Ayatollah Dijkstra
completely lost common sense and issued a fatwa in which he
declared PL/1 to be a "fatal disease". Those spikes of religious
fervor damaged the language standing and helped more primitive
languages with much simpler compilers such as Pascal and C to get
ground Another advantage of Pascal was that it has freely available
compiler (despite his conversion into verification zealot, Wirth
remained a master of compiler writing to his last days). It was
based on recursive decent parsing and was specifically designed to
make compiler so fast that it can be used instead of linker (source
code linking). This tremendous speed with which Pascal can be
compiled (which was later demonstrated to the surprised world by
Turbo Pascal) was probably the most innovative feature of the
language. Compiler from C were also much simpler then compiler
for comparable subset of PL/1 such as PL/M and were distributed
freely with Unix source code. Creators of C discarded bogus "no
reserved keywords" idea and greatly simplified the syntax of
declaration of variables which removed to warts of PL/1 language
not only at no cost but with considerable savings in simplicity of
compiler. But cutting the language to the subset suitable for system
programming they cut way too much. and those decisions hunt C
and C programmers to this day. They also made some blunders in
design of the syntax of the language (no mechanism for multiple
closure of {} blocks with a single bracker like a: end a in PL/1 in one
obvious blunder. Usage round brackets as delimiters for conditional
expressions in if statements is another. Just those two errors cost
C programmers immense amount of lost hours in trying to find errors
that should not exist in properly designed language in the first place.
They also ignored some important heuristics for catching "running
string literal" errors invented in PL/1 optimizing compiler.

Structured programming dogma and verification frenzy were two first
religious movements in programming but unfortunately they were not
the last. Later object orientation (OO) became fashionable with its
own crowd of snake oil salesmen. Each of those splashes generated
huge crowd of crooks and religious fanatics, as well as promoted
corruption in computer science departments. As for computer science
departments, the level of corruption from early 80th became probably
pretty close to corruption of economic professions with its bunch of
highly paid intellectual prostitutes or outright criminals masquerading
as professors.





File: 808a02662da1c26⋯.jpg (173.83 KB, 1200x1000, 6:5, 15116248530.jpg)




>all these insightful and well-thought-off effort-posts that contribute to the thread

brain-damaged and unbased


>>1064137 (unbased)

Here is your insightful and well-thought-off effort-post that contributes to the thread:

For a number of years I have been familiar with the observation that the quality of programmers is a decreasing function of the density of go to statements in the programs they produce. More recently I discovered why the use of the go to statement has such disastrous effects, and I became convinced that the go to statement should be abolished from all "higher level" programming languages (i.e. everything except, perhaps, plain machine code). At that time I did not attach too much importance to this discovery; I now submit my considerations for publication because in very recent discussions in which the subject turned up, I have been urged to do so.

My first remark is that, although the programmer's activity ends when he has constructed a correct program, the process taking place under control of his program is the true subject matter of his activity, for it is this process that has to accomplish the desired effect; it is this process that in its dynamic behavior has to satisfy the desired specifications. Yet, once the program has been made, the "making' of the corresponding process is delegated to the machine.

My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible.

The unbridled use of the go to statement has an immediate consequence that it becomes terribly hard to find a meaningful set of coordinates in which to describe the process progress. Usually, people take into account as well the values of some well chosen variables, but this is out of the question because it is relative to the progress that the meaning of these values is to be understood! With the go to statement one can, of course, still describe the progress uniquely by a counter counting the number of actions performed since program start (viz. a kind of normalized clock). The difficulty is that such a coordinate, although unique, is utterly unhelpful. In such a coordinate system it becomes an extremely complicated affair to define all those points of progress where, say, n equals the number of persons in the room minus one!

The go to statement as it stands is just too primitive; it is too much an invitation to make a mess of one's program. One can regard and appreciate the clauses considered as bridling its use. I do not claim that the clauses mentioned are exhaustive in the sense that they will satisfy all needs, but whatever clauses are suggested (e.g. abortion clauses) they should satisfy the requirement that a programmer independent coordinate system can be maintained to describe the process in a helpful and manageable way.

It is hard to end this with a fair acknowledgment. Am I to judge by whom my thinking has been influenced? It is fairly obvious that I am not uninfluenced by Peter Landin and Christopher Strachey. Finally I should like to record (as I remember it quite distinctly) how Heinz Zemanek at the pre-ALGOL meeting in early 1959 in Copenhagen quite explicitly expressed his doubts whether the go to statement should be treated on equal syntactic footing with the assignment statement. To a modest extent I blame myself for not having then drawn the consequences of his remark



They aren't even getting the syntax right, it's

DECLARE postnumber BASED;


The only insight your post has given this thread is that you're too new to blockquote properly. Lurk more and take your syntax errors elsewhere.



>The only insight your post has given this thread is that you're too new to blockquote properly.

No shit. I'm not an annoying faggot, that's why I can't do it properly.

unbased btw



What you have done is not just implement your own error, you have implemented an error enum type that encapsulates other errors, and also the necessary switching logic and the From traits to automatically convert. Don't bullshit me, you idiot. Here's a proper simple error type:

use std::{error::Error, fmt};

struct MyError;

impl Error for MyError {}

impl fmt::Display for MyError {
fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
write!(f, "Something broke")

You have to impl the Error trait to treat it as an Error, and the only function you need to implement for your own error type is that fmt function, which can easily be one line, exactly like I said. You need extra code like you wrote to have a proper error wrapper enum type, but that's not what I said. I was talking about how to "Define an error type", not "Define an error type that wraps other errors". If you want to wrap errors without any extra code, you can also just throw a Boxed Error, but the way you showed is far better.



>Still not a one-liner

>Still a pathological liar

>Still a disappointment to everyone

>Still a help desk nobody

>Still unshaven and covered in macaroni and cheese stains

>Still indicted for possession of child pornography

Rust in a nutshell:

the people who wrote the application with more CVEs than any other application in the world other than a full OS got together and made a "safe" language. *Unironically*

To nobody's surprise, the language is full of hidden bugs, is completely unspecified, and is objectively worse than the language it was meant to replace (C++). These shortcomings are dealt with by the lowest form of developer life, the soy webdev, flooding the internet with false praise. Of course, in their smooth-brained reasoning, the only thing that matters is hype and the only metric of software is popularity. Four years since 1.0, they still live in a pathetic state of denial. Shitting all over the internet is the only thing they have left to do with their time because God knows they sure as fuck aren't writing working software.



>the people who wrote the application with more CVEs than any other application in the world other than a full OS

LOOOOOOOOOOL. Imagine anti shilling Rust this hard.

>completely unspecified

I recommend you to look up how long it took C/C++ to get specified :)

sage negated btw




>Still not a one-liner

I didn't say it was a one-liner. I said you only have to implement one function, and the implementation of that function could be one line. If you have to misrepresent what I said, you have no argument.

> All that pathetic projection

You're such a sad.



Goon stop posting.





"Scripting language" is a meaningless term used by autists to define what they believe is not "real programming".

Also, languages aren't inherently "compiled", "interpreted", or "executed in a virtual machine". It all boils down to the implementation.

And no, differences among languages go far beyond syntax. Either you're baiting, or you truly know nothing.




The "for" example is even wrong kek.

This stuff is a textbook example of pointless, excessive formalism.

It's quite ironic, considering that you yourself bring up "cancerous academicians".


[Return][Go to top][Catalog][Nerve Center][Cancer][Post a Reply]
Delete Post [ ]
[ / / / / / / / / / / / / / ] [ dir / 1cc / ausneets / b2 / choroy / dempart / lounge / mde / pinoy ]