Comments URL: https://news.ycombinator.com/item?id=8600336

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=7090822

Points: 1

# Comments: 0

    var fooString = "foo";
    var secondFooString = fooString;
    secondFooString;  // => "foo"
    
    fooString = "bar";
    secondFooString;  // => "foo"

This is not the case with arrays in JavaScript:

    var firstArray = [1, 2, 3];
    var secondArray = firstArray;
    
    firstArray[0] = 100;
    firstArray;  // => [100, 2, 3]
    secondArray;  // => also [100, 2, 3]

But, using Mori, collections are values, just like strings:

    var firstVec = m.vector(1, 2, 3);
    var secondVec = firstVec;
    
    firstVec = m.assoc(firstVec, 0, 100);
    firstVec;  // => [100, 2, 3]
    secondVec;  // => still [1, 2, 3]

The most obvious way to build this would be to deep-copy the entire collection when it's changed, but that would of course be way too slow and wasteful — imagine copying a one-million-long array just to change one element. Clojure, ClojureScript and Mori minimize unnecessary copying using a very thoughtfully designed data structure you can read about here: http://hypirion.com/musings/understanding-persistent-vector-... The short story is that, surprisingly, you get "effectively O(1)" copying when you use assoc.

While Clojure surely has a bigger learning curve than Go, it's much simpler and more approachable than Scala. I've learned it recently and am an absolute convert. It seems perfect for your use case and you could even skip writing the prototype in Rails because you'll be just as productive in Clojure.

Note that I'm not trying to convince you to change; you obviously found something that works for you. But I am curious if there were obstacles to using Clojure (missing libraries? poor tutorials?) and if so, how that could be fixed.

Comments URL: https://news.ycombinator.com/item?id=6922935

Points: 2

# Comments: 0

However, I'm surprised that you single out a 40-hour work week as though it's something exceptional. Isn't that the standard? I would never consider joining a company that expected me to work weekends. I hope that's not as common as you imply.

Only in a naive implementation. Clojure, for example, has a persistent vector that only requires O(log32 n) copying, which grows so slowly as to be effectively O(1).

See: http://hypirion.com/musings/understanding-persistent-vector-...

https://en.wikipedia.org/wiki/Singular_they

Some object to the usage because:

> Proponents of gender-neutral language argue that the use of gender-specific language often implies male superiority or reflects an unequal state of society. According to The Handbook of English Linguistics, generic masculine pronouns and gender-specific job titles are instances "where English linguistic convention has historically treated men as prototypical of the human species." Words that refer to women often devolve in meaning, frequently taking on sexual overtones.

> These differences in usage are criticized on two grounds: one, that they reflect a biased state of society, and two, that they help to uphold that state. Studies of children, for instance, indicate that the words children hear affect their perceptions of the gender-appropriateness of certain careers. Other research has demonstrated that men and women apply for jobs in more equal proportions when gender-neutral language is used in the advertisement, as opposed to the generic he or man.

https://en.wikipedia.org/wiki/Gender-neutral_language_in_Eng...

Many years ago, I would have agreed with you that using "he" as neuter was correct and therefore preferable to singular "they". I no longer feel that way. I'd attribute that change in opinion to two causes:

One, I'm less concerned with by-the-book "correctness" and pedantry, and more concerned with the real-world effect my words have on people.

Two, I now realize that English is a living, evolving language, and there is no one authority on what is or is not correct usage. What is widely held to be proper English at a given time is a product of who happened to have influence in society at that time, no more, no less.

Also, although this is not what changed my opinion, I find it interesting to note that many of the same people who call the matter trivial will also expend considerable time and effort defending generic "he". If you find it so trivial, why not humor the people who think gender-neutral language is important?

https://github.com/cryptocat/cryptocat

That doesn't solve the problem. No one is going to manually view source and compare it every time they use the damn thing.

> To address your points 1 and 4: Since all data is encrypted BEFORE leaving your browser (this was NOT the case with lavabit) even if our servers were compromised your data would still be secure.

At rest. Yes, at rest it's fine, like I said, but if someone logs in while the server is compromised, it would be trivial to decrypt anything they post or access during that session. Same as Lavabit.

> We'll be releasing [..] a browser-extension, that will help confirm that the code you've received on the site is the same as that in the repository.

So it'll download two copies of the code, one from your servers and one from GitHub, and check that they match? Doesn't seem to me that that buys you much. And unless it's mandatory, you'll be leaving the users that don't install the extension unprotected.

See here for a long list of other reasons in-browser crypto is problematic: http://www.matasano.com/articles/javascript-cryptography/

This concept may sound clever at first but gives you as the user no additional confidence compared to encrypting data on the server side upon arrival. Either way, you're trusting the host.

The threat model for server-side encryption is essentially:

1) the host has an unethical employee who wants to read your content.

2) the host's servers are insecure and get compromised.

3) someone successfully MITMs your connection to the host (possibly due to the SSL problems being discussed here).

4) the government compels the host to provide your data (i.e. what happened with Lavabit).

The threat model for browser-based client-side encryption is the same! In any of these cases, the attacker (or the host, in case of #1 or #4) simply sends JavaScript encryption code to your browser with a backdoor in it.

Cryptocat originally worked the same way: all chats were encrypted on the client side, but with JS code sent from the server, in which a backdoor could be inserted at any time. After much criticism, this is why Cryptocat is now a browser add-on, with discrete releases made available from a central source (Chrome Store/Mozilla addons site), which can be audited.

Having done a few Clojure projects lately, I got most of these right immediately, but there were a few I messed up. It would be cool if you could go through these flashcard-style: one try for each koan in a category, then re-show the ones you got wrong, and repeat until you get them all right.

https://mediacru.sh/transparency/warrant-canary.txt

(Note: the date 08/11 is written European style meaning November 8th, as you can see if you go up a directory.)