Things Rust shipped without • Hacker News Board

Re: Things Rust shipped without

#251

Post by andresmanz » Sat, Jul 04, 2015, 9:22 AM UTC

dragonwriter wrote: post #110

andresmanz wrote: post #88

Earlier quoted context omitted.

Style recommendations are great and if I was writing code for the standard library, I would certainly follow them. But they don't simply recommend their style. "We recommend doing this like that" is very different from "Doing this that way is considered poor style". That sounds like their recommendations were objective facts and you shouldn't do anything else, even if that worked better for you and the majority of ot…

> That sounds like their recommendations were objective facts On the one hand, it is an objective fact that it is considered, by the authors, poor style. On the other hand, that it is "considered" anything is an explicit (not merely implicit) statement that it is subjective (and "poor style" -- or good style, for that matter is inherently subjective in any case.) So, characterizing that language as making it sound "l…

You can say that it can be an objective fact, though, that the majority of 'good developers' considers all that stuff poor style. Which is what I get from reading that book. If they don't intend to imply that, they should write it in a different way. The authors of various other books on various other programming languages are able to do that.

Re: Things Rust shipped without

#252

Post by eddyb » Sat, Jul 04, 2015, 9:58 AM UTC

beeforpork wrote: post #250

geofft wrote: post #218

Earlier quoted context omitted.

Rust is the first language that fixes all of these things, can be used as a replacement for all of C's use cases (including ABI-stable libraries, kernels, etc.), and has a sufficient community / mindshare that you can expect libraries to exist in the language for functionality that you generally expect to find in libraries. Maybe we should be embarrassed as an industry that it took us 20 years to get there, yes.

If Rust misses 'goto', it is not suitable for translating SSA into it, which most compilers natually produce (also for LLVM, obviously). I.e., it is not suitable for being used in a compiler backend. Here, it can never fully replace C. 'goto' should not be daemonized, we know better today.

I don't follow, why would SSA need to be translated into an input language?

LLVM used to have a C backend, yes, but that hasn't been maintained for a while now.

Re: Things Rust shipped without

#253

Post by sklogic » Sat, Jul 04, 2015, 10:43 AM UTC

istvan__ wrote: post #206

chjj wrote: post #143

Earlier quoted context omitted.

I've always defended goto and gotten a lot of flak for it. As soon as I say, "I wish I had X-language had gotos", I see jaws drop. Response: "Wow, haven't you heard the news?! GOTOs are considered harmful!" I think goto should be in almost every language. It's one of the most primitive instructions, why shouldn't it be available when needed? Yes, it can be misused, just like any other feature in the language , but it…

I do not use goto in my code. What do I do wrong? :) Ok, I have to admit that I used it on C64 in the 80s. Anyways, exceptions are sort of gotos or at least they can behave that way.

If you're not implementing fast FSMs, fast bytecode interpreters (and dynamic dispatchers in general), and you're not using metaprogrming to the full power, not implementing multiple embedded DSLs - then you can live without a goto. Otherwise it is essential.

Re: Things Rust shipped without

#254

Post by sklogic » Sat, Jul 04, 2015, 10:46 AM UTC

jacquesm wrote: post #245

zem wrote: post #90

Earlier quoted context omitted.

~20 years of using various combinations of C and C++, and i never knew you could take the address of a label! reminds me of computed GOSUBs from my basic days :)

Before you use such constructs make sure your team lead or boss is ok with it, it's incompatible with many compilers and ugly to boot. This is the kind of code that gives C its bad reputation.

This is the kind of code which makes OCaml the fastest bytecode interpreter out there, and selection between an ad hoc switch and a comuted goto is done transparently with a single ifdef.

Re: Things Rust shipped without

#255

Post by comex » Sat, Jul 04, 2015, 11:10 AM UTC

milspec wrote: post #227

geofft wrote: post #216

Earlier quoted context omitted.

Rust is not a language that looks favorably on things that are easy to misuse and hard to use correctly. You can make the same argument about, say, untagged / C-style unions, which are much more common in C, but Rust doesn't have those either. I don't plan to stop using ncurses in particular, but one of the reasons I am supportive of Rust is that I would like to stop using all C software sometime in my lifetime.

Rust should have untagged unions. Obviously, ones that allow pointer abuse would be restricted to code marked unsafe. Note that a union of two pointer-containing structs is safe as long as the pointers line up, having the same type and offset in each struct.

They've been proposed:

https://github.com/rust-lang/rfcs/pull/724

