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

141–150 of 237 posts

Re: Rust 2019 and beyond: limits to some growth

#141

Post by jules »

cryptonector wrote: post #39

> Reputation for overcomplexity, loss of users. Becoming the next C++ or Haskell. I think Rust is already there. It's a concern, but I'm not sure you can or should try too hard to avoid this. What you can do is look to make simplifications as you add complexity. And sometimes innovations can have simplifying effects. For example, the various "effects" libraries for Haskell simplify I/O code compared to not having the…

It's quite difficult to simplify an existing language, even when adding a feature could theoretically simplify a language. For instance, higher kinded types are simple in principle: it's just removing an arbitrary restriction about what you're allowed to pass to a type constructor. However, when adding them to an existing language it doesn't always work that way. In the limit of removing type system restrictions you end up with dependent types, which are very simple in terms of the number of type system rules that they require, but try adding them to Java and you'll get a monstrously complicated beast.

Re: Rust 2019 and beyond: limits to some growth

#142

Post by baq »

dullgiulio wrote: post #135
kentrado wrote: post #128

Earlier quoted context omitted.

Why?

LLVM and GCC are dominating the space and pretty much killed propretary compilers.

Rust both greatly benefits from and is encumbered by LLVM. Maybe there’s room for a different LLVM-like or perhaps LLVM compatible project.

Re: Rust 2019 and beyond: limits to some growth

#143

Post by millstone »

Ericson2314 wrote: post #45

The comparison between C++ and Haskell is laughable, and shows that Graydon is missing the most important facet of this: GHC Haskell and Rust with have an intermediate language (Core and MIR + Chalk, respectively), which keep the rest of the language in tight check. No other mainstream language has this (Java bytecode doesn't really speak to high level safety properties). This ensures the vast majority of the languag…

Is the discussion of the intermediate language meant to rebut the claim of "reputation for overcomplexity" or "loss of users?"

Re: Rust 2019 and beyond: limits to some growth

#144

Post by qznc »

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

Re: Rust 2019 and beyond: limits to some growth

#145

Post by akavel »

the_clarence wrote: post #114
sudeepj wrote: post #92

I have written non-trivial code in Go and Rust. My situation is C++ dev -> Go -> Rust -> Go (current day job). The shifts have been due to various circumstances on my day job. The thing is when I moved back from Rust to Go, I had forgotten how productive Go is and I felt something like this: https://youtu.be/1i_Eqj7wu88?t=50 (20-30 sec video) As someone who tried to "sell" rust in my org, I see the biggest issue is:…

Big fan of Rust as well, but this is why both Go and Rust are going to co-live. They are both amazing languages.

Personally, in my heart, I'm kinda keeping fingers crossed for a future where if one needs to/has to, one uses Rust (mostly where one would use C/C++ today, including for "squeezing the last drop of performance", and especially high risk everpresent libraries like libpng; plus as an extra, probably for highly ambitious parallelism like in Servo); otherwise, one just goes with Go (for the amazing general productivity and readability).

Though then there's also Luna-lang, which I'm hoping even stronger to become long-term a new breakthrough paradigm/tech in programming & scripting...

On a mostly unrelated note, but continuing with off the sofa predictions, I'm curious on a few more developments:

- whether WebAsm will become the new de-facto universal architecture — at least for VMs, but I wonder if we won't eventually end up living on purely WebAsm CPUs at some point in future? (Unless WebAsm has some inherently hardware-hostile design decisions; I'm not a CPU/ISA guy to know that.)

- then RISC-V; will it become the ultimate personal computer/device CPU in the meanwhile? Also, what may happen if both RISC-V and WebAsm start naturally competing in this domain eventually?

- Fuchsia off-handedly dethroning the Linux kernel & ecosystem (and maybe even Windows) as the sudden standard mainstream OS (and thus also, amusingly, suddenly swinging the Tannenbaum's argument up through a semi-random caprice of Google's deep pockets)?

