Hacker News Reader

Comment by threeseed | Hacker News Reader

The hype for Go/Rust is really just on HN.

If you are involved in data analytics then you could always immerse yourself in the Hadoop stack e.g. Cascading, Spark, Mahout etc. It's a platform that is increasingly become a fixture in enterprise companies and plenty of new technologies. For me the future will be "container driven development" where everything will be deployed as a container and dynamically wired together. Loads of new technologies e.g. Docker, Consul and plenty of challenges still around.

None of what I wrote is around languages/frameworks though mainly because I think that the majority of them won't be really used in 5-10 years.

View on HN

I would have to disagree.

If you think it's just hype, try and calculate the enormous waste of both time and money from memory leaks caused by code written in C and C++. Rust solves this, and it's only going to get better once we're on the other side of Rust 1.0, and the library ecosystem grows.

I think by hype he meant enthusiasm : it doesn't mean Rust or Go is useless but that enthusiasm for this languages is far more present on HN than anywhere else.

Not just memory leaks... all the recent hacks/exploits are showing us that even the best people in our field can't write secure code in C/C++. You can reduce your attack surface substantially by using a language like Rust.

Imho, it's a scalability issue.

Was OpenSSL secure when it was originally written in X lines of code? Very likely.

Is it feasible to expect it to be secure now that it's X^Y lines of code, when a large class of bugs can exist in any line of code? No.

That's what 15 years of an evolving codebase has taught us. Which is reasonable, given that a lot of open source projects came into existence in the mid-90s. Inculcate lesson, design language for next 15 years. Not that radical.

Does it really matter whether it's a scalability issue though? The bottom line is that the code has bugs, whether it's due to the fact that the codebase is large is somewhat irrelevant.

By scalability, I meant more along the lines of, "Is it possible/efficient/reasonable to write large, secure codebases in language X using process Y?"

Answer A is "Yes, bugs come from bad development practices or unskilled programmers."

Answer B is "No, there are fundamental issues with the language that make it unreasonable to expect a secure product."

In other words, are the primary sources of bugs programmers or the ways the language forces them to interface with it?

> Try and calculate the enormous waste of both time and money from memory leaks caused by code written in C and C++. Rust solves this...

This seems like an unusual language feature to highlight --- don't most modern programming languages solve this problem with various implementations of GC or memory management? N.B. I am not at all familiar with Rust and so maybe I'm missing some important context...

Yes, but all managed languages will necessarily be less performant and less efficient than C/C++/D/Rust (barring a hypothetical future interpreted language with an amazing JIT and GC; LuaJIT has the JIT part down but definitely not the GC). Rust is specifically for systems programming. If you don't need to do systems programming, then sure, use C# or Scala or whatever you like.

The more I've been hearing about Rust, the more I'd like to try it. What's the equivalent of "_why the Lucky Stiff's Poignant Guide to Ruby" for Rust?

The official guide[0] is worked on by Steve Klabnik and serves as a good introduction to the programming language. Where you go from there is the hard part a lot of people interested in Rust struggle with. I recommend building a clone of some command line tool you like or if you're a Ruby/Python/JavaScript programmer try and build an extension for those languages but written in Rust instead of C. Good luck!

0 - http://doc.rust-lang.org/0.12.0/guide.html

You know what language Docker is written in, don't you?

Emacs is written in Lisp; so?

Yes, lots of other cloud software is written in Golang as well.

Reply on news.ycombinator.com