Thread: Let's talk about Rust!

Originally Posted by Neo1

This is absolutely toxic, and frankly i no longer see any reason to remain an active member here. Bye.

I think you are overreacting. I do not believe you are fault or in error. You brought up a topic you wanted to discuss, discussed what you wanted to do. Who cares where the topic heads? If you don't like something, ignore it! You don't need to respond. Pick what interests you and focus on that.
This topic was fun. I do not see it as damning. Btw, I am not included in the group who are "against" you.

I'm surprised that nobody brought up Ada (equally surprised that I didn't think of it). Doesn't Ada already do the things that Rust is claiming to do (compiler-enforced safety, standard abi, C interop), and more? Ada has been around longer than C++, has evolved more-or-less in parallel with C++, with a roughly equivalent feature set, had the full force of the US DoD behind it in its early years, and still only sees limited, niche use (#32 on the TIOBE index, as of 2014). I think it's safe to expect an even lower adoption rate for Rust.

Originally Posted by Neo1

The reason there is no worthwhile content is because this place has become a reverberation chamber for those arguing the established 'truths' of the business. This is absolutely toxic, and frankly i no longer see any reason to remain an active member here. Bye.

The only establishment in know of in this industry is that someone always ends up throwing up their arms when discussing what language is better. Which is essentially what you did here, despite your best attempt at painting yourself as a victim; you tried to indoctrinate that one language is better than the other and threw up your arms when, surprise, no one agreed.

Best of luck in whatever new programming discussion group you end up.

Originally Posted by Elkvis

I'm surprised that nobody brought up Ada (equally surprised that I didn't think of it). Doesn't Ada already do the things that Rust is claiming to do (compiler-enforced safety, standard abi, C interop), and more? Ada has been around longer than C++, has evolved more-or-less in parallel with C++, with a roughly equivalent feature set, had the full force of the US DoD behind it in its early years, and still only sees limited, niche use (#32 on the TIOBE index, as of 2014).

Well, yes Ada supports a number of the things promised by Rust.

Where Ada (arguably) fell down is that it was a huge specification so rarely taught at educational institutions, a large learning curve, and few obvious means of learning it gradually so programmers tended to gravitate to something else. The US DoD tried to mandate its usage by making it mandatory in contracts, and then ran into resistance from suppliers because development of compiler and run time was expensive, getting validated implementations more so, they had to swallow the investment of time needed for developers to learn it since they couldn't readily recruit people who were expert in it, and the US contracting model places a large emphasis on affordability (i.e. minimising billed cost).

Originally Posted by Elkvis

I think it's safe to expect an even lower adoption rate for Rust.

Those things are hard to predict. Rust does have an advantage of a community of people who are interested in using it, rather than having to be forced by an employer to use it.

We've also had one person here mention that the attraction of Rust is its relatively small size (a characteristic that would be hard to associate with Ada - even some of the standardised subsets are huge by various measures). Given the change between versions of Rust, I would suggest - assuming it remains popular - that it will grow.

Pragmatically, the growth of popularity of any programming language relies on people being able to achieve useful things with it, and being able to see potential of doing MORE useful things with that language. Where the notion of "useful" is an individual thing, that depends on a person's preferences, the work they do, the work they want to do, and things like that. When people successfully do useful (to them) things, and see the scope to do much more, they'll invest the effort to learn. That learning involves a significant investment of time and effort, both to learn good techniques and (often more important) to learn what to avoid.

Proselytising doesn't work, as anyone who has invested effort to learn a language has encountered its strengths and weaknesses - and accepted them. And has also probably been subjected to zealots claiming they've made the wrong choice - usually for the "better" choice to either not last, or to turn out to be suitable for a very different style of development. Telling people what to do without an honest attempt to understand what they're really about is not the way to win them over.

Which is why a pitch for a new language, if made to a community of people with experience in another language, needs to openly discuss benefits and trade-offs with practical use cases. Without proselytising. People will then decide to look further, or not, depending on their individual interests.

Originally Posted by iopq

I wouldn't call Rust a small language.

I don't claim to be an expert in Rust, but from my reading about it I wouldn't suggest it is small either.

Originally Posted by iopq

First of all, it has a lot of syntax like for, if, etc. in Smalltalk this is implemented with method calls and then inlined by the JIT (hopefully).

To say the least, that (e.g. implementing an if as a special case of method dispatch, rather than as a separate language feature) was a rather unusual decision by the Smalltalk designers.