Especially per the last point, I wonder if we'll eventually end up in a world with much more... "secure"... personal devices. And if yes, will it end up being net good or bad (or just neutral/hard to say/nuanced, a.k.a. both, as usually) for humanity. Given that I'm recently realizing that "secure" unfortunately seems to be a very close sibling, or even maybe just an other face of, "closed" — think DRM, walled-garden ecosystems, no more rooted Android or XBOX... or even no more control at all over your PC, a.k.a. no general computing for the masses, potentially. Though I personally stay mostly hopeful on this front; in part because I think I believe people are as a sum too chaotic for this to be able to happen completely.

Re: Rust 2019 and beyond: limits to some growth

#146

Post by _ek94 »

steveklabnik wrote: post #34
reificator wrote: post #33

Earlier quoted context omitted.

Let's also come back to it when Rust is older than C++. It's a new language targeted toward people who want stability and performance, what do you expect to see by now?

Rust will never be older than C++ since they both get one year older every year ;)

Interpreting GP's comment using the Principle of Charity[1], I assume GP meant "older than C++ is now".

[1]: https://en.wikipedia.org/wiki/Principle_of_charity

Re: Rust 2019 and beyond: limits to some growth

#147

Post by grumdan »

skybrian wrote: post #11

As a newcomer to Rust and perhaps having been spoiled by Go's very readable specification, I was surprised that Rust doesn't have a definitive language spec. How do the people working on Rust ensure everyone has a common understanding of the language without one?

It's not a specification, but an interesting project is to formalize and prove safety guarantees of Rust:

http://plv.mpi-sws.org/rustbelt/#publications

In order to do this, there also needs to be an unambiguous formal semantics of Rust, so one might even hope that this will turn into some form of official language specification.

Re: Rust 2019 and beyond: limits to some growth

#148

Post by qznc »

skybrian wrote: post #74
f2f wrote: post #64

Earlier quoted context omitted.

> Go’s spec isn’t formally proven, for example, so you could make a similar claim: how can people know that it all works without a proof? that's moving the goalposts. let's see Rust's language spec finalized first, then we can talk about it being proven. without the two you shouldn't throw stones.

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…

I would rather have a formal spec as the definitive one. Deriving a formal spec from a readable one seems to hit ambiguous cases all the time. Just look at publications that do that for C or Java.

With a formal spec you could also derive an implementation automatically which is a great useable reference. Look up the K framework for one possibility.

Re: Rust 2019 and beyond: limits to some growth

#149

Post by dullgiulio »

baq wrote: post #142
dullgiulio wrote: post #135

Earlier quoted context omitted.

LLVM and GCC are dominating the space and pretty much killed propretary compilers.

Rust both greatly benefits from and is encumbered by LLVM. Maybe there’s room for a different LLVM-like or perhaps LLVM compatible project.

Interesting, what do you think makes is encumbered by LLVM?

I thought that sqeezing MIR in the middle Rust could get both Rust-specific transformations and then benefits from the LLVM generic code optimizations...

Re: Rust 2019 and beyond: limits to some growth

#150

Post by ramchip »

cageface wrote: post #137
jurip wrote: post #130

Earlier quoted context omitted.

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…

I think this is a really appealing idea but so far nobody’s managed to build a successful language this way. I’d love to see a mainstream language designed on these principles myself but I think it’s not going to be an s-expression based language.

Whether it’s mainstream is debatable, but I think Elixir is a really successful example of extensible language, and indeed it managed to do this without s-expressions. Various libraries extend the language for HTTP routing, parsing, DB queries, property testing, static analysis, etc. It makes possible a lot of experimentation by the wider community, and not just the group of core language developers.

The creator has repeated this philosophy a few times:

> There is very little reason for an Elixir v2.0 with breaking changes. The language was designed to be extensible and if we need to do major changes to the language to improve the language itself, then we failed at the foundation.

https://elixirforum.com/t/what-would-you-like-to-see-in-elix...

> A big language does not only fragment the community and makes it harder to learn but it is also harder to maintain. It is also why the language was designed to be extensible: so the community could build what is necessary without a push to make everything part of the language.

https://elixirforum.com/t/questions-about-property-testing-s...

> We also understand there is a limited amount of features we can add to the language before making the journey too long or the language too big. Adding something now means not including something else later. As an exercise, let’s see a counter example of when we didn’t add something to the language: GenStage. [...]

https://elixirforum.com/t/questions-about-property-testing-s...

Post reply on HN