Rust: Not So Great For Codec Implementing • Hacker News Board

Re: Rust: Not So Great For Codec Implementing

#231

Post by pjmlp » Wed, Aug 02, 2017, 6:48 AM UTC

phkahler wrote: post #39

mrec wrote: post #22

Earlier quoted context omitted.

If anyone's interested, this is the (epic!) discussion thread for "Getting explicit SIMD on stable Rust": https://internals.rust-lang.org/t/getting-explicit-simd-on-s... It still wouldn't compete with really good hand-tuned asm, but it might help reduce the perf/usability tradeoff a bit.

I'd just like to see 2,3, and 4 element vectors as a first class citizen in C, C++, or Rust. These are incredibly common for so many things it's hard for me to understand this omission. I want to be able to pass them by value and as return values from function. I want to do operations like a=b+c with vectors without creating classes or overloading operators. For a lot of people the SIMD instructions are about paralle…

They are coming to ANSI C++.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p019...

Re: Rust: Not So Great For Codec Implementing

#232

Post by pjmlp » Wed, Aug 02, 2017, 7:03 AM UTC

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

A current problem with " should just use crates" is that cargo only works with source code dependencies, not binary libraries.

So each new crate added to your project ends up increasing the overall build time, which gets exponentially bad if you happen to add a dependency to a crate than happens to have a big dependency list.

I have a very basic word counting application with a GUI written in Gtk-rs, a fresh build straight out of "git clone" takes a few minutes, mainly thanks to Pango.

Re: Rust: Not So Great For Codec Implementing

#233

Post by slededit » Wed, Aug 02, 2017, 7:30 AM UTC

wahern wrote: post #199

legulere wrote: post #177

Earlier quoted context omitted.

The C standard actually has many alternatives to undefined behavior: implementation-defined behavior like the propagation of the high-order bit when a signed integer is shifted right, unspecified behavior like the order in which the arguments to a function are evaluated. Related to those are the implementation-defined, unspecified and indeterminate (unspecified or trap) values. Now unspecified values are tricky again…

https://kristerw.blogspot.com/2016/02/how-undefined-signed-o...

Unless you are paid by the line that should either work as "expected" (i.e. wrap) or produce an error about a meaningless comparison.

Is it worth a few developer days worth of work to track down a hard to repro bug that only happens with hard to debug optimizations enabled?

Re: Rust: Not So Great For Codec Implementing

#234

Post by deathanatos » Wed, Aug 02, 2017, 7:39 AM UTC

wahern wrote: post #190

adrianratnapala wrote: post #151

Earlier quoted context omitted.

These things originate in hardware variations. Apparently all architectures use binary the same way so unsigned overflow just drops the MSB. But signed integers aren't always two's complement, so there is variation. See, no tedious rules to remember, you just have to understand how computers work. But the C standards call such things "undefined behaviour" rather than "platform specific" behaviour, and then try to pre…

At least one extant (or recently extant) system has to emulate unsigned, modulo arithmetic. This can be handled by the C compiler transparently, however. From the C compiler documentation: | Type | Bits | sizeof | Range | +---------------+------+--------+----------------------------------------+ | ... | | unsigned long | 36 | 4 | 0 to (2^36)-2 (see the following note) | ... Note: If the CONFORMANCE/TWOSARITH or CONFO…

A range of 0 to (2^36)-2 implies that there's one bit combination not mentioned here (that range has only 2 ^ 36 - 1 values; 36 bits can store 2 ^ 36). What's the last combination used for?

Re: Rust: Not So Great For Codec Implementing

#235

Post by test9753 » Wed, Aug 02, 2017, 8:21 AM UTC

gwbas1c wrote: post #160

steveklabnik wrote: post #82

Earlier quoted context omitted.

There's a whole chapter in the second edition of the book devoted to error handling https://doc.rust-lang.org/book/second-edition/ch09-00-error-...

Yes, that chapter painfully explains my point. Most of the replies pointed out the new ? operator, which I'll have to check out. (One of the things that I like about the Rust community is that they constantly improve.) The thing is, if you've only handled errors via return codes in C, then Rust's system is a major improvement. The challenge comes once you've programmed with exceptions that have inheritance. It's pret…