Am I right in interpreting your point as being that Rust supports various abstractions using language features (i.e. there isn't an aim to slavishly minimise the size of the core language, and relegate everything else to the library)?

How important is that sort of distinction in a discussion of utility of Rust though? Does it affect people implementing libraries for use by other Rust developers, the people writing the Rust compiler or library, or does it affect someone using Rust as a tool to do something else? Those sorts of questions are relevant to any languages - I'm just trying to get an idea of where Rust sits.

Originally Posted by iopq

Then you have pattern matching syntax, macros, and a complex type system that involves lifetimes and borrowed pointers. Then you have interactions between these features like the borrow checker doesn't know that the pattern matching on a slice borrow the rest of the array, so you get an error because it tries to move the value instead of making a reference to it because it's a value type.

I assume that is more a reflection of maturity of the borrow checker (it's design, implementation, etc) than a flaw of what it is about (which I understand to be detecting invalidated iterators at compile time if possible).

Originally Posted by iopq

Then you just throw stars and refs at it until it compiles and you have no idea why it even works.

From an assurance and safety perspective - that notion really makes me shiver. If a developer can't explain why their code works, let alone the conditions in which it works, it's really hard to convince someone else that it does.

A similar phenomenon affects C and C++ developers (and makes me shiver just as much) when people play with multiple levels of indirection, and start throwing asterisks and ampersands around.

Originally Posted by iopq

When I think of a small language I think of a language like Lisp.

Sorry, my cat just choked on a furball. A small one

Originally Posted by iopq

Rust's philosophy is basically focusing on being the best low-level language possible.

Yeah, but what does that really mean? I'm not being flippant in that, but to be "best" at anything, it's necessary to articulate a set of measurable criteria that provide evidence for or against such a conclusion, and provide a level playing field for comparing alternatives. For that matter, what do you mean by "low-level"? People interpret that notion differently.

Those aren't really fair questions though. Different people will have different notions of "best" and "low-level", which are influenced by (as distinct from being driven by) programming language of choice.

Practically, I don't tend to worry about whether a language I'm using is high level, low level, best, or anything else. In software development I start from the perspective of trying to achieve something, and choose techniques (design approaches, requirements capture, etc) and tools that are appropriate to do the job, and to provide evidence I've met requirements. Choice of language (or languages), IDEs, toolchains, etc is just one of many choices - and is rarely black-and-white.

Originally Posted by iopq

that means a fully-functional Mill can outperform the top of the line Intel/AMD processors in some tight loops by an order of a magnitude while still being just a as fast in general-purpose code

That sounds a little too good to be true. I'm going to take that with a grain of salt. True, the x86 architecture isn't the most efficient around, but I honestly don't think it will loose out to another architecture on such a degree. It's not like Intel/AMD are rolling their thumbs.
What does C++ being an assembly language mean anyway?

Originally Posted by Elysia

That sounds a little too good to be true. I'm going to take that with a grain of salt. True, the x86 architecture isn't the most efficient around, but I honestly don't think it will loose out to another architecture on such a degree. It's not like Intel/AMD are rolling their thumbs.
What does C++ being an assembly language mean anyway?

As you know, nobody writes assembly by typing in machine code directly
Each assembly language is a macro language

in other words, most assembly languages have the capability of writing

Code:

repeat  3
add     ax, [bx]
add     bx, 2
endm

this would generate an intermediate code of

Code:

add     ax, [bx]
add     bx, 2
add     ax, [bx]
add     bx, 2
add     ax, [bx]
add     bx, 2
add     ax, [bx]

and then get generated to machine code
this is the "macro" part of the macro assembler language


on the mill, that "macro" language is C++
so you write

Code:

for (int i = 0; i < 3; ++i)
     addu(b3, b6);

and that will generate an executable file
that executable file contains three calls to the addu "function"

all the addu "function" does is generate the correct machine code for that instruction, so once you call it three times, it's just the same thing as generating a temporary file that says

Code:

addu(b3, b6);
addu(b3, b6);
addu(b3, b6);

this means that you can use all the if statements, loops, classes, templates, anything you want in C++, and eventually you'll get native Mill machine code as the output

I attended this talk about the Mill where Ivan Godard explained how it worked: http://millcomputing.com/topic/specification/

So in other words, it just generates more complex instructions. Though I'm not sure if that's an advantage all the times, as history has taught us that RISC architecture often perform better than CISC. x86 translate complex instructions into micro-ops that are more RISC-like too.
But I'm pretty sure that x86 can (I am not an expert in x86 assembly, though) do:

add ax, [bx + 0]
add ax, [bx + 2]
add ax, [bx + 4]
add ax, [bx + 6]

etc