Rust's 2018 roadmap • Hacker News Board

Re: Rust's 2018 roadmap

#221

Post by golergka » Tue, Mar 13, 2018, 1:33 PM UTC

lucideer wrote: post #218

golergka wrote: post #215

Earlier quoted context omitted.

This is all good and well, but there are also projects that need to be delivered in this imperfect world and imperfect tools that we have. And I'd rather assume the worst of the world in the beginning and take appropriate precautions than debug some tooling problem right on the day of the release.

You're right, economic incentives do usually favour ignoring/avoiding difficult problems and increasing technical debt. but I'd generally like to approach that as a pragmatic balance between what should be done and what needs to be in the short-term.

> ignoring/avoiding difficult problems and increasing technical debt

Technical debt, like any debt, shouldn't be blindly avoided, but instead managed in a smart way. But anyway - it is not my debt or problems to solve. Most of the tools I'm talking about are closed source, and I wouldn't be able to do anything with them except hacking around.

Re: Rust's 2018 roadmap

#222

Post by kiriakasis » Tue, Mar 13, 2018, 2:10 PM UTC

camplum wrote: post #181

chmln wrote: post #153

Earlier quoted context omitted.

> 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…

> It means you have already spewed your privilege in believing that the diverse opinions are already bad/dumb ones.

this sounds uncalled for in my opinion. there is a difference between saying that something is "needed" and that something is "good". The parent simply said that the statement on the need of diversity was likely political.

Diversity is something worth investing into, many agree with this, but to saying that a project needs it implies that you cannot succeed (whatever your idea of success is) without it.

EDIT: I am totally ok with a project choosing to support diversity both within itself and in the broader community, i believe that many ways of doing it are extremely beneficial. yet often that _is_ a political stance and can be discussed as one.

Re: Rust's 2018 roadmap

#223

Post by Sean1708 » Tue, Mar 13, 2018, 2:36 PM UTC

kvark wrote: post #35

aturon wrote: post #20

Earlier quoted context omitted.

There are changes that require a new edition, particularly around new keywords. However, to be clear, editions are primarily a marketing/communication/project management tool. They give us a way to try to bring together a number of threads of work into a coherent whole, with a high level of polish across the board (including docs and tooling), and then to present that work to the world with a clear story. It's worth…

That's what I've been afraid of. When epochs were announced, I thought it is kinda nice to have backwards compatibility while introducing breaking changes. It's a good technical concept. Trying to change it's role into "marketing/communication/project management tool" out of a sudden is what puzzles me. > It's worth comparing this to the recent Firefox Quantum release I don't think it's a fare comparison. Firefox Qua…

