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

171–180 of 253 posts

Re: Rust's 2018 roadmap

#171

Post by marshray »

kibwen wrote: post #118
marshray wrote: post #108

Earlier quoted context omitted.

> C++ had an era of malaise where conflicting implementations of the standard library across a dozen+ platforms led to the complete abandonment of it by the mid 2000s What are you talking about? C++ has continually been in the top 5 on the TIOBE list. https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/cplusplus/

I'm loathe to dignify TIOBE with analysis, but even by TIOBE's own numbers C++ has fallen from 15% in 2001-2004, to 10% in 2005-2013, to 5% in 2013-2018. And given that C++ was ranked #2 as early as 1993, even the era of 15% was likely a fall from an earlier height. Compare C, which has held steady since 2001 (with the exception of that huge anomalous dip last year which is being corrected (and which caused C to trig…

Right, I wouldn't rely on TIOBE for anything more precise than "has continually been in the top 5".

Re: Rust's 2018 roadmap

#172

Post by zenhack »

debaserab2 wrote: post #78
smoe wrote: post #65

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). As someone not only new to Rust but also systems programming in general I especially appreciate that the chapters include actual reasoning about why things are how they are in Rust and that they seem pretty open abou…

I also just started learning rust over the past few weeks. While I'm still grasping with some of the core concepts of the language (like ownership), I do feel like there's adequate documentation and resources out there that I'll get there. What I really like is how helpful the compiler is. It's fast and the errors feel well explained and relevant to the problem in my code. It almost feels like I'm developing on a REP…

There's definitely a lot of syntax that makes the language look bigger than it is. When I realized Rust's oo-style dot notation/self/Self was just sugar for plain old function calls, suddenly a big chunk of the language I thought I hadn't learned yet turned out not to just not exist.

Re: Rust's 2018 roadmap

#173

Post by teacpde »

conradev wrote: post #110
pimeys wrote: post #43

I've been spending a good majority of my work hours with Rust and especially writing network services using Tokio. When things work there, it is very reliable, fast and has a tiny footprint with resources. Now reading the promise to get a stable async/await and also having Tokio 0.2 in the pipeline, I'd say async Rust might be ready for prime time. Don't get me wrong here, I enjoy using Tokio, but I'd say if you're n…

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

Re: Rust's 2018 roadmap

#174

Post by nogenerics123 »

harpocrates wrote: post #87
gilmi wrote: post #73

Earlier quoted context omitted.

> a common problem I have in Haskell is figuring out _which_ monad a certain `do` block is using. Does type signatures not help in that case?

Yes, when people use them. There is no really elegant way of adding a type annotation to a `do` block. (do x It isn't uncommon to have to scan the `do` block for some statement that constrains the monad somehow. This is a known and discussed problem, so I'll refer you to the article usually reference around this issue: https://wiki.haskell.org/Do_notation_considered_harmful

Many times do blocks are passed into functions so the monad type can be looked up from the function definition.

    flip runStateT s $ do ...
To find the type of this do block I don't have to scan it I just have to look up the definition of runStateT.

If I have to add an explicit annotation to a do block it's simple enough to separate it into another function.

    justSix :: Maybe Int
    justSix = do
        x
I read the article and couldn't find the part where they said that type inference is a problem with do notation.

Re: Rust's 2018 roadmap

#175

Post by zenhack »

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…

HKT would somewhat ease the type signature question; as I understand it in the rust community being able to parametrize over ownership/mutability is the big selling point that gets discussed. You could instead have a single Fn, and stuff may require Fn or Fn, rather than a separate FnMut. There's no keyword now, but owned could be part of that dance too. There's obviously the question of how to deal with backwards compatibility though.

There are more convenient ways of composing monads than monad transformers; extensible effects are a lot easier to work with.

Ulttimately I agree though, monads are not the right abstraction for a systems language. I'm quite happy using them in languages like Haskell and OCaml, where you've not only got a garbage collector solving the tricky ownership qustions for you, it's also faster than it has any right to be, so you can basically ignore the overhead of heap allocating a closure.

They become much less attractive when you're in a problem domain where you actually want to worry about fiddly details around memory allocation. This is much smaller space than people think it is, but it's what Rust is for.

Re: Rust's 2018 roadmap

#176

Post by skeleton »

matthewmacleod wrote: post #97
chmln wrote: post #82

Earlier quoted context omitted.

Its all just fluff. Might have something to do with Mozilla being left-leaning. Skin color has nothing to do with non-lexical lifetimes. They will say that they value diversity of thoughts that may come when you have people with various backgrounds, but it is much more primitive in practice, always boiling down to companies acquiring people with certain skin color or gender just for the sake of it. There are well-kno…

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.

Okay but what does one actually do to make the community more 'diverse and welcoming'? What is preventing a particular person from contributing to the project?

Are contributions currently being rejected based on personal traits?

I think the answer to this question would help me a lot in understanding any of this.

Re: Rust's 2018 roadmap

#177

Post by solidsnack9000 »

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

There are many axes along which a community can be non-inclusive. I will always remember being made fun of in #gentoo for using Haskell. (Although I can not argue with the general guidance to install Gentoo.)

Once you see that worthy men can be made to feel unwelcome, merely due to their choice of programming language, it makes one wonder if other worthy people do not feel unwelcome when they are treated dismissively in some other way, as by by referring to every one as “men” indifferently.

Re: Rust's 2018 roadmap

#178

Post by webkike »

xedrac wrote: post #161
awestroke wrote: post #121

Earlier quoted context omitted.

Discrimination, noun: > the unjust or prejudicial treatment of different categories of people, especially on the grounds of race, age, or sex. Is it unjust to make sure people from a minority do not feel alienated?

Is it just to alienate the majority to encourage the minority? A lot of companies promoting "diversity" certainly think so.

The rust team isn't alienating anyone

Re: Rust's 2018 roadmap

#179

Post by zkomp »

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.

In this minefield, I really miss the irony tag here.

I do, really do, belive this should just boil down to: - don't be a jerk - don't discriminate

Re: Rust's 2018 roadmap

#180

Post by GolDDranks »

skybrian wrote: post #72
tiuPapa wrote: post #67

Do we get the fearless concurrency part of rust on wasm?

Webassembly (and JavaScript) are single-threaded. The platform has web workers, but they are more like processes since they mostly don't share data. There do seem to be some proposals to add threads, though. Also, it's possible (but hard) to build cooperative multithreading on top of it; apparently Go is going to do that.

Note that there is also single-threaded concurrency, since concurrency is not parallelism. The upcoming async stuff is going to help with this.
Post reply on HN