Rust Programming Language by Mozilla

please stop these posts

Rust is a meme language

>>59502652
More meme everyday, that's too these posts.

>>59502652
Rust is a lot like C++ in the way that it uses RAII (look it up). It does not allow null pointers and dangling pointers. You can break out into C or ASM whenever you want to by marking that block with the "unsafe" tag.

It is safer than C because it doesn't have much legacy code lying around. Marginally better in other ways too.

Problem is, Rust is not used much because it is a new language, so if you want to get paid, learn C++, if you want to get paid later (student) learn C++ and Rust

>>59502658
It is not.

>>59502652
It's very fast, can easily be programmed functionally in, is designed for multi-threaded applications, is safe when you need it to be, but if there's something that just isn't there you can always just directly port over C libs with ffi, and it has a huge tech company behind it, increasing its staying power.

It will likely not "replace" any other language, but there is no reason for it not to become a major contender in the language game in the future, and it provides valuable tools almost every programmer would benefit from having under their belt by learning it.

>>59502776

Also,

>>59502763
> if you want to get paid later (student) learn C++ and Rust

This. Learning only one language as a programmer is fucking stupid and limits you massively.

>>59502776
exactly, Rust definitely has a reason to exist and might become big one day. I hate how everyone thinks its a meme. There's a reason it's here and that's to make a more stable, safe C++. Look at Servo, very interesting project.

File: 1462244554384.jpg (10KB, 201x251px) Image search: [Google]

10KB, 201x251px

>>59502793
anon, you have made my day

>>59502652
Rust is very fast and better than C++ in a lot of ways, including stability and multi-threading, but it hasn't been used so widely yet

Rust is not a meme, is the best contender to C++ we have. Rust is better than C++, D, Swift and Objective-C. Rust is the high performance language of the future.

>>59502658
>Rust is a meme language

perfect for the 4chan userbase

>>59502950
>this

>>59502658
The language is fine, but the management is retarded. It copies the firefox/chrome release model of never having a real release and instead opting for new shit hitting the streets every six weeks. They also always expect you to be connected to the internet when coding.

Never using it for reasons above no matter how good it may be as a language.

>>59503115
The management is one the best parts.

You are free to never update it if you want, also Rust is now mature to the point that new releases are backwards compatible with old ones.

Is not like Scala that breaks every two years, or worst... Python.

>>59503159
f# is the best scripting language

>>59502652
Can the rust shilling stop. Its syntax are really ugly and not very readable.

>>59503708
its syntax is okay but comments exist for a reason too

>>59503708
can you cite an example of "good syntax"?

>>59503770
One of my favorites languages is perl, and sometimes it isn't really readable. Even with stupid comments like saying what every line does gets confusing to understand some parts program I believe that's the case with Rust too.

>>59503801
Yeah i can see where you're coming from, but I think its an okay compromise, but we all have our opinions

>>59503775
>can you cite an example of "good syntax"?
An constrained version of C goes directly to the point.
D has a nice syntax.
My favorite FP syntax is OCaml.

>>59503708
>>59503801
Nah, Rust has a complete lack of ambiguity in its design. The problem is that lots of people just can't comprehend newer concepts like lifetimes or they're still stuck hating on generics.

>>59502950
The big problem is that Rust won't be mature for like 5+ years. Even now 99.999% of projects are stuck using nightly instead of a stable branch.

Absolutely haram.

>>59504472

I don't see these as reasons to avoid Rust. That's true of any young language.

>>59504745
It's not a reason to avoid it, it's great. Those are reasons not to USE it in projects because stable rust 1.0 was premature. It's a fine little toy languge now but all the big features are in nightly.

>>59502652
C and C++ fag here. I quite like it. Although it's safety features can get in the way, since I'm intelligent enough not to to stupid things.
Despite that, Rust is still a brilliant language.

>>59502652
Rust is still a few years away from breaking into the industry. Don't focus on it now if you're looking for a bread and butter language. Concentrate on what will earn you money, then dabble in it in your spare time.

>>59502814
>Servo
It's also slow and buggy as fuck

>>59505193
Nah servo's fine, it's the other parts that are shit.

>>59505219
What other parts?

>>59502652
Learn the language of McCarthy.

>>59505249
Servo's just a renderer, it loads pages perfectly fine. Anything that isn't literally drawing a page on the screen is other parts, probly reused from firefox.

File: 1452129628634.png (364KB, 483x288px) Image search: [Google]

