Hacker News Reader

Comment by deafpolygon | Hacker News Reader

Let's put it this way... when you absolutely must syntax highlight code in order to be able to explain Rust syntax.. it's ugly.

Let's just go with a really contrived and stupid example... "pub fn". Would it really have killed them to spell it out? Why do we need 'fn'? Functions with a return type (i.e. `fn add(a: i32, b:i32) -> i32`) is just not easy to read. Yes, I'm aware that someone here will find this 'beautifully terse and concise', as well as easy to read. But without syntax highlighting, it's just a jumble of characters to me.

We read code more than we write, so clarity of code should be the goal of any 'modern' languages these days.

View on HN

Funnily, nearby on the frontpage is The Python Paradox[1], an essay which contains:

  > At the mention of ugly source code, people will of course think of
  > Perl. But the superficial ugliness of Perl is not the sort I mean. Real
  > ugliness is not harsh-looking syntax, but having to build programs out
  > of the wrong concepts. Perl may look like a cartoon character swearing,
  > but there are cases where it surpasses Python conceptually.

I do think there's something to be said for the notion of "conceptually ugly" rather than "syntactically ugly", though the latter is what people tend to focus on. Perhaps we need a better word than "ugly," with its superficial connotations.

[1] https://news.ycombinator.com/item?id=34541933

A “conceptually beautiful” language would consist of orthogonal concepts, right? What would be good examples of such languages?

Interestingly, Python’s aspiration to have only one (obvious) way to do things could be understood as an aspiration to achieve conceptual beauty.

I suppose there's also a distinction between "beautiful in implementation/concepts available" vs. "beautiful/pleasant to work with."

Harping on Perl again, one could see its roots in natural language with sigils representing different kinds of "nouns", and ability to rearrange conditions to be more like spoken language ("do X if Y vs. if Y do X") as an aspiration towards "beautiful to work with."

And of course the various notions of beauty can get in each others' way.

But they're all a lot more fruitful to consider than a mere "yuck, too much punctuation."

There has to be a more objective way to rank uglyness. The example function you provided looks perfectly fine to me. I don't see how syntax highlighting makes it any better.

