4 ms·
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
by dmit 9y ago
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.
- _eht 9y agoIt'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 9y agoDo 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 9y agoYes, 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.
- methodin 9y agoPerhaps 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 9y agoYou'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 9y agoYeah 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.
- yjftsjthsd-h 9y agoRust 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 9y agoRust 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.
- sjellis 9y agoI wish that I could upvote this twice.