I am somewhat disappointed that we still feel the need to create entirely new toolchains and rewrite everything just to support what should be an incremental improvement. But at a certain point, a lot of the reason for the hype is that it sells these solutions to newer developers that haven't had exposure to these concepts before. I suppose we can consider them fortunate for not having to do systems programming while suffering through implementing their own reference counting and garbage collection semantics.

Those, plus the total package of tradeoffs in Golang did for me, in terms of implementing a game server. The whole package really is game changing for what I'm doing.

I am somewhat disappointed that we still feel the need to create entirely new toolchains and rewrite everything just to support what should be an incremental improvement.

There's something wrong with programming as an entire field. Don't other fields figure out ways of not reinventing the wheel?

But at a certain point, a lot of the reason for the hype is that it sells these solutions to newer developers that haven't had exposure to these concepts before.

Luminaries of our field have been lamenting for decades that programming forgets its own history and discoveries. Maybe we should make it de rigeur that people relate their "inventions" with past art? A lot of times, when I point out past art, I get met with instant open hostility from younger devs. Is it any wonder that programming has the attributes of a popular medium, not a field of engineering study?

If young coders want to be the future intelligentsia and harbingers of a better kind of programming, they need to foster a set of subcultural norms that best leverages collective knowledge. Programming has to become a field that remembers its own history and can learn from its mistakes.

If young coders want to be the future intelligentsia and harbingers of a better kind of programming, they need to foster a set of subcultural norms that best leverages collective knowledge. Programming has to become a field that remembers its own history and can learn from its mistakes.

Graydon has consistently pointed out Rusts influences, indeed it is one of the reasons behind its name - ie. 'rusty old ideas'. But the influences of the creator are not enough. We need to promote the value of a historical perspective in our discourse, and so I I'm glad for your post. As a young developer I see it in my peers, but even sadder I also see it in my mentors and elders. So often there is two extremes of fervent excitement and lack of imagination that things could be better beyond ones own experience... both borne out of a lack of historical literacy.

That said, I don't mind reinventing the wheel in new ways - every time our wheels get better and better. But perhaps they could get better faster with fewer steps backwards with a little schooling on the foundations of our field.

Not always. Pry debugging Ruby can be pretty awesome but still often leaves a lot to be desired compared to the VisualWorks Smalltalk debugger+environment. Then there's the One Laptop Per Child project. How many developers were trying to recreate things that already existed in Smalltalk? What if they could've freed up the developer power wasted in that wheel reinvention? Seriously, a lot of the advanced state saving/rollback features would've just come for free in Smalltalk.

How many Smalltalks were not closed source and with commercial IDEs and toolsets?

You may be interested in Graal/Truffle. One of the main aims is to make it a playground for experimenting with programming language design by reducing the work that goes into the underpinnings of these new languages. It's also meant to offer fairly decent performance.

https://medium.com/@octskyward/graal-truffle-134d8f28fb69#.n...

https://github.com/graalvm/truffle/blob/master/README.md

Look at all the research and prototyping in aviation. What's weird about programming is the amazing longevity of experimental ideas vs. heavily engineered products.

I like that very much! Also strange are the obscurity and outright myths surrounding heavily engineered products, followed by hyped reinvention.

No. In fact even in the actual field of "wheel manufacturing", we have been re-inventing the wheel since for ever.

Those who don't like "re-inventing the wheel", would they rather use stone or wooden wheels for their cars? Or perhaps some of the crude early metal ones? Or they rather use the re-invented modern mix of alloys and plastic?

My university did a pretty good job teaching the ways of the past.

Sadly things seem to have changed for the worst in the last 20 years.

That's because the past then was still modern.

Those majoring in systems programming had a good glimpse of OSes and programming languages.

I've been doing C/C++ for close to 15 years now, I find that the borrow-checker not only helps with safety but also with guiding a good architectural foundation. Nothing keeps you from dropping into an unsafe block and cranking out very c-like code if you want as well.

All my green-field code now is Rust. Sure there's some hype but that's because people are genuinely excited about the language.

The thing is that even with unique_ptr I can easily reach in via get() and I've broken the shared mutable state contract. It's trivial for me to trace what modifies things in Rust, I just follow the 'mut' annotations and since only one thing can hold it at a time it's very straightforward.

Rust also has one the best package managers I've seen. Union types which are the best way to represent states and state machines bar none. An iterator class that's the best I've seen(seriously has anyone actually used <algorithm>? How man begin/end pairs do I need?).

Plus the community is super-welcoming, there's more reasons but those are my top ones right now.

