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

61–70 of 110 posts

Re: One year of Rust

#61

Post by msbarnett »

pcwalton wrote: post #54
msbarnett wrote: post #40

Earlier quoted context omitted.

> Debugging, building, testing, packaging all seems pretty well handled. Eh, debugging is a mess, at least on OS X. Rust advertises LLDB support, but it seems semi-broken. Listing source is non-functional and just setting a break-point requires a lot of hand-holding.

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 executable set to 'hello' (x86_64).
    (lldb) source list
    (lldb)
    (lldb) b 2
    error: No selected frame to use to find the default file.
    error: No file supplied and no default file available.
I don't see how the core team could be unaware of this unless literally no one has done even a cursory glance at OS X & LLDB in months.

Re: One year of Rust

#62

Post by zcdziura »

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

There are some libsodium bindings that you can use[1]. Otherwise, there's not a ton of "Made In Rust" crypto libraries, though I know some are being written. I myself am working on a prime number generator library[2], which is fairly usable in its current state.

1. https://crates.io/crates/sodiumoxide 2. https://crates.io/crates/pumpkin

Re: One year of Rust

#63

Post by pcwalton »

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…

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!)

Re: One year of Rust

#64

Post by aleksi »

steveklabnik wrote: post #56
aleksi wrote: post #52

> While much of Dropbox’s back-end infrastructure is historically written in Go I'm sorry, but much of Dropbox’s back-end infrastructure is historically written in Python, not Go. Go is a new addition to the stack. Only a small and very specific part of Dropbox is written in Rust, where things like an effectiveness of CPU caches becomes important. Other back-end code is still being written in Go.

I think it depends on what you mean by "historically". My understanding is that the server-side was largely in go for a long time now, but you're also right that before that, it was Python. While you're right that it's a small and specific part, it's also the core of the whole thing, so it's a very significant part. Dropbox isn't moving away from Go generally any time soon, as far as I know: it's still very much the…

> server-side was largely in go for a long time now

I guess I call "a new" what you call "a long time now". Dropbox is using Go for about 3 years.

Re: One year of Rust

#65

Post by jdright »

EugeneOZ wrote: post #39
sargun wrote: post #10

Earlier quoted context omitted.

I really wish that Jetbrains had a Rust IDE. I love their Go, and Erlang plugins for IntelliJ, Java with IntelliJ, and Clion with C. Without them, I don't think I could be anywhere as effective as I am. I tried to pickup Rust, but I was super frustrated by the code/compile/run cycle with the current plugin. But, hopefully more users will make that better.

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

Re: One year of Rust

#66

Post by vvanders »

pcwalton wrote: post #57
Lewisham wrote: post #37

Earlier quoted context omitted.

I'd say rustdoc is pretty rough. It's very hard to navigate the rust stdlib vs, say, Go, and when you do find what you want, it's often specified in some very cryptic manner that seems to require a PL PhD. It is a really big barrier to adoption because it's very hard to find out what functionality is or is not offered. Here's an example: I want to iterate over a set. Easy, right? No. http://static.rust-lang.org/doc/m…

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

Re: One year of Rust

#67

Post by blaisio »

Lewisham wrote: post #37
merb wrote: post #4

Earlier quoted context omitted.

Except the tooling, could be better. A language like Rust will benefit from a rich IDE a lot. But still the language is great.

I'd say rustdoc is pretty rough. It's very hard to navigate the rust stdlib vs, say, Go, and when you do find what you want, it's often specified in some very cryptic manner that seems to require a PL PhD. It is a really big barrier to adoption because it's very hard to find out what functionality is or is not offered. Here's an example: I want to iterate over a set. Easy, right? No. http://static.rust-lang.org/doc/m…

I agree that the rust docs need work, but I disagree with your example. cycle is just a method defined as part of the Iterator implementation - it's just like a method you might define to implement an interface in Java. JavaDocs actually have the same layout as the Rust documentation in this case: you have to actually click on the method to find out how it works. This is also how docs for other languages are often laid out as well.

Re: One year of Rust

#68

Post by msbarnett »

pcwalton wrote: post #63
msbarnett wrote: post #61

Earlier quoted context omitted.

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…

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

Re: One year of Rust

#69

Post by steveklabnik »

aleksi wrote: post #64
steveklabnik wrote: post #56

Earlier quoted context omitted.

I think it depends on what you mean by "historically". My understanding is that the server-side was largely in go for a long time now, but you're also right that before that, it was Python. While you're right that it's a small and specific part, it's also the core of the whole thing, so it's a very significant part. Dropbox isn't moving away from Go generally any time soon, as far as I know: it's still very much the…

> server-side was largely in go for a long time now I guess I call "a new" what you call "a long time now". Dropbox is using Go for about 3 years.

Yeah, maybe that's entirely it. Words are tough. :)

Re: One year of Rust

#70

Post by zyngaro »

aleksi wrote: post #52

> While much of Dropbox’s back-end infrastructure is historically written in Go I'm sorry, but much of Dropbox’s back-end infrastructure is historically written in Python, not Go. Go is a new addition to the stack. Only a small and very specific part of Dropbox is written in Rust, where things like an effectiveness of CPU caches becomes important. Other back-end code is still being written in Go.

So Dropbox is no longer using Python for it's backend code ?
Post reply on HN