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

211–220 of 237 posts

Re: Rust 2019 and beyond: limits to some growth

#211

Post by oscargrouch »

dan00 wrote: post #173
oscargrouch wrote: post #106

Earlier quoted context omitted.

I dont think that by looking only to features we can understand this very well. Go was very lucky to be launched when cloud computing fever was catching up, and people were being burned for using techs like Java for this end. C++ were very performant, and unlike Java not a memory hog, but for this sort of tasks it was deemed to complex. Besides the ammount of people that were able to program in it was limited (and yo…

> Now what about Rust? Its trying to eat some lunch from C and C++. But a lot of code and value is already there in C and C++, where rewriting it in Rust just for some ocasional added value here and there is not reasonable. For existing software it certainly is less about rewriting it but extending it in Rust. Thanks to not having a runtime and being quite easy to create a shared library with a C-ABI, pretty much any…

> Thanks to not having a runtime and being quite easy to create a shared library with a C-ABI, pretty much any software written in any language could be extended with code written in Rust.

Ok, but you kind of added complexity to your codebase. Now you will need not only C++ coders, but also Rust coders. If you are Mozilla or Google you can do that, you eat complexity for breakfast.. But they are probably not the companies you need right now to keep your steady growth, unless of course you are lucky that they created some killer app in Rust because of their in-house use of it. Like Google did recently with Kubernetes, only it is in Go of course, but i guess it checks the square of a killer app which helps into the language adoption as a programming trend.

Speaking of Go, it once was suffering from the same problem Rust is going through right now. It was sucessful in a first phase because of its community, but it needed more to start having more adoption and mind share. Then, Docker happened, and Go found a sweet spot to aim for and take it to the second base.

Re: Rust 2019 and beyond: limits to some growth

#212

Post by adwn »

pjmlp wrote: post #191
paulsutter wrote: post #49

Earlier quoted context omitted.

According to that we should all be using COBOL Did you hear they’re finally making it object oriented? The name will be ADD ONE TO COBOL

Cobol is already OOP for several years now.

> Cobol is already OOP for several years now.

I think that was supposed to be a joke, mocking Cobol's verboseness (compare "C++", which adds 1 to C and which extends C with OOP).

Re: Rust 2019 and beyond: limits to some growth

#213

Post by oscargrouch »

1-KB-OK wrote: post #185
oscargrouch wrote: post #106

Earlier quoted context omitted.

I dont think that by looking only to features we can understand this very well. Go was very lucky to be launched when cloud computing fever was catching up, and people were being burned for using techs like Java for this end. C++ were very performant, and unlike Java not a memory hog, but for this sort of tasks it was deemed to complex. Besides the ammount of people that were able to program in it was limited (and yo…

It's a good point that a language needs a platform to really shine. I think one place where Rust can find it is by targeting WASM and being the first systems language that can compile to code that runs in the browser. The rustc compiler supports WASM out of the box and I think this is one direction that the language adoption is going to grow. Another platform is cryptocurrencies/blockchains- Rust lends itself uniquel…

These are definitely a couple of good bets to be aiming for.

The blockchain trend reminds me that Rust could also try to find some cosy home in banking software, in expert systems and in embedded software.

The key now is to be humble and not to try to pick up a fight with C and C++ just yet.

Go only now is in a position to pick a fight against Java in the server and in the cloud, and Rust will probably need to get into the same point of adoption, if it wants to be seen as a serious contender to those languages in the eyes of the people they need to convince.

Unfortunatelly Rust missed a good new trend now, with multi-platform cores for mobile phones that ended up being written mostly in C++.

Rust wasnt even invented when people were trying to solve the problem of multi-os phone apps.

And that is the current trend which is giving the system development trend a second chance. But is not that bad, because thats exactly what is making people to take a serious look at Rust.

Battery life, memory, storage. It all matters again thanks to the phone environments, and you cant afford the be wrapped in layers upon layers of software virtualization like it was common in the early PC era, where Java and C# were kings.

Re: Rust 2019 and beyond: limits to some growth

#214

Post by electrograv »

zanny wrote: post #65

Since when did you need to read, comprehend, and digest every language feature in Rust to ever use the language? The absence of HKT / GATs / overloading / default arguments from the language doesn't make it easier for a newbie to learn. These aren't topics someone new, or even intermediate, should ever be touching until they need them. And in the absence of having this functionality (example - we JUST got const fn th…

I completely agree that complexity of edge cases, undefined behavior, and high combinatoric complexity between language features is a FAR more damaging kind of complexity (due to its nonlinear cost) than simple language feature count.

However, I disagree that simple language feature count has no cost: Assuming “linear cognitive complexity”, even such linear features do have a cost: Sure, you may not need to learn what a “const fn” is until you need it if you’re working only on your own project, but if you’re working on a team and/or with external libraries, the chances that you can get by without knowing the ENTIRE LANGUAGE diminish rather quickly with project size.

This is why even the least costly kinds of language complexity can still end up costing a lot in a large project containing a lot of code, dependencies, and developers.

Re: Rust 2019 and beyond: limits to some growth

#215

Post by baq »

pjmlp wrote: post #187
phkahler wrote: post #170

Earlier quoted context omitted.

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.

Small yes. Simple, only for those that never read ISO C, or tried to write actual portable C code, instead of using gcc C and GNU/Linux everywhere.

Don’t forget secure, too. It can be done, but at what cost.

Re: Rust 2019 and beyond: limits to some growth

#216

Post by skybrian »

lambda wrote: post #195
steveklabnik wrote: post #186

Earlier quoted context omitted.

> I'd also make sure that everything covered in the Reference is covered in the Book, They have very different goals, so this will never happen. The Book's job is to teach you how to program in Rust. The referece's goal is to (eventually) be a full specification. The former must be a sub-set of the latter. I do agree that everything should be documented, but the book cannot cover every last possible thing.

Yes, that's why I included the second part, "or the Book provides at least an introduction to the topic and then a reference to the more detailed information in the Reference." For example, I don't think that every last detail of #[repr(...)] needs to be covered in the Book; but as the entry point for most people, it's how they discover features, so it should at least provide an introduction, and link to the referenc…

Compare with Go's language spec, which is written in a formal (but readable) style with little math. I wouldn't want it to have examples because it's good that it's concise.

One way to start might be to have an official extended cheat sheet. A cheat sheet needn't explain everything, but it should list every language feature available. The idea is to give you a definitive "inventory" of everything available so you can search for answers elsewhere if you see something you don't understand. It should also be brief enough for the language maintainers to commit to updating it when they enable new features.

Re: Rust 2019 and beyond: limits to some growth

#217

Post by skybrian »

electrograv wrote: post #209
skybrian wrote: post #74

Earlier quoted context omitted.

I actually think a mathematical-flavored spec where a proof would be meaningful would be a bad idea to the extent that it makes the spec less readable by ordinary users. For example, Dart has a more mathematically flavored spec and it's not readable by most people. Of course, formalisms can still be useful, but as a matter of writing style, maybe it's better to put that sort of thing in an appendix? (As sometimes don…

One can generate an informal spec from a formal spec. One can NOT generate a formal spec from an informal spec (or else that “informal” spec would actually be formal, after all). So, a formal spec is strictly better than an informal one — it enables all the benefits of an informal spec, via the ability to generate any number of informal specs from it in many human languages, cultures, levels of detail, etc., and of c…

Since many programmers are not mathematicians, a formal spec will always have a smaller audience than a well-written spec written in English. You cannot automatically derive good writing from pure mathematics.

As a result, neither is strictly better than the other. They have different audiences and serve different purposes. The audience for pure mathematics is quite small.

Re: Rust 2019 and beyond: limits to some growth

#218

Post by pjmlp »

adrianN wrote: post #168
klodolph wrote: post #116

Earlier quoted context omitted.

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.

Just like wanting to learn Python 3.7 means learning about 500 PEPs and how they interact across each Python release (major.minor, during the last 25 years and alternatives to CPython.

Re: Rust 2019 and beyond: limits to some growth

#219

Post by mwcampbell »

steveklabnik wrote: post #200
mwcampbell wrote: post #199

Earlier quoted context omitted.

> we cannot run a web server or use a ton of JavaScript Just curious, why are those constraints there?

The documentation is distributed locally, as static files, as well as being available on doc.rust-lang.org. This is considered a big feature. I personally would love to tell people "sorry, you have to run a basic web server, even locally" for a few reasons, but it doesn't feel socially viable at the moment, sadly :/

Here's one way you might be able to make the case: If you require a web server even locally, then the docs can be installed as a single file (zip archive, SQLite database, etc.). This would eliminate the overhead of lots of small files on at least one popular desktop OS, speeding up installation and updates.

Re: Rust 2019 and beyond: limits to some growth

#220

Post by the_duke »

steveklabnik wrote: post #35
the_duke wrote: post #29

Earlier quoted context omitted.

I was drawn to Rust because, behind the apparent complexity of the borrow checker, the language is/was actually very simple and easy to understand. I have been using Rust extensively for over 2 years. In those two years, the language complexity has increased substantially. It's already at a stage where I'm worried about losing track. Also, there is quite a large amount of changes in the pipeline that were already acc…

One thing that’s come out of this years’ posts by various people is that, after those features have landed, people generally do want things to be done. These features shore up major weaknesses in the language for various domains, but there’s not really things not in that list that many people still extremely desire.

Totally agree that the features I mentioned address shortcomings.

And while I think Rust could do just fine without GATs, specialization is something I'd really hope for.

People will never be satisfied though and always ask for new features.

Post reply on HN