Live data from Hacker News

Why I love Rust

speakerdeck.com

111–120 of 159 posts

Re: Why I love Rust

#111

Earlier quoted context omitted.

I actually think you'd go far to spend 3 - 4 months learning C++. Almost every language you can likely encounter in your career will use some feature that will get introduced to you in C++, especially modern C++, and, almost any language will be easier to learn and use after first going through a C++ learning curve. Besides, C++ is still the big player, more than all others. Even Apple's new language Swift is written…

I think that is a great answer. I actually see some parallels between the relationship of Rust/C++ to Scala/Java. Both basically use the backend of the established language and provide an 'improved' language on top of it. Scala uses the JVM, and Rust uses LLVM. What is interesting is that with the release of Java 8, a lot of Scala early adopters and cutting back their investment in Scala in favor of Java (for example…

Anyone who's actually used Rust, C++, Scala, and Java knows that Rust and Scala involve considerably less suffering than their counterparts. The "adopted features" don't change the fundamental problems.

Java 8 lambdas are fundamentally broken due to checked exceptions, and the likelihood that checked exceptions are going to be removed from the language is essentially nil.

Likewise, Rust error messages are already better than C++ compiler error messages, and the nature of C++ template expansion makes that unlikely to change.

Learn what you want to learn... not what large companies have decided to adopt (or not) based on a number of factors that have nothing to do with the quality of the language or its educational value.

Re: Why I love Rust

#112

Earlier quoted context omitted.

> If you start with C++, you're committed to a multi year project, that's what it takes to advance from novice to junior level. This is ludicrous. Depending on your back-ground and the amount of time you spend working in the language each day, a journeyman level competency can be had in just a few months. Honestly this sounds like a comment from someone who has not done much C++. Please correct me if I'm wrong.

I agree with GP and I've been doing C++ for a long time. There are a lot of dark corners that aren't a problem until they suddenly are. Most C++ devs don't really understand iterator invalidation, for example.

Or undefined behavior.

I guess it can be summed up as: C++ is extremely good at making people think they're writing safe programs.

This feeling of safety is virtually always incorrect in the case of large-scale software, and the huge stream of memory-related vulnerabilities that virtually all popular network-facing C++ applications have and continue to have is proof of this. There is no reasonable way to argue against this; the fraction of popular network-facing C++ software written by a large team that have had memory safety problems rounds up to 100%.

Re: Why I love Rust

#113

Earlier quoted context omitted.

I'd really like to know how well that works out at Dropbox. How honest and public do you think they'd be if major data losses resulted from Rust crapping out on them? I'm not sure about them but lots of businesses keep such things on the DL. I think it's a risky move. I'd have first deployed existing, native code along with Rust in parallel using the data splitting technique so some is saved with original and some wi…

> I think it's a risky move. > It's just... wow, that's pretty mission critical for what I gather is still a beta-phase tool. I think this is very '90s thinking. Extreme "if it's not C++, you can't deploy it!" conservatism about programming languages hasn't been true for well over a decade. Paul Graham has written some nice essays about this very phenomenon. Also, Rust is not "a beta-phase tool". New languages are mu…

You've been in discussions on this forum where I slam both C and C++. I'm clearly against it unless I absolutely have to use it due to its issues. That's why your strawman is more amusing than most. My actual argument was that new tools are usually unstable in terms of features, implementation bugs, and (with compilers) performance. So, default recommendation for mission-critical apps are mature tools whose strengths and weaknesses are well-understood so pro's can use them robustly.

Back to beta-phase claim, you're saying the core features and compiler of Rust are no longer in development or testing? Totally stable now with only extensions, library features, and optimizations being added? If so, that's good news and I'll drop that claim in the future. Otherwise, it's in the beta phase. Another hint would be existence of any bugs with core functionality in your compiler or libraries.

Again, though, if the spec and core functionality are frozen with all bugs fixed then I won't call it beta. Is it there yet?

Re: Why I love Rust

#114
post #52

Earlier quoted context omitted.

Rust and Go are going into different directions. Rust is trying something new and Go tries to only use the stuff that worked in the past. It's no surprise that people favor Go instead of Rust. Also the last time I saw a video about a low level language discussion, only Rust had a dev there nobody really knows. C++, D and Go had prominent people speaking for them. The tooling really isn't the problem, as far as I can…

"Also the last time I saw a video about a low level language discussion, only Rust had a dev there nobody really knows. C++, D and Go had prominent people speaking for them." That has nothing to do with anything. "Rust is trying something new and Go tries to only use the stuff that worked in the past. It's no surprise that people favor Go instead of Rust." That's a good point. Anyone doing something critical wants lo…

> Go's methods were proven in Pascal, Oberon, etc. So, Go is less risk.

Totally disagree. Rust's ideas are tweaks of decades-old research. These tweaks are what make it interesting and constitute research in their own right, but Go did that too with their tweaks to CSP and interfaces.

Re: Why I love Rust

#115
post #53
post #34

Earlier quoted context omitted.

I think the reasoning behind the debate is that, together , they mostly obsolete C/C++. Go takes the high-end and Rust takes the low-end, and there's no niche left for C to occupy in the middle. I guess the real answer is, if you want to learn "the language that people will be using instead of C in ten years"... learn both of them.

I don't think so. Of course, there is space for Rust and Go. But that does not mean there will be no niche for C and C++. That is simply not correct. Ignoring C and C++ mean you are ignoring maybe billion $ industry around them . and That is simply wishful thinking.

>>Ignoring C and C++ mean you are ignoring maybe billion $ industry around them

Right, very difficult to move the inertia in any direction. The same is true about Java too.

But there are fewer reasons for any starting a new project to do it in C or C++.

Newer stuff replaces older stuff, Heck when C came along, there were languages with billion $ industry around them. C replaced them.

Re: Why I love Rust

#116
post #52

Earlier quoted context omitted.

> it's still pretty immature from a production tooling point of view. I think that the production tooling for Rust is pretty good. For example, it has a package manager that everyone uses, with features like lockfiles that are specifically designed for production. Not many languages have this. It's undeniable that Go is more popular than Rust, but I think "production tooling" is not the reason.

Rust and Go are going into different directions. Rust is trying something new and Go tries to only use the stuff that worked in the past. It's no surprise that people favor Go instead of Rust. Also the last time I saw a video about a low level language discussion, only Rust had a dev there nobody really knows. C++, D and Go had prominent people speaking for them. The tooling really isn't the problem, as far as I can…

Rust is actually pretty conservative regarding "new stuff".

Every single feature of Rust, with the exception of the borrow checker, has been around since the 80s.

Even the borrow checker is based on linear / affine types that had been researched in other languages at least over a decade ago.

Re: Why I love Rust

#117
post #8

Earlier quoted context omitted.

Career wise, you should pick up popular languages, Java/C#/Python/Ruby/JavaScript. Between Go and Rust, I think you should pick Go because there are a significant number of developers from Python/Ruby/JavaScript enjoying programming Go. Many startups start using Go[1] and couple of universities use Go in their classes[2]. Rust targets system development primarily occupied by C/C++ developers. Many still prefer C++ an…

The TIOBE Index for January, 2016 has Java at number one. Rust is at 47 and Go is outside the top 50: http://www.tiobe.com/index.php/content/paperinfo/tpci/

TIOBE is bullshit.

Its based on search engine 'search' text typed by users. 'Go' and 'Rust' are both words used for a wide variety of purposes apart from programming languages. Same with Python.

Don't trust TIOBE on these things.

Re: Why I love Rust

#118

Earlier quoted context omitted.

> 3-4 months into programming Rust and you may just be getting past the phase where it takes you 10 minutes of fighting the borrow checker to get relatively simple code to compile. This exactly is why I can never get past the first couple weeks of playing with Rust. Every few months I revisit it and every couple weeks after that I put it aside again. When I was first learning C++ I spent a huge amount of my time insi…

I'm always interested in trying to figure out how to explain these things better, if you ever want to vent some frustrations at someone :) > bury Rust's borrow checker for those parts of an application The problem with that is, if you did, you're back to > I spent a huge amount of my time inside the debugger trying > to figure out why a pointer wasn't ... pointing. What I can say is that after you get over the hump,…

I swear I've seen more than one person gripe about this. Mostly from a change of thinking but it seems recurring. Might hurt adoption. I'd have expected Rust proponents to have a link on-hand for this to a guide that teaches this stuff in a way to reduce the effect. To be clear, this is not a critique of the Rust team so much as an observation of a larger problem in PL adoption that might be affecting Rust.

The trick, IIRC, was to have some smart people create a series of programming exercises that are complex enough to be a learning experience, teach a subset of the language at a time, and gradually let the concepts sink in. Practical Common LISP and Land of the LISP do this pretty well for a very confusing language. Rust will probably benefit from such a work, even more than CL. Just a suggestion in case someone's not working on it. ;)

That stuff works wonders for ease-of-adoption but such writing takes talent to produce. Takes someone with strong, tech skills who can also break anything down into English a layperson can understand. As in, it's really a series of consistent abstractions that form an effective, mental foundation for using and applying the language. Not regular definitions and examples but a true, gradual, practical process. Hopefully, you've seen such a great work vs a regular, language guide so you know what I'm talking about.

Re: Why I love Rust

#119

Good presentation with a great, artistic style. Also liked her articles about speeding Java up and "A/A testing." Far as this one, the only correction I have is regarding the slide that says you can't write an OS in Java. Several have been written w/ JNode and JX OS coming to mind immediately. JX is my favorite given its interesting architecture is mostly compatible with high assurance requirements. Just needs a high…

Yes indeed, and of course we must not forget Singularity/Midori which were implemented in a derivative of C# and .NET

I'd really like an OS built this way to become competitive. 64 bit flat address spaces and fully type safe designs really let you simplify things a lot in some fundamental ways. And you'd be able to run existing Java desktop apps without much in the way of porting effort.

Unfortunately all the Java OS's out there are hobby/academic projects that never got very far beyond a basic window manager.

Re: Why I love Rust

#120
post #78

Earlier quoted context omitted.

As someone in the games industry, I don't see anybody moving towards either of these languages over C++, or really even any excitement over them. I'd be very surprised if Rust displaces C++ here, and put the chance of Go doing so at pretty much 0. If anything, the current trend is moving more low level (rather than higher level, which these languages both are), as techniques like data oriented design becoming more ma…

> (rather than higher level, which these languages both are) Rust should be (and is, modulo wrinkles, I mean there's no fundamental reason) as low level as it gets. What makes Rust too high-level for gamedev?

It's probably not too high level for game dev.

However, modern AAA game dev is largely about customising and upgrading large existing game engines, which are all C++ based. Rust could be used for them, but isn't, and the extra features Rust brings are not compelling enough to rewrite huge amounts of working code and suffer (re)training costs.

This is a hole many new languages find themselves in. JetBrains have come up with a very clever solution for their Java/Scala competitor Kotlin: the language was carefully designed from the ground up with perfect Java interop in mind (Java/Kotlin call into each other seamlessly, the IDE can refactor across languages, Kotlin uses the same standard library etc). And quite amazingly, the IDE can automatically rewrite Java into Kotlin. This isn't a party trick, it works very well.

I think if Rust wants/wanted to be a serious competitor to or upgrade path from C++ it'd have needed to take at least some level of C++ interop into account from the start such that Rust and C++ could be intermixed freely. AFAIK though, the best you get is a typical C export/import layer which is too trivial to be compelling.

Of course, it's a lot harder than connecting with Java because of the way C++ stuff is defined using header files. But at least basic interop could have been done.

Post reply on HN