364KB, 483x288px

I don't like Rust because most of the people who think it's good are amateurs, web developers and/or cargo-cult programmers who don't really know anything and just regurgitate what they hear in their IRC circle jerk sessions. Pretty much the entire Ruby on Rails crowd ended up on the Rust bandwagon.

No thanks.

They think the programs they write are defect free, because muh buffer overflows and automatic memory management, but little do they know about things like ensuring numerical stability, floating-point error, and so on, etc. They also tend to ignore the fact that the languages Rust is competing against have static analyzers which detect many of the security issues they purport to solve with their language. In critical systems development, we use things like SEI Cert C and Misra C, with analyzers that ensure compliance. For stuff that's even more critical than the average shit consumers end up using, we use formally verified software, and the industry as a whole is moving towards this.

Furthermore, Rust shills have gamed online communities and have invented a larger than reality presence, artificially inflating the language's perceived popularity. They also constantly F5 in their web browser on software bug for In all actual polls with hard numbers, Rust doesn't even show up in the charts. Take TIOBE or the recent Redmonk Language Poll for 2017. Where's Rust? It's a fucking footnote.

https://www.tiobe.com/tiobe-index/
http://redmonk.com/sogrady/2017/03/17/language-rankings-1-17/

Rust has no utility in the real world. People and companies who do real work are avoiding it like the plague for the same reasons I avoid it. Quite frankly, we're getting sick of Rust. Rust is only real in the minds of Rust sycophants. I almost feel sorry for all of the university/college students who are falling for the Rust meme. But in the end, it's only going to improve job security for those of us with real skills outside of Rust.

>>59505443
>They also constantly F5 in their web browser on software bug
Was going to say they also constantly F5 in their web browser on software bug defect mailing lists looking for for fresh exploits so they can chime in "oh, look, your language caused this, it's time to rewrite it in Rust, if we had a Rust version of this, this bug never would have happened."

>>59505443
Don't forget that for some reason, many Rust advocates believe stuff like asan aren't a thing and that a supposedly safe language which hasn't been formalized and proven isn't a joke. As weird as it may sound to those who aren't as versed in safety-critical software, the "languages" they think are unsafe are the ones actually used.

>>59505507
Yeah and they're constantly exploited with easy to design around problems. C is absolutely harmful for system software. That being said, Rust is in no position to replace anything at the moment. Someday, maybe.

>>59505443
You have no idea what your talking about.
t. C(++) fag

I haven't used it yet but it looks sort of like if someone took a C like language and changed a few parts that were programmer error prone. Things like having mut as a directive for whether a value should be changing and also for loop iteration that isn't programmer error prone.

>>59502652
Rust is good for what it claims to be (safety+control) but I bet not a single person on this board has a legitimate use for it.

>>59505925
It's a C++ replacement for me, so whatever use C++ has Rust has. Which is most of everything I do

>>59505925
I just made a pull request for Servo...

>>59505443
> most of the people who think it's good are amateurs, web developers and/or cargo-cult programmers
I think it's good and I'd like to use it on my job instead of C++, and I've been a professional C++ programmer for 12 years now.
> They think the programs they write are defect free
Having less defect != defect free, but it's still better than having more defects.
> static analyzers
You have no idea what you're talking about if you think static analyzers make C/C++ anywhere close to Rust.

>>59507310
know idea

>>59505794
that and the ownership/borrowing/lifetime system. go google that.

>>59502658
>SHUT IT DOWN GOYIM
Rust makes it harder to produce security bugs and CIA does not like it. CIA actually posts in /g/ (see vault7 leaks) and shills against Rust.
Rust is a very good general purpose programming language. If you want security use either Rust or Ada

File: 1482438643142.png (165KB, 2000x2562px) Image search: [Google]

165KB, 2000x2562px

over engineered garbage

>>59508439
>Too dumb for anything but if else for while loops
Do you happen to be a C toddler?

>>59502652
/g/ hates it, so yes

File: 1468839104430.png (73KB, 2048x1024px) Image search: [Google]

73KB, 2048x1024px

>>59508578
i wanted to like Rust, but i can't do many things in it without putting unsafe { } everywhere

what's the point of having safety features that just get in your way?

the syntax for lifetimes is verbose too. couldn't they come up with something simpler?

File: 1489880434820.jpg (147KB, 2038x1505px) Image search: [Google]

147KB, 2038x1505px

