Live data from Hacker News

Why I love Rust

speakerdeck.com

91–100 of 159 posts

Re: Why I love Rust

#91
post #71
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.

"together, they mostly obsolete C/C++. Go takes the high-end and Rust takes the low-end" In that case some one just code "GoRust" language ^_^

Go is of Pascal tradition of simple, efficient programming languages. Rust has memory and concurrency safety. So GoRust would be...

Concurrent Pascal (1975) by Brinch Hansen http://brinch-hansen.net/papers/

...Concurrent Pascal used in Solo OS. It supported human review via readable syntax, type safety, safe ops on memory, and a concurrency system that caught race conditions at compile time. The runtime underlying the OS was about 4K with the OS itself concise enough to put in one PDF in source form. So, Hansen for the [1975] win in the GoRust competition?

Re: Why I love Rust

#92
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.

Sure, but you could argue the same for things like COBOL

Re: Why I love Rust

#93

Earlier quoted context omitted.

This is a weird answer to the question, especially since Rust very probably has whatever "modern C++ techniques" you were thinking of.

I disagree. As others have pointed out, the demand for C++ jobs is still much higher than Rust jobs, so I think my answer still stands as a way to set yourself apart when thinking of a new language to spend a few months on. Ideally, one would learn Rust and C++ both and see how they differ, and why.

You must say the same thing about COBOL in other threads. Demand for it remains high with people getting paid a premium in some areas for the shortage. Something like a billion lines of it out there. Microfocus is probably hiring, too.

So, anyone following your argument should skip C++ and learn COBOL because COBOL is easier to learn, in widespread use, and has jobs available.

Re: Why I love Rust

#94

I want to spend at least 3-4 months learning a new language but just can't figure out if I should spent time learning Rust or Go. I am thinking more of it from a career perspective than interest.

What languages do you know currently? This will probably be an unpopular opinion but unless you know more than you can count on two hands, it's unlikely that Rust or Go will be give you the best ROI if your focus is career enhancement. The largest career ROI is probably in getting to advanced-intermediate level in a couple of the following (in absolutely no order, I intentionally put ones I don't know first):

- Python

- Ruby

- JavaScript

- PHP (especially for WordPress if your focus is web)

- C#/F# and the .NET ecosystem generally (especially for corporate)

- Java (especially for corporate)

- VB.Net if you want a government job

- C/C++

- Enough SQL to do whatever you want with the above

Re: Why I love Rust

#95

Earlier quoted context omitted.

> it remains the language where so many jobs are "The" language where so many jobs are? It's one of many. > As for whether C++ has any techniques to teach that Rust does not, C++ is definitely a unique experience to go through and certainly gives a developer more insight into the actual machine they are working on in a way that few languages do. Can you name, specifically, a way in which C++ gives you "more insight i…

I think that Rust simplifies some things that you must do yourself in C++, and learning how to do them is valuable. At the very least, it will help you appreciate other languages, but it can also show you areas where you get manual control over performance in ways no other language offers. And, perhaps most significantly, there are a wealth of C++ libraries out there that have no equivalent in other languages, and be…

The C++ programmers here disagree given how often they point out that C++ close to the machine is actually the C style of programming done with C++ language. It's actively discouraged by the C++ community in favor of the C++ style of programming described in Modern C++, etc. The C++ style gives low-overhead abstractions that increase safety and maintainability (in theory) while aiming for C compatibility and performance. Main libraries and well-written apps are big on metaprogrammed constructs.

So, learning to code professional C++ will not help you understand machines more. You'd have to learn C, basic OS/CPU structures, and which compilers produce for certain C statements. Maybe read Write Great Code by Hyde or some online articles. Learn C++ to understand machines? Not happening unless you microprogram a CPU for it on a FPGA.

Re: Why I love Rust

#96
post #51

Earlier quoted context omitted.

> I disagree. As others have pointed out, the demand for C++ jobs is still much higher than Rust jobs, so I think my answer still stands as a way to set yourself apart when thinking of a new language to spend a few months on. It's not going to be a particularly interesting thread if everyone who works in a language that trends higher than Go on Google chimes in to say "you should learn my language instead, because it…

OPs asked which language to learn from a career perspective, so C++ is good advice in that respect

[deleted]

Re: Why I love Rust

#97

Earlier quoted context omitted.

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…

> you can see C++ adopting pretty much the borrow checker as a tool This may be because I'm too close to it, but the Core Guidelines are similar in ways, but also very different. Preventing data races is an explicit non-goal, for example, whereas in some ways, it's the focus of the borrow checker. > Rust has no major production deployments of which I am aware Dropbox is the latest production user, as of last month. A…

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 with Rust. Any compiler or library related issues on Rust side would be caught without data loss. I wonder if they did this in alpha stage and how long that lasted.

I mean, I love seeing Rust in production and some success stories would be great. It's just... wow, that's pretty mission critical for what I gather is still a beta-phase tool. I'd be testing on the middle or front-end layers first given they're usually stateless(ish).

Re: Why I love Rust

#98
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…

"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 low risk. Using a proven tool or one with proven concepts is lower risk. Go's methods were proven in Pascal, Oberon, etc. So, Go is less risk.

Not to knock Rust in any way with the above. Might be safer in long run due to design and improving toolchain. However, there is a risk perception and a real issue of new concepts taking time to spot then eliminate problems. So, I encourage Rust for systems use on less critical stuff right now but was shocked Dropbox uses it in storage functions.

Re: Why I love Rust

#99

Earlier quoted context omitted.

> you can see C++ adopting pretty much the borrow checker as a tool This may be because I'm too close to it, but the Core Guidelines are similar in ways, but also very different. Preventing data races is an explicit non-goal, for example, whereas in some ways, it's the focus of the borrow checker. > Rust has no major production deployments of which I am aware Dropbox is the latest production user, as of last month. A…

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…

The project lead already said on Reddit that if Dropbox loses data, it's now Rust's fault, so... :)

The project was a whole team of engineers working for almost a year, with extensive testing. At least, that's what I've heard. So like, I think they did exactly what you said, it's just that it's ready by now.

Re: Why I love Rust

#100

Earlier quoted context omitted.

I disagree. As others have pointed out, the demand for C++ jobs is still much higher than Rust jobs, so I think my answer still stands as a way to set yourself apart when thinking of a new language to spend a few months on. Ideally, one would learn Rust and C++ both and see how they differ, and why.

You must say the same thing about COBOL in other threads. Demand for it remains high with people getting paid a premium in some areas for the shortage. Something like a billion lines of it out there. Microfocus is probably hiring, too. So, anyone following your argument should skip C++ and learn COBOL because COBOL is easier to learn, in widespread use, and has jobs available.

Interesting point. I was curious about this, and turned to Wikipedia:

>In 2006 and 2012, Computerworld surveys found that over 60% of organizations used COBOL (more than C++ and Visual Basic .NET) and that for half of those, COBOL was used for the majority of their internal software. 36% of managers said they planned to migrate from COBOL, and 25% said they would like to if it was cheaper. Instead, some businesses have migrated their systems from expensive mainframes to cheaper, more modern systems, while maintaining their COBOL programs.

Post reply on HN