Thread: Let's talk about Rust!

Originally Posted by Elysia

That's why it's important to have in place from day #1 so no legacy code will be able to "get in the way." That gives the highest probability of there ever existing a common ABI.

You just don't get it, do you? The 'B' in ABI means 'binary', as in, machine code. It cannot be fully standardized by the language specification without making it unportable (to anything not covered by the spec, obviously).

So... Are we gonna all just ignore the fact that MILL architecture CPUs sounds absolutely astonishingly amazing? It's free performance boosts without code rewrites. I started watching the presentation on branching and I'm really starting to get into this. I mean, forget writing in assembly. Learning assembly in this day and age just seems silly unless you're either getting paid for it or you're getting paid a lot for it.

The speaker is also a perfect caricature of a computer scientist, imo. And I absolutely loved his joke, "Now, some of you younger folks may not recognize it but this is 'assembly language'."

Originally Posted by Elysia

What you are saying makes no sense. Either you have fewer, but more complex instructions or you have more, but simpler instructions. You can't have both.

They aren't instructions, he is specifically talking about assembly macros.

Many assemblers support predefined macros, and others support programmer-defined (and repeatedly re-definable) macros involving sequences of text lines in which variables and constants are embedded. This sequence of text lines may include opcodes or directives. Once a macro has been defined its name may be used in place of a mnemonic. When the assembler processes such a statement, it replaces the statement with the text lines associated with that macro, then processes them as if they existed in the source code file (including, in some assemblers, expansion of any macros existing in the replacement text).

Note that this definition of "macro" is slightly different from the use of the term in other contexts, like the C programming language. C macros created through the #define directive typically are just one line, or a few lines at most. Assembler macro instructions can be lengthy "programs" by themselves, executed by interpretation by the assembler during assembly.

Since macros can have 'short' names but expand to several or indeed many lines of code, they can be used to make assembly language programs appear to be far shorter, requiring fewer lines of source code, as with higher level languages. They can also be used to add higher levels of structure to assembly programs, optionally introduce embedded debugging code via parameters and other similar features.

If you don't know what something is, don't pretend to follow along.

So, I'm currently looking through the Rust wiki and I have some comments/thoughts :

1. No null pointers is interesting to me though I'm sure other languages already have this

2. It's performance is expected to be similar to C++ with proper checking which means native versions of C++ are faster and a performant build of Rust would have to be "unsafe"

3. I like the functional style in the factorial examples and that if-else is an 'expression'

4. Things are automatically immutable so I don't see how time is saved or this is preferred over using 'const' in C/C++ because I have to declare 'mut' for everything I want changed

5. println() is no better than printf() and both are less useful in my mind than std::cout which just prints anything without me specifying

6. Spawning multiple threads is very similar to std::thread + lambdas

And I have to read more about the pattern matching and recursive data structure examples to understand them.

Yeah, once I discovered languages that don't have null I pretty much stopped being impressed by languages that didn't solve this problem. That's why I didn't like Dart: it's not doing enough to really replace JavaScript. It has all the null pointers, all the callback hell, it's just a small improvement that's not worth the investment to learn it.

Unlike D, Rust doesn't have "unsafe" builds that perform better. But you can write code that is marked trusted and the compiler assumes you know what you're doing. In other words, you either leave safety to yourself or the compiler. You'll have to use the more low level APIs explicitly.

In regards to const, 80% of all variables are used once and only once. What's the point of marking 80% of your variables const when you can just mark 15% of your variables mut? (The other 5% are never used)

println! macro is better than printf because it won't compile when you have the wrong amount of arguments, while printf will barf at runtime

to the contrary, most variables are something like

Code:

ui_inputSpinBox1 = findChild<QSpinBox*>("inputSpinBox1");

and then later

Code:

ui_outputWidget->setText(QString::number(value + ui_inputSpinBox2->value()));

so you assign something, use it once and you're done
this is 80% of all variables according to research