>>59508638
>what's the point of having safety features that just get in your way?
For safety. Something 'c' has ZERO concept of

>the syntax for lifetimes is verbose too. couldn't they come up with something simpler?
Now this is called babyduck syndrome

>>59508638
>i can't do many things in it without putting unsafe { } everywhere
what are these "many things"?

>>59508670
You literally cannot write a circular linked list in Rust without 'unsafe'.

>>59508680
is this true? someone please defend this

>>59508680
Why the fuck do you need linked lists, idiot?

>>59508687
What's there to defend?

>>59508694
>Can't implement a basic data structure
>Y-you don't n-need it

>>59508694
C tards' baby duck syndrome, they don't have dynamic arrays so they use (((link list))) and hack together the thing people call vectors
>>59508702
C doesn't even have strings

>>59508702
>a basic data structure
Rust has strings

>>59508711
>C doesn't even have strings
is this true? someone please defend this

>>59508722
Yeah no one can. The shitlang doesn't even have vectors. What a fucking joke!

>>59508711
You seem to be awfully hostile and insecure about C for some reason. Did C programmers bully you, or something.
>they don't have dynamic arrays
Notice how I said "circular". That is a different structure and is not related to a dynamic arrays at all.

>>59508711
>>59508719
>>59508722
>C doesn't even have strings
It does, you idiots. A string in C is a null terminated char array.
There is no string type, though.

>>59508731
>A string in C is a null terminated char array.
kek I didn't thing C was that timesink

>>59508731
What do you mean?
string name = "My name"; doesn't work?

File: 1489842602922.jpg (115KB, 699x520px) Image search: [Google]

115KB, 699x520px

>>59508745
no

>>59508748
this HAS to be a shitpost

>>59508745
Strings in C are typically dealt with using char pointers.
You can't take an arbitrary char pointer and say "this definitely points to a string" though. That's where preconditions come into play, though.

>>59508745
>>59508736
>>59508731
>>59508729
>>59508722
Strings in any language are just char arrays.

Other languages just wrap it up for you. Just do the same in C. Or use any of the hundreds of libraries.

>>59508748
>>59508758
Holy mother of autismal keks

>>59508771
>>59508768
Yeah because of autistic shit like this no one uses C these days

>>59508783
>no one uses C these days
>If I keep saying it, maybe it will become true!

>>59508768
There is ZERO excuse for not having a string type

>>59508785
C's popularity dropped another 11% in Stackoverflow in the last 3 years...

>>59508795
>stackoverflow is industry standard

>>59508799
You seem upset

>>59508799
Who the fuck would use autistic shit like C? It doesn't even have strings LMAO

>>59508787
Do you even know what C is for?

>>59508804
I am not though

>>59508808
Autists

>>59508787
Yes there is. If you actually understood any of C's design decisions, you would understand why it would be inappropriate and extremely difficult to enforce correctness any more than char *s do now.
Really though, this is all a fucking strawman.

I'm still waiting for my "safe" circular linked list in Rust.

>C
>Doesn't have strings
Is this the new meme or is it actually true?

>>59508804
Why would anyone be? We have job security for years to come. Come back to me when you land a fucking job with your meme language.

>>59508818
That's just like spewing nonsense like
>oh we are so edgy we use int to produce chars from the ASCII table :D

>>59508820
>We have job security for years to come.
If you were actually working you would know C is not really a big demand

>>59508827
What the fuck are you on about?

>>59508819
C actually has no strings. It's a poorfags' language

>>59508838
You can use ints to represent chars

>>59508834
In my place, Java is. But the point still stands.

>>59508847
You can use anything to represent anything. It's all just 1s and 0s. You can literally take any memory you want and say it's something else.

>>59508855
>In my place, Java is. But the point still stands.
No it doesn't

>>59508847
What the fuck do you even mean by that?
A char is an integer. An int is an integer, that is at least as large as char if not larger.
Is it supposed to be some huge revelation that you can store a smaller type in a larger one?

>>59508865
>A char is an integer.
And a string is an array of chars. Why the fuck C has chars then? Chars are bloats

>>59508873
>This hurts a C tard

>>59508864
Yes it does, please fucking point me to a job opening specifically looking for Rust proficiency. But you can't, because it isn't industry standard yet. But please, keep grasping strawhat arguments.

>>59508873
Pls delet

>>59508882
I originally said C is not a big demand. Rust is like 2 y/o, if you are so insecure about it than shame on your 40 y/o language

