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

Rust: Not So Great For Codec Implementing

codecs.multimedia.cx

Post reply on HN
Print view View original

41–50 of 283 posts

Re: Rust: Not So Great For Codec Implementing

#41

Post by icebraining »

simias wrote: post #5

Some of the complaints are perfectly fair (compile time, powerful but unwieldy macros). Other complaints seem a bit odder to me: > While overall built-in testing capabilities in Rust are good (file it under good things too), the fact that benchmarking is available only for limbo nightly Rust is annoying; Okay, but what are you comparing it against? Neither C or C++ have builtin benchmarking or even tests. > If you ca…

Good comment; shame about that gibe in the middle, it'd be better without making it personal.

Re: Rust: Not So Great For Codec Implementing

#42

Post by [deleted] »

Animats wrote: post #32

The only legitimate complaint there is that it's tough in Rust to get two arbitrary mutable slices into the same array. Rust wants to be sure they're disjoint, to prevent aliasing. For some matrix manipulation, this is inconvenient. It would be easier if Rust had real multidimensional arrays. If the compiler knows about multidimensional arrays, some additional optimizations are possible. For example, if you want to b…

[deleted]

Re: Rust: Not So Great For Codec Implementing

#43

Post by ditonal »

zanny wrote: post #27
Sean1708 wrote: post #11

> And don’t tell me about Bytes crate—it should not be a separate crate I'd be interested to hear the author's reasoning behind this, if it does what they want then why not use it? It's small and well written, so I don't think vetting it should be a problem. The rest of the article seems quite sensible, that comment just strikes me as a little odd.

There is a real change in mentality you have to go through if you transition from a fairly strict C/C++/ even Java background to trying out Rust. In the former languages, adding dependencies rapidly becomes a painful experience, whereas Rust does much better dependency management and automatic building than even Python (where you need a requirements file or something similar to go pull down all the deps). With Rust,…

> even Python

Off topic, but it shouldn't be better than "even Python", because Python has a really, really broken dependency system. Far more so than Java, which has Maven/Gradle which are both infinitely better than the pip/virtualenv disaster.

People complain about things like shading in Maven being complicated. What they might not realize is that pip doesn't even try to address conflicting dependencies, it will just silently give you the wrong version! You ask for A==0.2 and it will give you A==0.1 if another dependency asked for A==0.1 first. And it won't even warn you even though it's straight up broken behavior. Virtualenv makes packaging annoying since it's almost vendoring but not quite. To totally understand the packaging system forces you into the world of eggs, wheels, disutils, conflicting versions, condas, etc.

Sorry for tangent, just thought it was funny you would hold Python up as a standard of dependency excellence when it's probably the worst overall ecosystem of major languages.

Re: Rust: Not So Great For Codec Implementing

#44

Post by binarycrusader »

Sean1708 wrote: post #11

> And don’t tell me about Bytes crate—it should not be a separate crate I'd be interested to hear the author's reasoning behind this, if it does what they want then why not use it? It's small and well written, so I don't think vetting it should be a problem. The rest of the article seems quite sensible, that comment just strikes me as a little odd.

A little copying is better than a little dependency. https://go-proverbs.github.io/

As a developer at a large software company, every dependency that is not part of the language runtime itself is a pain because legal paperwork and evaluation has to be done for each individual component before I can use it / ship it.

NOTE: I am not referring to copying I would be doing, but to the crates thats have little dependencies that should consider including a copy of their little dependency instead via whatever method is appropriate for licensing.

This makes languages like Python, Go, Perl, etc. preferable over languages/projects like node.js, rust, etc. because (at least I) don't generally end up with tens/hundreds of dependencies since the standard library is rich enough for most work.

Additionally, I personally despise have many, small dependencies because it means I have more to think about and manage. Instead of just being able to think about the version of the compiler/standard library I'm using, I have to consider every individual crate.

I'm well aware of why rust chose to make certain tradeoffs with crates, but having numerous pieces of what many of us consider "basic functionality" as a third-party dependency is frustrating. Languages with richer standard libraries have spoiled us all.

Re: Rust: Not So Great For Codec Implementing

#45

Post by nolok »

zanny wrote: post #27
Sean1708 wrote: post #11

> And don’t tell me about Bytes crate—it should not be a separate crate I'd be interested to hear the author's reasoning behind this, if it does what they want then why not use it? It's small and well written, so I don't think vetting it should be a problem. The rest of the article seems quite sensible, that comment just strikes me as a little odd.

There is a real change in mentality you have to go through if you transition from a fairly strict C/C++/ even Java background to trying out Rust. In the former languages, adding dependencies rapidly becomes a painful experience, whereas Rust does much better dependency management and automatic building than even Python (where you need a requirements file or something similar to go pull down all the deps). With Rust,…

Haven't used Rust yet, is it kind of similar to Go where any file can simply import and then Go knows how to fetch and build when needed ? And then when you remove the calls (eg during a refactor) the compiler force you to remove the imports too, stopping the infinite bloat caused by "no one really knows if we still need this" that can be common in other language.

I really liked that "dependancy as part of the language and build tool".

