Hacker News Reader

Comment by MrBuddyCasino | Hacker News Reader

Rust is unpleasant to look at. I know its silly, but that my biggest gripe with it as well, aside from sometimes overly complex type signatures due to generics. As a reference, I consider Python and Kotlin to be a e s t e t i c.

View on HN

What was the first programming language you really understood and learned? I ask because most of the time people think something different is complex or "ugly" it's because they're using bad abstractions between what they fully understood first to other things they think is in the same domain.

Patricia Asa has an excellent presentation[0] on how she tried to learned C# and one of the biggest things she discovered was these bad cross-over abstractions held her back.

[0] https://www.youtube.com/watch?v=Id2jBMJLz2Y

My first programming language was Python. And now I write Python and Go frequently.

I'm trying to learn Rust, working through various programming exercises, but it looks and feels very foreign to me.

One example is the closure syntax. Compared to Go where closures look just like function definitions, closures in Rust look needlessly complex.

I also always find myself wanting to type mut &a instead of the correct &mut a. The former just seems more obvious to me, a reference to a is &a. Mutable a is mut a. So a mutable reference must be mut &a.

Then the lifetime syntax, I don't even know what to think of that, but that's probably more because I'm struggling asking myself "Should I use a lifetime here, or am I doing something else wrong that is preventing the compiler from figuring it out."

Maybe these things make more sense to people coming from C.

We took the closure syntax from Ruby/Smalltalk, and the lifetime syntax from OCaml.

On &mut a vs. mut &a, when read literally left to right the former is “a reference to a mutable a” and the latter is “a mutable reference to a”

I'm guessing the &mut a stuff makes more sense to C folks. In C you have to deal with const, and it can go anywhere. A const pointer to a non-const item, a pointer to const value, etc. That's my guess anyway.

For the record, I consider Clojure to be beautiful as well, in its own way.

I had experience somewhat counter to this. I learned C and C++ first, and when I first started working with Java things like CamelCase did seem a bit strange and off-putting to me, but I got used to the less keystrokes surprisingly quickly, and it's one of the things which bothers me most about working with Rust.

I think there is such a thing as liking what's familiar, but there are also design decisions which are simply easier to read or easier to parse. Another one would be semicolons: I have never missed semicolons one bit in a language where they're not required.

> I have never missed semicolons one bit in a language where they're not required.

I dutifully wrote semicolons for years, but just a short stint of Scala and I don't like using them anywhere now.

I have the same experience - I don't know what the hell is going on in the code with Rust. Compared to say F#, its far more verbose and feels too much like C++.

In the same vein I think Typescript error messages are absolutely horrific. Furthermore, I keep seeing people who start using Typescript to "make it like my preferred language xyz".

Coincidentally these devs 1) hate Javascript 2) end up writing a massively over engineered OO big ball of mud

These reasons are why I avoid Typescript where I can.

And crystal lang, for static typed language example.

https://crystal-lang.org/reference/overview/http_server.html

I'm so not a fan of the ruby-style blocks. I never understood the appeal of typing "end" a million times instead of a single close brace.

{} blocks are used but for one line methods/closures. Since programming has nothing to do with typing speed, there isn't much difference between `end` and `}` other than `end` making more sense in ruby's english-like syntax.

> Since programming has nothing to do with typing speed

I have heard this a lot, and I am not sure I agree. I agree that the limiting factor for how long a project takes to finish is never going to be how fast you can type, but when I am really in flow I am actually typing pretty quickly, and I don't really like more friction when it's not necessary.

Of course it's a matter of taste, but the argument that it's english-like never made sense to me either. There is no english sentence construct with "do ... end" or "wile ... end".

The problem with 'end' IMO is that you have to actually read the word, with } you don't. Of course, this is all useless to argue about. I quite like that lots of languages look different.

Reply on news.ycombinator.com