Hacker News Reader

> I don't want to work with languages that attract this kind of person

I haven't used Rust professionally, but I find the community extremely inclusive and helpful. I joined the Discord server and asked all sorts of stupid questions and people always helped me and explained to me what was wrong with my code (or my assumptions). But, again, I haven't used Rust professionally and it may be different in that context

> I don't want to work with languages that require a relatively heavy cognitive load on simply reading the lines of the source code

Strongly agree on this, I haven't tried to introduce it where I work for the same reason. The cognitive load is massive compared to a language like C# or JS and the gain is minimal for the average developer writing microservices for React frontends. In this context you need a JSON serializer, iterators and maybe generics, and Rust is not much better than C# on this front.

It may be my limited experience with C#, but I really missed Rust/serde when deserializing a config file into a class/struct. (Actually INI not JSON.) It feels like doing error handling twice: first catching parser exceptions, and later checking for null fields everywhere. (Basically I was forced to default-construct the object before parsing, which either means nullable fields, or having hardcoded defaults for every field.) I guess the pragmatic thing is to turn off null warnings and accept that it may fail later.

> I get the same vibe from certain other groups in this industry, most recently from functional programmers and Rust afficionados, for example.

Another trait in programmers that is worth avoiding is the false equivalency between C++ template metaprogramming and generic programming in languages with expressive static typing.

It's not clever or inscrutable like templates, quite the opposite. It's explicit about constraint. Generic Rust makes it easier to understand complex code and write it correctly. An immediate red flag for me are programmers who don't "get it" because they equate that to some kind of SFINAE or compile time magic they once saw in C++. They're not the same feature, except superficially.

>Second, I don't want to work with languages that require a relatively heavy cognitive load on simply reading the lines of the source code. Units of code (i.e. statements, functions, structures and modules) are already a cognitive load--and the more important one. Any extra bit I have to supply to simply parsing the symbols is a distraction.

The weird thing about these comments to me (as someone who doesn't use Rust) is that the most difficult syntax in the original examples represents a semantic detail that most languages don't have to deal with: the lifetime. The amount of times I think about the lifetimes of variables I write in Python is zero. Parsing the symbols and understanding the code here aren't separate; that weird apostrophe thing in angle brackets is a symbol I don't use referencing a concept I don't use, which fits. If you replaced the symbols with keywords or something, it would just be longer, not simpler.

Also, it's a choice to write your code like he did. You can define local variables that hold intermediate results and subexpressions and give them descriptive names, if you want. You could assign `drop = (|_| ())` for example.

Yea, so pretty much every programmer needs to be aware of thinking about lifetimes.

The classic issues are creating a local and then giving a reference to it, to something much longer lived, or even undying. In that last case, if your doing it a lot, with no regard to the objects change in lifetime, your effectively creating a leak (I can guarantee you someone, somewhere, is making this mistake in js right now). Most collection strategies won't touch an object that still has a reference to it.

The second issue that became really common when people stopped paying attention to lifetimes, is that many resources you may be using (file handles, db connections, etc...) have very different constraints than memory. So you have to be cognizant of the fact that even though something has gone out of scope, it's lifetime really doesn't end until the gc gets around to collecting it. This is the reason special syntax and functions, like "with" and Dispose had to be added to languages like C# and Java. Python with it's reference counting maybe somewhat less susceptible to this second issue than the others, but it's not immune to it.

Finally in many cases being aware of object lifetimes and specifically manipulating them can get you performance speed ups.

> Back when I wrote C and C++ for a living I'd occasionally meet someone who thought their ability to employ the spiral rule or parse a particularly dense template construct meant they were a genius. I get the same vibe from certain other groups in this industry, most recently from functional programmers and Rust afficionados, for example. Nobody gives a damn if you can narrate a C spiral or a functional-like Rust idiom.

I think one problem is dealing with "just because you can doesn't mean you should". It is easy to be nerd-sniped into optimizing everything in Rust. I've seen complain about an arg parser using dynamic dispatch when anything the program actually does will dwarf the time that that takes. I feel we need a reset; a stdlib-alternative that optimized for those learning and prototyping at the cost of performance. I suspect people using that will help break them of the feeling to optimize the trivial but to instead focus on what profilers tell them.

I’m with you. I think people that treat syntax as some completely unimportant detail are forgetting that reading code is a more important use case than writing code.

No matter how much you internalize the syntax of language X, as the sheer number of syntactic structures in the language increases, the higher the likelihood you’ll misread something.

> I get the same vibe from certain other groups in this industry, most recently from functional programmers and Rust afficionados

Perl one-liner guys used to exemplify this. But I don't really agree that functional programmers do, except for Haskell and people who use lots of the car and cdr compositions, or those who use too much metaprogramming, or... okay maybe you're right. But at least the fundamental premise of functional programming is simple..

Functional programming usually includes Lisp, whose advocates mainly like showing off how powerful and complicated it is. (see: loop macro, call/cc)

I don't use Rust a ton, certainly not enough that the syntax density fades into the background, but something I'll say for the ecosystem is rust-analyzer is really good and pretty much always knows and warns you when you're writing something incorrectly that won't compile. The worst parts of the syntax effectively become self-writing, though it does nothing to help reading.

> And this syntax density is one of the reasons I stopped advocating for the use of Rust in our systems.

Trouble is I've found this type of genius is most languages. There are always some esoteric functionality that few people understand that some people will choose because its "the most appropriate" but largely because its a challenge. Of course such talented people move on to the next project quickly as maintaining their crap is not fun.

If not C++ or Rust, what languages do you advocate for now?

Depends on the application, really. And I wouldn't call it "advocacy" so much as being resigned to accepting a less odious bad option. In that case, typically Go or Python, unless we need that last bit of performance and can't get it with a pre-built library: then I'd argue for C, C++, and Rust (in that order).

Not the OP, I rather use managed languages with AOT/JIT toolchains.

C++ and Rust I leave for scenarios where choice is imposed on me due to platform SDKs, or having any kind of automatic memory management isn't an option.

Rust's memory semantics are definitely a kind of 'automatic memory management' though. I mean, that's the whole premise - to have the kind of guarantees about memory safety that until Rust where only available in GC'ed languages running on some runtime.

There is nothing automatic about compiler errors in lifetimes.

As for until Rust, Cyclone and ATS did it first.

Not sure if Cyclone and ATS don't predate it, but Rust's memory management is a bit like 1/3rd of Linear Lisp (specifically, the compil time garbage optimizer)

To be more precise, Rust uses affine types as basis for the borrow checker.

https://en.m.wikipedia.org/wiki/Substructural_type_system

Its biggest achievement is making them more well known to mainstream devs without CS background.

While I personally agree, I think the bar for readability gets slowly lowered over time. In the Typescript/JavaScript world a for loop used to be (and still is to some) considered more readable than using the functional array functions.

Our reasoning for readability is usually based on what the average programmer is able to read, so the more programmers get used to dense syntax the more readable it is. There's rarely any "real argument" to be had for or against readability.

Haskell and other languages that are inspired by math look very noisy to me, but at the same time I understand that math people don't agree.

> First, I don't want to work with languages that attract this kind of person.

exactly. always noticed people interested in excessive syntax tricks are only good at precisely that. excessive syntax tricks.

zig?