> (if you don't consider deprecating the old plugins one, that is)

I honestly can't think of a bigger breaking change that FF could have made.

Re: Rust's 2018 roadmap

#224

Post by smoe » Tue, Mar 13, 2018, 3:02 PM UTC

logicallee wrote: post #184

smoe wrote: post #166

Earlier quoted context omitted.

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'…

I mentioned CRUD web apps because first, I get the feeling that at least a bunch of the comments talking about high learning curve of Rust are from web developers expecting as fast an on-boarding as say in Python, Node.js or Go and more importantly because I'm a web developer myself with a lot of domain knowledge -- building a simple crud web app (or in Rust context more api) is going to be fairly easy to me in pretty much any language that provides some basic tools for it.

In dsp on the other hand I'm starting completely afresh and more time is spent learning the fundamentals and brushing up on the math than coding. I know pretty well what kind of things I want to build and understand the higher level concepts, but don't know yet how to get there. Meaning at the moment Rusts' learning curve doesn't get in the way of reaching my goals.

What I have done so far in Rust is some simple wave form generation and modulation and writing it to wav files (via an encoder library). Which kinda is the audio equivalent of "hello world" so I wouldn't call it application.

My first actual application I'm aiming to build by the end of the book, is a basic midi playable polyphonic synthesizer with the usual features and some effects. If this is realistic or not, I don't know. But I reckon if Rust gets in the way it is not because of the language but lack of resources and available libraries for the domain.

Re: Rust's 2018 roadmap

#225

Post by technological » Tue, Mar 13, 2018, 3:15 PM UTC

anderspitman wrote: post #127

krylon wrote: post #114

Okay, after two failed attempts (mainly due to lack of motivation, I hasten to admit), I think it's time for me to learn me some Rust. I spent a long time working mostly with dynamically typed languages, but over the past few years, I have slowly drifted back into statically typed territories. At home, I have used Go a lot, at work, I have grown to like C#. Rust kind of looks like the next logical step along that tra…

I've had a couple false starts over the past 2 years or so as well. This time I'm determined to reach "critical mass" where I'm comfortable reaching for Rust when I need to hack together a new CLI tool, web service, whatever. I won't quit this time if you don't.

Me 2, Let me know if you want to learn together by building a CLI tool or stuff. I think it would be great to help each other and learn along the way.

Re: Rust's 2018 roadmap

#226

Post by swfsql » Tue, Mar 13, 2018, 3:37 PM UTC

jayroh wrote: post #163

swfsql wrote: post #79

I'm an average programmer, but I honestly don't get the goal of inclusiveness [edit: from the Rust 2017 Survey Results] > Diversity and inclusiveness continue to be vital goals for the Rust project at all levels. I mean.. lifetime checks won't stop working if you don't consider yourself heterosexual or anything o.O The two matters simply don't mix in my head

If you're open to learning about why it _actually is_ important, there are some good resources out there to give you a little more context as to the reasons why. You could read this: http://www.latimes.com/business/technology/la-diversity-righ... Or maybe if you like listening instead: https://www.gimletmedia.com/reply-all/52-raising-the-bar So, while it's a nuanced and complicated topic, there are actual reasons why…

What if it happens that you can only hire one person, and one "externally looks" homogeneous to the rest of the hired workers, but the other one "externally looks" like a minority member,

but you think that the first one, based on your own judgment, will be more "out of the box" when having solutions for the company.

So no matter what you think, the one from a minority is certainly preferable for hiring?

Re: Rust's 2018 roadmap

#227

Post by swfsql » Tue, Mar 13, 2018, 3:41 PM UTC

andrewflnr wrote: post #168

swfsql wrote: post #85

Earlier quoted context omitted.

I see, but this is still a political issue. Maybe a lot of minorities people just voted "no" in that survey question. Because.. why excluding people based on their skin color is discriminatory, but including people based on their skin color is not discriminatory?

There is a difference between "including" and "not excluding" people based on color or whatever. It's (officially, anyway) about removing barriers, not roping people in. I'll grant in practice it's a blurry line. So, yeah, it's a political issue, but an open source project is necessarily a political entity by virtue of being made of people. You can't escape making political decisions, and since "inclusivity" mostly j…

I completely agree, and I'd like to add that if one is "not excluding", asking for color skin should be forbidden. Because knowing color skin cannot possibly help one to "not exclude".

In other words, "not excluding" implies not asking for color skins.

Re: Rust's 2018 roadmap

#228

Post by kowdermeister » Tue, Mar 13, 2018, 4:02 PM UTC

steveklabnik wrote: post #217

kowdermeister wrote: post #210

Earlier quoted context omitted.

Long for sure, but I really miss practical use cases, for example: > Asked how long the string is, you might say 12. However, Rust’s answer is 24: I get that, `.len()` is tricky, but why not include an easy, common way to determine character length of a string in the documentation?

There are different concepts of length depending on what you need. And not all of them are in the standard library, and hence, the book. “Character length” is not a Unicode concept, for example.

Obviously, but it's a page about strings and a hint about how to get exact character length would be nice to have. But sure, the answer is just a googling away.

Re: Rust's 2018 roadmap

#229

Post by kbenson » Tue, Mar 13, 2018, 5:45 PM UTC

smoe wrote: post #224

logicallee wrote: post #184

Earlier quoted context omitted.

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'…

I mentioned CRUD web apps because first, I get the feeling that at least a bunch of the comments talking about high learning curve of Rust are from web developers expecting as fast an on-boarding as say in Python, Node.js or Go and more importantly because I'm a web developer myself with a lot of domain knowledge -- building a simple crud web app (or in Rust context more api) is going to be fairly easy to me in prett…

> But I reckon if Rust gets in the way it is not because of the language but lack of resources and available libraries for the domain.

I guess you'll get to play with the FFI capabilities by incorporating some C libs then. :)

Re: Rust's 2018 roadmap

#230

Post by kbenson » Tue, Mar 13, 2018, 6:01 PM UTC

swfsql wrote: post #226

jayroh wrote: post #163

Earlier quoted context omitted.

If you're open to learning about why it _actually is_ important, there are some good resources out there to give you a little more context as to the reasons why. You could read this: http://www.latimes.com/business/technology/la-diversity-righ... Or maybe if you like listening instead: https://www.gimletmedia.com/reply-all/52-raising-the-bar So, while it's a nuanced and complicated topic, there are actual reasons why…

What if it happens that you can only hire one person, and one "externally looks" homogeneous to the rest of the hired workers, but the other one "externally looks" like a minority member, but you think that the first one, based on your own judgment, will be more "out of the box" when having solutions for the company. So no matter what you think, the one from a minority is certainly preferable for hiring?

> So no matter what you think, the one from a minority is certainly preferable for hiring?

I think the idea is to include as best as possible what may be hard to assess factors such as difference of experience, culture and upbringing and using that, make a decision as the hirer who you think will benefit the company best, not to choose a person and then override who you think is best just because of one factor.

All this really takes is valuing an outside perspective. An yes, sometimes just the skin color can be enough, if that skin color has affected how people see them or any unique problems it has come with. That does mean it is or must be enough though, just that it may be something worth including.

As a simple example, I'll leave you this: How We Accidentally Made a Racist Videogame.[1] It should be easy to see how a slightly more diverse group of developers and/or QA testers could have avoided that problem. Similar things exist with dealing with other cultures or countries, or people with disabilities, or if you're really unlucky, just people of the other sex if you're unlucky enough to have that much of a homogeneous set of coworkers.

1: http://www.kotaku.co.uk/2017/01/12/how-we-accidentally-made-...