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

One year of Rust

blog.rust-lang.org

Post reply on HN
Print view View original

71–80 of 110 posts

Re: One year of Rust

#71

Post by pcwalton »

msbarnett wrote: post #68
pcwalton wrote: post #63

Earlier quoted context omitted.

Well, I do use it regularly for testing Servo. There's a debugger harness run as part of the test suite too. (Not to say we shouldn't fix whatever is causing your problem, though!)

I can make it work if I feed full file paths to the debugger using syntax I can't remember off the top of my head. Maybe that's one way some scripts might be functioning? I'll copy and past this into a Github issue when I have a sec. edit: https://github.com/rust-lang/rust/issues/33674

Thanks! Forwarding to the appropriate people.

Re: One year of Rust

#72

Post by Lewisham »

vvanders wrote: post #66
pcwalton wrote: post #57

Earlier quoted context omitted.

> fn cycle(self) -> Cycle where Self: Clone I agree that a summary would be good, but this doesn't require a PL Ph.D. It means "cycle is a method that moves its receiver and returns a Cycle object of the same type of the receiver, and only works if the receiver is cloneable". The trickiest thing here, IMHO, is move semantics, which is something fundamental to Rust in general.

Yup, I've got the same feeling here. If you've spent more than a cursory time with Rust this is pretty straightforward. You'd represent this in Java(minus move semantics, because Java has nothing like that) via: class IntoIter { public Cycle { ... } ... } Where Clone is just an interface that knows how to clone its value.

Fair enough; some more noodling over the signature made it a bit more obvious than it seemed banged out at the back of an OSCON presentation.

I think the point still holds. Maybe just not for that one.

Re: One year of Rust

#73

Post by vvanders »

Lewisham wrote: post #72
vvanders wrote: post #66

Earlier quoted context omitted.

Yup, I've got the same feeling here. If you've spent more than a cursory time with Rust this is pretty straightforward. You'd represent this in Java(minus move semantics, because Java has nothing like that) via: class IntoIter { public Cycle { ... } ... } Where Clone is just an interface that knows how to clone its value.

Fair enough; some more noodling over the signature made it a bit more obvious than it seemed banged out at the back of an OSCON presentation. I think the point still holds. Maybe just not for that one.

The thing is what you linked is the docs of an implementation not the interface.

I guess I've just had a different experience. I come from almost no PL/ML background and I've found the Iterator interface in Rust(along with Option/Result) to be some of the most impressive, clear things about the language.

Re: One year of Rust

#74

Post by EugeneOZ »

jdright wrote: post #65
EugeneOZ wrote: post #39

Earlier quoted context omitted.

There is unofficial plugin: https://github.com/intellij-rust/intellij-rust and works very well: https://www.youtube.com/watch?v=mHa7QlFz7io (small video recorded by me)

Is that Racer happening? It look like there is still a lag in the completion suggestion... and that is a huge problem (mainly when using it as to find things).

No, this plugin works without Racer. I use it every day and I don't see any problems with code completion. Except of cases where code completion isn't supported yet :) But it's all personal and better to try - it's free.

To clarify: I'm not author of this plugin.

And I tried Racer with Microsoft Visual Code plugin - it works without any lags, very fast. Just fails sometimes :)

Re: One year of Rust

#75

Post by kibwen »

nilved wrote: post #50
_redwire wrote: post #49

One thing I'm really hoping to see happen in Rust is more development to make it more "functional," as in suitable for a functional programming style. It's already so close and, while I don't want to bring up the higher-kinded types discussion, things like stronger support for closures being returned from functions are just not quite there yet for me. I filled out the survey that was sent around and mentioned some of…

I think this ship sailed when Rust removed function purity. Rust is a Scala, not a Haskell.

Nah, Scala does support higher-kinded types. :P Rust just isn't an especially functional language, though it may seem that way relative to C.

Re: One year of Rust

#76

Post by killercup »

_redwire wrote: post #53
nilved wrote: post #50

