[dmit]

I downvoted paule89's comment because it felt like a cheap shot at an established product with well-known pros and cons.

Yes, Electron apps consume a bunch of RAM. Yes, Rust needs you to deal with data lifetimes. Yes, Go still doesn't have generics. Yes, Haskell has a steep learning curve if you learned imperative languages first.

No, restating those facts on HN at every opportunity is not constructive.

[yjftsjthsd-h]

Rust is built on lifetimes, Go is designed to not have Generics, Haskell will always be weird. A UI toolkit has no inherent reason to use a large amount of resources, so there is some value in noting that they either don't care or haven't managed to fix it yet.

[zanny]

Rust is built on lifetimes but the compiler could definitely infer them better. Not only from my experience, but all attempts to introduce coworkers / anyone else to Rust usually meets a "this 'a thing is ugly and awful and I hate it".

Really it was more a design decision on the language part than something it was "built" on. In 99% of cases the compiler can identify where exactly you need to annotate lifetimes to sate itself. They are only there for explicitness. Tagged lifetimes will help a lot with this, because it is much more intuitive for anyone using any other language to say "ok I need to say result R lives as long as argument A that makes sense" vs "stick an 'a on everything" and have functions that have nothing to do with generics looking like generics to the average joe.

I know I personally have written function signatures to take (or return) owned data in Rust just to avoid having to lifetime annotate the whole thing. It is just a chore that most of the time is just boilerplate to "make it obvious" to readers of code, despite almost every situation I see lifetime annotations I can straightforwardly understand that the & in the return is lifetime bound to the & in the arguments or the struct field it comes from.

[methodin]

Perhaps not but not all of us follow such things as closely as you might so the assumption that it's common knowledge is not necessarily accurate.

[dmit]

You're absolutely right that not everyone seeing this comment tree knows the details of Electron's memory usage. But I don't think that GGP's original comment was aimed to educate those people about the issue. To me it just sounded like a quip aimed at getting some cheap points from the choir.

[methodin]

Yeah I could see how if you are used to seeing such posts it would come as more of a slight but from my perspective it's good to know people's gripes about a product having not followed much about this before - especially if some people might be trying it out as a result of the article. The ambiguity of purpose is the bane of internet comments.

[_eht]

It's a hugely beneficial visual when they are deciding what to prioritize on the roadmap going forward.

It's input directly from their user base about what they want in their work environment.

[dmit]

Do you think this thread is the best place for that input? Or that the input is valuable enough to post at any opportunity?

For the record, I disagree with both of those statements.

[_eht]

Yes, I do think this is the best place for that input. People post things on HN, and there is a comment section where we talk about the thing. What else would be in a thread about a thing?

Noted.

[sjellis]

I wish that I could upvote this twice.