>>59508873
>And a string is an array of chars
So?
>Why the fuck C has chars then?
A char is the type with the weakest alignment requirements and the smallest size in C.
It's the size for which every other type is based off of.
A char is actually the definition of a byte in C. While the name suggests 'character data', it's used for more than that.
>Chars are bloats
How would bloating up strings to 4 times the size they need to be not be bloat?

>>59508873
>>59508865
He thinks chars are somehow fundamentally different to ints. That chars can only represent letters and ints represent numbers. They have no concept of think in bits or storing different values in "int"s. Cause they're just numbers, man.

It is how people who are introduced to programming at the Java and C# level think.

>>59508896
Still looking for any arguments that validate char's existence while ints or bytes exist

>>59508912
A char is a byte. What the fuck?

>>59508912
>bytes
There is no type named "byte" in C, you javatard.
As I fucking said: chars are bytes.

>>59508922
>>59508923
Still looking for any arguments that validate char's existence while ints or bytes exist

Ada does everything rust does better than rust does it, and it has been around for 40 something years.

Just use Ada if you want safety, rust is completely unnecessary.

File: 1488577937023.png (81KB, 512x288px) Image search: [Google]

81KB, 512x288px

>>59509047
>Ada does everything rust does better than rust does it
How so?

>>59509047
>this meme again
Ada's memory management story is nothing like Rust's, Ada relies on runt-time checks extensively while Rust ensures safety at compile time.

>>59509164
A real Ada programmer would never allocate at runtime.

>>59509164
>runt-time checks
>>>/brit/

>>59502658
but Rust isn't Japanese, anon

File: gopher.gif (181KB, 500x500px) Image search: [Google]

181KB, 500x500px

It's not unfair to say Rust is a failure, and it is, by every measure possible. Luckily, there are good languages that succeed.

>>59510894
>Stop the world GC bullshit
>Shared pool of memory for goroutines

This is just retarded. They chose easiness over simplicity, and it will cost them.

>>59511086
Languages are successful because they made the right tradeoffs in their design. The fastest growing language therefore has the best design.

meme
any functional language is meme language

>>59511125
Languages that grow fast also tend to die fast.

Golang is going to be the new Ruby. The concurrency model is just too fucked up. Which makes Golang just a more memory safe C with worse performance and compatibility.

File: 1480873556161.jpg (100KB, 736x736px) Image search: [Google]

100KB, 736x736px

>>59511125
>javascript has the best design

File: laterhomo.jpg (27KB, 500x499px) Image search: [Google]

27KB, 500x499px

>>59510894
Nice generics, fgt.

>>59508818
>I'm still waiting for my "safe" circular linked list in Rust.
Rust's analysis requires that ownership model be structured as a tree. If you want to move outside that, you either use standard library types such as Rc and RefCell that remove compile-time restrictions in exchange for run-time checks, or you write some unsafe code yourself.

>>59511184
This. Anon is delusional if he thinks quality is the #1 factor in language adoption.

>>59511231
>Language billed as 'safe' C can't do basic data structures without becoming 'unsafe'

This is why it is a meme language.

>>59511284
C can't do anything without becoming 'unsafe'.

>>59511284
That's the sort of reason C should be removed by force, even its most basic propositions are unsafe. I have a feeling your data type is just implemented retardedly.

>>59511231
>Rust's analysis requires that ownership model be structured as a tree.
I've worked on maybe 3 programs like that.
Rust is optimized for a very niche use case. It put all its eggs in one basket, and the basket has a hole in it.

>>59502652
Rocket.rs --- comfy AF

>>59511284
What.

C:
>code inside data structure implementation must be written carefully to avoid memory errors
>code using the data structure also must be written carefully to avoid memory errors

Rust:
>code inside data structure implementation must be written carefully to avoid memory errors
>code using the data structure is checked automatically; memory errors are prevented by the compiler

How is this not an improvement?

