Why is Rust difficult? • Hacker News Board

Re: Why is Rust difficult?

#221

Post by SamReidHughes » Mon, Jan 22, 2018, 8:08 PM UTC

bitL wrote: post #30

SamReidHughes wrote: post #21

Earlier quoted context omitted.

You have the same thing in C++, right?

Yes, and sometimes I wish C++ stayed somewhere in pre C99 levels where a single person could master it. As much as new features are useful, they make codebases unreadable to anyone that doesn't grasp all concepts. Even Google internally "javaizes" C++ and uses a strict subset to keep some sanity. Scala is another language that can go insane in the same fashion if teams don't enforce strict rules.

Rust is a "Javaization" of C++ checked by the compiler.

Re: Why is Rust difficult?

#222

Post by AnimalMuppet » Mon, Jan 22, 2018, 9:15 PM UTC

pjmlp wrote: post #217

AnimalMuppet wrote: post #216

Earlier quoted context omitted.

Yes and no. Yes, Stepanov's first attempt at writing something like the STL was done in Ada. But no, it wasn't "the STL" - it was neither Standard nor Template. And Stepanov abandoned Ada for C++, because Ada wasn't expressive enough for what Stepanov was trying to write.

Meaning if Stepanov had not played with Ada for its first implementation, followed by Bjarne advocating him to use C++ instead, the STL would never happened in its form. And yes, it wasn't quite the STL, we had quite a few variations of it, the most well known coming from SGI, until things kind of settled at ANSI.

I disagree. Stepanov wanted to write that kind of software. He would have done it in any vehicle he found suitable. If he hadn't started with Ada, he still would have wound up writing it in some language.

And C++ was among the better candidates for the language to use. It was more suitable than Ada.

And, do you have any basis for the statement that Stroustrup advocated C++ to Stepanov?

Re: Why is Rust difficult?

#223

Post by AnimalMuppet » Mon, Jan 22, 2018, 9:33 PM UTC

pjmlp wrote: post #218

AnimalMuppet wrote: post #213

Earlier quoted context omitted.

"Less than absolutely total standard compliance" != "a significant challenge compared to absolutely total standard compliance", especially if the differences are clearly documented.

The challenge is not being able to write idiomatic ANSI C, rather trying to tame the compiler to produce code comparable to hand tuned Assembly to fit into those processors, the majority of time using compiler specific extensions.

You're sounding like a propagandist - like you want to just argue your talking points, rather than actually have a conversation where you listen to what the other side is actually saying. It makes you a real pain to talk to.

Just in case you're actually trying to engage in good faith, though, I'll try this one more time. If I have a compiler that is less-than-100% standards compliant, I may not be able to use a few features of the standard. That means there may be a few ANSI C idioms that I can't use. Of those, the number that I would choose to use on that size of processor is very, very few. So in practice, there is no "challenge".

Why would I use very few of these features? Because on a processor that size, you're not writing a huge app. You don't use all the functions in the standard library, you don't use all the keywords, you usually don't push the language very far at all. At worst, you might have to develop one or two idioms of your own. It's... mildly annoying, rather than the big deal you're trying to make it.

Re: Why is Rust difficult?

#224

Post by pjmlp » Mon, Jan 22, 2018, 9:39 PM UTC

AnimalMuppet wrote: post #222

pjmlp wrote: post #217

Earlier quoted context omitted.

Meaning if Stepanov had not played with Ada for its first implementation, followed by Bjarne advocating him to use C++ instead, the STL would never happened in its form. And yes, it wasn't quite the STL, we had quite a few variations of it, the most well known coming from SGI, until things kind of settled at ANSI.

I disagree. Stepanov wanted to write that kind of software. He would have done it in any vehicle he found suitable. If he hadn't started with Ada, he still would have wound up writing it in some language. And C++ was among the better candidates for the language to use. It was more suitable than Ada. And, do you have any basis for the statement that Stroustrup advocated C++ to Stepanov?

From the source itself,

"And, of course, Andy and Bjarne Stroustrup are responsible for putting STL into the standard."

"The support of Bjarne Stroustrup was crucial. Bjarne really wanted STL in the standard and if Bjarne wants something, he gets it. He is as stubborn as a mule. He even forced me to make changes in STL that I would never make for anybody else - I am also stubborn, but he is the most single minded person I know. He gets things done. It took him a while to understand what STL was all about, but when he did, he was prepared to push it through. He also contributed to STL by standing up for the view that more than one way of programming was valid - against no end of flak and hype for more than a decade, and pursuing a combination of flexibility, efficiency, overloading, and type-safety in templates that made STL possible. I would like to state quite clearly that Bjarne is the preeminent language designer of my generation."

http://www.stlport.org/resources/StepanovUSA.html

Re: Why is Rust difficult?

#225

Post by bjz_ » Mon, Jan 22, 2018, 9:51 PM UTC

sillysaurus3 wrote: post #14

Is there a way to avoid the true-believer syndrome for Rust? I want to embrace Rust, but everyone ~100% of the time comes away chanting about how awesome Rust is. So much so that it's a bit unsettling. Zealotry in general is bad, but especially in programming: once you identify as an X programmer, you lose out on ideas from Y and Z. Every tool has its flaws, but for whatever reason it seems extremely rare to discuss…

I like to look beyond to other languages, like Idris, ATS, Sixten, F*, Lean, Koka, etc. Rust has many clunky parts that become more obvious through use, even though it is still my goto language. I find often the most zealous folks are those who come from scripting language or Java/C#-ish backgrounds, and have not yet delved further into the possibilities of static types and higher order abstractions.

Re: Why is Rust difficult?

#226

Post by AnimalMuppet » Mon, Jan 22, 2018, 9:54 PM UTC

