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

Rust's 2017 Roadmap

blog.rust-lang.org

Post reply on HN
Print view View original

251–260 of 274 posts

Re: Rust's 2017 Roadmap

#251

Post by stable-point »

hyperpape wrote: post #164
flukus wrote: post #111

Earlier quoted context omitted.

As far as fighting the borrow checker goes, how familiar are you with more functional style programming approaches, mainly immutability? I'm extremely new to rust so I don't know if fighting the borrow checker is in my near future or something I will largely avoid.

Mutability makes it worse, but there are at least some issues with borrowing that have nothing to do with mutability. If your experience is with garbage collected languages, I suspect you'll encounter errors that surprise you.

Could you provide an example where the borrowing would cause issues for immutable data?

I'm still learning Rust, but I thought the fact that you could have as many immutable borrows as possible would limit what errors the borrow checker could throw at you.

Re: Rust's 2017 Roadmap

#252

Post by lmm »

jeffdavis wrote: post #249
lmm wrote: post #198

Earlier quoted context omitted.

Are the with-GC options really that much better? Rust or OCaml's advantages over C++ seem much the same as OCaml's advantages over, say, Java, no?

I don't quite follow the question and/or implication.

Nostrademons said "for programmers that can use GC, there are already very good solutions out there", which I understood to mean "the advantages of most ML-family languages over other languages that require GC are smaller than the advantages of Rust over other languages that do not require GC". Which I was questioning.

Re: Rust's 2017 Roadmap

#253

Post by iopq »

kibwen wrote: post #242
iopq wrote: post #201

Earlier quoted context omitted.

And it should be white-space sensitive! 1. Writing a tab character introduces the equivalent of {} for blocks, but not other uses of {}. 2. You can still use {} for blocks if need be 3. Everyone uses elastic tabstops in their editor oh yeah, and parens are optional for function application

> parens are optional for function application I think you've gotten confused somehow... Rust++ is a pure concatenative programming language, function application is wholly unnecessary.

Stop, I can only get so hard before an unsafe drop in blood pressure

Re: Rust's 2017 Roadmap

#254

Post by yarper »

PeCaN wrote: post #117
yarper wrote: post #76

Earlier quoted context omitted.

https://github.com/ninjabear/nickel-bootstrap You might be interested in this

Why would someone trying to learn Rust be interested in a web framework? I think they ought to learn how Rust works first, or they'll just be more confused.

Different strokes for different folks

Re: Rust's 2017 Roadmap

#255

Post by ainar-g »

steveklabnik wrote: post #239
ainar-g wrote: post #96

Earlier quoted context omitted.

Okay, thank you again for your time!

Ah! I understand now. Handlers aren't meant to be nested like this. That is, it's always going to break this way, because the handler needs to live as long as the request and response, so creating a sub-handler is not ever going to live long enough. So yes, the solution is to not implement Handler for your UserIndexHandler; then you can just call it. I bet there's something larger you could do as well, but I don't ha…

Yeah, I figured that out as well, but thank you for finding the time to analyse the code and write an answer. I appreciate it and may be on my fourth attempt at actually learning Rust :)

Re: Rust's 2017 Roadmap

#256

Post by steveklabnik »

ainar-g wrote: post #255
steveklabnik wrote: post #239

Earlier quoted context omitted.

Ah! I understand now. Handlers aren't meant to be nested like this. That is, it's always going to break this way, because the handler needs to live as long as the request and response, so creating a sub-handler is not ever going to live long enough. So yes, the solution is to not implement Handler for your UserIndexHandler; then you can just call it. I bet there's something larger you could do as well, but I don't ha…

Yeah, I figured that out as well, but thank you for finding the time to analyse the code and write an answer. I appreciate it and may be on my fourth attempt at actually learning Rust :)

No problem. :)

Re: Rust's 2017 Roadmap

#257

Post by jeffdavis »

