Comment by moogly | Hacker News Reader

Comment by moogly | Hacker News Reader

Parent Full thread

I'll be honest: Rust is kind of losing me with these changes. I started following/tracking the language about a year ago, and I thought the syntax looked really succinct and easily readable back then, but with changes like this, [T] => Vec<T>, the region/lifetime syntax, together with the propensity to abbreviate almost everything, code is quickly starting to look kind of soupy to me.

I get the arguments, and they're logically sound, but in the end it's beginnning to read like C++03.

On the one hand, the Rust community's generalising a lot of stuff, which sounds great, but then adding a bunch of macros (I know, this ain't yo daddy's C macros) to replace first-class citizens ([1, 2, 3] => vec!(1, 2, 3) for example), and I worry how IDEs will be able to handle macros from an autocomplete/intellisense standpoint, not just checking/displaying type information when using them, but also writing new ones.

I guess it's a language primarily by and for text editor users, and I'm beyond that point these days.

As I said, I started following the language daily a year ago, and a couple of months ago I was thinking of jumping in around this point in time, but right now I feel like I want to wait another year to see if the syntax has become more readily intelligible.

I still think it's a fantastic effort, and kudos for all the hard work.

Odd, I've just been getting the impression that the language is become much, much readable. I agree with thestinger, here:

> uses and instead of &&, or instead of ||, list instead of [] and so on. Most people find it far easier to read and search for these than the sigil alternatives. The avoidance of more than one way to do the same thing (like including both ~T and Box<T>) is another reason why people find Python easy to read.

What is the source of that statement? Because honestly, if the future of Rust is to look like this, that would be somewhat horrifying.

Python is a great language for beginners and people who get into programming through nontraditional channels without having much of a symbol-pushing background; presumably, being able to parse symbolic expressions naturally is a skill that needs to be learned, and perhaps even needs to be learned early in life to wield effectively. If you don't have the ability, classical systems languages will look like malicious ASCII soup and a language whose code you can actually read like a paragraph of text will be long-overdue respite from this misery; the same perhaps even applies to other non-verbose shorthand (as an anecdote, one of my graduate program's logic-heavy classes is currently suffering from a student who more or less constantly interrupts the lecture to get all the mathematical notation on the board read out to him in natural language). The latest startup/trendy tech boom has made a disproportionate number of people of this type gravitate towards programming, many of them coming from the wider blogosphere/"social internet"; as a result, their opinions regarding what is good or bad and legible or illegible have come to entirely dominate the airwaves. It is all to easy to forget that there is a barely visible core of often significantly more prolific "native" programmers hiding in newsgroups/IRC channels/mailing lists and more often than not having very different measures regarding what constitutes good language design. When Rust came about, its design held the promise to finally deliver something to this group that might offer a way out of the C monastery; having it reorient itself to appeal to more popular sensibilities at this point is bound to cause a lot of hard feelings.

Personally, I always found the flat monotonicity of Python code to be rather unpleasant to read and write. Having what some people like to denounce as "line noise" actually enables a very useful visual contrast between "structural" (parentheses, scope boundaries, operators) components of the code and largely user-defined "names". Looking at a piece of code like "if(vals[1]==1 && vals==[1,2,3]) { ... }" allows you to break up the code visually before having read and echoed to yourself even a single word of natural language; this can't be said of a (hypothetical) example like "if vals.at(1) equals 1 and vals equals list(1,2,3):". Adding to that the general lack of code layout flexibility and the deliberate lack of alternatives to express a given pattern, the resulting picture is that the way an experienced programmer would usually gather a slew of information from diagonally skimming over a piece of code (segmenting all of it using the visually distinct "line noise", gathering when and how data is accessed, inferring the original writer's priorities from how the code was spaced out and what constructs were chosen, spotting the names of external dependencies...) is severely crippled.

> When Rust came about, its design held the promise to finally deliver something to this group that might offer a way out of the C monastery; having it reorient itself to appeal to more popular sensibilities at this point is bound to cause a lot of hard feelings.

Syntax is a very small part of the overall design. Rust won't stop being Rust just by removing a few confusing sigils.

The key to this comment is "[t]he latest startup/trendy tech boom has made a disproportionate number of people of this type gravitate towards programming". The rest can be extrapolated from that sentiment.

I understand that the sentence you quoted is easily construed as a cheap potshot at startups, but all I meant to say is that suddenly, there is a large number of people coding - and, more importantly, writing about coding - who did not grow up staring at mangled C++ debug symbols and hex dumps. I don't mean to say not doing that makes you a worse programmer - the difference does, however, seem to explain the composition of two groups who like shouting things to the effect of "I don't understand how you can find that easier to read than this" at each other.

[T] => Vec<T>

It's ~[T] that is now Vec<T>, which was a good change in emphasis (the former is still valid, though it will become Box<[T]> with this RFC).

Besides the implementation differences, I think readability is improved when `Vec<T>` is written.

Ah yes, sorry.

I guess it's a language primarily by and for text editor users, and I'm beyond that point these days.

What do you mean?

EDIT: Imagine a programming language designed around an IDE. Fun thought. Not sure whether it's a useful thought, but it's fun to think about.

I actually regret that comment. I feel I was being a bit too negative in my original post, and I don't want to add fuel to the fire by continuing the argument here.

No, no... I'm sorry if my comment sounded strange. I wasn't being ironic or snarky, I was being genuine.

What are your thoughts regarding IDEs vs editors? It's an important topic.

Honestly, as a guy who works on a lot of old code that I didn't write, IDEs are a complete godsend. Features like 'find me everywhere this method gets called', or 'find everywhere this value gets written to', and just simple navigation between functions/files. They're a backbone of my maintenance programming strategies, and I don't know what I'd do without them.

I do all of my javascript coding in vim and don't miss IDEs so much, but that's because I mostly only work on my own javascript code. For large, multi-person projects I massively prefer working inside an IDE.

I think the real key here is not ide friendliness, but "compiler as a service." The compiler, by definition, is already capable of understanding our code. If that understanding can be exposed as a standard api, we can build up a set of powerful capabilities for refactoring and much deeper programmatic transformations. With very large code bases, this is no longer just nice-to-have ... it is the next tool we should rationally insist on.

And we shall call it Java.

That isn't really the case at all. Java (the language) is relatively small and simple. Java code can be written quite easily without an IDE. In fact, that's how it was done for many years by most Java developers, before Eclipse, NetBeans and other IDEs became more commonly used.

The unnecessarily complex design of many Java libraries and frameworks is generally what pushed developers toward using an IDE, not the language itself.

Actually we call them Smalltalk, Interlisp, Delphi, Visual Basic and Eiffel.

Text Editor vs IDE.

Hmm... I don't understand why it has to be Text Editor vs IDE. The two concepts are orthogonal. One is for editing text; the other is for understanding and autocompleting text. If their concern is that there aren't any good tools for Rust yet, that'll be solved with time.

I think you are missing the point of the statement. If one was designing a language meant to be developed in an IDE, you can hold various assumptions which would influence how syntax shapes up.

A trivial example which is not related to rust but I think serves as a decent example, you can assume the IDE will color/italicize/etc member variables to get rid of _var __var var__ nonsense. You can also use slightly less verbose terms even if they are less informative if you assume a tooltip with a concise and complete explanation pops up.

I'm a little terrified by the prospect of a language designed to be incomprehensible without a stack of tools that will explain it to you.

I'm not sure how interesting this topic really is. As an example, look at Smalltalk. Crazy easy syntax, and made to be used in an IDE that dwarf what most of us consider an IDE.

Reply on news.ycombinator.com