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

Four years with Rust

words.steveklabnik.com

Post reply on HN
Print view View original

121–130 of 199 posts

Re: Four years with Rust

#121

Post by notheguyouthink »

moosingin3space wrote: post #24

As a relatively new Rustacean (since May 2016), I have to say that Steve has been one of the most influential people on my Rust coding style and understanding of the importance of community in a language. Prior to talking with Steve on IRC, I believed that community was secondary to language quality, but now I fully understand the importance of strong community in a programming language.

I've moved away from Rust lately (long story), but in my attempts to move to Rust i was blown away by Steve. His presence in the Rust community is staggering, and his efforts truly made a Rust newbie like myself feel very welcome.

Re: Four years with Rust

#122

Post by vvanders »

pjmlp wrote: post #117
vvanders wrote: post #109

Earlier quoted context omitted.

C# Rust is pretty straightforward. Just follow the C FFI side on Rust and C# has standard marshal mechanisms for calling C code. extern/dllimport[1] Covers most of it. There's automatic conversion for CString/string and delegates as function pointers. If you need to go deeper than that there's the marshal namespace[2]. Going through C++/CX sounds really painful. [1] - https://msdn.microsoft.com/en-us/library/e59b22c5…

> C++/CX sounds really painful. Not for someone that knows C++ since C++ARM. :) I am pretty comfortable with C# and native interop, my issue was trying to map Rust strings with .NET UTF-16 ones, including passing ownership from Rust to .NET side.

If I remember right you can specify encoding as an attribute on the extern decl.

Re: Four years with Rust

#123

Post by tatterdemalion »

losvedir wrote: post #116

Wow, four years already. Maybe you can help settle this question I've had. I'm a rubyist (like you were/are, and wycats, and a bunch of rustaceans), and I think that sort of drove my interest in rust. But after 4-5 years of ruby the dynamism which initially was super cool, has grown a little frustrating and I long for a more sophisticated type system and a compile step, since frustrating bugs crop up from time to tim…

Languages I use most are Rust and Ruby. I find the type system not frustrating, but challenging, on occasion. But only when I'm trying to write a library with a very convenient, flexible API. Its probably easier to write the first draft of this sort of library in Ruby, but in my experience what the library does under edge cases and bugs is often super unpredictable. Not so much in Rust.

I haven't had these frustrations in application code in Rust.

Re: Four years with Rust

#124

Post by cyphreak »

dang wrote: post #33
Twirrim wrote: post #29

Earlier quoted context omitted.

Odd. It was indicated in that thread that "We've banned this serial troll, of course, but the immune response from the community was particularly healthy here." I guess they got un-banned?

They certainly didn't get unbanned! And btw I vaguely recall other accounts being silly around a similar derangement-point, so perhaps this is a serial troll, which is one of the few cases where we just ban accounts immediately. The comment might have gotten unkilled because of a bug that I might have introduced yesterday. Looking into it now. Edit: yep, it turns out I introduced a bug, with the dismaying but hilario…

Lol Ive been in hn-guts for years. You fucking retards can't ban me

Re: Four years with Rust

#125

Post by kibwen »

olauzon wrote: post #78
isuraed wrote: post #20

Earlier quoted context omitted.

What kind of application s would Rust be an appropriate for? What languages is it largely meant to replace/improve on.

I've been using Rust to process fairly large amounts of streaming financial data. I am using Protocol Buffers (and evaluating Cap'n Proto) for network serialization and Kafka for buffering/queuing, and overall the library support is quite good. Previously I was using JVM languages for this purpose, but grew weary of the resource footprint, and especially the unpredictable GC pauses. I am aware of the Azul JVM which r…

What Rust libraries are you using for protobufs?

Re: Four years with Rust

#126

Post by flukus »

oxymoron wrote: post #120
losvedir wrote: post #116

Wow, four years already. Maybe you can help settle this question I've had. I'm a rubyist (like you were/are, and wycats, and a bunch of rustaceans), and I think that sort of drove my interest in rust. But after 4-5 years of ruby the dynamism which initially was super cool, has grown a little frustrating and I long for a more sophisticated type system and a compile step, since frustrating bugs crop up from time to tim…

I've worked primarily in Java and C++ for the past few years, but also with several dynamic languages. I sometimes miss the expressiveness of Python, but I can't say I'm ever frustrated by a strong type system nor does the compile step annoy me as long as my write-compile-test cycle is reasonably quick (usually achievable). With Java 8, and even more so with Rust, I'm less frustrated by the lack of expressiveness, so…

> but I can't say I'm ever frustrated by a strong type system

Never? I can't say it happens very often but occasionally the type system get's in the way, usually when you want the function to be type T1 but sometimes it'd be convenient to do a little bit more if the type is also T2.

Re: Four years with Rust

#127

Post by flukus »

losvedir wrote: post #116

Wow, four years already. Maybe you can help settle this question I've had. I'm a rubyist (like you were/are, and wycats, and a bunch of rustaceans), and I think that sort of drove my interest in rust. But after 4-5 years of ruby the dynamism which initially was super cool, has grown a little frustrating and I long for a more sophisticated type system and a compile step, since frustrating bugs crop up from time to tim…