>>59511301
>>59511307
I am not saying Rust is bad (I wasn't that anon), but I am just telling you guys why everyone thinks it is a meme.

>>59511326
The main use case for a systems language is to write libraries for higher-level languages. In a real code base, your library code is in pure C, and your application code is in something like Python. There's no place for Rust in that ecosystem.

>>59511359
Everyone, LITERALLY everyone, thinks in C style. Even in other VM languages or dynamic typed stuff you have in the back of your mind some abstraction you're mindful of. Safety and like lifetimes is some orthogonal tier of mindfulness that hasn't been adopted by many people yet.

The problem is literally a meme in the Dawkinsian sense.

>>59511399
This is literally something similar to what a Haskeller would say.

And you guys still can't see why Rust is a subset of meme-lang.

>>59511399
The whole safety thing is a red herring. Just write code.

>>59511481
...only Haskellers don't insist that everything is rewritten in their language.

>>59511363
Your main use case, maybe. Meanwhile my kernel, display server, web browser, terminal, terminal multiplexer, shell, vector graphics editor, raster graphics editor, music player, and PDF reader all written in C or C++. The only major piece of software I interact with that's not written in either C or C++ is my window manager (xmonad, Haskell).

>>59511481
An entire generation of people learned in C, it's as close to the bare metal as is comfortable for just about anyone. Rust isn't a solution yet, it just has some amazingly good theoretical design ideas.

>>59511494
Safety is usually vitally important in the places that C/C++ is still being used. Otherwise it doesn't matter what language you're going with. Rust still isn't a very good solution because all the system-software-level features are coming in future versions.

>>59511515
In a sense, the OS is a set of libraries for higher-level scripting, such as with shell scripts.

>>59511533
C/C++ programmers already know how to use sanitizers and test their programs thoroughly. The vocal minority clamoring for "safety" is doing so in ignorance of how professional programmers do their jobs. The emphasis on memory safety is also a disservice to all the other verification work that goes into working on a real program. Anyone drinking the Rust kool-aid is an existential threat to the whole software industry.

>>59511494
t. CIA nigger looking for another 0day to buy

>>59511603
> C/C++ programmers already know how to use sanitizers and test their programs thoroughly.
Statnizers are relatively new thing and most o C/C++ programmers never heard of it, and they are nowhere near Rust's borrow checker in thoroughness.
> Anyone drinking the Rust kool-aid is an existential threat to the whole software industry.
Of course, it's they who are responsible to for all these security vulnerabilities the industry have to deal with every fucking day.

>>59511661
>Statnizers are relatively new thing and most o C/C++ programmers never heard of it
If the software industry is so overrun by amateurs who can't be bothered to learn these basic skills, then the ship is already sinking and there's no use trying to patch the leaks. Just let our profession die with a little dignity.
>and they are nowhere near Rust's borrow checker in thoroughness
That's hardly plausible, and not an excuse even if it's true.

The only problem with it are the compile times

>>59511326
>How is this not an improvement?
The problem I foresee here is that (1) almost anything of substance you actually write needs to use a bunch of unsafe crap, and (2) the unsafe part of the language, and the libraries designed around the unsafe world, will never be as well-developed as (say) C++ because it is forever considered the bastard stepchild of the language. Doing substantial things in unsafe-land will be ugly and primitive because that's not what rust is about, and yet you need to do it all the time, leading to something worse than C++ in practice for anything beyond toy examples.

Note: I don't use rust; the above is my expectation for where things will go, not actual experience.

>>59502652
i bet you cant even use it because you dont abide with mozilla's code of conduct.

>>59511603
Depends really, a lot of Rust's safety guarantees are handled at compiletime so the use of safety checks CAN cause slowdowns if it's not designed in from the bottom up. It's not just a programming skill related improvement. Either way the rust guarantees are there whether or not some idiot in their massive pajeet programming pool fucks up.

If you can design around these failures you can optimize the design instead of having a different optimization for every check ever written, that's at least a time saving exercise and has merit.

>>59511742
>Everything you want to do in C-style has to be unsafe
Right now there's built in ways of handling a lot of that but they are idiomatically different. A lot of things are just completely different mentally and lifetimes fuck me up sometimes anyway. Rust's biggest problem is its immaturity rather than the memeC bits that can eventually be worked around.

>>59511775
The fact remains, instead of participating in a process like a responsible adult, you're placing trust in a piece of technology that's supposed to automatically solve all your problems. Never mind that these safety checks cannot be turned off, or run as a separate step from compilation. The fundamental problem is the same Silicon Valley mentality that has already done so much to ruin the world.

If computers were cars, you'd be the person handing out driver's licenses to inexperienced teenagers who don't know the rules of the road, and then pushing self-driving cars because you're surprised when these "drivers" get into wrecks.

>>59511868
There's multiple stages of compilation, I don't understand what that was about. Also, I can never ever rely on anyone else being responsible for themselves ever. Nobody should because that is stupid. People fuck up, don't rely on them never fucking up because one person doesn't fuck up often. If the task you're performing happens a billion times a minute even a very rare fuckup is a large fuckup.

>>59511895
If there is nobody left who demonstrates enough patience and sound judgement to be trusted with responsibilities, then human civilization is on the verge of collapse.

>>59511915
If someone thinks they're 100% flawless 100% of the time, they're wrong.

>>59511868
> Never mind that these safety checks cannot be turned off, or run as a separate step from compilation.
Why don't you research the topic first? It's obvious your knowledge of Rust is bases exclusively on /g/ memes.

>>59511944
It's unethical for inexperienced people to estimate their own abilities.

>>59511987
It's unethical to rely on estimations of abilities when there's an alternative.

>>59512002
It's not an alternative until it's proven itself.

>>59512009
Agreed but even the concept of computers checking the work for errors is accepted universally. That was never in doubt, just minor implementation details left.

>LARPers and schizos thinking smart compilers will lead to the collapse of civilization
If you seriously have issue trusting the complexity of the Rust compiler (over, say, GCC) you are seriously misinformed. At worst, Rust incorrrectly validates your program which leads to undefined behavior, which is what you'd probably get in C anyways.

I do not think Rust is a great language however. Rust's standard library is already huge yet it still seems like its missing things (I recently made a simple tree structure and realized I needed a simple f
unction that required the ultra nightly unstable build and the sacrifice of a small child). Maybe developers will eventually get used to crazy borrowing semantics, maybe they won't need to and Rust will die. Either way, its perpetually lacking, moreso than other new languages this old, and the community libraries feel as immature as shitty hyped JS framework.

