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

Re: Rust: Not So Great For Codec Implementing

#191

Post by freshhawk » Tue, Aug 01, 2017, 11:23 PM UTC

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…

Yeah, as someone who's done a deep dive into Python dependency management (mostly because virtualenv has some insane ideas about how to make shell tools) that bit made me laugh.

There are a lot of great things about Python, but dependency management is right there under the GIL on the list of things that are very painful.

Re: Rust: Not So Great For Codec Implementing

#192

Post by barrkel » Tue, Aug 01, 2017, 11:25 PM UTC

glandium wrote: post #186

WalterBright wrote: post #183

Earlier quoted context omitted.

TP was indeed a fine project. But it wasn't OOP (which was very hot at the time) and TP was very customized to the PC, meaning it had no penetration outside of DOS. TP died when DOS died.

TP 5.5 (1989) had OOP. https://en.wikipedia.org/wiki/Turbo_Pascal#Object-oriented_p... I only started using TP with version 6, so all I know is OOP TP...

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.

Re: Rust: Not So Great For Codec Implementing

#193

Post by ryl00 » Tue, Aug 01, 2017, 11:49 PM 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…

Fortran?

Re: Rust: Not So Great For Codec Implementing

#194

Post by davemp » Tue, Aug 01, 2017, 11:58 PM UTC

adrianratnapala wrote: post #173

davemp wrote: post #166

Earlier quoted context omitted.

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.

Even if you don't really want C on such a process there will be an emergent and unholy aliance between (1) a pointy-hair impulse within the manufucturer to have "programmable in C" on the feature list and (2) an empire-building impulse within the C standards writing ecosystem that wants to encompass every chip under the sun.

Those forces are so strong people are still pushing for C on FPGAs.

Re: Rust: Not So Great For Codec Implementing

#195

Post by Aaron1011 » Wed, Aug 02, 2017, 12:04 AM UTC

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…

> Yeah, that's always been a minor annoyance of mine too. I intuitively think that a(b()); should be treated like let tmp = b(); a(tmp); That is b() would terminate and release its borrows before a is even considered and "tmp" would live until the end of the block. I'm guessing that there must be a good reason why it isn't so however.

That's because lifetimes in Rust are currently tied to a lexical scope - a borrow of a variable is kept alive until the variable goes out of scope, even if it's never used after a certain point in the function.

There's currently an open RFC that would allow the kind of nested calls described in the blog post: https://github.com/rust-lang/rfcs/pull/2025

Re: Rust: Not So Great For Codec Implementing

#196

Post by _5ysi » Wed, Aug 02, 2017, 12:31 AM UTC

camgunz wrote: post #101

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.

I can't speak for the author of course, but probably their argument is that a systems language should be able to directly manipulate bits and bytes without outside dependencies. I don't know that I agree. A reasonable counter example is that you need library support to allocate memory in C. The argument is that it's a feature to not require C implementations to include dynamic memory allocation because not all projec…

You don't need a library to allocate memory in C. For example on Linux, use sbrk() system call to grow the heap, then start using it.

But your larger point still stands.

Re: Rust: Not So Great For Codec Implementing

#197

Post by sitkack » Wed, Aug 02, 2017, 12:56 AM UTC

cryptonector wrote: post #179

adrianratnapala wrote: post #150

Earlier quoted context omitted.

On particular platforms they have nailed down the C++ layout enough to make this possible. I think windows did it for COM (or DCOM?). But in general you are right. On of the most infuriating things about fancy languages is the way they all have their own ABIs. I mean it's nice that they support special features through those ABIs, but standardized vtables and dictionaries would take us a long way. And Kudos to Micros…

Yes, that's right, and multiple compilers support the Windows C++ ABI. You still couldn't write portable C++ in C or assembly (or anything else not C++). Does anyone write C or assembly to that ABI? Probably not, though to be fair that's probably in large part because if you're going to do that you might as well write in C++ :^) Still, I think a public and stable ABI with fine-grained control of binary elements is a…

I would like a declarative language for laying out the heap, stack, objects, etc. Why have one ABI and not an ABI configuration protocol? Would love to share data structures between languages w/o having to write serializers.

Re: Rust: Not So Great For Codec Implementing

#198

Post by sitkack » Wed, Aug 02, 2017, 12:58 AM 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…

> you just have to understand how computers work.

rude.

Re: Rust: Not So Great For Codec Implementing

#199

Post by wahern » Wed, Aug 02, 2017, 12:58 AM UTC

legulere wrote: post #177

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…

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

Re: Rust: Not So Great For Codec Implementing

#200

Post by flavio81 » Wed, Aug 02, 2017, 1:12 AM UTC

WalterBright wrote: post #153

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

> Honestly, the popularity of C itself is due to the success of UNIX, I beg to differ. C was a fairly obscure language until MS-DOS came out. C turned out to be ideal for programming on DOS, and DOS programming was far and away the most programmed system in the world for a decade and a half. MS-DOS also made C++ into a major language (via Zortech C++). When ZTC++ came out the penetration and popularity of C++ went th…

> I beg to differ. C was a fairly obscure language until MS-DOS came out.

On the early days of DOS, what was used the most was IBM-BASIC (and GW-BASIC) for users, assembler for games like Alley Cat, IBM LOGO for teaching, some games were made on FIG-FORTH even

Then borland brought Turbo Pascal which was hugely popular together with MS QuickBasic.

Meanwhile, and we're at 1986-7, a good amount of software was already made for the Unices, in C. I don't think anyone was doing C for DOS back then. My grandpa -a PC nerd- had a huge (200+) collection of diskettes around that era, which now I own, there are all sorts of compilers for the above languages, plus Fortran, Clipper, etc; but no C compiler. Even though he owned the K&R book.

First time i saw use of C on the DOS world was with Borland Turbo C++.