asdf-asdf-asdf

it's unfortunate that the webpage is so misleading. for example, about email, it says:

" Google and its partners have access to all your information and they can collect data, they can display ads inside your inbox, and the contents of your inbox are shared with random third parties. "

the proof they link to is an article about cases where the gmail-user gave permission to those third-party apps to read their gmail-email. so, no "random third parties", no "partners". if you remove those parts from the argument, what remains is an email provider that also displays ads next to your email.

it is really frustrating to read infinite variations of the comment "javascript development is too complicated", "it is much simpler in other languages" etc.

yes, it is complicated. the problem is, there are certain constraints that we just cannot ignore: we want to write code in a "normal", efficient way (code organized in namespaced modules, perphaps static typing etc.), but we need it to be executed by the web-browser, maybe an old version of a web-browser. so we need solutions that work with these constraints.

if you know about simpler solutions, i'm very interested hearing about them. but please note, it has to work with those constraints, so ideas like "just write a native application" does not help.

nobody thinks that this behavior is good. the problem is, this is how it was at the beginning, and javascript will not break backwards compatibility. so we have to live with it (or use a third-party sort-function, like "lodash.sortBy").

there are other similar problems in javascript too:

- "typeof null === 'object'". this is very wrong, but again,this is how it was implemented at the beginning... you know the rest ( https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... )

- another problem with ".sort()" is that it both mutates the input-array and returns the mutated input-array. so you write code like "const arr2 = arr1.sort()", and the code works, but if you don't know the spec, you will not know that "arr1" was modified and basically "arr1 === arr2".

unfortunately it's not possible to change the behavior because of backward compatibility.

maybe we could have a `sort2()` method that works differently.

i'm glad it worked for the author, and i am sure you can achieve better performance with Rust than with NodeJS, but i'd like to discuss some of the mentioned advantages:

in general, typescript is optimized for cooperating with other javascript code, to make it easy to drop it into a javascript-based project, and also, it does not really have it's own "runtime". typescript is javascript plus types. in fact, if you want to convert from typescript to javascript, you can take a typescript-file, and just delete all the type-definitions and you get a working javascript file (there are some exceptions to this, but it generally is true). this approach has it's downsides of course, for example,when you need to interface with a javascript (not typescript) module, you can easily, but you have to know what types it expects and returns,otherwise you might get invalid structures in your code. there are things that can help you there (https://github.com/DefinitelyTyped/DefinitelyTyped), and it works quite well in practice, but there is no 100% guarantee that the types will be correct.

>> STRICT TYPING (in typescript) For example, the data might contain additional fields or even incorrect values for declared types.

- typescript is structurally typed most of time, so if you have a function that needs an `{a:string, b:string}`, and you send it an `{a:string, b:string, c:string}`, it will accept it. it's a different trade off,sometimes better, sometimes worse, compared to nominal-typing (https://en.wikipedia.org/wiki/Nominal_type_system).

- the part "even incorrect values", it should not happen in your own code. as i wrote above, i can imagine it happening when interfacing with other non-typescript code.

>> DATA VALIDATION: You have to write data validation code to ensure that you’re operating on correct data in TypeScript. You get this for free in Rust...

in typescript if you want to read,let's say JSON data,and map it to a typescript-structure, and return an error if it does not have the correct structure, you can use libraries like IO-TS (https://github.com/gcanti/io-ts/blob/master/index.md) to make that happen. i do not know how you get this "for free" in Rust, i know there are libraries like Serde (https://serde.rs/) that do it.

in theory, yes.

the problem is, how can chrome+firefox persuade microsoft, apple, debian and redhat to add it? and how long will that take? maybe some of them don't want it at all.

with the current approach they can offer this improvement to their user right now.

i thought so to, but it's not like that. of you open that article:

title: "Today’s Firefox Blocks Third-Party Tracking Cookies and Cryptomining by Default"

from the text: "...will block known “third-party tracking cookies” according to the Disconnect list."

so basically they have a blacklist of third-party cookies, and if it is not on the list it is allowed.

i was planning to try out Nix on MacOS, because i always wanted to try out Nix and i use MacOS, but then Catalina happened,a and suddenly there were problems with Nix on Catalina.

last time i checked the install-instructions on Catalina, you had to create an unencrypted volume to store the nix-things, which i'd prefer not to do (i understand those files are probably non-personal, so no need to encrypt them, but i don't want to have to remember that half of my hard-drive is unencrypted)