File: okcupid.png (36KB, 768x308px) Image search: [Google]

36KB, 768x308px

https://tech.okcupid.com/rust-and-rpc-okcupid-hackweek-2017/
Meanwhile, OkCupid is close to using Rust in production. But hey, what would they know, right?

>>59511742
Reasoned arguments, on MY /g/? Truly, this is a sign of the end of days.

>(2) the unsafe part of the language, and the libraries designed around the unsafe world, will never be as well-developed as (say) C++ because it is forever considered the bastard stepchild of the language
You are totally right on this one. Even the core language syntax is clunky when you're working with raw (unsafe) pointers. The example that bugs me frequently is having to explicitly dereference raw pointers, as in `(*x).f`, when normal (non-unsafe) references add the deref automatically when you write `x.f`.

>(1) almost anything of substance you actually write needs to use a bunch of unsafe crap
The idea is that you will write a bunch of unsafe code but hide it behind a safe abstraction for the rest of the program to use. Thanks to inlining and other compiler optimizations (what Rust people call "zero-cost abstraction") the performance should be on par with the C version, but the compiler can catch bugs thanks to the lifetime annotations on the safe API's method signatures.

How well this actually works depends on what exactly you're doing. It works best if you can somehow present a tree-structured view of your data, even if the actual layout in the heap is more complex. Other structures may require some tricks to make the API design fit into Rust's model, such as defining a custom smart pointer or adding dynamic checks somewhere.

I don't know of any hard numbers on how much unsafe code is required in the average Rust project. But my impression is that this idea of wrapping up a small amount of unsafe code behind a safe API mostly works as intended, though sometimes Rust programmers do wind up choosing a different data representation that fits the ownership model better.

>>59509164
>Ensures safety with half-baked static checks
Sure thing, buddy

>>59502652
>by mozilla
>good

>>59512390
Mozilla research is not regular mozilla: webshit & codes of conduct.

>>59512143
>Reasoned arguments, on MY /g/? Truly, this is a sign of the end of days.
Sorry anon, won't happen again. Should I call you a faggot for good measure?

>Even the core language syntax is clunky when you're working with raw (unsafe) pointers.
*nods*. I have no problem in principle with a language that contains an especially-safe subsystem with limited applicability; that's an incremental improvement even if it is not perfect. But when that results in a stratified system of first-class and second-class sublanguages, things become unpleasant -- unless you can ensure the situations that require the second class language is *very rare indeed*.

It seems Haskell has sort of the same problem, with a really awesome purely functional sublanguage, and a clunky and primitive stateful sublanguage built on top of it. This is a hard trap to avoid when designing something that is not the epitome of perfection, and I don't know how to do a better job of it other than throwing out anything that is not perfect.