Existing error handling facilities in Rust may not suit every use-case. For me personally, the difficulty with the `?` operator (and try! macro) is that the File + Line info about the source of error is lost. Also, I want something simpler than the approach taken by the `error-chain` crate. My current solution is to use some custom macros to check for errors and display an execution trace (example here: https://play.rust-lang.org/?gist=a7fb903ce2bbb37914ab380d342... )

Re: Rust: Not So Great For Codec Implementing

#236

Post by Sean1708 » Wed, Aug 02, 2017, 8:21 AM UTC

pjmlp wrote: post #232

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

A current problem with " should just use crates" is that cargo only works with source code dependencies, not binary libraries. So each new crate added to your project ends up increasing the overall build time, which gets exponentially bad if you happen to add a dependency to a crate than happens to have a big dependency list. I have a very basic word counting application with a GUI written in Gtk-rs, a fresh build st…

> So each new crate added to your project ends up increasing the overall build time,

That's only a problem the first time you compile though, isn't it?

Re: Rust: Not So Great For Codec Implementing

#237

Post by Sean1708 » Wed, Aug 02, 2017, 8:37 AM UTC

binarycrusader wrote: post #109

floatingatoll wrote: post #75

Earlier quoted context omitted.

I believe they mean, each time a source code is downloaded and used that contains a LICENSE file, a legal review must occur. So if it's bundled into one licensed work "Rust With Lots Of Crates Bundled", then that's one form to fill out, but if it's "Rust" and then "Download And Use Crates", that's one form per addon to fill out.

Yes, anytime source code is retrieved that isn't an existing, approved version, legal review of some sort must occur. This includes even referencing it despite what the other poster mistakenly believed I was implying.

I see what you mean, would something like cargo-vendor[0] help with this?

[0]: https://github.com/alexcrichton/cargo-vendor

Re: Rust: Not So Great For Codec Implementing

#238

Post by pjmlp » Wed, Aug 02, 2017, 8:42 AM UTC

Sean1708 wrote: post #236

pjmlp wrote: post #232

Earlier quoted context omitted.

A current problem with " should just use crates" is that cargo only works with source code dependencies, not binary libraries. So each new crate added to your project ends up increasing the overall build time, which gets exponentially bad if you happen to add a dependency to a crate than happens to have a big dependency list. I have a very basic word counting application with a GUI written in Gtk-rs, a fresh build st…

> So each new crate added to your project ends up increasing the overall build time, That's only a problem the first time you compile though, isn't it?

A problem that I usually don't have with C++[0], Java[1] or .NET[2], thanks to the build systems support for binary libraries.

[0] - I eschew header only libraries, only if there is no technical way around them (e.g. templates).

[1] - I can AOT compile with Excelsior JET, IBM J9, JamaicaVM, PTC, , Oracle Java 9 (Linux x64 for the time being), ...

[2] - I can AOT compile with Mono, NGEN, .NET Native, CoreRT, IL2CPP, ...

Re: Rust: Not So Great For Codec Implementing

#239

Post by barrkel » Wed, Aug 02, 2017, 8:44 AM UTC

pjmlp wrote: post #226

barrkel wrote: post #192

Earlier quoted context omitted.

TP's OOP was modelled after Apple's Object Pascal. It was an awkward ugly implementation that had e.g. slicing problems and weird initialization syntax, and was fairly quickly deprecated when Delphi came around.

I loved Object Pascal, and it was my introduction to OOP, literally. As I had to give a class on OOP to fellow students at the technical school as exchange for having access to Turbo Pascal 5.5. Never was a big fan of some of the Object Pascal changes made by Delphi's class model, specially the fact that it was a kind of lost the opportunity to introduce RC alongside those changes. Which eventually lead to the schizo…

RC only for strings originally, later dynamic arrays, variants and interfaces; I no longer recall if the legacy OLE automation classes did automatic RC, but I don't think they did (beyond explicit RC in constructor / destructor implementations).

I maintained the Delphi compiler front end for 6 years or so, adding closures, enhanced RTTI, a bunch of work on generics and 64-bit porting, and some other things that ultimately didn't see the light of day. I have a long list of things I don't like about the Delphi language, corner cases you only really become fully aware of when living with the workarounds they force on the codebase.

Overload resolution is an almost wholly unspecified mess, for example. It started out Java-style, but the definition of more specific isn't locked down, and everything from strong typedefs (type TFoo = type TBar;) to closures (MyFunc(methodRef) - do you mean to pass method ref or result of calling method ref), to ranges (are smaller ranges more specific? what about overlapping ranges?)... and don't get me started on all the different string types.

Re: Rust: Not So Great For Codec Implementing

#240

Post by k__ » Wed, Aug 02, 2017, 9:12 AM UTC

steveklabnik wrote: post #170

k__ wrote: post #169

Earlier quoted context omitted.

The Python devs I worked with always envied me for npm. I asked them if they don't have something similar with pip, but seems like npm is a whole different level. Cargo should even be better than npm. On the other hand I always asked myself if they couldn't simply use Nix?

I can't simply use Nix; it doesn't support Windows.

It doesn't run on the Linux subsystem?