is that still required or is there a simpler approach now?

so, what makes up the 19MB difference? (i assume it's not caused by the nix one being MUCH older :-)

couldn't you simply do a multi-stage docker-image (in the not-nix situation),where you just copy over the go binary into the final docker-image, and add the needed files?

I don't think your description of Elixir and Phoenix is correct: Elixir is a language targeting the erlang virtual-machine. it does not seem clojure-inspired. Phoenix is a web development framework written in Elixir.

it probably should be mentioned that the first github issue you linked is about signal loosing SMS-messages, not signal-messages. so for the case mentioned by the parent (" getting friends to adopt it") it is not really relevant.

you can use NixOS on MacOS.

i was planning to try it out (currently i use homebrew), but with Catalina it seems things are somewhat complicated for nixos+macos.

my understanding is that NixOS wants to live in "/nix", and Catalina does not like that.

there are some solutions to this problem but they seem somewhat incomplete (you have to make an unencrypted partition for Nix etc..), though i haven't tried it so i might be wrong :)

https://github.com/NixOS/nix/issues/2925 https://github.com/NixOS/nix/pull/3212

oh, i see what you mean. yes, i did somehow miss the "You can't build everything in safe Rust - certain things _require_ the use of unsafe." part of the argument.

i did talk about it in my other comment here: https://news.ycombinator.com/item?id=22701550

exactly this. i understand that it's necessary to have raw/unsafe/whatever-is-the-name code when you interact with the outside world, or to implement building blocks of the language. that's not my problem. my problem is when you look at something innocent-looking third-party library like a http-header-parsing library, and it contains unsafe-blocks. again, i understand it will give it a boost of performance. it's just not the tradeoff i would take personally.

[EDIT]: clarified that i mean third-party libraries.

sorry, what does "to optimize the balance of safety and speed with as few compromises as possible" mean? it's possible to cover many-many situations with that description.

i don't think i missed the point here.

i wrote: "i do understand code using "unsafe" can be safe if the developer does not make mistakes. the problem is, developers do make mistakes."

you wrote: "Usage of unsafe is effectively flagging areas for peer review. You can't build everything in safe Rust - certain things _require_ the use of unsafe. Having it gated, reviewed, and so on is effectively a check on a class of bugs that can be hard to pin down."

it's the same thing. the difference is that you look at it from the glass-half-full point of view (it's good that must-be-verified-by-a-person blocks are limited here), and i do from the other end (it's bad that these blocks are necessary).

11 uses of "unsafe".

(this is not a critique of this specific library, it's more a look at the rust ecosystem as a whole)

i keep looking at Rust, but at the end it seems it is not a language for me. Rust developers just seem to use more "unsafe" than what i am comfortable with. generally, if there could be a choice between using "unsafe", and taking a 2% performance penalty,i personally would go with the performance-penalty. of course, i can understand others have different priorities. the question is, what are the priorities of the rust ecosystem? i mean, can i find libraries that go with as-safe-as-possible or are most libraries as-fast-as-possible?

also, the claim that the rust language is fast and safe becomes harder to accept when the fast libraries use unsafe :) (i do understand code using "unsafe" can be safe if the developer does not make mistakes. the problem is, developers do make mistakes.)

title is wrong, the spec is not ignored. spec says: " When an element’s autofill field name is "off", the user agent should not remember the control’s data, and should not offer past values to the user. "

please note that it uses "should", not "must". these words have precise definition in specs, see RFC2119:

" SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. "

one may argue whether chrome has valid reasons or not, but saying they ignore it is incorrect.