Who said it does? And why would it have to?

It'a just about catching those "certain class of errors that the Rust compiler will check that will still give you a segfault in C++".

Plus a nicer looking language, with a more modern design.

There will always be that compiler or team that doesn't have any kind of reviews, static analysis, making use of binary libraries or legacy code.

Hence why safety at language level is much better than third party tooling, as tools can be ignored.

I agree that "salvation" is a bit much, though.

For whatever hype Go had and may have, it's still a resoundingly successful language that's building meaningful stuff that improves people's lives. Sounds like a success to me.

I don't personally divide my life into "before move semantics" and "after move semantics" - but thanks to move semantics, I have to anyway. And I feel like I'm all the better for it.

Any ideas about how to add this small "incremental improvement" of Rust-like safety to C, for example?

> I just don't see Mozilla having enough resources to keep-up the momentum long-term.

Did you forget about Samsung? Mozilla and Samsung aren't the only two companies backing Rust.

http://www.tiobe.com/tiobe-index/

Call it money or whatever, but Go seems to be getting substantial TLC from the people working on it for every point release.

Of course, this could just be an easier thing for them to do since their approach is not as ambitious as Rust's.

Google is not a language company and doesn't hire good language people so I don't see this changing.

Disclaimer: I work for Google

If I have to write native code, right now it'll be C++ precisely because it's able to express complex problems with a high degree of getting-it-right (because while I would never claim to understand C++, I feel confident in my understanding of the subset of C++ that I use). I really like Rust and look forward to it being a better fit for what I want to do, and every time I look at it it's getting closer.

I don't think that the language creators are behind this in this instance, more over-excited users continuing the hype cycle. I definitely agree that it does a disservice to the language. I posted this on /r/rust[0]:

> Please don't push the hype train to far - our language, tooling and strong community does a lot of work to sell itself, and we will get a backlash if we are not up-front honest about Rust's problems. Ruby and Go are experiencing that now. Some languages are better than others especially in specific domains, but even the better ones are not silver bullets, and Rust is no different. I use Rust for some things because I feel the trade-offs are worth it.

Not all of us feel the need to sugar coat Rust.

[0]: https://www.reddit.com/r/rust/comments/5kytg5/rust_is_softwa...

I think the main hype danger for rust right now is that the number of killer applications written it will fall short of the hype. But the linked article is from someone writing redox-os, so it's hard to criticize this article specifically for contributing to overhype.

Ruby had the opposite problem, which is that a lot of people were writing amazing applications, but it fell down technically (applications got messier and slower; or at least that is the perception). In theory the same thing could happen to rust, but it seems less likely.

Having said this, Go got its killer application in the form of the main language driving container implementations.

Rust might eventually get its one beyond the current browser implementation and get adopted by an OS vendor.

Just with Apple doing Swift, Microsoft .NET Native and C++/GSL, maybe it is left for Google and their Fuchsia project or an embedded OS vendor to do it.

It's a vast oversimplification of the real issues while ignoring the reasons programming or are hard.

Of course it's possible. Say you would fork gcc (or clang) and teach it a few extensions for the C type system that allow some more safety checks at compile time (for example something similar to Rusts borrow checker). Since those checks don't change the generated code, you now have a language that's safer than C, but equally fast. Now you add some language primitives that make it easier for the compiler to understand the intend of the programmer, making it easier to optimize the code (there are already plenty of opportunities used by C extensions, like signaling that some if branch is unlikely to be taken. More opportunities exist if you modify the language more heavily). Now you have a language that's both safer and faster than C.

I don't want to make any claims about Rust performance in practice, I haven't run enough benchmarks for that. But it's perfectly possible that the statement could be true.

Maybe not faster than C but at least as fast while bringing modern patterns and better safety.

It's actually entirely possible. For example it's how Fortran has been traditionally faster than C, by not allowing for aliasing (which is also an unsafe feature) it can give the compiler more room from optimization.

That's from the linked article 'Rust is Software's Salvation' (bullet point 3).

That's C's limitation: it can only be as fast as the compiler geniuses can make it, or as concurrent as its users can explicitly make it. Given that almost all computers where you care about raw performance are multiprocessing now, that's a huge deal. Languages with primitives like async/parallel map() are going to have a hard time keeping up with those that do.

Sure, you can write ultra fast code in C or assembly. The fastest way to do so might be to write it first in Erlang, Go, or Rust and reverse engineer it from the resulting machine language.

(It's not built in, but that's a good thing IMO. :-))