My only complaint is the mix between snake_case and PascalCase. I tried removing it(in favor of snake_case, but you could probably get a similar result if going full PascalCase), and it looks much better(no guarantee it has the same semantics, I've never worked with rust):

     fn handle_message(&mut self, find_node_query: messages::find_node_query) {
        let origin = node::udp_node::deserialize(find_node_query.get_origin());
        let target = address::from_str(find_node_query.get_target());

        {
            // Borrow self.routing_table first time
            let nodes: vec<&box<node::node>> = self.routing_table.nearest_to(&target);
            let response = message::response(
                self.transaction_ids.generate(),
                response::find_node(&self.self_node, nodes)
            );
            origin.send(response.serialize());
        } // Done borrowing self.routing_table here

        // Borrow self.routing_table again
        self.routing_table.insert(origin);
    }

It sure does look more like C that way (if that's something you're into), but that also makes it harder to scan for types at a glance.

Rust used to work that way, but it was changed primarily to visually distinguish between enumerated variant names and variable bindings in patterns. e.g. match foo { none => ... } and match foo { non => ... } having completely different interpretations was confusing.

Can you please post an equivalent Java program for comparison?

Java is also a completely different language. Each tool has a different purpose.

Exactly. There are few fundamental principles which have been neglected in order to provide way too many features (a kitchen sinc syndrome).

For example, "do not create unecessary entities" maxim, which, it seems, is central for good language design (ML, Scheme, Haskell, Smalltalk, Erlang, Golang are small languages, the first three are even standardized). As long as we violate this genetal rule we end up in a mess like CL, C++, and of course Java as a peak of absurdity).

The meme that "implementation languages must be feature rich" does not hold beyond certain limits, and even Rust designers have realized that there must be certain restrictions. In fact, C - the oldest and most common implementation language is still alive and well (despite all the mess other people made of it since it left Bell Labs).

The best illustration I know is refusal of the Golang designers to complicate (to ruin the balance of simplicity and elegance with expressiveness, which is the most difficult to attain - every poet or artist will tell you that - to create an unbalanced pile of features is way easier) the language by adding generics in the language and runtime. For them interfaces (duck-typing) is good-enough).

"Explicit is better than implicit" is also a naively wrong maxim. Verbosity is bad. Period. Every good writer I know is non-verbose. Meaning behind words is what makes a good literature, not long words or elaborate passages half page long (ironically, common men think exactly opposite is true). Convention over configuration (evolved defaults instead of explicitly spelling every single rule over and over again) is the same notion from a different perspective.

Here comes Scheme - the greatest mostly-functional small language with balanced defaults, cohetent semantics (almost like in math), and unmatched expressiveness with almost no syntax at all (expressive power comes from coherent defaults that everything is an expression, everything (including lambdas) is a first-class value referenced by symbol, lexical scooping, very few standard special forms and the ability to create new ones.) as an good example. Smalltalk and Erlang are another ones for the emphasis on message passing and, in case of Erlang - pure functionality and isolation - the way vastly complex biological systems has been implemented by evolution.

So, those who have seen highly refined languages like Haskell or Scheme or Smalltalk would never be fooled by "features". The meme that "each project must first agree on which subset of C++ it would restrict itself to" is another good illustration. Rust, like Java, is already suffering from this kitchen sink syndrome, so the comment above is legitimate.

BTW, it seems that many of features should go from the language to sanitizers and checkers, like it is with clang tooling.

> "Explicit is better than implicit" is also a naively wrong maxim. Verbosity is bad. Period. Every good writer I know is non-verbose. Meaning behind words is what makes a good literature, not long words or elaborate passages half page long

Good writing often allows (or even encourages) a reader to concoct their own inference of exactly what the author means. Witness discussions that last to this day of many ancient classics. Such ambiguity may be fine for writing, but it is obviously disastrous for large engineering projects.

That's fine - not all code is a large engineering project - but most of the people I know who work on very large code bases will take explicitness every time. And those are the kind of projects that Rust is aimed at tackling.

Explicitly passing &self is lame. Haskell's implicit parameters are clever.)

Actually, the language fells Rubysh - a bit of syntax from here and there. Swift has much more refined and concise syntax, because they paid way more attention to details.

Patter matching on type constructors could have been taken from Haskell - it won't hurt.

Block syntax with where clause (why?) is really bad.

The syntax inconsistency and awkwardness aren't major issues, but it is telling.

None of your examples make sense to me.

You say "explicitly passing self is lame" and then praise Golang for "feature restraint" when it does the exact same thing.

I don't know what "pattern matching on type constructors" means. You use the constructor syntax to pattern match in Rust.

There is no such thing as "block syntax with where clause". Where clauses go on signatures, not blocks. This is also the exact same syntax as Swift, which you praise for "more refined syntax".

Golang is praised for attention to details and fair attempt to attain that kind of balanced mix of complementing each other features.

The principles, rather idealistically, are outlined here:

http://karma-engineering.com/lab/wiki/Bootstraping

Pattern matching is technically almost unchanged since Standard ML, but in Haskell the syntax is refined by perfectionists (in best possible meaning of this word).

Swift, obviously, trying very hard to look familiar for [Objective-]C (but not Java) programmers, and to follow the principle of less astonishment, produced much more concise syntactic choices, and the devil is in the details.

BTW, if one wants to see another example of carefully crafted language, there is PLOT

http://users.rcn.com/david-moon/PLOT3/

This is very philosophical and also entirely unresponsive to my points.

> Explicitly passing &self is lame

Explicit passing of &self (or &mut self, or self) might be 'lame', but it also gives more clarity as to what the code is doing. I can't say it's ever once given me pause.

Rust is emphatically not a kitchen sink language. If you believe otherwise, please explain what features you would remove without compromising safety or the notion of zero-cost abstractions.

I don't believe in safety and zero costs. These are mere catchy memes.

I could only repeat my question: How Common Lisp or even more pragmatic Golang are less safe? I am not asking about Haskell or Erlang.)

Compile time error for trying to use an old binding/reference? Is this memory safety?

The engineering decisions are not based on beliefs. They are usually trade-offs. Safety in Rust has a very specific meaning clearly outlined in the official book. There are users who prefer it for certain tasks. The answer to your last question is also in the book.

Why not state it here in a few simple sentences, like for a 5 year old? Clarity is usually an evidence for deep understanding. I hope I will be able to get it.

Memory safety without garbage collection. (While still supporting dynamic allocation.)

Go is less safe due to the "Off to the Races" problem, but there's a legitimate debate as to whether that safety loss matters in practice.

Common Lisp and Golang use GC, which exacts a performance cost in some scenarios. Go also has highly dynamic semantics (e.g. with defer) which have unavoidable performance overhead, especially in an AOT compilation setting.

Do you have specific examples of Rust features you claim are unnecessary?

Rust would not work at all with the borrow check as a separate tool, by the way. It would be comically easy to write broken code.