I did mention it will look perfectly fine to someone here. [ and what better, to someone's nickname is Gigachad :) ] But if you had a sea of functions that looked just like that.. it'd be hard to pick things out without syntax highlighting.

How can we actually prove this statement though? I work with TS, Ruby, and Rust daily and I honestly can't think of a single time I had any problem reading Rust once I understood the language. But saying "works for me" is just as anecdotal as "doesn't work for me". There needs to be a better way of talking about the problem to progress on this.

When the function name & types are harder to grok than the body I think it’s an issue. Looking at you, TypeScript.

For me it is an issue as well, but it doesn't seem to be an issue for the others. I strongly prefer Haskell/math notation for denoting the types of functions, but all the new languages choose other syntax.

I don't think the syntax of TS is the problem. It's that people are trying to define types for massively dynamic JS that is inherently hard to express as a type.

You can run a survey.

Brevity isn't always a bug even when optimizing for reading rather than writing. Spending extra characters spelling out `function` doesn't necessarily make code more readable.

I do, in general, think keywords should not be abbreviated. We have "return" rather than "ret", "continue" rather than "cont", and so on. This wasn't always the case; ancient (pre-1.0) versions of Rust had a lot more abbreviation in the language and library than current versions.

I think there's a good reason for the function keyword to be abbreviated.

We know that when people read lines of text, they pay a lot of attention to the beginning and the end and comparatively less attention to the middle. One result is that lines with common prefixes tend to blur together. To get around this, you want the reader to encounter the unique portion of the line ASAP, which makes it desirable that any kind of necessary prefix be brief.

Upshot is you want the function signature to be what you see as you scan down the left side of the page, so it does make sense to keep the function keyword particularly concise.

Wait, do you want functions _without_ a return type?

I don't understand this complaint on a statically typed language.

In theory the return type can be inferred by the body of the function given the fixed argument types.

However rust has made the stance that the full signature is required for the reason of local static analysis. If you have a function A that calls another function B, you shouldn't need to analyse B in order to analyse A (both as a human and as a compiler)

That's another thing. I don't want to see 32 and 64 crap in code that is supposed to be high level and portable.

i32 means I'm doing FFI with C libraries.

If you check the Rust documentation, you see it has no integer types that are not a fixed size.

"All the world is x86/ARM (formerly DEC VAX / Sun SparcStation )"

C started on 18 bit machines. A program that correctly used "int argc" for the main argument count runs on an 18 bit machine or a 16 bit machine without modification.

> C started on 18 bit machines. A program that correctly used "int argc" for the main argument count runs on an 18 bit machine or a 16 bit machine without modification.

I'm guessing you're too young to remember the 32 -> 64 bit transition, because this is backwards in practice. Non-fixed integer sizes are a nightmare for portability and the reason why some C code still hasn't been ported even today, whereas programs in e.g. Java or OCaml ran without modification on the new machines.

A modern language should make it easy and first-class to use arbitrary-precision integers and decimals though.

Java programs run without modification on a new machine for basically the same reason why, say, a Nintento Game Boy program runs without modification on an emulator, more or less. The machine has been ported, taking the programs with it, which have not been ported.

Not necessarily; in that era compiling with GCJ was a viable option too. And in the case of something like OCaml there's no VM. The point is that running the program on a different machine does not result in random changes to when arithmetic does or doesn't overflow.

Compiling doesn't mean you don't have a virtual machine. Don't forget that emulators (good ones) use dyanamic translation techniques.

Executor, Valgrind ...

(This one: https://en.wikipedia.org/wiki/Executor_(software) )

MC68K MacOS software running on x86 via executor has not been "ported", even though it is transpiled to x86 code.

That's approximately the same as Java portability. There is a Java virtual machine (whether interpreted or compiled). Programs are written to that, and the virtual machine semantics is what is ported.

The programs are running on the Java machine, just like the programs running under Executor are running on a 68K Mac (as far as they know).

C programs also run on the C abstract machine, if you want to use that kind of logic. GCJ was a true native compiler, not an emulator. And Java is far from the only language that offers specific-sized integers. (Even in C, people writing portable code know to avoid the machine-sized integer types and use POSIX intN_t types instead).

There is no one C abstract machine; the implementation has to choose parameters and instantiate an abstract machine.

The portable C program is a kind polyglot among more than one of these (possibly all).

I am seriously confused. Using fixed size integers is about correctness. Randomly changing the size of your integers will cause unexpected integer overflows.

I16 and I64 is more concise than short and long and it is immediately obvious what the number range is for a beginner. The only complaint regarding portability is the unstated assumption that every computer can only store two values per bit. A hypothetical QLC based computer might store a I64 number in 32bits.

You know you're dealing with a goofball C programmer when you have code with some small array like:

  unsigned char buf[1024];

and the index being used to walk over the buffer is uint16_t rather than just plain old int.

When I look at Rust code and see all the 32 and 64, it's triggering my bozo switch.

It's clear who they are trying to attract, in any case.

Which is why Rust has `usize` for indexes and memory offsets. Beyond that, a good programming language can't fix a bad programmer.

Were you aware that, because people use `int` so liberally, the LLP64 model 64-bit Windows uses and the LP64 model Linux, macOS, and the BSDs use keep `int` 32-bit on 64-bit platforms? Hello, risk of integer overflow.

LLP64 even keeps `long` at 32-bit.

https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_m...

It turned out that the C approach was so bad for portability in practice that it de-facto standardized `int` as 32 bits wide.

The C standard describes an int type whose minimum range is -32767 to 32767.

Any programmer worth their salt knows this. If writing maximally portable code, they either stick to that assumption or else make some use of INT_MIN and INT_MAX to respect the limits.

The minimum range is adequate for all sorts of common situations.

Some 32 bit targets had 16 bit int! E.g. this was a configuration for the Motorola 68K family, which has 32 bit address and 32 bit data pointers.

See the "-mshort" option of GCC, documented here:

https://gcc.gnu.org/onlinedocs/gcc/M680x0-Options.html

> It turned out that the C approach was so bad for portability in practice that it de-facto standardized `int` as 32 bits wide.

And, so, Rust builds on that by renaming that to i32, to further entrench the poor practices.

Of course, you will not win any popularity contest by appealing to people who know what they are doing, who are the minority.

> Any programmer worth their salt knows this.

Rust is one big "C and C++ have proven that 'hire better programmers' isn't a viable solution". You might as well use the same logic to argue against C and C++ restricting and complicating assembly language with a type system and the removal of unconstrained GOTO.

> And, so, Rust builds on that by renaming that to i32, to further entrench the poor practices.

The rationale is that a program's logic should function the same on different targets, or fail with a compile-time error if that's not feasible.

THAT is why the default is to use fixed-size variables except for the `size_t` equivalent which is intended to fit any valid memory offset, and to encourage use of correct types for various applications by making it more bothersome to convert types. (eg. Does a file format use a 16-bit integer for an image dimension? Expose that in the parser's API.)

> Of course, you will not win any popularity contest by appealing to people who know what they are doing, who are the minority.

I dunno. I know what I'm doing, but I choose Rust over every other language because it's refreshing and de-stressing to teach the compiler to watch my back as much as possible.

Everyone has bad days, and distracted days, and tired days, and, unless everything you write is closed-source hobby code, you have to deal with code other people have touched.

Personally, I struggle to see what's good about unspecified-but-fixed-width integer types as in C/C++. A lot of real-world code I see uses uint32_t (sometimes typedef'd to u32) and the like to get predictable data layout and to avoid cute gotchas like long being 64-bit on x86_64 Linux but 32-bit on Windows.

I also like how Rust makes both signed and unsigned types equally easy to type, because I feel that a lot of people use signed integers where they should be using unsigned simply because it's easier to type "int" compared to "unsigned (int)". And if you absolutely need a machine word size dependent type in Rust, you do have usize, which is the equivalent of size_t.

Not once did I want a magically differently sized integer. But if you do, Rust has these.

I on the other hand like that _int_ doesn't mean "some integer of implementation defined width". I want to know for sure how big my numbers can be and how much memory an array of such numbers consumes.

> stupid example... "pub fn".

I just don't get why this even gives someone pause.

Reply on news.ycombinator.com