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

201–210 of 237 posts

Re: Rust 2019 and beyond: limits to some growth

#201

Post by Ericson2314 »

millstone wrote: post #143
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?"

"Reputation for overcomplexity", especially there being little on w technically level to stop the language from growing and devolving into inconsistent design.

Re: Rust 2019 and beyond: limits to some growth

#202

Post by Ericson2314 »

zbentley wrote: post #174
Ericson2314 wrote: post #78

Earlier quoted context omitted.

No (safe) Rust is safe, while arbitrary assembly is unsafe. "Sugar" where the difference between the range (of elaboration) and codomain is significant is not sugar. If we had an assembly+proofs language and a compiler from Rust to it, then I would agree. See CakeML for an example of research towards correctness-proof-preserving compilation.

I think you are using a different definition of "safe" than Rust folks use.

Actually this is for any definitional of "safe". The important part is codomain vs range. As long as the target language allows source language invariants to be preserved (by explicit proof or by construction (proof in meta theory)), I'd call it sugar.

This doesn't obviously match with Felleisen's notion of expressitivity (which might be used to draw the line between desugaring and general compilation), but I think I like it better. I value invariants over expressiveness.

Re: Rust 2019 and beyond: limits to some growth

#203

Post by mroche »

SSLy wrote: post #167
amelius wrote: post #67

Earlier quoted context omitted.

> 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?

Used over in HPC here and their cluster version (which bundles Intel MPI) is several thousand dollars. Aren’t it’s tools also the core of Clear Linux? Or does that default to GCC/Clang?

Re: Rust 2019 and beyond: limits to some growth

#204

Post by cryptonector »

augustk wrote: post #134
gpderetta wrote: post #60

Earlier quoted context omitted.

There are only two types of languages, those that are too complex and those that aren't yet.

There is at least one language that evolves in the opposite direction. The philosophy of Oberon is that "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."

So we should be using Forth then, got it :)

Re: Rust 2019 and beyond: limits to some growth

#205

Post by cryptonector »

jules wrote: post #141
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…

You're not wrong. Rust is a very fluid language though, and now is the time to get these things right for Rust. Java feels like a lost cause.

Re: Rust 2019 and beyond: limits to some growth

#206

Post by Ericson2314 »

dbaupp wrote: post #151
Ericson2314 wrote: post #97

Earlier quoted context omitted.

OK yours is the second comment to talk about "Users". IMO this first-impression-based design methodology, like we're writing some consumer CRUD app for the startup [proverbial] you're gonna quit in terrible skeumorphic philosophy for designing languages. Languages are for more terrible; programs last (too?) long; long-future readers may be expert or knowledge. Let me response point-by-point > It's not a thing your us…

"User" refers to someone writing code in the programming language---someone "using" the compiler. It's not some project-management-y jargon. ----- Extending expressiveness vs sugar is fundamentally a property of the high level language, not the mid-level IR. It happens that talking about a mid-level IR is sometimes a nice way to "prove" that something is new or sugar. As the parent said, the programmer using the comp…

- New program writers (more writing)

- Old program maintainers (more reading)

- Language implementers

You leave out the 3rd and conflate the second. Others have conceive of PLs as some sort of bargain between human and machine, or human and pure math. Either way, there's multiple interests at stake.

Or, even simpler, what if Rust becomes way harder to learn, but mastery gives one correspondingly way more productivity? Is that a fair trade in your eyes? (I do not believe in practice it will become way harder to learn, but I accept the situation I describe as fair and not a failure of Rust).

-----

You may not write it directly, but you will still think about it. Again the IR of these good languages is like some platonic ideal that sacrifices concision of programs for concision of the language. It is not just an inplementation detail.

Hell, if you insist on thinking that is just some crufty implementation detail, sure. But then let me show you how it's an abstraction that leaks badly, hahaha.

- "Non lexical lifetimes" are probably the most anticipated Rust change lately (see rest of thread). But crucially, they are lexical at the level of MIR. The easiest way to precisely define them is desugar to an explicit control flow language. Otherwise you are forced to look at the a combinatorial explosion of surface-level constructs, or just handwave based in the intuition of control flow.

