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

231–237 of 237 posts

Re: Rust 2019 and beyond: limits to some growth

#231

Post by shmerl »

klodolph wrote: post #227
adrianN wrote: post #168

Earlier quoted context omitted.

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.

I would disagree with the claim that “C++98 isn’t all that complex.” It was so complex that any project I found using it would restrict itself to some arbitrary subset, just to keep complexity under control. Java has gone through years of backwards-compatible changes, and is still wonderfully simple compared to early versions of C++. C++ started with a mess of different features and hasn’t really gotten worse. If any…

> I think people underestimate how complex these things are when they are learning C++, and how complex their interactions are. Then there’s the preprocessor.

And then there is arcane stuff like this:

* https://en.cppreference.com/w/cpp/language/eval_order

* https://en.cppreference.com/w/cpp/language/copy_elision

That does make the language feel very complex even without the whole templates depth.

Re: Rust 2019 and beyond: limits to some growth

#232

Post by steveklabnik »

lambda wrote: post #230
skybrian wrote: post #216

Earlier quoted context omitted.

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…

Thanks for the reference to the Go spec (link for the lazy: https://golang.org/ref/spec ) It is actually fairly comparable to the Rust Reference ( https://doc.rust-lang.org/reference/introduction.html ), though the way the Rust Reference is divided into chapters makes it a bit hard to see everything at once or search. They both do contain some examples, as well as things like the syntax in a BNF like format. Perhaps…

The reference has a search function, if you use the little magnifying glass at the top.

You can also use the print option to see it all on one page, if you prefer.

Re: Rust 2019 and beyond: limits to some growth

#233

Post by kccqzy »

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…

The C++ lifetime proposal doesn't seem have to a lot to do with templates. https://github.com/isocpp/CppCoreGuidelines/blob/master/docs...

Are you talking about something else?

Re: Rust 2019 and beyond: limits to some growth

#234

Post by e3b0c »

pjmlp wrote: post #188
e3b0c wrote: post #111

Earlier quoted context omitted.

C is a language designed to enable more efficient communication between the computer and the programmer in mind. C++ is a language designed to enable more communication between the compiler and the programmer. Go is a language designed to enable more efficient communication between programmers.

C was a language designed by two developers without background in language design that got lucky, because Bell Labs wasn't allowed to sell UNIX thus it ended up licensing it for a symbolic price to universities. C was hardly efficient in the 80s micro-computers, and outside Bell Labs people were doing compiler optimization research in languages like PL.8 and similar. Had Bell Labs been allowed to sell UNIX and histor…

When talking about "efficient communication" between the computer and the programmer, it does not necessarily imply the characteristics of the runtime performance.

For instance, Fortran is very performant in numerical computing, even outperforming C, but it has difficulty in accessing I/O mapped registers or implementing an interrupt handler, a jump table, or just cleaning a particular chunk of memory addresses.

Re: Rust 2019 and beyond: limits to some growth

#235

Post by pjmlp »

e3b0c wrote: post #234
pjmlp wrote: post #188

Earlier quoted context omitted.

C was a language designed by two developers without background in language design that got lucky, because Bell Labs wasn't allowed to sell UNIX thus it ended up licensing it for a symbolic price to universities. C was hardly efficient in the 80s micro-computers, and outside Bell Labs people were doing compiler optimization research in languages like PL.8 and similar. Had Bell Labs been allowed to sell UNIX and histor…

When talking about "efficient communication" between the computer and the programmer, it does not necessarily imply the characteristics of the runtime performance. For instance, Fortran is very performant in numerical computing, even outperforming C, but it has difficulty in accessing I/O mapped registers or implementing an interrupt handler, a jump table, or just cleaning a particular chunk of memory addresses.

Another urban legend from C yearly days. There was plenty of research in system languages since the early 60's outside Bell Labs, with OSes being written in Algol, Pascal and PL/I variants.

"Oh, it was quite a while ago. I kind of stopped when C came out. That was a big blow. We were making so much good progress on optimizations and transformations. We were getting rid of just one nice problem after another. When C came out, at one of the SIGPLAN compiler conferences, there was a debate between Steve Johnson from Bell Labs, who was supporting C, and one of our people, Bill Harrison, who was working on a project that I had at that time supporting automatic optimization...The nubbin of the debate was Steve's defense of not having to build optimizers anymore because the programmer would take care of it. That it was really a programmer's issue.... Seibel: Do you think C is a reasonable language if they had restricted its use to operating-system kernels? Allen: Oh, yeah. That would have been fine. And, in fact, you need to have something like that, something where experts can really fine-tune without big bottlenecks because those are key problems to solve. By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine. This is one of the reasons compilers are ... basically not taught much anymore in the colleges and universities."

-- Fran Allen interview, Excerpted from: Peter Seibel. Coders at Work: Reflections on the Craft of Programming

Re: Rust 2019 and beyond: limits to some growth

#236

Post by augustk »

pjmlp wrote: post #193
augustk wrote: post #134

Earlier quoted context omitted.

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."

And sadly lost its opportunity to Java in the late 90's. So whatever Wirth has done was quite of interesting in terms of language research for the language geeks among us, but hardly with any market relevance.

If you are interested, I can recommend the Oberon compiler OBNC: https://miasap.se/obnc/

Re: Rust 2019 and beyond: limits to some growth

#237

Post by pjmlp »

augustk wrote: post #236
pjmlp wrote: post #193

Earlier quoted context omitted.

And sadly lost its opportunity to Java in the late 90's. So whatever Wirth has done was quite of interesting in terms of language research for the language geeks among us, but hardly with any market relevance.

If you are interested, I can recommend the Oberon compiler OBNC: https://miasap.se/obnc/

Thanks for the heads up, I am quite aware of Oberon's ecosystem though.

You can check Oberon's history on my website.

Post reply on HN