Hacker News Reader

> I don't mean to burst your bubble here.

You won't.

> But people need to feel productive quickly with a language, otherwise they'll drop it and move to something else which makes them feel that way.

This is relative. Rust is far easier to learn than C++. It has a compiler that will even enforce that you don't shoot yourself in the foot. It also has nice tooling to get you up and running quickly. It has good documentation. It has a free book. We've had no trouble getting our new grads up and running with Rust. It's not that hard.

> Javascript is thought of as a terrible language by language snobs, and yet it has a huge following.

Having a huge following doesn't make it less terrible by the measures of PL theory or sensibility. It's also the only choice on the web, but that may soon change, Rust has first class support for wasm so it's in a good spot there.

> Haskell, on the other hand, is much beloved, and doesn't. Don't get me wrong, it's got its share of love, but hasn't seen the explosive growth that python or java has.

By most accounts the Haskell ecosystem and user base are quite large considering it is intended as a research language, and the community is still growing. Rust isn't intended for research, and it's incredibly young compared to Java or Python, so it has plenty of time to catch up.

> but people were so much more productive with Java.

Hahaha. You mean people wrote a lot of Java. Let's please make the distinction between productivity and writing a bunch of enterprise crapware churned out by barrelful.

> They didn't have to worry about memory management, segfaults, crazy C++ semantics, etc.

That's exactly what Rust does for you.

> Companies were more willing to throw hardware at a problem to reduce risk/time in development. And that is still true today.

Actually companies are becoming more aware that speed is a feature, and that Moore's law isn't holding out. We're also moving to smaller form factors: phones, watches, glasses... the future is not on the desktop by any means, and no one wants to waste capacity in a datacenter needlessly.

I think Rust should stop looking at C++ as the becnhmark / comparison point for complexity. The expectations that developers have from languages has increased over time, and Rust itself has contributed to raising that bar.

We don’t generally consider other languages as a measure of what complexity is “okay” or something, and are extremely aware of Rust’s complexity. Rust has a lot of requirements that directly lead to a lot of that complexity. But it’s neccesary, not incidental. Or that’s the hope, at least. Rust is also not perfect.

A lot of (but not all) complexity is solved in C/Python/Java by throwing a data structure at the problem. But is it a fair statement to say that not all data structures will work in Rust? Or is it better to say that some data structures work better in Rust than others?

Writing certain data structures in safe Rust can be hard, but not impossible. I’m not aware of any data structures that simply cannot be written in Rust.

Of course, since anything that can be written in C can be written in unsafe Rust.

Though, reading the post above yours, I was thinking more about the use of data structures than the implementation of them. In C++, when faced by the need to efficiently iterate through a data structure in different, incompatible orders, the tool of choice is often just to make intrusive linked lists with multiple next pointers per element. I think I've even once implemented something that was a priority queue (heap), two different lists and a tree at a same time.

While doing that in Rust is by no means impossible, it seems to me that the use of such a structure would be much more clumsy in Rust, to the point where I would try hard to solve the problem in some different way.

The languages are all turing-compatible anyway, so it's not about what can be done, it's about what approaches does the language make easy and promote. Overall I really like the kind of code idiomatic Rust tends to end up like.

Thanks for the thoughtful post. I do have a question, that maybe you can answer?

> The languages are all turing-compatible anyway, so it's not about what can be done, it's about what approaches does the language make easy and promote.

Turing completeness is kinda besides the point. We probably wouldn't be talking about it on HN if it wasn't. :)

I guess what I'm wondering is does Rust encourage simpler but possibly slower data structures, or are there some complex data structures which are simpler to ensure safety than other simpler ones?

In other words, does Rust encourage simplicity at the cost of speed?

As with all performance questions, the answer is “it depends.” For a look into this question, see http://dtrace.org/blogs/bmc/2018/09/28/the-relative-performa...

Hey thanks for the response.

I'm happy that rust has a good set of performant data structures, but on the other I feel like it's too soon to say Rust is the big winner here as the author does. I've been very skeptical on fantastical claims by language promoters.

But taking the pain out of making common data structures is a good start.

