Posts by Phil Lord

The Rust Foundation gets ready to Rumbul (we're sure new CEO has never, ever heard that joke before)

Re: Garbage Collection

The number of variables can be determined at compile time. The number of values cannot. It's references that are one of the mechanisms for achieving this.

The value "5" is a different kettle of fish. Integers are fixed in size and usually take up the same amount of space as a reference. So most languages store these directly on the stack, rather than using a reference to the heap. You are wrong if you think that there is only one value 5 in a program; there could be any number and the compiler cannot determine how many 5s there are at compile time.

It can determine how many literal 5s there are, or expressions that always evaluate to 5 (i.e. constant folding). Again, there would still be multiple copies of "5" in the program, because there is no point interning an integer. Unlike, say, a string which might very well use an interned reference.

Of course, there are circumstances when it makes sense for "5" as a value to be referenced rather than stored directly, which is when you want to add some extra behaviour to it. Atomicity, is one example. Another is when 5 is not an bounded and fixed-size integer but a number you want to be grow to any arbitrary size or precision.

As for your last comment: c.f. previous argument about civility. It is a shame that you lack it.

Re: "Reference Counted"

Rust by default does not use reference counting at runtime. Rather it determines statically at compile time when the value associated with a variable can be deallocated and does this automatically for the programmer. There is no runtime cost associated with this.

This is not always possible, of course, for example if you intern strings created across a program to save memory. For those cases, Rust has support in the standard library for a reference counted pointer. Actually two. One for single threaded use and one for threaded use. Using the wrong one (i.e. using the single threaded one across threads) is a compile time error.

So, you pay the costs for what you need and pay no cost for what you do not need.

Re: Garbage Collection

I don't know what a reference counting variable is either. References counting is done at the level of the value. The whole point is for where you cannot determine whether multiple variables point to the same value.

To bring it to the question of Rust, it does not reference count. The language uses a system of lifetime analysis to ensure that only one variable owns a value and that value outlives all references to that value. Mostly this is done statically. For the situation where it's too complex, Rust also provides library support for reference counting values. There are also libraries which do mark-and-sweep GC. I don't know how widely used they are.

Most people who use terms like "fanboi" and accuse others of being "clueless" do not actually have "inquiring minds", they just lack civility.

Re: Garbage Collection

GO uses "critical sections" to address the realtime problem. I'm not sure that I would distinguish between reference counting and GC. Reference counting is a form of GC as far as I can see.

Rust doesn't GC by default, but it does provide a reference counting system -- so some of the values in a program are effectively GC'd and some not.

Re: Someone have to say it

The semi-colon in Rust has some semantic beyond the end of the line actually. Or more the lack of one. Without a semi the line becomes a function return expression.

Feels a bit ugly when you start, but works out nicely once you are used to it. Having learned it, though, I find my python code keeps breaking, when I forget to put a return statement in a one line function.

Re: about that steeper learning curve...

"C [...] is still a bit faster according to the article".

Yeah, the article is probably wrong there. It's very hard to compare across languages, of course, but where it has been done Rust and C come out about as fast as it is possible to come out, and much the same. GO is also very fast, even with GC.

The article is also wrong about concurrency. Rust had this well before version 1.39, it just didn't have async/await as keywords. That should be obvious really. Who would design a single-threaded programming language in the 21st century?

I think most of the articles conclusions (lone programmers vs big groups) are equally suspect. Still, the title is fun.

Re: about that steeper learning curve...

There are more C/C++ programmers out there than Rust, so obviously, there are more people who can teach it also.

Having said that, Rust has produced quite a large quantity of fairly good documentation, freely available, as well as a number of books that you can buy. They have also a very good and supportive community. All of which is available world wide via the magic of the web. It's how I learned Rust.

Decreasing the learning curve, indeed, is a good thing. Some of that comes from your background. Javascript programmers will probably have an easier time than C programmers, because Rust is fairly functional. And some will come from the many "quality of life" improvements that Rust has made particularly to lifetime handling. I think it is easier now than it was four years ago when I learned it, although that's hard to measure.

Re: Congrats

Also, alas, high competent programmers write unreliable programs.

Looking for better tools to write code with has been happening since the beginning of computer time. Why would it stop now?

Keep calm and learn Rust: We'll be seeing a lot more of the language in Linux very soon

Re: I tried to love it but...

You aren't the only one. Quite a few people have found GO easier to learn than Rust. Although Rust has a somewhat richer semantics, some of which GO will gain over time (like generics!), which will make GO more complex.

Rust has also got easier over time. The most difficult bit is almost certainly lifetimes, and "fighting with the borrow checker" must be the most common point at which people give up. But this stage is significantly easier than in the past because the language has changed.

Linux PC shop System76 is building a new desktop environment in Rust

Re: Build back better?

You can use store the truck load of crap where ever you want. Being able to install it in user space is fantastic for getting things done is an environment where you are not otherwise allowed to install anything!

Re: Build back better?

It does have it's own package management system. It's rather better integrated with python than pip is which feels (and is!) a bolt on.

In terms of "3rd party" packages that it is a more complex question. Rust has gone the route of a small core, with add on packages for non-core functionality. That means it can offer somewhat different stability guarantees between the core/standard library and more extended functionality. How well this works we will see in time, but it should avoid the python/java standard library of cruft issue.

The hard bit of "3rd party" is, of course, that Rust is not a product of an standard organisation. The core/std library is produced by "3rd parties" in the sense that the code is not written by the company (or foundation) that owns Rust. So some "3rd party libraries" are effectively part of Rusts extended library support. Consider clap, for example, which does command line parsing. It isn't part of the standard library, but is used by rust-lang.org in their command line documentation. Would bringing it into the standard library magically make it more secure? Or just mean that it's release cycle would be tied to Rusts?

Latest patches show Rust for Linux project making great strides towards the kernel

Re: Next to learn

"Which means, in my bombastic opinion, that it has the potential of following the same path as ADA"

It could do. My feeling with Rust is that the learning curve is actually getting less over time. It's easier now to learn Rust than it was in the past, mostly because the compiler handing of the hardest bit (the lifetime and borrowing rules) has got a lot cleverer.

Of course, it's hard to be sure from personal experience; I learned Rust a while back and that it feels easier to me could just be that I am better at it, but I have heard similar anecdotes from others.

Re: dis-un-de-throne C in the Linux kernel?!

"C++/Rust/OOP further that sacrifice by the concept of a v_table (jump, jump)."

Rust isn't OOP though, and doesn't use a v_table. Most calls are statically determined at compile time. Polymorphism is achieved through the use of generics and the code is monomorphised to allow this.

There are exceptions because a dynamic dispatch allows you to do things that are hard otherwise. One of the changes with the Rust 2018 edition is the introduction of an optional keyword to mark usage; that will become a hard requirement for Rust 2021.

Re: Another dimension of complexity

Well, C was a modern language once, so clearly you think that it lived to it's hype.

In the end, while there will always been some guess work, the real solution is to try things out, slowly and cautiously, see if they work and make an judgement at the end of it, rather than just assuming that "C is the safest bet" based on your prejudices.

Rust is designed to fill a hole and address a variety of problems that C does have. There is no serious doubt that C has its problems and allows a wide variety of bugs which occur with regularity. Rust is designed to address these; whether it will do in the context of the linux kernel or not is what we do not know yet. This is an attempt to answer that question.

Facebook, it's cool to see you using Rust and joining the foundation, but please don't Zuck it up for all of us

Re: Rust [ ... ] as a C/C++-like programming language

The compile time is a bit slow, but the forums are not full of people complaining that it's slow. I mean, the forums where people using Rust are.

You are correct, though, it's not very C like.

Re: Rust - the language for coders who can't.

I struggle to see how this makes sense. Good coders will use the tools that are available to them.

Rust is one of those tools, and having the code compile does indeed detect lots of errors that you might need to test for in other languages. More time fighting the compiler in its sometimes baroque ways; less time writing tests. That's an engineering compromise like any other.

I've stopped worrying about lift doors shutting one me also, and don't use a cloth when taking an light bulb out any more, so perhaps I am becoming sloppy and have too much blind faith.

University duo thought it would be cool to sneak bad code into Linux as an experiment. Of course, it absolutely backfired

Re: A punitive sanction against the Uni for approving it

> "The university's apparent belief that research can only be unethical if it involves human subjects is just plain wrong. "

I think it's the apparent belief that is wrong. The University will know that things other than human subject research can be unethical. In fact, in this case, the problem is likely that they hadn't worked out that it was effectively human subject research. My guess is they read "tool and method for discovering security flaws".

If they have read, "we will see if people can detect our attempt to deceive them", then the panel would have said no.

FSF doubles down on Richard Stallman's return: Sure, he is 'troubling for some' but we need him, says org

Re: too young, (s)he knew what (s)he was doing

Ah, but which law is that?

In this case, the woman in question was 17. So capable of making an informed decision? Well, not in the territory that these events are said to have happened where the age of consent was (and maybe still is) 18.

It was foolish to have such a nuanced argument on an email list; it was likely to be misunderstood there as it is here, but that was the argument.

Google putting its trust in Rust to weed out memory bugs in Android development

Re: Too bad

Rust is a little unusual in it's loops. But as `loop` and `break` generalize both `while` and `do while`.

The syntax is occasionally overly complex -- like most C syntax languages the paren matching can get a bit much; but it's okay to my mind. Then I like lisp, so perhaps I am odd here.

Re: Too bad

I can see that you have some problems with Rust, but it's a shame that you don't say what they are, rather than alluding to other languages. What part of the Steelman requirements is it that you think Rust needs?

And the idea that Rust has a weak type system similar to Python sits poorly with me. Rust's type system is really nothing like Python. What is the weakness in Rust's type system that you dislike? Rather than just referring to Python?

Happy birthday, Python, you're 30 years old this week: Easy to learn, and the right tool at the right time

Re: pip is part of all python distributions now

No, that's not true. If you run "venv/bin/python file.py" it will run in the virtual env, if the virtual env has been created. And if you have used venv as the file name, which you don't have to. And, of course, when anyone else runs python as god intends using "python file.py", they will get a different experience. Unless you have set up "#!/usr/bin/env python3" in your magic cookie. Although, if are on a shared computer and in the meantime someone has come along and updated your python, you might get a different version of python from the last time.

And so on, and so on.

Almost all of the functionality is there, but it's not bundled and packaged (pun!) nicely. And TMTOWTDI, which is not right. This is python not perl. There should be one way. That one way should be simply and easy. It might help

I have hope. There is pyproject.toml and associated PEPs. But python is way behind the curve here.

Re: At last! Reasonable reasons!

It's really nothing to do with the IDE. It's a fundamental problem that the ending of a block is implicit. No editor can ever no with certainly while moving text, where the end of the block is, nor where you as the user intend the end of the block to be.

Curiously you see the same problem in Word. If you have a piece of text in Italics and you cut and paste this, or paste any text to it, you cannot tell Word whether you have intend to be inside the end of the italic block or past the end of the italic block. Now in the case of Word, there really is an end of Italic thing in the data model, but it makes no difference at all, because you, the user, cannot see it. You cannot tell Word whether to include it or not and Word cannot tell you whether it has included it or not.

Practical upshot, sometimes when you cut and paste, suddenly a pile of text will appear in Italics when it shouldn't or vice versa. It's an inconsistent user experience and that inconsistency is irritating.

I don't use a modern IDE. I write code in Emacs or Vim, both of which are forty years old.

Re: Why do some people not like python's indentation=code block container

I'd agree whitespace doesn't cause bugs. But it makes the editor experience more clunky, because the editor has to infer when a block ends.

Imagine you are copying a piece of text into a function, behind a for loop. Your editor doesn't know whether you are pasting at the level of the function or the for loop. If it gets it wrong, you have to manually re-indent the code. That's fine is the pasted cost is all at one level, but if it includes indented blocks itself, that can break as well but not indenting correct. Still at least it is not all bad. You used to be able to mix tabs and spaces; I used to do this in an exercise with my students -- the code only ran if it looked badly indented. Python3 has killed this off, I believe.

With other languages there is an explicit start and and explicit end. Of course, there are famous bugs where white space indentation and blocks were mismatched. Python's approach sought to avoid all of those which it does. But that was 30 years ago. No one indents their code nowadays.The IDE does it. And, in languages with good tools, you run the code auto-formatting tool and lint check in your git hooks/CI.

It's not a biggie, it's a not a disaster for python and it's now not worth fixing. But, while it was an interesting design feature of the original language, 30 years on, it is clear that it was a mistake.

Re: pip is part of all python distributions now

pip is nowhere near as good as tools used elsewhere.

Take for example, cargo and rust. I download a project, type "cargo build", "test" or "run", and it will do precisely that.

With python no. First, the project may or may not be using requirements.txt because there are several different options. pip, of course, will try to do a system wide install, unless you tell it do a user install. Although that will break if there are already dependencies with a different version number. Unless you use a venv. Which you can set up, of course. Although, if you type "python file.py" in that directory, it won't use the venv. Unless you have activated it if you shell. Or in your IDE, if you are launching from the IDE. But, that's okay. You can use pipenv which does all of this for you. Except for using requirements.txt. And it was a bit broken, although then poetry came along which is nicer, although for some reason still ignored the python version requirements, and now pipenv is better and maintained again, but perhaps poetry is still the way to go.

It works in python. But only just. You need to pick a workflow and then you need to set up your environment and then you need to follow the rules quickly and be able to debug when it goes wrong. I can get it working. But I also teach this stuff to 300 students who never done dependency management before. It's really, really not easy.

Popular open-source library SDL moving development to GitHub despite 'calamitous design choices' in git

The UI sucks. Compare

git worktree remove fred

git branch -d fred

Or:

git branch add

which adds a branch called "add". It's all just so weird.

In Rust we trust: Shoring up Apache, ISRG ditches C, turns to wunderkind lang for new TLS crypto module

Re: Can't disagree

This is true. Rust has gone the approach of having a small standard library and then a dependency mechanism. This avoids the issue that Python has with a big standard library a lot of which is covered in rust (sorry, bad pun). And, so while the core of Rust is relatively stable (not compared to C) and has strong promises about forward compatibility, it's hard to get far using just Rust the language and standard library.

There needs to be an additional layer of metadata in the dependency ("crate") infrastructure that lets you know which crates are stable enough and which going to provide future stability promises. This would allow you to get some idea of how long the software that you are building on is likely to be supported for.

At the same token, Rust version moves are generally pretty easy to manage, and were fairly well tooled. They haven't got to the Python2/3 (or Perl 6!) situation so far.

Re: Valgrind says 'hi'

> What is in some respect surprising is that 50 years on we are (in general) still developing code (whether it be ASM, C, Rust etc.) in exactly the same way as we were back then...

Perhaps that is not so surprising. All the massive changes in technology that we have both seen over the years, and here were are, writing short notes to each other in English. Not that different from a bulletin board in the late 70's.

But the languages have changed, and so have the idioms and standard practices. I routinely hack on one piece of software that has been in continuous development for 40 years. You can see the change and flow of the decades, sometimes in pieces of code that sit next to each other in the same source file. How much of this is a fashion cycle? When I see people getting excited about functional programming, like it's new, I wonder at times.

Re: Valgrind says 'hi'

> No what was being advocated was to adopt a disciplined aka Software Engineering approach, where you will have worked out the logic and associated data structures before even opening the code development toolset.

Yes, if that helps you. But how do you do that? Keep it all in your head? Or do you use some design tool to record those data structures before you open up your code development toolset? Some clicky, pointy, UML type tool?

Personally, I've never particularly liked those. I'm just not much of a figure person; I don't draw flow charts when writing documents either. I'd rather write a set of outline notes, with some comments, which I gradually expand in to a long document. With code, I do the same thing, just using comments in a code, with some rough outline of the data structures, in code. I can't see the point of using a tool that at some point you have to say "now we stop and write these things in Rust".

The OP was advocating the same thing. Writing comments first. So straight into a code development environment.

Re: Valgrind says 'hi'

Advocating for use of valgrind and static analysis is just suggested that people use better tools, to help them avoid problems. That makes sense. Choice of language is, likewise, just another tool.

In terms of comment driven design, rust has an integrated documentation format, which allows inline, examples that compile down to tests. This is in addition to its unit testing features. And it's support for "examples" -- longer free form source files that again are compiled and run as tests. All doable in C, all standard in Rust.

With respect to logic errors, indeed, no language can stop you from just coding the wrong thing. Although, it can stop you forgetting to handle specific cases, it can stop you from forgetting to handle return values, it can stop you from dead code, all of which are common sources of logic error.

In the end, I think, contrary to your statement are acknowledging their development process is faulty. One solution is to switch parts of the code away from C.

Not sure where you get the bit about Rust and casting. Do you have an example?

Re: But///but...this is routine programming

Rust does neither. You can access arrays either safely (with bounds checking) or unsafely (without). The unsafe portions are marked syntactically and semantically and clearly identifiable as such.

In actual use it favours richly functional iterators. This fulfil 95% of the use cases where C would use array access. This high level functionality is bounds safe. The underlying low level code uses non bounds checked array access, and so is unsafe, as a result of which has been heavily checked and audited.

Result: Most rust code cannot array out of bounds, and this is achieved without runtime bounds checking. It's a key example of a Rust high-level, zero cost abstraction.

Severe bug in Libgcrypt – used by GPG and others – is a whole heap of trouble, prompts patch scramble

Re: eliminating the entire class of errors.

Rust compiles to an intermediate representation which is then compiled down to assembly with LLVM. It also has good support for using the C ABI, or compiling down to the C ABI.

So, yes, it works with valgrind, mostly useful for when working with C built libraries. Yes, it works with profilers. I don't know about the ease of auditing generated assembly, but as it is LLVM which does this and is not rust specific, I would guess that it should be similar.

In my use of these tools, I have found them less slick than using over C, but functional, mostly either because they are harder to launch or because you had to do some name munging. This was last year, though; Rust is quite a fast moving target in this way.

Go I don't know about, as I've not used it other than playing.

Re: eliminating the entire class of errors.

These projects were done in C because there are lots of C programmers, it's fast, and when these projects were started, it was the obvious choice. Some of these are still key points: there still lots of C programmers; others are not so: C is fast, but no faster than Rust or Go. If Rust and Go continue their climb in usage, the availability of knowledge will probably change.

Is it worth moving? A whole sale re-write, almost certainly not. Whether it could be done incrementally, and whether that would be useful, I don't know. It would certainly require a substantial investment and that is perhaps the bigger issue. I am not and would not advocate wholesale porting to Rust of anything.

Could it make better use of tools? Maybe, but I doubt that the developers have not thought of using these tools. It maybe that the code is old enough that the tools work poorly, either missing problems or more likely giving a high false positive rate. For a piece of software as old and critical as GPG, changing code to avoid these kind of false positives would not strike me as good practice either. Perhaps you could try them on GPG?

In the end, though, C is just a tool. It is and will remain a useful tool, but it's not the only one and it has serious flaws. Ignoring this and blaming people for their lack of skill is and remains not sensible.

Re: Stick to your channels and get back after you have learned some basic developer workflows ...

To me, this doesn't sound arrogant, but someone who is bit pissed off that after years of maintaining a piece of software, they only get any attention when they get something wrong. Then loads of people jump up and tell them how they could do it better; but no one actually helps them to make it better.

Re: eliminating the entire class of errors.

"You still need to take care in your work and be professional, only in software is that considered a burden."

At the end of the day, the programmers that introduced this bug have been maintaining a complex piece of software that has been a cornerstone of internet and software distribution, allowing signing and identification, as well as encryption. It's fair to say that the are careful and professional in this work in almost every sense, except for the "getting well paid" bit.

And, yet, these bugs happen. And have happened again and again. "They should have taken more care" is not a sensible response.

AWS hires Rust compiler team co-lead Felix Klock

Re: Nice move

> I'm also convinced its too steep a learning curve for many C# / Java developers.

This is always hard to tell of course, but I did find Rust pretty hard to learn when I started working with it. Mostly because of the borrow checker; the actual concept is not too bad, but the consequences of lifetimes I found hard to deal with. Nowadays, it is much less of a problem. I seem to use explicit lifetimes rarely, normally just one at a time, and they just slow in there and away you go.

There are two possible reasons for this. One is that I am just a better rust programmer than I was and what used to be hard has become second nature. But, the other is that Rusts borrow checker has become noticeably more forgiving than in the past, which, of course, it has. It's quite possible that the learning curve is not what it was when you learned it.

I also think that he documentation is partly at fault; the Rust book spends too much time talking about lifetimes and leaves you feeling that Rc and the like are for desperate times. In actuality, they are there to use, effectively adding GC for when you need it.

Venerable text editor GNU Nano reaches version 5.0 and adds the modern frippery that is scrollbars

That and the difficulty inherent in the copyright assignment process which many (but not all) GNU projects require. It's an ongoing discussion that raises itself every few years, and I suspect will eventually happen. Savannah is an a fork of sourceforge I think, and given that everyone has abandoned that is indicative.

ZFS co-creator boots 'slave' out of OpenZFS codebase, says 'casual use' of term is 'unnecessary reference to a painful experience'

Re: Political correctness gone mad

Locking the PR involves the impact of having to delete all the daft comments of the form that we have sen here. If it is a feel-good crusade, well, that's fine. It has made something a little bit better if people are feeling good.

A PR stunt to self-promote? They just made a change. Lots of other people are doing all the self-promotion for them.

Re: My first thought:

I think that would be a good argument if we didn't continually the words we use because we are industry where fashionable buzzwords are part of our meat and drink.

I mean this happens all the time, so really changing "slave" to "dependent" is really going to get lost in the noise.

Re: Political correctness gone mad

Here is the justification.

It is a small change, which simply moves one name for another. It took them no time at all, because they were sensible enough to lock the pull request before a bunch of right wing nutjobs descended it. The change means that one of the more unpleasant parts of human history will no longer be used as a metaphor for a piece of computing.

So a low impact change; won't make things a lot better, won't make anything worse.

Re: Bollocks.

Really. It looks to me like you are saying that because someone has made a small and technically inconsequential change to their project on the basis of it reflecting in a mood change in society, you are not going to use their software. At the same time, you are saying that the maintainers lack technical focus. Even though you are prepared to make a decision without any reference to the technology at all.

Makes no sense at all. Why don't you just drop the facade of "technical focus" and say "I will not use a piece of software whose maintainers make political decisions I disagree with". You'd have my vote on the underlying principal there, regardless of whether I agreed or disagreed with your politics.

Rust marks five years since its 1.0 release: The long and winding road actually works

Re: What does Rust actually do?

What does Rust do?

Well, it provides a clean, high-level language which is comfortable to use, while providing a single powerful language feature that makes a very large class of bugs extremely unlikely in normal use (ie double free, buffer overflow, uninitialized memory, and memory leak).

It does not have garbage collection any more; it did at one point, but it now uses "lifetimes" to be able to work out when it should automatically free things without the programmer having to do anything. Looked at another way, it has a static analysis garbage collector -- so like a Java style GC without the runtime overhead. For when that isn't enough, it has reference counting, but used only for those bits of code that need it. No application needs GC; they need automated memory management, and Rust has that.

How does it do "hard stuff" like Linked Lists with pointers. It uses pointers. The safety guarantee is, as I say, just a language tool. Most of the time you use this tool, and that's fine, but you can write "unsafe blocks" which let you outside the box, which includes raw pointers, even pointer arithmetic.

Re: The language might be super-safe, not so sure about the installer

If someone hacks rustup.rs, then could put anything they like up there and people would run it now? On the other hand, if someone hacks an .deb, or RPM server, they could put random binaries up there, but they couldn't sign them.

It's not, perhaps, ideal, although as it's non-root, it's a little less of a disaster.

Re: On speed

Trait implementations have overhead if you cannot determine what the trait implementation is at runtime -- you end up with a virtual method call. However, if you use traits as a generic bound, you can work out the implementation at compile time, so no over head. Array bounds checking, yes, also, although if you iterators like the `for` loop does, it does not array bounds check. For some uses of arrays in C, Rust uses tuples which again do not bounds check (at runtime -- they are type safe at compile time). Memory dropping is worked out at compile time in most cases. You can explicitly use reference counting where it's too complex to work out where dropping should occur at other times and yes, this has some overhead.

Finally, all of this you can turn on with unsafe code. And, of course, all of the above is true on the Rust side; in practice even when Rust thinks it is array-bound checking, LLVM may be optimizing it away.

What I am saying here is not that Rust is faster or that C is faster. I am saying that you cannot reason it; you have to build it and check.

Re: On speed

Rust does very few runtime checks -- the majority are done at compile time, and the runtime ones are normally explicit at development time (that is, you know you will be getting a runtime check). In all cases, if you *really* care about performance you can run time checks and do most of the things you can do in C, sacrificing the safety guarantees in those areas.

I would also say that Rust has fewer undefined behaviours than C, so the Rust one can optimize to run faster than the C one. Of course, it might not, but I think the idea that C is going to be faster is not true.

Re: The language might be super-safe, not so sure about the installer

This doesn't install rust, it installs rustup which installs rust. Everything else is underneath that. You can install it in other ways if you like, but this approach is nice because it's non-root and updated at the same time as Rust is.

Most installation processes require you give over all power on your computer to the installation process. This is as safe or unsafe as your trust in the organisation at the other end.

Although, actually, the Rust installation suggested above is probably less dangerous than many since it does not require admin access.

In Rust We Trust: Stob gets behind the latest language craze

Re: Let

`let` has been around for ages in functional languages. Obviously having a keyword there means that you cannot do:

let my_variable = 1

me_variable = my_variable + 1

or similar spelling mistakes. Unintialized variables are fairly rare in Rust. If you want to, though, you can do it, but it still produces something that is vaguely readable because you need the type:

let s: String;

Yes, "var" and "const" are contractions of words, but Rust emphases "const" -- so "let" on it's own is equivalent to "const". To get `var` you do `let mut x = 1`; a bit wordy, but the `mut` keyword is also uses in locations other than `let` declarations, such as parameters for instance.

It all makes sense, I think and was thought out.

Re: Haven't looked back

The Rust library ecosystem is a little biased toward the systems programming end, but it's actually a pretty rich environment overall, and because the tools (esp cargo) are good, it's easy and low cost to add dependencies to your own projects. There have been significant efforts to cover the few remain holes that exist.

Having said that, my own experience is that it can be hard to find a the right library out of several choices, and the rust community has got a bit obsessed with semantic versioning, meaning that libraries tend to sit at version < 1 for ages; bit like googles tendency to call everything beta.

Re: sCeptic

Oh, that's easy. It is all achieved at compile time. So, *efficiency* in the runtime sense of the word is not affected at all. The "portability" bit largely comes from LLVM which Rust uses to produce the final binaries. Or to look at it another way, Rust achieves memory management through it's type system.

The compilation process is a little bit slow, though, partly because of this checking, although, in practice this time is far outweighted by LLVM doing it's thing, especially when running under full optimisation.

The original poster is also simplifying things somewhat; actually, Rust has a "safe" subset that does all of this. It also has an "unsafe" set -- you lose the guarantees, but can do any memory manipulation that you want, including referencing invalid memory locations. You don't need to do it that often, but the option is there if you need it.

I thought long and hard about Rust or Go, when I was starting a new project that I wanted to be fast.

In the end, I went for Rust; it seems to have fulfilled it's promise to be honest. The code is clean, succinct and even with a naive implementation is more than an order faster than Java equivalent that I wanted to replace (I realise that Java is not a speed monster, here). In terms of usage, the tooling is very nice and comfortable, and the language really gives the impression of being carefully thought out, and as equally carefully developed and updated. Of course, there is only so much time in the world, so how much of this would be true of Go, I cannot say, because I tried it less.

In the end, there were a three main reasons for choosing Rust. First, although it is indeed a fussy language, the community is very supportive and has helped me when ever I needed it (and as probably the first local adopter I needed it). Secondly, it's backed by Mozilla who are, I think, less likely to be evil than google; in particular, there is a strong community ownership of Rust. And, finally, the killer issue, which is reason enough to choose all by itself: Go uses tabs by default; and not just tabs it uses combined tabs and spaces; it is too hideous for words.