If you have a namespace, can't people just globally-claim namespaces instead? like serde/serde or something similar. I feel if you really don't want people claim whatever they want, you have to do the Java package style where namespaces are tied to domain names.
Ha! I was thinking more "a drawing language" like the one in the Show HN post. So cool!
I was wondering if there are other languages like these, and a measure analogous to Turing completeness, but for "canvas completeness" for drawing any bitmap on a canvas! :)
I think all other methods require a reflow as well (internal or external). Because at the end of the day, you still need to measure the height of the text before rendering a larger box.
In all seriousness, what fuck is going on in Fandom? It has soooo much ads!
I just turned off my ad blocker and literally only 21% of the page is content and the remaining is ads. After 2 seconds, it got replaced by a full screen ad. What? How? What are the people at fandom thinking? This is completely unusable without adblockers!
I am actually not sure if this is satire, but in case it is not, I don't think Firefox is in the position to boycott France, when Google Chrome exists, and is very likely to comply with the new law.
Honestly, I'm incredibly frustrated with this issue; it's just pure idiocy. Commenting out a part of the code and observing the effects is such a simple and useful debugging technique, yet this "feature" of Go prevents you from doing so effectively.
What's even more frustrating is that when you search for solutions, you come across two kinds of (pardon my language) completely brain-dead responses:
First, there are those who argue that unused variables/imports lead to bugs and worse performance in production, so they should always be fixed. But that's completely beside the point; I've never seen anyone argue that allowing unused variables is good for production. It's always been about facilitating the development process and debugging. Yes, I am aware now there are unused variables, but please just let me see what does removing this part of the code do.
Secondly, people suggest using a dummy function like UNUSED or a blank variable _ to solve the problem. But again, these suggestions miss the mark entirely. Changing variable names or adding UNUSED calls to "disable" the rule is even worse than what we've been doing to temporarily "circumvent" the rule, which is simply commenting out the declarations, test, and undo afterwards. Not only it involves more effort, but more crucially, you might actually forgot to revert those changes and leave in unused variables.
Frankly, I believe this is just a bad design decision, and it seems like the Go team is stubbornly doubling down on this mistake due to ego.
(Sorry, I just have a very strong opinion on this topic, and I am deeply frustrated when the tools I am using think they know better than I do and are adamantly wrong.)
> I've never seen anyone argue that allowing unused variables is good for production. It's always been about facilitating the development process and debugging. Yes, I am aware now there are unused variables, but please just let me see what does removing this part of the code do.
Yes, but once you allow that, you'll inevitably end up with unused variables in production code (warnings are useless). That's the core of the issue and why the Go team made the decision.
In my opinion, the real solution is to have two build modes: --devel and --release. This would allow for not bothering devs with anal checks during development while preventing substandard code in production.
Though the real advantage would come from the reduced pressure on compilation speed in --release mode which would make room for more optimization passes, resulting in faster production runtime speed and lower binary size.
Fully agree on both of these messages. This is the only thing I don't agree:
> warnings are useless
Warnings are useful, to (no surprise here) warn me about possibly problematic stuff. That's why my C++ builds are usually full of warnings during development, but the final build for production won't contain any, because it is performed with -Werror (i.e. "treat all warnings as if they were compilation errors"), thus any unsolved warning would break the build.
A common reply to this argument, which just in case I'd like to reply in advance, is: "but the end result will be that in order to save time, and to avoid having to fix all those pesky warnings, lazy devs will end up doing production/release builds without the -Werror flag (or equivalent for whatever compiler)". To which my response is: That's a social/political/behavioral problem, a poor project management, or any combination of them, and you cannot even start to pretend that those can be solved with technology.
I will literally not touch any language that does that. Not too sad about missing out on Go, but Zig unfortunately also shares this braindead thing.
The solution is all so easy also — just add a debug and a production profile. Enable your strong linter in prod, for all I care, but this is a must-have development tool.
> Something not commonly seen in JVM malware that is present here is a class titled VMEscape. It checks if its in a sandboxed windows environment by checking if the current user is WDAGUtilityAccount, which is part of the Windows Defender Application Guard. If this condition is met, an attempt to escape the sandbox system is made.
> The process is roughly as follows:
> - Start a repeating thread to run the following actions:
> - Create a temporary directory using Files.createTempDirectory(...)
> - Iterate over FileDescriptor entries in the system clipboard (Supposedly this will be accessing the contents of the host)
> - Create a shortcut that looks like the original file (using icons from SHELL32) but instead invokes the malware
> - Assings this shortcut to the clipboard, overwriting the original file reference
> Thus, if a user copies a file and goes to paste it elsewhere they will instead paste a shortcut that looks like their intended file, but actually runs the malware.
kind of reminds me of the very subtle malware found in a modified version of a bitcoin wallet that would lay low but when you copy-paste a BTC address in the recepient field, the malware replaces the clipboard with their own address in hopes you don't check it twice
But only if the user has a high balance on their own wallet.
At least one person fell for this when they made a small test-transfer which went through but when they entered the higher BTC amount the recipient was replaced. Pretts smart and evil stuff
It gets even better, those malware even dynamically generate replacement wallets, finding ones that have similar starting and ending characters to the target one so that the victim can't easily recognize that the wallet has been replaced.
Wow, that is nasty. I would actually fall for that, I never thought of double checking copy/pasted data, only in cases I copied something similar before and I want to make sure I really did press copy.