I think if you'll look into the author's credentials he is far from a "language promoter."

See the thing is that I agree with most of your statements, so you're really not changing my mind with your arguments.

> Actually companies are becoming more aware that speed is a feature

No. If that were true, Python wouldn't be the fastest growing language, and we'd be hand optimizing everything in assembly and using languages that allowed us to do that (C). That was the entire point I was making. It's why Java won.

I can't figure out if Rust is serious about being a true competitor, or just merely riding the peak on the Gartner Hype Cycle [1].

[1] https://www.gartner.com/en/research/methodologies/gartner-hy...

Python is growing because it's a good scripting language, and there's a need in the ML community for a standard language to write scripts in. The ML community is growing like crazy, thus Python grows. Even though Python is secretly calling Fortran for scipy, or Tensorflow (C++), or PyTorch (also C++), all of which would make good candidates for Rust replacements. So obviously speed is necessary to enable what people are doing in Python.

I make the distinction between script and what we software engineers do, because I had the misfortune of spending half a decade in research doing ML, and those guys are not writing production programs. They're hacking out Jupyter notebooks and writing precariously balanced code that barely works.

That doesn't make Python suitable for large applications. It doesn't diminish the fact that CUDA is growing, SGX is growing, embedded is growing, that we're now unlocking 100G fiber, that we've reached the limits of single core performance, that intel is rolling out 8+ core consumer CPUs. Python is not going to shine for any of these things, but Rust will.

tl;dr: despite being relatively slow Python is a fantastic glue language. Some people thing rust is well positioned to steal Python's dinner.

That's not what I said. I said Rust was a good candidate for all the things Python is using to actually do useful work. The underlying libraries written in Fortran, C, and C++.

Don't tl;dr; if you don't know how to r.

To be fair, it's much more likely that Julia will be stealing Python's dinner, rather than Rust.

Django is not going to be rewritten in Julia. Neither is Linux going to be rewritten in Python. Different languages have different domains. Some of these comments seem to think all languages is competing in the same domain as if Rust is a direct competitor to Julia or JavaScript.

The context of the comment I replied to was that Python was fantastic glue code _for scientific computing_. Julia won't won't impinge on Django's usage share.

Rust will not steal Pythons dinner, they are used for completely different domains. The comment was saying that Rust might be a realistic alternative to C/C++/Fortran for modules which are not written in Python.

Speed matters, it’s just that it’s far from the top priority.

All else being held equal, developers and stake holders will choose the faster language, it just makes sense.

The trick is that speed is typically seen as diametrically opposed to usability, since quite a few languages achieve speed by turning all the safety rails off or existing way too close to the metal for comfort.

If rust could deliver speed without compromising on ease or safety, and I honestly don’t know if it can, then it will absolutely crush the competition.

Safety and speed are the big words on the box. Usability is harder, because it's somewhat a matter of opinion. As someone who has professionally worked with the expression based Haskell, Erlang, Elixir, and OCaml, I find Rust to extremely expressive. If you come from that camp and feel that OOP is a bad toolkit of abstraction and that higher order functions, typeclasses, type parameters, and ADTs are much more powerful, then I think yes, Rust ticks all the boxs.

> If rust could deliver speed without compromising on ease or safety, and I honestly don’t know if it can, then it will absolutely crush the competition.

It has to be more than safe and fast. It has to be a productive language to use. A dev can't sit for 6 months trying to figure out how to write a website, when he can pick up RoR and do it in a day.

That’s why I said “ease” too.

Comparing Haskell to JavaScript is silly - JavaScript is popular because it is the only option in the browser. It has noting to do with the quality of the language itself. If VBScript had won, everyone would be using that. If Netscape had decided to use Scheme or Haskell as the scripting language, this is what everyone would be using.

Rust is competing in the space of C and C++, it is not competing against Java or Python. People are not gong to write operating systems in Python because it feels more productive. For simpler desktop applications you may have a point, but heavyweights like Word or Photoshop are written in C++ and Rust may be a realistic migration. JavaScript or Python is not.

>heavyweights like Word or Photoshop are written in C++ and Rust may be a realistic migration

