4 ms·

I think this really over emphasises the difficulty in writing code with a different programming language. The hard part is generally finding a good solution to

by lhnz 10y ago

I think this really over emphasises the difficulty in writing code with a different programming language. The hard part is generally finding a good solution to the problem you're working on... When I've worked with Rust, 90% of the time I found it just as easy as working with something like JavaScript or Python. However 10% of the time it becomes much much much more difficult. And those times I often end up going in the wrong direction, reading documentation and trying to apply a solution which doesn't fit (i.e. no syntax that will make things work because I am fundamentally doing the wrong thing). For example, the other day I tried solving a problem in which I had to do an in-place matrix transposition on some slices and I was getting a bunch of compile-time errors for everything I tried. I googled later on and found this [0], which makes it seem like I would have needed to use `unsafe`, however maybe that's just a misunderstanding and there is a safe way. People are making it out to be harder than it actually is. The semantics aided by the compile-time errors make most problems quick to solve. It's very expressive and gives types which help to avoid fragile code (e.g. `Result` and `Option`). The only times that it becomes difficult are when you need to reach for a solution but do not know what to search for, and I think this could be improved if some of the errors linked to related topics, and once the IDE support improves. [0] https://athemathmo.github.io/2016/08/29/inplace-transpose.html https://athemathmo.github.io/2016/08/29/inplace-transpose.ht...

bjz_ 10y ago
I like it because usually that 10% of the time is where I should really be focusing my attention.
drbawb 10y ago
Just glancing at that code: the use of unsafe is more or less only there to avoid initialization & bounds checking. Basically it's an optimization, and I don't think there's anything there that couldn't be accomplished in safe Rust. I have an idea as to why the author approached it this way: typically Rust wouldn't let you take out a mutable borrow to a vector while you're iterating over it. If Rust did allow that and you modified the collection then the iterator might reference freed memory! A common way around this is to just use a typical `for <range>` loop and index into the array directly to limit the scope of the mutable borrow to _a single iteration of the loop_ and not _the lifetime of the iterator._ However indexing in Rust incurs a speed penalty for bounds checking, and the unsafe code here lets you skip those checks. Really all the unsafe code is doing is saying: "I promise to initialize `rowcol` entries, and I won't try to access anything outside `rowcol`. Please don't burn cycles worrying about it Friend Compiler." It looks to me as though this could've been written as a vector initialized with all zeroes (which possibly isn't even that expensive, since modern OSes heavily optimize the case of giving you a zeroed page.) Then in the hot loop the author could've just used iterators to avoid the bounds check. Using an iterator for that should be fine in this instance since you're immutably iterating over one matrix, and the only mutation happening is in the new transposed matrix. That all being said: transposing the matrix in-place would run into exactly that scenario. now you could still do it in safe rust, you would only need to add the unsafe code if you wanted to turn off the bounds checking for maximal performance.

by lhnz 10y ago

bjz_ 10y ago

I like it because usually that 10% of the time is where I should really be focusing my attention.

drbawb 10y ago

Just glancing at that code: the use of unsafe is more or less only there to avoid initialization & bounds checking. Basically it's an optimization, and I don't think there's anything there that couldn't be accomplished in safe Rust. I have an idea as to why the author approached it this way: typically Rust wouldn't let you take out a mutable borrow to a vector while you're iterating over it. If Rust did allow that and you modified the collection then the iterator might reference freed memory! A common way around this is to just use a typical `for <range>` loop and index into the array directly to limit the scope of the mutable borrow to _a single iteration of the loop_ and not _the lifetime of the iterator._ However indexing in Rust incurs a speed penalty for bounds checking, and the unsafe code here lets you skip those checks. Really all the unsafe code is doing is saying: "I promise to initialize `rowcol` entries, and I won't try to access anything outside `rowcol`. Please don't burn cycles worrying about it Friend Compiler." It looks to me as though this could've been written as a vector initialized with all zeroes (which possibly isn't even that expensive, since modern OSes heavily optimize the case of giving you a zeroed page.) Then in the hot loop the author could've just used iterators to avoid the bounds check. Using an iterator for that should be fine in this instance since you're immutably iterating over one matrix, and the only mutation happening is in the new transposed matrix. That all being said: transposing the matrix in-place would run into exactly that scenario. now you could still do it in safe rust, you would only need to add the unsafe code if you wanted to turn off the bounds checking for maximal performance.