- https://github.com/thepowersgang/mrustc/tree/master/src/mir this is the alternative Rust implementation's MIR. It's pretty close to the same thing! (Not so with LLVM IR and GCC's RTL.) If mrustc gets to implementing NLLs, it will probably get even closer.

- mrustc does not implement old borrow checking probably because it's sort of an arbitrary spec against the surface syntax. Surface syntax is much more boilerplate to go through all the cases, and while old lifetimes may have a simple enough rough intuition, they are very arbitrary when considered precisely.

And yes, the core language can change underneath the hood, but this is highly unlikely in practice. GHC's core has certainly changed, but this is evolution more than revolution.

I think the heart of what I'm saying is two things:

1. Formal reasoning is the only way to constrain complexity. Humans alone inevitably don't fully graps the entire thing (it's just too big!), and even when they do don't have identical mental models. The results is always contradictory design if any change at all is permitted.

2. Human PLs have lots of conveniences and other fluff (yes, even Scheme, Nix, or your other favorite minimalist language), so the only efficient way to reason about them formally is by desugaring to a core language.

Re: Rust 2019 and beyond: limits to some growth

#207

Post by Ericson2314 »

leoc wrote: post #192
Ericson2314 wrote: post #100

Earlier quoted context omitted.

Yes this hole thread makes me think we have a bunch of people who think complexity = initial learning curve. No wonder most of our industry is an inscrutable inconsistent mess.

Allow me to summarise the pitfalls of any sweeping 'keeping features out of the languge spec will prevent users from having to deal with the complexity burden of those features' assumption with a story: Once, long ago, there was a new programming language. It was lean and mean. Partly to keep codebases understandable to all, and to make the language easy to learn and straightforward, it eschewed both having too many…

Yeah understanding the forest is more important than understanding the trees!

Re: Rust 2019 and beyond: limits to some growth

#208

Post by ThenAsNow »

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.

It's not a simple matter of how frequently it occurs, the fundamental question is one of rigor. The principal difference between craftsmanship and engineering is also rigor. Historically, the ability to prove your code was free of classes of error required sacrifices that few practicing software developers could or would accept (e.g., formal proofs, use of "niche" languages, uncomfortable toolchains, etc.).

What's got people excited is the evolution of these systems which have a rich intersection between rigor and usability (to include ecosystem, tooling, etc.). The ability to statically eliminate classes of error with good (or maybe good enough) ergonomics means these questions of "how frequently does this occur" are not relevant - you can drive such occurrences to zero and doing so should become table stakes. This is a proper engineering mindset.

None of this is to dismiss craftsmanship, which definitely has its place. And before the ability to practically apply rigor, that's all there was. After all, people have been building complex systems for centuries without the benefit of modern mathematical foundations. But none of those are good reasons to eschew rigor when it is within reach and when the systems you develop are big/complex/widely-used enough.

Re: Rust 2019 and beyond: limits to some growth

#209

Post by electrograv »

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…

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 course enables things like compiler reproducibility (which you cannot do at all without a formal spec).

That being said, any spec is probably better than no spec.

Re: Rust 2019 and beyond: limits to some growth

#210

Post by Ericson2314 »

zbentley wrote: post #172
qznc wrote: post #152

Earlier quoted context omitted.

While I generally agree with your point, D/Walter Bright slightly disagrees with the sentiment. One constraint for D is "must not require data flow analysis" because that incurs a cost on compilation time. Afaik this was mostly inspired by Javas definite assignment rule [0]. If fast compilation is a goal, then a language is constrained by implementation and IR aspects. [0] https://docs.oracle.com/javase/specs/jls/se6…

This is a perhaps over-fine semantic distinction, but I would argue that there's a qualitative difference between IR/language implementation and compilation speed. The former should not drive the language's features; the latter is a language feature.

IMO most discussion of the compilation speed is incredibly narrow-minded. We incremental compilation more than anything else. Programs barely change each rebuild, so that should solve all the performance problems without having to maim ourselves.
Post reply on HN