Especially we've gotten used to so many of C++ shortcomings that we don't see them, but someone learning both Rust and C++ will (I'm sure) have a better experience in Rust. Even just the built in tooling (Cargo test, Cargo crates, rustup, etc.) feels so much more mature than when you're in 2018 looking at how to compile some C++ without an IDE.

Text editors like vscode and atom (electron) go head to head with sublime (c++). The dominant editor now is vscode.

For Rust to win it must be adopted by Gaming or gaming engines.

If Netscape had used Haskell the WWW might never has taken off. Or att least scripting it might not.

Despite Java's growth, C remains the language of choice for operating systems and C++ for web browsers, desktop applications, games and high performance web services.

Rust is really only competing with C/C++, not JavaScript or even Java (or Go).

I'm waiting for game engines to pick up Rust.

Not sure why downvoted. A language aimed at replacing systems languages like C++, which happens to be the go-to language for game development, seems like a reasonable choice for a game engine.

There's actually a website dedicated to tracking this - http://arewegameyet.com/

Actually it is quite interesting, thanks for sharing.

I think to be on pair with C++, a Rust based engine needs to have some Unreal like tooling.

Which actually seems to be a couple of WIP on that website, so I will now get to track their progress. :)

To be competitive to C++ on the AAA world, Rust engine tooling need to be on pair with Ogre3D, Godot, Cocos2d-X, SpriteKit, Unreal, Unity, CryEngine.

So it would be interesting to see what Seed Studios will come up with.

Some of those reasons are political, not technical.

Like C on embedded vs C++.

On Windows large majority of apps are in .NET with some C++.

On OS X and derived systems it is all about Objective-C and Swift for desktop apps. C++ is mostly used for drivers, LLVM tooling and Metal shaders.

Android is Java with some C++.

ChromeOS is all about JavaScript.

So no, C and C++ have lost the desktop, nowadays they are used for the graphics composition engine, while the remaining APIs are built on top of it with another set of languages.

If Rust is supposed to beat C and C++ on the desktop, it needs to be able to integrate into the IDE tooling alongside the mixed language tooling experience.

C is not used in the embedded space for 'political' reasons but for the fact that in contrast to C++ you have full control over what your program does and don't have to worry about when certain functions get magically called and why the size of your two-int struct is suddenly way larger than the 64 bits you expected it to be.

Sure, this is all a matter of 'using it right', but from my experience many developers in the commercial embedded space are not programmers by trade and this learning those intricacies is a real hurdle for them.

Sure it is for political reasons when even C99 is seen as too modern, and many are unwilling to let go of C89 and Assembly even if the OEM toolchain supports modern C.

And for another point of view of someone more relevant than my insignificant self,

CppCon 2016: Dan Saks “extern c: Talking to C Programmers about C++”

https://www.youtube.com/watch?v=D7Sd8A6_fYU

"Embedded Development with Dan Saks"

http://cppcast.com/2016/10/dan-saks/

Thankfully there are industry certification standards like AUTOSAR, which now require C++, so those devs can choose to keep grasping to C and switch industry or learn more modern languages.

That's relevant when you target <1$, >.15$ processors, but they are rather niche.

> Despite Java's growth, C remains the language of choice for operating systems and C++ for web browsers

Does it? Existing project use what they have chosen long time ago, we can only discuss choice for new ones. And new OSes often choose something else. I am not aware of any new webbrowser, so can't say anything about that.

> But people need to feel productive quickly with a language, otherwise they'll drop it and move to something else which makes them feel that way.

Yes, I agree, but that's not the full picture. People want a language in which they can be productive quickly, but once they master it, they, or at least some of them, will then look into quality and performance. Languages like JavaScript or Python (and even Go to some extent) are popular and easy to pick up, but there's not much room for further progress. JavaScript is already stretched to its absolute limits when it comes to performance and it's still not performing very well. And when it comes to quality, well, TypeScript is a thing for a reason.

I don't believe Rust will ever be as much of a language for the masses as JS, but it has a good chance to become a niche language for those who need or want more performance and/or quality than they can get with langs like JS or Python.