Earlier quoted context omitted.

I think this ship sailed when Rust removed function purity. Rust is a Scala, not a Haskell.

So I'm actually not super familiar with Scala. I do know Haskell a little bit. Could you elaborate on what you think the implications are for Rust's development down the functional route are? I've heard about the potential for support for higher-kinded types, which makes me think there could actually be a strong incentive to be able to do more functional programming in Rust if people started working on monad implemen…

There was a very nice comparison between the type systems of Rust and Haskell a few days back on reddit: https://www.reddit.com/r/rust/comments/4jh8hv/question_about...

Re: One year of Rust

#77

Post by tatterdemalion »

kibwen wrote: post #75
nilved wrote: post #50

Earlier quoted context omitted.

I think this ship sailed when Rust removed function purity. Rust is a Scala, not a Haskell.

Nah, Scala does support higher-kinded types. :P Rust just isn't an especially functional language, though it may seem that way relative to C.

The grandparent was probably referring to the fact that Rust allows mutation and side effects, which Scala also does. "Functional" is not a very meaningful term, but Rust has about equivalent support for higher kinded polymorphism as SML or OCaml (in that there is no first class support but another language feature can be used to implement it), which are certainly functional languages. And of course, many lisps are considered functional languages despite not having types at all.

Re: One year of Rust

#78

Post by pjmlp »

nilved wrote: post #50
_redwire wrote: post #49

One thing I'm really hoping to see happen in Rust is more development to make it more "functional," as in suitable for a functional programming style. It's already so close and, while I don't want to bring up the higher-kinded types discussion, things like stronger support for closures being returned from functions are just not quite there yet for me. I filled out the survey that was sent around and mentioned some of…

I think this ship sailed when Rust removed function purity. Rust is a Scala, not a Haskell.

Having started functional programming with Lisp and Caml Light, with Prolog on the side for logic programming, it feels strange this modern notion that Haskell is the be all and end all of FP.

Re: One year of Rust

#79

Post by Manishearth »

msbarnett wrote: post #61
pcwalton wrote: post #54

Earlier quoted context omitted.

Bug reports of specific problems would be very appreciated! We emit fairly complete DWARF, but debuggers tend to be finicky about the exact subset of DWARF they accept.

I'll try to submit a report later. It's exactly what it sounds like, though. $ cat hello.rs fn main() { println!("Hello world!"); } $ lldb -v lldb-350.0.21.9 $ uname -a Darwin mycomp 15.5.0 Darwin Kernel Version 15.5.0: Tue Apr 19 18:36:36 PDT 2016; root:xnu-3248.50.21~8/RELEASE_X86_64 x86_64 $ rustc --version rustc 1.8.0 $ rustc -g hello.rs $ ./hello Hello world! $ lldb hello (lldb) target create "hello" Current exe…

I think this is a known issue relating to some lldb versions no longer treating unknown languages as C; which got fixed in lldb upstream but may not have been released yet.

Re: One year of Rust

#80

Post by lossolo »

I've tried to learn Rust twice because i think it's great idea (memory safety with C++ performance) BUT... Rust seems even more complicated than C++ for me, really i find C++11/14 a lot easier to reason about than Rust. I am not sold on functional programming also. Dangling pointers/memory leaks are problems of C and old C++ but not modern C++. I don't remember when i last seen any memory problems in modern c++ code base where ownership is encapsulated inside smart pointers. I think Rust is great and would have a lot more attention and adoption if version 1.0 would ship in 2009. I think Rust is too late into the game. That's why probably only mozilla is really using it and dropbox for really small part of their infrastructure from known players. From what i researched big part of "friends" that use Rust in production are using it because of hype? I am not sure exactly why but some of their use cases for sure not need systems programming language. Maybe it will not end up like D which tried to solve similar problem.

EDIT: It's funny how people down vote my personal feelings about the language without any anti-argument or comment. It seems having other opinion than "Rust is GREAT" is not desirable here.

Post reply on HN