If you really need them, you can implement them in a library by declaring a suitably sized byte array and having methods that return casted pointers to it. This would be illegal in C due to strict aliasing, but IIRC Rust does not have a strict aliasing rule (because almost all pointers being the equivalent of 'restrict' drastically reduces the benefit).

There are issues with size_of not being a constant expression and such (at least in stable), but those are definitely going to be fixed.

Re: Things Rust shipped without

#256

Post by the_why_of_y » Sat, Jul 04, 2015, 11:20 AM UTC

ufo wrote: post #186

shawn-butler wrote: post #123

Earlier quoted context omitted.

> For example, consider math.h. If your program is using one function (say, sin) from math.h, you have to parse all the prototypes in math.h. (And if you have inlined functions or templates in the header files, you have to parse those too!) Isn't this pretty much a solved problem with precompiled / pre tokenized headers? PTH are language / arch / compiler agnostic. http://clang.llvm.org/docs/PTHInternals.html

Precompiled headers are a big hack. As pcwalton mentioned, the problem was actually solved when people invented real module systems.

Which, notably, happened decades before the first implementation of the precompiled headers hack.

Re: Things Rust shipped without

#257

Post by comex » Sat, Jul 04, 2015, 11:21 AM UTC

shawn-butler wrote: post #123

pcwalton wrote: post #43

Earlier quoted context omitted.

> Which is barely enough to say that Rust is hugely different than just #include-ing C files. Well, sure, if you want to get fancy enough you can make a module system out of #include. (Your code snippet isn't enough because it doesn't replicate privacy or imports.) But replicating something approximating Rust's module system with "#include plus other stuff" doesn't show that Rust's module system is "just #include". >…

> For example, consider math.h. If your program is using one function (say, sin) from math.h, you have to parse all the prototypes in math.h. (And if you have inlined functions or templates in the header files, you have to parse those too!) Isn't this pretty much a solved problem with precompiled / pre tokenized headers? PTH are language / arch / compiler agnostic. http://clang.llvm.org/docs/PTHInternals.html

Note that Clang has been working on a true module system for C and C++:

http://clang.llvm.org/docs/Modules.html

Re: Things Rust shipped without

#258

Post by the_why_of_y » Sat, Jul 04, 2015, 11:38 AM UTC

pcwalton wrote: post #102

amelius wrote: post #60

Earlier quoted context omitted.

Coroutines, Go style.

M:N threads didn't work for Rust, and they don't have that many advantages anyway even in languages where they do work. There has been a lot of discussion on this over the years and this has been the conclusion everyone came to.

M:N threading may make sense for a higher-level language implementation like Erlang or GHC where you have a runtime in charge of things anyway and can reap benefits with initial stack sizes substantially smaller than a single VM page, allowing creation of millions of threads.

But since Rust is intended for runtime-less lower-level programming it doesn't make any sense here.

Re: Things Rust shipped without

#259

Post by alextgordon » Sat, Jul 04, 2015, 11:43 AM UTC

beeforpork wrote: post #250

geofft wrote: post #218

Earlier quoted context omitted.

Rust is the first language that fixes all of these things, can be used as a replacement for all of C's use cases (including ABI-stable libraries, kernels, etc.), and has a sufficient community / mindshare that you can expect libraries to exist in the language for functionality that you generally expect to find in libraries. Maybe we should be embarrassed as an industry that it took us 20 years to get there, yes.

If Rust misses 'goto', it is not suitable for translating SSA into it, which most compilers natually produce (also for LLVM, obviously). I.e., it is not suitable for being used in a compiler backend. Here, it can never fully replace C. 'goto' should not be daemonized, we know better today.

Rust only targets LLVM IR, so its chances of fully replacing C are nil anyway.

Re: Things Rust shipped without

#260

Post by the_why_of_y » Sat, Jul 04, 2015, 11:58 AM UTC

steveklabnik wrote: post #29

MrBuddyCasino wrote: post #24

I don't get why those are bad? - random-access strings - auto-increment operators

The first is bad because of UTF-8, basically. It's unclear what an index should even return: bytes, codepoints, grapheme clusters? Furthermore, because it's a variable-length encoding, it's not O(1) access, which is what [] implies, and since Rust tries to surface the cost of operations, it would be inappropriate for Rust. (Note that Rust _does_ have a ranged syntax here, which returns bytes, and is O(1)) Pre vs post…

And UTF-16 random-access strings (like in Java and many other things designed in the 90s) make the problem even worse, because with UTF-8 you will notice the bugs as soon as the first non-English-speaker uses your system, but with UTF-16 the affected languages are a lot more obscure.