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

Things Rust shipped without

graydon2.dreamwidth.org

Post reply on HN
Print view View original

221–230 of 330 posts

Re: Things Rust shipped without

#221

Post by gilgoomesh »

yazaddaruvala wrote: post #198
andrepd wrote: post #12

What about things that Rust shipped without that should have been included?

I really wish Rust/stdlib had been built around a good async io story. Right now it just feels neglected "because the crates ecosystem can deal with it". I might be wrong here but it always seemed to me that Rust was built to replace C/C++ in critical infrastructure like Firefox, Nginx, Redis, etc. Basically critical network dependent infrastructure. With respect (because I understand the difficulties that come with…

The absence of async IO in the standard library in Rust 1.0 is probably an artefact of Rust's original intention to use M:N green threads and blocking IO based on libuv:

https://www.reddit.com/r/rust/comments/1v2ptr/is_nonblocking...

The timing of the move away from green threads didn't really offer enough time to implement a stable async IO option before 1.0

Re: Things Rust shipped without

#222

Post by eddyb »

toolslive wrote: post #121
MrBuddyCasino wrote: post #24

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

i += ++i; what should be the result ? what is the result in C++ ? (undefined)

This could actually work fine in Rust, because it has deterministic evaluation ordering for everything (or almost everything, though I can't think of anything that isn't deterministic).

Knowing that `++i` is `{ i += 1; i }`, we have `i += { i += 1; i };` (which should compile already).

The nested assignment can be hoisted to obtain `i += 1; i += i;`.

That means Rust would compile `i += ++i;` as `i = (i + 1) * 2;`.

Re: Things Rust shipped without

#223

Post by EugeneOZ »

pcwalton wrote: post #8
IvyMike wrote: post #6

> goto (not even as a reserved word) I haven't done this for a while, but once upon a graduate program I wrote a compiler from a made-up-language (MUP) to C. MUP had some strange control structures, and if C did not have "goto", it would have been a lot more difficult to implement those structures. Since then, I have always thought languages should have a "goto" statement that human-written code is not allowed to use…

It often simplifies a lot of the compiler implementation if you only have reducible control flow. LLVM is fine with irreducible control flow, because it has to handle C, but rustc uses a CFG for the borrow checker, which is flow-sensitive. You can convert irreducible control flow to reducible control flow, but it can explode the size of the graph in pathological cases. (I don't recall whether the borrow checker actua…

I think the point of parent comment is "it's ok to don't have goto in Rust, but it's not the reason to be proud of just not having goto". Goto is important enough operator and doesn't deserve blind hate.

Re: Things Rust shipped without

#224

Post by EugeneOZ »

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.

No, exceptions are incomparable much harmful because they don't have destination, they just hysterically run, crashing everything on their way.

Re: Things Rust shipped without

#225

Post by tracker1 »

EugeneOZ wrote: post #223
pcwalton wrote: post #8

Earlier quoted context omitted.

It often simplifies a lot of the compiler implementation if you only have reducible control flow. LLVM is fine with irreducible control flow, because it has to handle C, but rustc uses a CFG for the borrow checker, which is flow-sensitive. You can convert irreducible control flow to reducible control flow, but it can explode the size of the graph in pathological cases. (I don't recall whether the borrow checker actua…

I think the point of parent comment is "it's ok to don't have goto in Rust, but it's not the reason to be proud of just not having goto". Goto is important enough operator and doesn't deserve blind hate.

Agreed... I honestly tend to break code into a lot of discrete functions, and combine for workflows, but sometimes you just need to easily jump back a few places, and where goto is available it's not always a bad option. Just one that should be used sparingly... once in a complex workflow is fine.. more than twenty times in a few thousand line method, not so much.

Re: Things Rust shipped without

#226

Post by cpeterso »

nightpool wrote: post #44
andresmanz wrote: post #32

Earlier quoted context omitted.

That's absolutely OK and I do understand that people want that. I actually like snake case and only slightly prefer camel case. I'd write snake case in large open source projects, if it's actually preferred. But it's very awful to type snake case code on my keyboard and I'm not ready yet to switch to a US keyboard. The worst thing about that warning is that I get some kind of a bad conscience by disabling it.

have you thought about binding underscores to some other key combination at the operating system level?

SHIFT+SPACE could be a good keyboard shortcut for underscore because snake_case's underscores represent spaces between words.

Re: Things Rust shipped without

#227

Post by milspec »

geofft wrote: post #216
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…

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.

Re: Things Rust shipped without

#228

Post by Gibbon1 »

bluecalm wrote: post #87
Animats wrote: post #51

Earlier quoted context omitted.

I don't think I've written a goto since the 1970s, and I've written a lot of code since then. If you need to bail out of something in the middle, make it a function.

As mentioned above, in C goto is often useful for error handling (where you need to free some resources before exiting the function). It's way more convenient and readable to write freeing code once and jump to it instead of having multiple return exits and duplicate the code before every single one of them.

I find myself often having the issue where the code digging through what can and often is, garbage. At some point you find it's pointless to continue. You are done. Fin. Goto error; in that case makes absolutely perfect sense.

Two things about goto and jmp instructions. Most people have no idea how badly they were abused back in old days. For instance to jump into the middle of a subroutine. Yay just saved 9!!! words of core memory!!! And most people forget that old computer scientists were obsessed with creating grammars that you could write formal proofs for.

Re: Things Rust shipped without

#229

Post by nwmcsween »

teacup50 wrote: post #207
Kranar wrote: post #151

Earlier quoted context omitted.

Funny, co-routines have been recently added to C++ and they work wonders. D has fibers which are used extensively and once again, it's a highly desired feature. Go is kind of the poster boy for coroutines and I doubt anyone claims that it doesn't provide many advantages. To be honest it seems to me like your explanation is an attempt to downplay just how nice fibers/coroutines are rather than acknowledge their utilit…

No, his explanation is the few-line summary of years of failed experiments in userspace M:N threading. Userspace is not equipped to make reasonable scheduling decisions that provide any significant performance advantage, and library/language runtime control of M thread register/stack contexts on top of N kernel threads plays absolute havoc with most operating system's standard libraries. Go works around this by expli…

IMO if you cannot directly do a syscall in an os its useless.

Re: Things Rust shipped without

#230

Post by mercurial »

FrozenCow wrote: post #128
saboot wrote: post #101

Rust also shipped without reflection, which was available in the beginning. I was a bit disappointed as it was something I would have made use of for serialization.

Wouldn't it be better to create serialization functionality at compile-time? In the Java space some libraries are moving to compile-time code generation instead of relying on reflection. It is a huge win, since a lot more can be checked beforehand. Dagger 2 is a good example how it can be beneficial. It provides dependency injection at compile-time, which will in turn check whether all dependencies are satisfied. I h…

Sometime I wish no runtime reflection was available to the programmer at runtime in Java, this would prevent people from being tempted to use brittle runtime magic. Of course, you would need a solid macro system instead.

And thanks for the pointer to dagger, this looks like an interesting alternative.

Post reply on HN