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

121–130 of 237 posts

Re: Rust 2019 and beyond: limits to some growth

#121

Post by shmerl »

mroche wrote: post #120
InGodsName wrote: post #107

Earlier quoted context omitted.

There is also a sunk cost fallacy which keeps people trapped.

Sunk cost or costly effort? There are a more than a handful of large of technologies, frameworks and libraries used in my industry which would have to be ported/rewritten and supported from C++ before anyone would think twice before using an alternate language. Particularly when speed is the name of the game (in terms of integration, not just compiled binaries). There are hundreds of C++ libraries employed daily that…

Things are being rewritten, and those which are still not, can be used by combining languages.

Re: Rust 2019 and beyond: limits to some growth

#122

Post by Ar-Curunir »

pantalaimon wrote: post #72
CJefferson wrote: post #2

I can't agree more with this. I am a long time c++ dev, been to c++ committee meetings. The language is too complicated and inconsistent, and that is now I believe unfixable. I believe no one understands it. New features keep arriving, but you still have to learn everything that came before, for older codebases. For example, {} style initalisers were added to simplify and "unify" things. Except to make a vector of le…

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.

Re: Rust 2019 and beyond: limits to some growth

#123

Post by Santosh83 »

Rust can force a programmer to be disciplined and that's good as far as it goes, but sadly no current language can force (or even encourage) a programmer to think critically at an architectural level. Indisciplined coding leads to security issues (at least immediately), but a poor architecture can mean a complete failure of the project to meet its goals, never mind exceeding them.

Re: Rust 2019 and beyond: limits to some growth

#124

Post by Too »

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.

Yep, to reuse the math analogy. C is like solving 3d geometric problems by manually aggregating endless lines of cos, sin and sqrt, instead of using vector mathematics where you can do the same with just a single line of matrix multiplication or a simple dot-product.

Re: Rust 2019 and beyond: limits to some growth

#125

Post by adrianN »

InGodsName wrote: post #107
shmerl wrote: post #69

Earlier quoted context omitted.

That social engineering strategy only helps in the short term (short on the language scale, which can still be many years). If you get a convoluted language in result, in the long term it will increasingly irritate programmers, who will anyway start looking for objectively better alternatives. So Rust took the right approach IMHO.

There is also a sunk cost fallacy which keeps people trapped.

It's not a fallacy if you either have to manage two language stacks or rewrite huge codebases. Those things are expensive.

Re: Rust 2019 and beyond: limits to some growth

#126

Post by adrianN »

pantalaimon wrote: post #76
zanny wrote: post #52

Earlier quoted context omitted.

I don't feel like C was ever meant to be the permanent foundation on which all other computing was built. It was a language for its time. It took assemblies of the 70s made them much more palatable with an imperative syntax. C++ was also not meant to be a permanent foundation. It took shortcomings in C for scale and hacked on top functionality Bjarne wanted. The complexity difference between a computer 46 years ago,…

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…

The neverending stream of exploits based on undefined behavior proves you wrong. There is not a single widely used codebase that is completely free of UB and doesn't come with a formal proof.

Re: Rust 2019 and beyond: limits to some growth

#127

Post by feanaro »

dccoolgai wrote: post #88
chubot wrote: post #56

Earlier quoted context omitted.

Yes, I think you could know "all of" of JavaScript in 2009, in the ES5 era. Does anyone even remember that anymore? I'm shocked at how much the language has changed. I was experimenting with server-side JS in 2009, before node.js was released, and I hacked on Brendan Eich's Narcissus interpreter, which gave me a good sense of the language. Now when I look at example JavaScript code on the web, I invariably find somet…

Yeah, it definitely feels like ES6/7/Next is packed with features that theoretically make it a little faster to write code while making it monstrously slower and harder to read for at least 80% of practitioners... (destructuring comes to mind, with a syntax that is bafflingly similar to literal decs, that used to be the "good part") Seems like they made that choice every time. I was reserving my thoughts about ES6 un…

Can you give an example of the aspect of restructuring you consider confusing?

Re: Rust 2019 and beyond: limits to some growth

#128

Post by kentrado »

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.

Why?

Re: Rust 2019 and beyond: limits to some growth

#129

Post by tspiteri »

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…

> Same way an actual, legitimate newbie to Rust is going to have much more difficulty processing why :: is the namespace delimiter or why you need curly braces to deliniate scope than how having the option to declare your function const would.

I disagree. :: and curly braces are just a shallow bit of syntax: you see it, learn it and it doesn't interact with anything. It is the easy part of learning the language. For example Go has curly braces too, and it is one of the fastest languages to get started with.

Maybe const functions are not visible immediately, but then as a beginner you would start looking at some documentation, and you'll see const there in API documentation and not understand it, so that makes the language look like it has these opaque features you do not understand. I'm not saying const functions are not worth the cost, I'm just saying that they do have a cost and add complexity in a way :: and curly braces do not.

Re: Rust 2019 and beyond: limits to some growth

#130

Post by jurip »

cageface wrote: post #54
CJefferson wrote: post #2

I can't agree more with this. I am a long time c++ dev, been to c++ committee meetings. The language is too complicated and inconsistent, and that is now I believe unfixable. I believe no one understands it. New features keep arriving, but you still have to learn everything that came before, for older codebases. For example, {} style initalisers were added to simplify and "unify" things. Except to make a vector of le…

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/cs655/readings/steele.pdf

Post reply on HN