>The idea is that you will write a bunch of unsafe code but hide it behind a safe abstraction for the rest of the program to use.
I think the Rust model works pretty well as long as what you are writing can fit this scheme. The problem is, I feel there are a LOT of cases of nontrivial data structures where this approach doesn't really apply.

My go-to example here is anything that involves an object-oriented tree structure -- say, a typical OO user interface designed around a tree of widgets, or a web browser that stores a DOM tree (a tree of HTML tags). In a typical C++ implementation, this tree is mostly stored on the heap; each widget would contain a list of (pointers to) its child widgets, and --importantly-- each widget also contains a point to its parent (which may be null for a root widget or whatever).

[1/2] Continued...

>>59512662
[2/2] continued:

>each widget also contains a point to its parent

That parent pointer breaks the rust pointer constraints. And yet you really need it if you want to do anything sensible with your object-oriented widget model. Operations like "is this button currently visible" involve following the parent chain upwards, in one way or the other. Rendering the button depending on the layout settings of the parent object(s), likewise. If you have a clicked() callback on your button, with the button pointer as its primary parameter, you need those parent pointers for the architecture to not break down completely.

You can sort-of avoid this problem by referring, never to widget pointers, but instead to paths in the widget tree; your clicked() callback does not take a parameter that is a widget pointer, but rather a sequence of widget pointers, the last of which is the Button and the first of which is the root widget / window / whatever. But I feel that is throwing out the baby with the bathwater -- you make programming your GUI application SERIOUSLY clunky to avoid having to deal with the nasty backpointer.

Along with the simpler example of the circular linked list, I feel the real answer here is "the sensible data structure is something richer than a pure object tree and your language had better deal with it". And I don't think this is something you can easily encapsulate in a nice abstraction either.

>>59503115
>They also always expect you to be connected to the internet when coding.

That's crazy, wacko bizarre.

If that's true, then it's absolutely unacceptable for me.

And if it's true, then whoever made that decision needs to get back on his medications immediately, and get himself checked back into a psychiatric hospital as soon as possible.

>>59503115
>>59512752
>They also always expect you to be connected to the internet when coding.

Why are you lying on the internet?

>>59512752
>>59512775
What that post meant was
>Rust has a package manager with library versioning

>>59512662
>a typical OO user interface designed around a tree of widgets, or a web browser that stores a DOM tree
Mozilla has already put quite a bit of work into Servo, an experimental browser engine written in Rust. I don't know how exactly their design works, but they definitely have some kind of solution to this problem. And given how closely the Servo and Rust teams work together, I doubt their solution relies on unsafe code at use sites, because they could have leaned on the Rust team to get better language support for whatever they're doing (especially back in the pre-1.0 days).

>>59512677
>That parent pointer breaks the rust pointer constraints
You will definitely need some raw pointers and unsafe code in the base library that defines widgets. The question is what kind of safe API you can put around that. Your suggestion of using paths in the widget tree would work, and thanks to operator overloading (particularly overloading of Deref) I don't think it would be too clunky to use. You could probably also get away with using normal references, but it might impose some restrictions on what operations you can implement.

>>59508649
>For safety. Something 'c' has ZERO concept of

Actually C has a little bit of a concept of safety.

For example, in C89, they introduced function prototypes so that the compiler could make sure that the types of the arguments match the types of the formal parameters.

But the problem with C is that the safety features that were added to it were only babby tier.

For the sake of compatibility, they never fixed the horribly, horribly unsafe functions like strcpy() and strcat(), which are kind of the software equivalent of a knife with extremely sharp edges everywhere you touch it -- yeah, you might avoid cutting yourself if you're very, very careful -- but why not simply redesign the knife to be safer to handle? Because backwards compatibility, that's why. So even today, every single copy of libc still contains strcpy() and strcat().

And even if you personally avoid the dangerous functions in C, that still doesn't fix the fact that the language is still *potentially* dangerous. This becomes an issue when you need to hire 20 programmers on a limited budget and realize that, sadly, not all 20 of them are going to be brilliant, experienced, careful coders who can safely handle the presence of dangerous libc functions like strcpy() and strcat(). So you start thinking about the long-term consequences of having all those less-than-stellar members of your team filling your code base with all those potential buffer-overflow errors, and you start thinking twice about C.

>>59513098
>This becomes an issue when you need to hire 20 programmers on a limited budget and realize that, sadly, not all 20 of them are going to be brilliant, experienced, careful coders who can safely handle the presence of dangerous libc functions
Rust is a poo in loo language

