Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust's 2018 roadmap

blog.rust-lang.org

Post reply on HN
Print view View original

181–190 of 253 posts

Re: Rust's 2018 roadmap

#181

Post by camplum »

chmln wrote: post #153
matthewmacleod wrote: post #97

Earlier quoted context omitted.

The only fluff I’m seeing here is your nonsense about about “taboo” or “uncomfortable truths”, which are usually a hallmark or someone with nudge-nudge-wink-wink dogwhistle objectionable opinion. Let’s make it simple - having a diverse and welcoming community makes a project more attractive to contributors, and means that it’s more likely to succeed in the long term.

> Let’s make it simple - having a diverse and welcoming community makes a project more attractive to contributors, and means that it’s more likely to succeed in the long term. Sure, I never argued against fostering a welcome environment for contributors. We need more of this especially in open source, where contributions can be sorely lacking. Instead I question the notion that Rust needs to have some sort or diversi…

I would love to see what these "success" metrics are. A happy and stress free workplace can be success to someone. To make money is a by-product of an efficient workforce powered to make decisions. If you have a group of people who always make the same kinds of decisions, based on the same experiences you will have the same kinds of companies making the same mistakes. i.e. Me too, white only hiring, etc. NO ONE EVER TOLD EACH OTHER DO THIS DUMB SHIT, it was built in the culture.

If someone who looks at the world different because they have seen different things, offers you a perspective, it's worth a listen. You are somehow conflating a diverse opinion already to a non-educated and therefor less useful one.

"See - bias". The fact that you reject said diversity is the argument. It means you have already spewed your privilege in believing that the diverse opinions are already bad/dumb ones.

Re: Rust's 2018 roadmap

#182

Post by kbenson »

staticassertion wrote: post #164
Rusky wrote: post #149

Earlier quoted context omitted.

That... does seem to be the goal.

No no no, you see, by making minorities safer we must then be making the majority feel less safe! Safety is a zero sum game after all.

It upsets me that the reason this joke plays so well is because we can see how this kind of thinking has become common in the world. Take your upvote, but know you've also made me sad. :/

Re: Rust's 2018 roadmap

#183

Post by akotulski »

Rusky wrote: post #107
harpocrates wrote: post #64

Earlier quoted context omitted.

You've changed my mind on adding special syntax for `async`, generators, and results (`?`). I previously thought it was a big mistake given that these all generalize as monads (granted, there is some ground to be covered before such an abstraction would fit in Rust). What I hadn't considered: specialized syntax leads to better error messages for the most common cases. That's probably quite a good thing, especially si…

> (granted, there is some ground to be covered before such an abstraction would fit in Rust) I would claim that such an abstraction is fundamentally incompatible with Rust. Not only does Rust lack the means to write a Monad trait on which to build do-notation, but even given HKT there's no single type signature that the various monad instances would fit. `Result` and `Option` are type constructors while `Iterator` an…

Algebraic effects are new hotness in FP research. They are easier to compose than monads and they can express things like async/await naturally. However, I'm not sure this approach works as intended with imperative programs where code will have (side) effects sprinkled everywhere. And there is no GC in rust

Re: Rust's 2018 roadmap

#184

Post by logicallee »

smoe wrote: post #166
logicallee wrote: post #162

Earlier quoted context omitted.

