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

111–120 of 199 posts

Re: Four years with Rust

#111

Post by dbaupp »

Animats wrote: post #79
dbaupp wrote: post #58

Earlier quoted context omitted.

> Rust as a language is now realizing the benefits of borrow checking. As the article points out, the syntax doesn't have to distinguish between move and assign. The borrow checker will catch a reuse of something already moved away. This turns out to be effective enough in practice that the syntax distinction isn't necessary. That wasn't obvious up front. Could you say a bit more about what you mean by "now"? You wri…

Never read "smallcultfollowing" before. The "implicitly copyable" problem is amusing. That was dealt with by Wirth in Modula 1 with the rule "if the programmer can't tell, it's up to the compiler". Thus, non-writable objects could be passed either by reference or by copy, depending on object size. This was up to the compiler. The usual rule was that anything up to 2 words in size was copied. Since the called function…

Fortunately there's no need to have read all of the (very interesting) archives of Niko's blog in this case, as the parent article linked to that post in the relevant section too.

Re: Four years with Rust

#112

Post by dbaupp »

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…

Why do you still think the compiler can't host those out of loops? LLVM is perfectly capable of doing so in many cases and you've been told as much previously, could you make your claim more specific?

Re: Four years with Rust

#113

Post by comex »

Manishearth wrote: post #100
CryZe wrote: post #93

Earlier quoted context omitted.

I feel like you could just add a version number to the Cargo.toml (cargo new would automatically set the latest one). The crate would then be built with the semantics of that version and all crates you use still use the version they were designed for (as long as the semantics can be properly translated between the individual versions).

That wouldn't work in practice. Breaking changes need not be syntactic, and probably wouldn't be syntactic -- Rust isn't going to break the language for that. There's a good chance it would be semantic breakage that can't allow interoperation between crates.

What sort of semantic breakage do you have in mind? My impression is that there are few changes of that sort that couldn't be worked around somehow.

Re: Four years with Rust

#114

Post by Animats »

pcwalton wrote: post #102
Animats wrote: post #97

Earlier quoted context omitted.

You mean there were lots of copies that made it to the back end, only to be converted to non-mutable references late in the compilation process?

How do you convert copies to non-mutable references? That involves proving things about aliasing. Even in Rust that is not that easy…

The other way round. Sometimes you want to convert non-mutable references to non-mutable copies. This is almost always a win for int, float, etc., and usually a win for anything up to 8 bits on a modern processor.

Re: Four years with Rust

#115

Post by pjmlp »

dbaupp wrote: post #110
pjmlp wrote: post #86

Earlier quoted context omitted.

It is not yet the same as Blend + Visual Studio (C#, F#, C++/CX, C++/CLI). Yes, I do use VSCode, but only for dabbling on Rust during plane/train travels. The language is not yet at a level it just fits on MS stack and is requested by our customers on their Requests For Proposals. Regarding C# Rust interoperability, it is very badly documented. I gave up on searching for it, and just used C# C++/CX Rust instead. Or I…

Have you seen the FFI omnibus http://jakegoulding.com/rust-ffi-omnibus/ which includes C# examples?

No, thanks for pointing it out.

Re: Four years with Rust

#116

Post by losvedir »

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 time that would be caught by that, and which slip through a hole in our test suite.

I've dabbled in Haskell and Rust and the whole "if it compiles it's likely to work, or at least the bugs will be significant logic ones" aspect of them is very cool.

I wonder, though, if the flipside is true? Maybe people who have a compiler and strong type system get frustrated with its rigidity over a number of years, and when they see ruby for the first time are blown away with what it can accomplish. After all, it took a number of years day in and day out with ruby to start seeing its blemishes, I wouldn't be surprised if the reverse were true.

So as someone who's now spent 4 years in the other grass, do you still find it greener? (Or am I wrong from the start, and maybe you like Rust for other reasons and its type system wasn't something that attracted you to it over ruby?)

Re: Four years with Rust

#117

Post by pjmlp »

vvanders wrote: post #109
pjmlp wrote: post #86

Earlier quoted context omitted.

It is not yet the same as Blend + Visual Studio (C#, F#, C++/CX, C++/CLI). Yes, I do use VSCode, but only for dabbling on Rust during plane/train travels. The language is not yet at a level it just fits on MS stack and is requested by our customers on their Requests For Proposals. Regarding C# Rust interoperability, it is very badly documented. I gave up on searching for it, and just used C# C++/CX Rust instead. Or I…

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.

Re: Four years with Rust

#118

Post by Manishearth »

comex wrote: post #113
Manishearth wrote: post #100

Earlier quoted context omitted.

That wouldn't work in practice. Breaking changes need not be syntactic, and probably wouldn't be syntactic -- Rust isn't going to break the language for that. There's a good chance it would be semantic breakage that can't allow interoperation between crates.

What sort of semantic breakage do you have in mind? My impression is that there are few changes of that sort that couldn't be worked around somehow.

Changes to the orphan rules, for one.

Changing the behavior and representation of stdlib APIs. You would end up with e.g. two incompatible representations of String being used across the crate boundary.

Re: Four years with Rust

#119

Post by shakna »

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…

The main languages I use with work are:

* C

* Scheme (Gambit)

* Python 3.4

* Pony

I find all of them frustrating at times.

Python's dynamism is nice, but it's so damn inflexible, requiring my to follow the One True Way.

That can be good, and makes it easier to eliminate bad code in reviewing.

But it also means that you can fight with the interpreter to do what you want.

Scheme gives me both dynamism and flexibility, with less speed tradeoffs. Yay!

However, there was someone on my team obsessed with turning everything into a macro.

What's the point of first-class functions if you just macro everything?

Also, Scheme's stdlib is purposefully small, so you sometimes need to reinvent the wheel. Thankfully Scheme makes it both easy and pleasurable to do so.

The rundown is, though fast and dynamic, code review can be painful unless you follow standards, and you might run up against, "Oh... I need to build my own FTP library", though SLIB (depending on your circumstances), can eliminate some of that.

C's compiler feels like a breath of fresh air after that.

Unless you hit a runtime error, it makes writing code a breeze, quickly and efficiently.

Unfortunately, it doesn't protect you against yourself, or lazy people on the team trying to use void pointers for everything.

So code review can be harder, and catching edge case segmentation faults can be quite difficult.

Enter, Pony.

Pony deals with the same areas Rust does, but for reasons I won't go into, when both Rust and Pony were young, my team started using Pony for a few little things.

It has been... An experience.

Pony is very type safe, it is exception safe, and data race free, all enforced by the compiler.

Which sometimes means the compiler will sit there bashing your code for a full day before you realise that you weren't writing it safe enough, and you can't just tweak it, the whole thing needs to be rewritten.

Also, the Actor Model being central to everything can be quite annoying, when you just need to fit a couple extra functions in somewhere, but you aren't sure where's best.

However:

The compiler doesn't let you screw up.

What you do write can become massively concurrent fast programs, easily.

Pony also has some fairly good documents, for such a young language that really doesn't have the backing of Rust.

So...

I get frustrated with any language I am forced to deal with over time.

I wish Python had compile-time contracts, but there is mypy to ease the pain now.

I wish Scheme had a better stdlib, but it goes against the ethos. (See RSR6 community breakdown).

I wish C was safer, but it's lack of safety makes it easier to do things like JIT.

I wish Pony was more flexible, but it'll never let me point a shotgun at my own foot.

If I spend too long in any world... It's time for a breath of fresh air.

Re: Four years with Rust

#120

Post by oxymoron »

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 I find myself missing dynamic languages even less.
Post reply on HN