>>59513128
Rust enables poocode, yes. It also enables /g/code. I don't know why the scrubs here don't like it more, I want to be able to use some library and trust that it's not going to explode.

>>59513188
>I want to be able to use some library and trust that it's not going to explode.

Agreed.

Obviously, to poos shouldn't have access to strcpy() and strcat().

But I'm an experienced C/C++ coder (25 years) and even I don't feel like expending the extra mental energy that it requires to use strcpy() and strcat() carefully.

Even the world's best carpenters still make sure that the shield is always in place when they use a rotating power saw -- and if they have an old saw with a busted shield, they stop using it. It's just common sense.

>>59512977
>but they definitely have some kind of solution to this problem.
I'm definitely interested in seeing what they come (came?) up with. But overall this still seems like a fairly fundamental issue that needs ad-hoc workarounds whenever you come across it, which is not really sustainable as a long-term general-purpose paradigm.

>because they could have leaned on the Rust team to get better language support for whatever they're doing
Trying to reimplement a hard-ass monster of complex software in the language to see what problems show up was definitely an excellent idea!

>You will definitely need some raw pointers and unsafe code in the base library that defines widgets.
That's one solution: careful encapsulation. The issue I foresee with this general approach is that, in the long term using rust for many projects, you'll be writing rather more icky pointer manipulation encapsulation classes than you typically do in C++. I wonder whether that is worth it.

>I don't think it would be too clunky to use
Perhaps. The bookkeeping involved with ever reparenting a widget will be horrible, though. Not sure whether that's a good or bad thing, overall. Also, I think it might break the OO paradigm to an extent (see below).

>but it might impose some restrictions on what operations you can implement.
That's an interesting third option: kill the backpointers entirely, and limit the operations you can perform on objects or add a bunch of extra parameters (parent paths, whatever) to them. This breaks much of the generally-accepted OO model of representing these structures, and makes composability harder. But then after all the hard work is done it may also result in a system in which the behavior of components is easier to understand? I can't predict where this will go. It's possible this radical redesign could fix several of the present-day challenges with heavy OO design (callback spaghetti anyone?), but it could also easily be as stupid as it sounds.

>>59507310
>if you think static analyzers make C/C++ anywhere close to Rust
You have no idea what you're talking about if you believe state of the art mathematical research is less valuable that checkers implemented in a toy compiler.

>>59502763
>if you want to get paid later (student) learn C++
Fixed.
Fuck Rust.
Maybe 15 years later it will be a thing, but luckily now, no one uses this cancerous SJW piece of crap.

>>59511184
>>59511249
well I mean, he is not that wrong.
we have javascript UI, desktop programs, music programs, javascript desktop environment, we have virtual machines in javascript, even my fucking dog might have been written in javascript.

>>59514225
That's fine since most C++ concepts translate directly to Rust anyway.

>>59514313
Well, basically what I said. C++ programmers at Facebook were quick to learn "HipHop" and whatnot. I mean a guy who can code C++ proper, will learn PHP or any other meme language in a day.

>>59514360
And when rust matures some people who are tired of constantly exploding C++ problems will probly just move to rust on their own. Or some other language like rust with safety checks built in.

Just use C with strlcpy and strlcat.

>>59513299
>This breaks much of the generally-accepted OO model of representing these structures
Rust isn't really designed for OO-style programming, so maybe a different style of GUI framework would be better when working in Rust.

I've had some success in one of my own projects with a more functional-style GUI, where the UI is strictly tree-structured with no parent pointers, and all operations are recursive traversals over the tree. There are no callbacks either - raw input events are passed down the tree until some widget handles them, then the resulting cooked event is returned back up the tree and possibly transformed at each level (for example, if a child button of a dialog returns a "Clicked" event, the dialog might itself return a "DialogSubmitted" or "DialogCancelled" event). This is an immediate-mode GUI, though, meaning everything is redrawn every frame whether it needs to be or not, which is usually acceptable only in games.

I definitely recall reading about a Rust GUI library that provided an immediate-mode API, but internally did lots of caching and diffing (React-style) to efficiently build a GTK+ UI matching your immediate-mode calls. I've forgotten the name, but I think it would still be a viable approach for writing GUIs that don't follow the OO paradigm.

>>59513098
>potentially* dangerous
Try COMPLETELY dangerous

Fuck C and Fuck security exploits