>I started learning Rust over the weekends and I think the second edition "The Rust Programming Language" is among the best introductory books on a programming language I have read (well half way so far). I'm genuinely curious (this is a straightforward question): have you personally gotten applications you've written to compile yet, or are you still learning theoretically? (I haven't used rust, but have read a few c…

Depends what you mean by application. So far I only worked on simple exercises and translated some algorithms I have previously written in Python. Compiling them is fairly easy since the compiler output is very helpful and IDE integration is quite good for still being new. Main painpoint is, that I haven't managed to get the debugger work yet. Rust does have a high learning curve but to me it seems justified by its g…

Thanks for the straightforward answer, and the clarifications too.

Starting at the end, a DSP is definitely what I mean by "application" (the reason I used the word 'application' is to exclude a straightforward 'hello world' copied from the exercise book.)

For example, have you gotten any audio processing application to work ta you've written, or anything like that?

I'm surprised you mention CRUD web apps, as I didn't think Rust was used in that domain much. (i.e. on the server side like php or even Go might be.)

Re: Rust's 2018 roadmap

#185

Post by steveklabnik »

derefr wrote: post #157
steveklabnik wrote: post #137

Earlier quoted context omitted.

> Rust assumes the developers learning about it have specific goals: namely, to evaluate Rust vs. C/C++. We don't assume that. From https://doc.rust-lang.org/book/second-edition/ > This book is written for a reader who already knows how to program in at least one programming language. After reading this book, you should be comfortable writing Rust programs. We’ll be learning Rust through small, focused examples that…

Sorry if I wasn't clear; I didn't mean to imply that the Rust maintainers assume any prerequisite knowledge of C/C++. I rather meant that the goal of someone learning Rust "in anger" is for that person to quickly decide if Rust is the best language to use to solve the problem they have. And, if Rust is even a candidate in their solution-space, then usually C and C++ (and sometimes also Go or D or C#) are the other ca…

Thanks for the clarification; sorry for misunderstanding :)

Re: Rust's 2018 roadmap

#186

Post by steveklabnik »

syeaj wrote: post #158
steveklabnik wrote: post #138

Earlier quoted context omitted.

I think your parent is saying "Rust isn't a great language to learn programming with", that is, if you've never programmed, Rust is not a great choice. I agree, but I don't think it's inherent; I think it's a lack of resources targeted at this demographic.

While the book is really top notch (I'm usually not a fan of programming language books), there's something to be said for not introducing all concepts at once. A scripting language has many of the same concepts, but not lifetimes, etc. Not to say objects are intuitive!

Thanks!

While this is true, those languages have stuff Rust doesn't as well. Take Ruby, for example: Rust doesn't have method_missing, or eigenclasses, or inheritance. "How do I know which method gets invoked" is much more complex.

Re: Rust's 2018 roadmap

#187

Post by steveklabnik »

curun1r wrote: post #165
steveklabnik wrote: post #138

Earlier quoted context omitted.

I think your parent is saying "Rust isn't a great language to learn programming with", that is, if you've never programmed, Rust is not a great choice. I agree, but I don't think it's inherent; I think it's a lack of resources targeted at this demographic.

I do think a lot of it is inherent in the design choices that Rust has made. Rust, as a language, has a fairly large surface area. There's a lot of different syntactical and conceptual lessons that need to be learned by new Rust programmers. Compare that to, say, Lisp. My first programming class at Berkeley was taught in Scheme, which is basically Lisp. Within the first 20 minutes of the first day, the professor had…

> Compare that to, say, Lisp.

This makes me think of the module reform RFC:

> In other words, while there are simple and consistent rules defining the module system, their consequences can feel inconsistent, counterintuitive and mysterious.

See also Rich Hickey's "simple made easy."

I do think Rust has some inherent learning curve, but I also don't necessarily agree with this framing. Simpler languages aren't always simpler to actually write software in.

Re: Rust's 2018 roadmap

#188

Post by steveklabnik »

teacpde wrote: post #173
conradev wrote: post #110

Earlier quoted context omitted.

> Trouble like a couple of pages of errors, that are just not readable at all This is indeed very frustrating. I've had to learn to translate between "what the compiler is telling me" and "what the issue actually is".

Is that because async is involved? I have minimal experience with async Rust code, but my experience with Rust compiler errors has been superb so far. The compiler always tells me exactly where things went wrong and the error messages are quite informative.

Yes, but also no. That is, async is done via futures, which means that you're composing a lot of futures together, which means that you have a long type signature, which means that if you get a type mismatch, you get quite a long error, where 99% of the type is the same.

Re: Rust's 2018 roadmap

#190

Post by zbraniecki »

kbenson wrote: post #182
staticassertion wrote: post #164

Earlier quoted context omitted.

No no no, you see, by making minorities safer we must then be making the majority feel less safe! Safety is a zero sum game after all.

It upsets me that the reason this joke plays so well is because we can see how this kind of thinking has become common in the world. Take your upvote, but know you've also made me sad. :/

exactly. I also gave them my sad upvote for a really spot on commentary on the diversity and inclusion issues. :(
Post reply on HN