Comment by newsat13 | Hacker News Reader

Comment by newsat13 | Hacker News Reader

> The second is that, other than C# in 2000, 1995 or earlier is where most of our programming languages come from. Have we really not made any advancements significant enough in the last 20 years to have gotten people’s attention?

This is like saying the bicycle was made in 1900 and modern bikes are the same. Has nothing changed in 100 years? Change for the sake of change is unnecessary and it most cases detrimental to the core product. Fact is that languages like PHP, Ruby and JavaScript are simple enough for most people to get their jobs done (read: 90% of all programming jobs) and to me this is the only requirement for a general purpose programming language.

From a marketing point, rust needs to decide if this is for the power programmer or not. For example, Go has taken the niche of easy to understand and won't complicate life by adding unnecessary features so that it can pretend to be "modern" (I am looking at you ES6/7). Rust needs to understand that it simply cannot replace Ruby/PHP or JavaScript. It is not easy to understand and it's super power is simply not required for most programming tasks.

My understanding is that it is meant for systems programming and this means that it should target C/C++ and stop comparing itself with scripting languages.

Considering Rust's target audience, I think comparing Rust to scripting languages is ok. While Rust is aiming to compete in the system programming arena, it also aims to allow programmers who have experience using higher level languages to be able to get into systems programming without having to worry about safety. Rust has many features that make it almost feel like a high-level language and thus makes it much more approachable. That being said, Rust does not aim to really replace Ruby/PHP or Javascript, but rather a be a tool available to those programmers to write fast and safe code when needed.

I think the bike analogy is a great one: yeah, today's bikes basically _are_ the same as 1900's bikes. Sure, you can get carbon fiber whatever, and there's been some small advances, but they're still pretty much bicycles.

In this analgoy, I'm suggesting that cars aren't really in widespread use yet.

I don't like this analogy as much as you because it misses a hundred years of industrial innovation that took the bike from a novelty to the most common form of assisted transportation on the planet. Rust isn't the bike, it's the factory that was built with the best manufacturing techniques from dozens of other factories combined into one. A bike (the software you're trying to make) is still a bike no matter who makes it but this new factory can make them safer, faster, and cheaper.

Possibly :) Analogies are hard.

> they're still pretty much bicycles.

And Rust is still pretty much a programming language.

A FORTRAN developer from 1960 would recognise Rust as a programming language in the same way a cyclist from 1900 would recognise a Brompton S-type or a Specialized Shiv TT. The general shape is still there, everything else has changed.

I'm not claiming that Rust isn't, as I said, the name "Rust" alludes to Rust not being incredibly cutting-edge.

It'll have a hard time in systems programming too, at least as far as converting people from C/C++.

It will attract new talent, but it's obvious to me that people who have invested years in C or C++ will not jump to Rust. The reasons for that are numerous, but the most important one to me is that in many cases __it is a lot harder in terms of mental load and time required to write safe Rust code than it is to write the equivalent C/C++__.

Not to mention a complicated syntax and flow that turns your brain into mush. Imagine working with code that looks like this all day (1).

Extrapolating from that we can probably say that Rust will be a failure (assuming goal of making a dent in the C/C++ entrenchment) in the near/medium term.

(1) https://i.yuki.la/g/1479897150581.jpg

That code looks prettier than some C++ I've seen, though.

As someone who works on a medium-sized C++ codebase, Rust is definitely interesting to me. If nothing else, Rust's dependency management and cross-compilation tools would solve many of our headaches. We use a giant ball of shell script and Makefiles to cross-compile our dependencies for iOS and Android, and Cargo/rustup seem like they would solve much of that. We've also written a complicated system of macros for error handling, but Rust has that stuff built into the language. Oh, and it's just as fast as C++, so we wouldn't take any performance hit. If we could do the project over from scratch, I would definitely push for Rust.

This what it would actually look like:

https://gist.github.com/mmstick/797fbc1cf20c92f05d33a85c38e1...

That's not what standard Rust source code looks like. I don't see the point in the &* or boxing values. It's not very idiomatic.

This is more representative of actual Rust software practices:

https://gist.github.com/mmstick/797fbc1cf20c92f05d33a85c38e1...

The boxing there is perfectly idiomatic. Your code is likely to result in a pile of unnecessary code bloat, due to monomorphising the generic function twice, rather than just using dynamic dispatch (the overhead of which is likely trivial for IO operations).

I would say that the dense layout is more confusing/weird than the actual operations the code is doing.

Reply on news.ycombinator.com