lmm wrote: post #252
jeffdavis wrote: post #249

Earlier quoted context omitted.

I don't quite follow the question and/or implication.

Nostrademons said "for programmers that can use GC, there are already very good solutions out there", which I understood to mean "the advantages of most ML-family languages over other languages that require GC are smaller than the advantages of Rust over other languages that do not require GC". Which I was questioning.

Interesting point.

I don't know if I'd pick Java as a comparison point because the ecosystem is unimaginably large, so it's hard to compare to Haskell/OCaml. A better one might be Golang or ruby.

I think ML languages just never made the case that other languages are bad enough for the particular thing someone is doing now, e.g. a web app. If you hit a NULL, you get an exception, track it down, probably not a huge issue. The best case could be made for ML on security grounds, but unfortunately nobody cares about security.

On the other hand, people were convinced that C/C++ were bad after decades of people saying so. But people didn't feel like they had an alternative until rust came along.

Re: Rust's 2017 Roadmap

#258

Post by devopsproject »

kibwen wrote: post #101
tormeh wrote: post #83

I once said that Rust would never become really, Java-level, popular. Mostly because I thought it focused too much on performance to the detriment of elegance and productivity. I'm not so sure anymore. This is a step in the right direction. That said, what makes me most nervous about Rust is pointers and mutability being mandatory for certain things, rather than the absence of books. Maybe that's just me, though. Any…

> I once said that Rust would never become really, Java-level, popular. I like Rust, but IMO no language will ever again be Java-level popular (not even Java!) in the same way that e.g. there will never again be a band as big as the Beatles. Technological contexts have changed such that niche languages can now successfully thrive and counteract the lower switching cost that comes with a monoculture; while certain lan…

c#?

Re: Rust's 2017 Roadmap

#259

Post by tom_mellior »

adwn wrote: post #240
tom_mellior wrote: post #220

Earlier quoted context omitted.

> If you write a library in Python, you can use it from Python. Or from C. Or from any language that can bind to C. Like Rust. I'm fairly sure the other languages you listed also allow calling from C and hence from Rust, as well as among each other. > not every object requires its own heap allocation Sure. That doesn't change if you add a GC to Rust: Objects won't magically become non-stack-allocable if they were sta…

> Or from C. Or from any language that can bind to C. Like Rust. I'm fairly sure the other languages you listed also allow calling from C and hence from Rust, as well as among each other. But then you have to include a foreign language runtime! Together with all the headaches and interoperability complications that entails. How many .NET applications do you know which include a JVM runtime, or how man Java libraries…

> Now compare that to the number of applications or libraries (in any language) that directly or indirectly depend on a library written in C or C++.

Every significant C++ library I've ever used had its own stupid intransparent memory use conventions and invariants and segfaulted on you if you unknowingly violated them. The only difference is that you call some libraries "libraries" and other libraries "runtimes". I don't think that divide is all that sharp.

> a GC probably won't have a positive effect on most programs written in idiomatic Rust, therefore there's no need

It would allow new idioms that many people would find useful because not all code is code where performance is more inportant than clarity.

> (contrary to what you claim)

I didn't claim that Rust needs a GC to be Rust, I claimed that Rust needs a GC to be a more popular, more-widely-regarded-as-useful language than today's Rust.

Re: Rust's 2017 Roadmap

#260

Post by flukus »

olivier1664 wrote: post #192

I would love to see some improvement in the desktop GUI libs. - GTK is a painfull to install. - Conrod: I was unable to do an hello world application with it. It just miss some tutorial. - KISS-UI: some dll to install - Qt: not totally free - Neon to plug on Electron: I'm not sure if I can do some callback from Rust to the GUI with this method. I finnally give up to play with Electron in javascript.

> GTK is a painfull to install.

Also no longer cross platform. LibUI (https://github.com/andlabs/libui) looks promising but I don't think the rust bindings are being worked on.

Post reply on HN