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

Re: Rust: Not So Great For Codec Implementing

#161

Post by steveklabnik » Tue, Aug 01, 2017, 9:27 PM 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…

At the point you want to handle them, you use match instead of ?, and then handle the cases you care about.

Re: Rust: Not So Great For Codec Implementing

#162

Post by davemp » Tue, Aug 01, 2017, 9:29 PM UTC

adrianratnapala wrote: post #151

legulere wrote: post #118

Earlier quoted context omitted.

Just a tiny nitpick: Only signed integer overflow is undefined, unsigned integer overflow follows modulo arithmetics. It's pretty much impossible to remember all those details.

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…

Thinking about hardware is definitely the move when writing C.

This is the major struggle with abstraction. We want to remove the burden of knowing the ins and outs of the target architecture. Inevitably, we create trouble and fall on our faces when it turns out that the hardware is still in fact there and doesn't like when we ignore it.

It's really an impossible problem. One can't account for every architecture when designing a language. Likewise, one can't feasibly remember the details of every architecture while programming. Honestly I'd be interested to see some tools that approach the problem from a direction other than maximum portability. Not that I think they'd be popular or "good".

Re: Rust: Not So Great For Codec Implementing

#163

Post by jandrese » Tue, Aug 01, 2017, 9:29 PM UTC

adrianratnapala wrote: post #151

legulere wrote: post #118

Earlier quoted context omitted.

Just a tiny nitpick: Only signed integer overflow is undefined, unsigned integer overflow follows modulo arithmetics. It's pretty much impossible to remember all those details.

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…

I wonder how many processors there are in use these days that don't use 2s complement. I don't think I've ever seen one.

Re: Rust: Not So Great For Codec Implementing

#164

Post by agumonkey » Tue, Aug 01, 2017, 9:31 PM UTC

flavio81 wrote: post #144

davemp wrote: post #58

> And that’s why C is still the best language for systems programming—it still lets you to do what you mean (the problem is that most programmers don’t really know what they mean) Honestly after a ~1yr of embedded C co-op/intership experience, I'm familiar enough but not too entrenched to say that C is not that great for embedded/systems. When you're dealing at the hardware architecture level you need more detail tha…

> And that’s why C is still the best language for systems programming I think the only reason C is very popular for systems programming is that it allows you to do most of what you could do in assembler, but in an easier-to-work way. So basically C is an "acceptable, easier-to-use assembler", but far from ideal, because of the reasons you point out. Honestly, the popularity of C itself is due to the success of UNIX,…

I was VERY surprised to read about the linguistic traits of [B]CPL .. C was a pragmatic regression in that regard.

Re: Rust: Not So Great For Codec Implementing

#165

Post by Manishearth » Tue, Aug 01, 2017, 9:31 PM UTC

greenhouse_gas wrote: post #125

Manishearth wrote: post #55

Earlier quoted context omitted.

> is it kind of similar to Go where any file can simply import You declare your crate dependencies in a Cargo.toml file. Rust does proper versioning of dependencies so having a separate manifest is desirable. Within your code you declare the existence of a crate via `extern crate` and then you can use it wherever. > the compiler force you to remove the imports too it warns.

Do you know if there are plans for rustfmt to auto-import like gofmt does? In the sense that if a crate is available (in the .toml file) and you reference it, rustfmt will automatically insert the required "import" and "use".

This would probably be an RLS thing.

There's a separate tool called rustfix in development that can apply the suggestions given by the compiler, so it could theoretically prompt for these.

Re: Rust: Not So Great For Codec Implementing

#166

Post by davemp » Tue, Aug 01, 2017, 9:32 PM UTC

jandrese wrote: post #163

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…

I wonder how many processors there are in use these days that don't use 2s complement. I don't think I've ever seen one.

Certainly not general CPUs, but there are probably domain specific processors out there that use something else. Why would you want to design a domain specific processor and still use C? Beats me.

Re: Rust: Not So Great For Codec Implementing

#167

Post by sedachv » Tue, Aug 01, 2017, 9:36 PM UTC

Nelson69 wrote: post #149

flavio81 wrote: post #144

Earlier quoted context omitted.

> And that’s why C is still the best language for systems programming I think the only reason C is very popular for systems programming is that it allows you to do most of what you could do in assembler, but in an easier-to-work way. So basically C is an "acceptable, easier-to-use assembler", but far from ideal, because of the reasons you point out. Honestly, the popularity of C itself is due to the success of UNIX,…

For big computers, C is good for systems programming because everyone else uses it and because of the titanic effort that has been put in to building really good optimizing C compilers. UNIX came along but when C killed pascal, IBM, Microsoft, everybody was on C's dick. On small embedded computers, I think C is popular because it's so easy to build something that resembles a C compiler. The fact is, undergrad compile…

> You can almost build a yacc grammar that will read C and emit assembly.

I have looked at a lot of C parsers and compilers and have written a C to Lisp transpiler and this statement is ludicrously wrong. You cannot even parse C code with yacc because of typedefs. The grammar of C is context-sensitive. And this is after the C code has been preprocessed, something that also cannot be done with yacc.

C compilers are easy to port to different machines, but that is because C is a very poor language in terms of features and control flow constructs. For the limited amount of things that C gives you as a language it also comes with a huge amount of complicated baggage when it comes to implementation and corner cases.

Re: Rust: Not So Great For Codec Implementing

#168

Post by JoeAltmaier » Tue, Aug 01, 2017, 9:43 PM UTC

sedachv wrote: post #167

Nelson69 wrote: post #149

Earlier quoted context omitted.

For big computers, C is good for systems programming because everyone else uses it and because of the titanic effort that has been put in to building really good optimizing C compilers. UNIX came along but when C killed pascal, IBM, Microsoft, everybody was on C's dick. On small embedded computers, I think C is popular because it's so easy to build something that resembles a C compiler. The fact is, undergrad compile…

> You can almost build a yacc grammar that will read C and emit assembly. I have looked at a lot of C parsers and compilers and have written a C to Lisp transpiler and this statement is ludicrously wrong. You cannot even parse C code with yacc because of typedefs. The grammar of C is context-sensitive. And this is after the C code has been preprocessed, something that also cannot be done with yacc. C compilers are ea…

True about the preprocessor. But the typedef issue is usually (trivially) solved with a link between the symbol table and the scanner.

Re: Rust: Not So Great For Codec Implementing

#169

Post by k__ » Tue, Aug 01, 2017, 9:49 PM UTC

zanny wrote: post #63

ditonal wrote: post #43

Earlier quoted context omitted.

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

My language development went from C -> C++ -> Java -> Python. So when I got there and figured out pip was a thing (or easy_install back in the day) it was a major innovation at the time. Additionally, for anyone coming from almost all compiled native languages, a native environment like Rust with better dependency management than Python (which, as you say, and in retrospect, is pretty broken) is a bit of a mind screw…

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?

Re: Rust: Not So Great For Codec Implementing

#170

Post by steveklabnik » Tue, Aug 01, 2017, 9:55 PM UTC

k__ wrote: post #169

zanny wrote: post #63

Earlier quoted context omitted.

My language development went from C -> C++ -> Java -> Python. So when I got there and figured out pip was a thing (or easy_install back in the day) it was a major innovation at the time. Additionally, for anyone coming from almost all compiled native languages, a native environment like Rust with better dependency management than Python (which, as you say, and in retrospect, is pretty broken) is a bit of a mind screw…

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.