Of course, Go still had its own dependancy issues (versionning, availability, ...) that they now work on, but that was a step in a direction I quite liked.

Re: Rust: Not So Great For Codec Implementing

#46

Post by jeeyoungk »

myusernameisok wrote: post #36
Animats wrote: post #32

The only legitimate complaint there is that it's tough in Rust to get two arbitrary mutable slices into the same array. Rust wants to be sure they're disjoint, to prevent aliasing. For some matrix manipulation, this is inconvenient. It would be easier if Rust had real multidimensional arrays. If the compiler knows about multidimensional arrays, some additional optimizations are possible. For example, if you want to b…

> The only legitimate complaint there is that it's tough in Rust to get two arbitrary mutable slices into the same array. Rust wants to be sure they're disjoint, to prevent aliasing. For some matrix manipulation, this is inconvenient. I've only looked into Rust briefly, but I thought this was the point of unsafe blocks? You can roll your own multi-dimensional array data structure using unsafe blocks if you're certain…

Unsafe allows you to dereference raw pointers and foreign-function calls, but you cannot go around the borrow checker, which is what's causing annoyance.

That said, you can create raw and dereference raw pointers, which lets you to do the above.

Re: Rust: Not So Great For Codec Implementing

#47

Post by kbenson »

cwyers wrote: post #30
simias wrote: post #5

Some of the complaints are perfectly fair (compile time, powerful but unwieldy macros). Other complaints seem a bit odder to me: > While overall built-in testing capabilities in Rust are good (file it under good things too), the fact that benchmarking is available only for limbo nightly Rust is annoying; Okay, but what are you comparing it against? Neither C or C++ have builtin benchmarking or even tests. > If you ca…

> Now this whole section feels a lot like "I'm trying to code in Rust like in C and it doesn't work and it frustrates me". Who's fault is that? Rust seems like an attempt to take a lot of foreign concepts to C/C++ programmers and dress them up in ALGOLy syntax. If you look at Rust's influences page[1], there's stuff from ML, Haskell, Erlang... and yet Rust code examples I've seen all look like "slightly weird C++." I…

Any language deserves to be assessed on its own merit, not what people's preconceptions are. I still believe that a lot of the flak Perl gets is from people that see that it looks somewhat like C and make assumptions, and are surprised when it turns out that it has a few surprises up its sleeve (e.g. context). The fault lies with the person who purports to learn a language, but then doesn't reassess their assumptions when confronted with evidence to the contrary.

Re: Rust: Not So Great For Codec Implementing

#48

Post by [deleted] »

myusernameisok wrote: post #36
Animats wrote: post #32

The only legitimate complaint there is that it's tough in Rust to get two arbitrary mutable slices into the same array. Rust wants to be sure they're disjoint, to prevent aliasing. For some matrix manipulation, this is inconvenient. It would be easier if Rust had real multidimensional arrays. If the compiler knows about multidimensional arrays, some additional optimizations are possible. For example, if you want to b…

> The only legitimate complaint there is that it's tough in Rust to get two arbitrary mutable slices into the same array. Rust wants to be sure they're disjoint, to prevent aliasing. For some matrix manipulation, this is inconvenient. I've only looked into Rust briefly, but I thought this was the point of unsafe blocks? You can roll your own multi-dimensional array data structure using unsafe blocks if you're certain…

[deleted]

Re: Rust: Not So Great For Codec Implementing

#49

Post by nolok »

ditonal wrote: post #43
zanny wrote: post #27

Earlier quoted context omitted.

There is a real change in mentality you have to go through if you transition from a fairly strict C/C++/ even Java background to trying out Rust. In the former languages, adding dependencies rapidly becomes a painful experience, whereas Rust does much better dependency management and automatic building than even Python (where you need a requirements file or something similar to go pull down all the deps). With Rust,…

> even Python Off topic, but it shouldn't be better than "even Python", because Python has a really, really broken dependency system. Far more so than Java, which has Maven/Gradle which are both infinitely better than the pip/virtualenv disaster. People complain about things like shading in Maven being complicated. What they might not realize is that pip doesn't even try to address conflicting dependencies, it will j…

I find it super weird how Python is still in this state while even PHP has managed to get something good going.

To me, this is a clear case of trying to fix a broken system whereas starting from scratch would be much better.

Re: Rust: Not So Great For Codec Implementing

#50

Post by ekidd »

moosingin3space wrote: post #15
modalduality wrote: post #4

Not a Rust expert, but some thoughts on the negatives. > Compilation time is too large Can you try compiling incrementally? https://blog.rust-lang.org/2016/09/08/incremental.html . Might still only be on nightly. > And, on the similar note, benchmarks. I agree, profiling as well isn't as full featured as in more mature languages. Clojure, incidentally has great benchmarking due to being on the JVM. > Also the tuple a…

I've found that using Linux tools like perf work well for profiling Rust, since it's compatible with C.

Yup! perf and kcachegrind actually work nearly as well for Rust as they do for C/C++. It's all just another LLVM compiler that emits debug info, as far as Linux tools are concerned.
Post reply on HN