pjmlp wrote: post #224

AnimalMuppet wrote: post #222

Earlier quoted context omitted.

I disagree. Stepanov wanted to write that kind of software. He would have done it in any vehicle he found suitable. If he hadn't started with Ada, he still would have wound up writing it in some language. And C++ was among the better candidates for the language to use. It was more suitable than Ada. And, do you have any basis for the statement that Stroustrup advocated C++ to Stepanov?

From the source itself, "And, of course, Andy and Bjarne Stroustrup are responsible for putting STL into the standard." "The support of Bjarne Stroustrup was crucial. Bjarne really wanted STL in the standard and if Bjarne wants something, he gets it. He is as stubborn as a mule. He even forced me to make changes in STL that I would never make for anybody else - I am also stubborn, but he is the most single minded per…

That says that, once Stepanov had written the STL in C++, Stroutrup advocated the STL becoming part of the C++ standard.

But you said,

> Bjarne advocating him to use C++ instead [of Ada]

which your quote here doesn't substantiate at all.

Re: Why is Rust difficult?

#227

Post by Rusky » Mon, Jan 22, 2018, 9:55 PM UTC

pjmlp wrote: post #71

Rusky wrote: post #68

Earlier quoted context omitted.

Callbacks by definition create multiple paths to the data. (You can also often get away with Cell rather than RefCell.)

> Callbacks by definition create multiple paths to the data. How come, when you have a struct method, accessing field members only visible to that specific method. Something that is very easy to do with moving in lambda contexts in C++.

Because the closure itself contains a reference either to the struct or to its fields. That's the second path, and it can be invalidated by the first path either a) freeing the struct or b) changing its "shape" in memory (resizing a `Vec`, changing enum variants, etc.)

You can alternatively move the struct or its fields into the closure, but then you lose the first path. I know you're not doing that because if you were you wouldn't be having lifetime problems (and you wouldn't be able to share the state across event handlers, so it's not a great solution anyway).

Re: Why is Rust difficult?

#228

Post by unethical_ban » Mon, Jan 22, 2018, 10:16 PM UTC

rspeele wrote: post #187

unethical_ban wrote: post #175

Earlier quoted context omitted.

I write somewhat simple programs and webapps for my job, from time to time. I use Python and its standard library, some modules, and the Bottle Framework. Pulling data from APIs, doing analysis, taking some user input, editing configs, etc. I hardly ever use classes unless I'm extending a vendor library. I have never used generics. Why are generics such a critical component of a programming language that every thread…

Python is a dynamically typed language so when you say you've never used generics, that makes sense -- the concept does not apply to dynamically typed languages. But I bet you frequently use lists and dictionaries, and perhaps occasionally use higher-order functions like map, filter, and reduce. All of those would be generics in a typical statically typed language, because with static typing you don't just have "a li…

Thanks. I took a year of CS ten years ago and haven't had to do statically typed development of any size since then - certainly not developing libraries.

So essentially, containers and function overloading is damned near impossible. Got it.

Re: Why is Rust difficult?

#229

Post by smaddox » Mon, Jan 22, 2018, 10:35 PM UTC

jchw wrote: post #49

jacobush wrote: post #47

Earlier quoted context omitted.

I agree with everything, just wanted to nuance with a little thought - if cloning memory at every occasion makes the code safer and more correct but slower, that might be worth it. Always favor correct over broken. If you are coming from C to Rust in a domain that is actually better suited for Go ... well at least you are arguably better off with Rust than C, right? So I think that Rust will advance the overall state…

Oh yes, as long as the anti-patterns that emerge don't cause other bugs, they're OK; but some may lead to logical bugs. I'm not sure how likely that is, though- not enough history to go off of yet. Rust is certainly a step in the right direction. I hope the toolchain and so forth end up in a state where all forms of users can love it, though; I have seem some reasonable opposition to including Rust in kernel code, an…

I wonder if rust could be transpiled to somewhat idiomatic C... It should be easier than the other way around.

Re: Why is Rust difficult?

#230

Post by pjmlp » Mon, Jan 22, 2018, 10:53 PM UTC

AnimalMuppet wrote: post #226

pjmlp wrote: post #224

Earlier quoted context omitted.

From the source itself, "And, of course, Andy and Bjarne Stroustrup are responsible for putting STL into the standard." "The support of Bjarne Stroustrup was crucial. Bjarne really wanted STL in the standard and if Bjarne wants something, he gets it. He is as stubborn as a mule. He even forced me to make changes in STL that I would never make for anybody else - I am also stubborn, but he is the most single minded per…

That says that, once Stepanov had written the STL in C++, Stroutrup advocated the STL becoming part of the C++ standard. But you said, > Bjarne advocating him to use C++ instead [of Ada] which your quote here doesn't substantiate at all.

I got the names mixed up, it was Andrew Koenig not Bjarne.

"My attempts to implement algorithms that work on any sequential structure (both lists and arrays) failed because of the state of Ada compilers at the time."

"In 1987 at Bell Labs Andy Koenig taught me the semantics of C. The abstract machine behind C was a revelation. I also read lots of UNIX and Plan 9 code: Ken Thompson’s and Rob Pike’s programming style certainly influenced STL. In any case, in 1987 C++ was not ready for STL and I had to move on. "

"In 1993, after 5 years working on unrelated projects, I returned to generic programming. Andy Koenig suggested that I write a proposal for including my library into the C++ standard, Bjarne Stroustrup enthusiastically endorsed the proposal and in less than a year STL was accepted into the standard. STL is the result of 20 years of thinking but of less than 2 years of funding."

http://stepanovpapers.com/history%20of%20STL.pdf