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

Rust 2019 and beyond: limits to some growth

graydon2.dreamwidth.org

Post reply on HN
Print view View original

161–170 of 237 posts

Re: Rust 2019 and beyond: limits to some growth

#161

Post by steveklabnik »

burfog wrote: post #73
galangalalgol wrote: post #18

Earlier quoted context omitted.

Async/await isn't stable yet, that seems to be making many commenters here wait to adopt, so at least that should make it in before they lock it down. I'd like the platform independent SIMD but that I can admit is niche and could live in nightly for a long time without harming adoption. They have polls to get a feel for the difference between those two categories and which features fall into them.

Async/await appears to require runtime support, possibly even a modern OS. Wasn't rust supposed to be suitable for writing bare-metal code? SIMD at least has hope of running on bare metal. I suppose the ideal is to have it adjustable: compiled to non-SIMD, using typical SIMD hardware, using implicit threads (and thus needing OS support), or using SIMD hardware with threads. I fear the high-level web developers are in…

async/await in Rust produces a single value, a Future. Executing that future requires calling its poll method repeatedly. That can be extremely simple, or it can be more complex. We call "a thing that calls poll repeatedly" an executor, and they can be written without an OS or even the standard library, just fine.

The largest, most well known executor is Tokio, which is built on top of OS primitives. If you're writing your own OS, you'd use those primitives.

> I fear the high-level web developers are in the driver's seat

First, I pretty fundamentally reject this as an idea, but since you don't, please do a Google Scholar search for many of the core team members. They're very much not web developers.

Re: Rust 2019 and beyond: limits to some growth

#162

Post by epage »

zanny wrote: post #108
epage wrote: post #102

Earlier quoted context omitted.

> Anything that would break failure in libraries written now would break all libraries because it would mean the fundamental Error trait has changed. Since failure is Error compatible you don't lose anything using it. Its only ~2500 lines of Rust. If you expose failure in your public API and failure makes a breaking change, it is a breaking change for your API because your clients need to be on a compatible version o…

Your clients don't though, you can have multiple versions of a crate in your build tree. Your failures aren't then compositable with newer failures as failures but they do impl Error and can be used as standard errors. The alternative is to just use... standard errors anyway? With the aforementioned sizable boilerplate? There's no downside to failure unless there's a less volatile error replacement you'd use instead.

> Your clients don't though, you can have multiple versions of a crate in your build tree

Yes, but you can only directly depend on one version of failure. What happens if you directly depend on two libraries with different versions of failure? How do you interop with them? In a lot of cases, you'll be lucky and not need to reference the types in any way and it will "just work". This breaks down if you do need to reference the types.

Re: Rust 2019 and beyond: limits to some growth

#163

Post by steveklabnik »

dbaupp wrote: post #132
Animats wrote: post #68

It's interesting to see this critique of the Rust language's development process. There's a lot of process. Most of it aimed at adding new features. That may be part of the problem. The Go crowd seemed to know when to stop. I've criticized Rust's growth here before. The big breakthrough in Rust was the borrow checker. Finally, one could have memory safety without garbage collection or reference counting. Huge improve…

All of those unsafe "hole fixes" are features, meaning your desires are for adding even more features. Additionally, useful back pointer support (i.e. for anything more than a toy doubly linked list) is probably a bigger feature than anything else added since Rust 1.0, and probably harder to work with.

... and basically an open research question, whereas the features we're talking about adding are generally less novel.

Re: Rust 2019 and beyond: limits to some growth

#164

Post by joppy »

jurip wrote: post #130
cageface wrote: post #54

Earlier quoted context omitted.

Maybe it makes sense to read the success of Golang as a smart piece of social engineering. Start with a simple and accessible language and gradually ratchet up the complexity to deal with more real-world problems. You may eventually wind up with a worse language but at least you'll have users. Rust tried to solve a lot of hard problems out of the gate and that has slowed its growth IMO. It's sort of another worse-is-…

This is what Guy Steele's Growing a Language talk was all about: "I should not design a small language, and I should not design a large one. I need to design a language that can grow. I need to plan ways in which it might grow—but I need, too, to leave some choices so that other persons can make those choices at a later time." https://www.youtube.com/watch?v=_ahvzDzKdB0 or as PDF: https://www.cs.virginia.edu/~evans/c…