Have you tried crystal? Looks like it could be the best of both worlds.

Re: Four years with Rust

#128

Post by Manishearth »

Animats wrote: post #108
elihu wrote: post #94

Earlier quoted context omitted.

No, but I'm pretty new to rust and haven't written enough code to know how often situations that call for unsafe code blocks come up. (My current project I'm using to learn Rust is to port a ray-tracer I wrote in Haskell. I wouldn't expect functional-style code to require a lot of unsafe blocks and I haven't needed any yet, but who knows?)

I listed two things Rust doesn't handle well without unsafe code, doubly linked lists and multidimensional arrays. Here are examples of both from popular repositories with high download numbers: - https://github.com/andelf/rust-adivon/blob/master/src/deque.... - https://github.com/andelf/rust-adivon/blob/master/src/queue.... These are all the doubly-linked list problem: struct Node { item: T, next: Option >>, prev: R…

The multidimensional array thing has nothing to do with "Rust not handling multidimensional arrays without unsafe code".

It's a mistake in the library to export that as safe, yes (filed an issue). But that unsafe code being unsafe has nothing to do with multidimensional arrays. It has to do with arrays in general.

Implementing multidimensional arrays in the language would not change the fact that they would have `get_unchecked()` and `set_unchecked()` methods. The only thing that would change would be that you might have slightly nicer syntax for them, and "one way to do it". It doesn't change the scope for optimizations, either. Subscript checks do get optimized out in 1D arrays and they should get optimized out in this case too. The way indexing works for 1D arrays is basically exactly the same; there's a pair of methods for checked and unchecked; the subscript operator is specified to do checked indexing via an Index impl, and the optimizer usually gets rid of the checks. This would not change if indexing for the 1D array type was not implemented by the language itself.

Sometimes when the invariants aren't easily seen by the optimizer it won't get optimized out, and that's when folks use unchecked indexing.

Now, there is a problem here, and that is that unchecked indexing is an unsafe operation in Rust, whether with 1-D or 2-D arrays. Could be fixed with dependent types, but that's a lot of complexity and 99% of the cases where dependent types would work would have been optimized anyway.

But this has nothing whatsoever to do with multidimensional arrays, and would not be helped at all by multidimensional arrays being in the language.

The compiler already knows enough about multidimensional arrays to be able to optimize things. Rust supports multidimensional arrays in the language. It just doesn't have syntax sugar for it; and syntax sugar can't really affect optimization.

> it might be possible to break it by instantiating it on a type with unusual semantics.

Can you give an example? A lot of the semantics are well-encoded in the marker traits, so as long as you correctly specify the right Sized/Copy/Send/Sync bounds these problems should go away.

(Panic safety could be an issue if you were calling methods on T, but you're not)

Re: Four years with Rust

#129

Post by kibwen »

dispose13432 wrote: post #82

What would be interesting if it would be possible to develop with GC on, but then if you benchmark and notice that it's too slow, turn on manual garbage collection for specific pointers. I don't know if it's possible, though (considering libraries).

Rust doesn't have a GC in the first place, so there's nothing to turn on. Even then, the fundamental hurdle with GC isn't the effect on your program's runtime, it's the effect that it has on the lifetimes of your data. GC (and RC) are means of dynamic lifetime determination. Manual memory management is static lifetime determination. The latter requires you to structure your code in a specific way, which may be less convenient for the programmer depending on the application. Converting dynamic lifetime determination to static lifetime determination then requires changing the very structure of the program itself (including how APIs work) while preserving semantics, which is beyond any existing tools.

Re: Four years with Rust

#130

Post by Manishearth »

amelius wrote: post #98
cesarb wrote: post #95

Earlier quoted context omitted.

> But reference counting may cause unpredictable pauses when large amounts of objects suddenly need to be freed (e.g. when dropping the last reference to a large array holding many references). That's still a predictable pause: it's the number of references contained within the array. If you know your array will hold at most ten references, it will take at most the time to free the ten references. Also, you know this…

> If you know your array will hold at most ten references, it will take at most the time to free the ten references. True. But if those references themselves contain references, it may become tricky to manage all of this. You basically don't want to think about it. But, like others mentioned, you can put the objects in a queue, and free them in the background. It would be interesting to know how such a solution stack…

Note that you don't need a GC to do that; the allocator can do it for you.

A lot of folks think that optimizations like having allocation arenas and spreading out deallocation pauses are unique to garbage collectors, but they're completely orthogonal to GC. You can have GCs with these optimizations, and GCs without. You can have regular allocators with these optimizations, and regular allocators without. Jemalloc does have arenas and stuff for allocation (I'm unsure if it spreads out deallocation loads). Of course, with a GC you can also defer the cost of iterating through large vectors and calling destructors.

But anyway, this only becomes a problem when you have large complicated Rc-trees in your application, which tends to not be the case in Rust.

Post reply on HN