This is an amazing talk, and a transcript does not do it justice in the slightest. If you have the time, listen to the talk!

Re: Rust 2019 and beyond: limits to some growth

#165

Post by barrkel »

shaklee3 wrote: post #115
pantalaimon wrote: post #76

Earlier quoted context omitted.

I think the fear of unrefined behaviour is starkly exaggerated in everyday C programming. If you follow the established best practices (and the compiler will warn you if you don't) you will not experience undefined behaviour. > Those kinds of complexities aren't generally something for users to explicitly learn in rote memorization to use the language - if Rust introduced overloading and default arguments all those w…

I agree. I see comments like that time and time again. As someone who writes it professionally, it just doesn't occur as often as the internet would make you think.

You think this until you're on the front line exposed as attack surface directly or indirectly via linkage. This is a knowledge category where ignorance really does give people unfounded confidence.

Re: Rust 2019 and beyond: limits to some growth

#166

Post by lifthrasiir »

Ar-Curunir wrote: post #122
pantalaimon wrote: post #72

Earlier quoted context omitted.

I feel like C is having a renaissance because of that. C is very conservative in adding new features, which makes it easy to get an understanding of the language - nothing is hidden, when necessary you can derive everything you need to know about a piece of code from first principles. C compared to C++ feels like high school math compared to university math with all it's scary notations.

I don't think this is true: what C leaves out in terms of language features , programmers have to reinvent or keep in their heads perpetually while writing code, leading to tons of gotchas.

In the other words, C standard library is not really small. It consists of a small mechanized portion and a much larger portion embedded in wetware, i.e. human mind. The second portion is very hard to update or fix, so the first portion keeps growing to cover all faults of the second.

Re: Rust 2019 and beyond: limits to some growth

#167

Post by SSLy »

amelius wrote: post #67
blattimwind wrote: post #9

Earlier quoted context omitted.

I've been dabbling in some Rust lately and as a long time mostly-C++-and-Python-and-some-Java dev I've found it relatively easy to get started with it. Sure, a lot of things are different (e.g. struct+impl vs. classes), many clearly better, some that may/may not be better just different, but overall it seems to me like Rust is relatively easy to pick up coming from C++. And C++ is usually way uglier and far more comp…

> The age of multi-vendored languages like C or C++ for systems programming might be coming to an end. I'd wager this is actually a good thing. That's because you can't make money writing compilers anymore.

Anyone knows if intel parallel studio is profitable?

Re: Rust 2019 and beyond: limits to some growth

#168

Post by adrianN »

klodolph wrote: post #116
cageface wrote: post #70

Earlier quoted context omitted.

What tends to happen is that you bring out a simplified, cleaned-up version of the popular language of the day. People then flock to that new language and start making feature requests. Over time that language becomes as complex and inelegant as the language it replaced and you can start the whole cycle all over again. The move from C++ -> Java -> Go is a perfect example of this cycle.

I don’t think Java and Go will ever, combined, reach the complexity of C++. The reason why older languages are complex and inelegant is because our understanding of how to create simple yet useful languages has increased, not because older languages accumulate much complexity.

Wanting to do what the new languages can do without breaking backwards compatibility is a big reason why C++ got so complicated. C++98 isn't all that complex, but if you want to learn C++20 you still have to learn every language feature that was developed in the last thirty years and how they all interact.

Re: Rust 2019 and beyond: limits to some growth

#170

Post by phkahler »

qznc wrote: post #144
jacquesm wrote: post #82

That is a super mature post whose content should be read by any language and/or eco-system component (libraries, frameworks and so on) creators and maintainers. I love the intentionally limited scope and the amount of thought that went into writing this, and I wished I had the clarity required to be able to do this. Especially the bit about 'negative space' got my intention, that's one tool I'm going to put in my too…

I believe C would be a good example for negative space. The spirit of C [0] explicitly contains "keep the language small and simple". [0] http://beza1e1.tuxen.de/articles/spirit_of_c.html

Came here to comment on C. IMHO it remains a gem in the space of languages, probably because it remains small and simple. It has many warts, but it does not suffer in the way C++ does.

People claim Rust is a better C++ and as from my outsider point of view it looks like it is. One of my fears is that it will follow C++ down the very road the author is concerned about.

Post reply on HN