News for hackers. Stuff that matters.
Re:Rust Is the Future of JavaScript Infrastructure by ASalazarMX on Thursday November 11, 2021 @05:03PM (#29193781)
JavaScript was made in like ten days just to add missing interactivity to HTML. If Brendan Eich had known how it was going to be used today, the language would have been very different, if at all.

Edit: it seems I don't have to wonder. Type coercion is one of the worst features IMO, and coincidentally one of his regrets:

> "One of the notorious ones was, ‘I’d like to compare a number to a string that contains that numeral. And I don’t want to have to change my code to convert the string to a number, or the number to a string. I just want it to work. Can you please make the equals operator just say, Oh this looks like a two, and this looks like a string number two. They’re equal enough.’"

> "And I did it. And that’s a big regret, because that breaks an important mathematical property, the equivalence relation property… It led to the addition of a second kind of equality operator when we standardized JavaScript.” One of the people who helped standardize JavaScript was Guy Steele, one of the co-creators of Scheme. “Guy said, ‘Don’t worry about it. There are Lisps that have five kinds of equals operators. We’ll just add another one.'"

https://thenewstack.io/brendan-eich-on-creating-javascript-i...

Re:Rust Is the Future of JavaScript Infrastructure by deckard1 on Thursday November 11, 2021 @06:01PM (#29194358)
The problem with equality and dynamic typing is rather deep and intractable. Kent Pitman (of Lisp fame) has an entire essay about it: https://www.nhplace.com/kent/PS/EQUAL.html

> If COPY can't be done properly, then neither can EQUAL. And, in fact, that's the case. There is no uniquely determined equality function for complex structures--there are only arbitrary ones.

What Steele says about equality is true for Scheme. Everyone has seen the famous "Wat" video of adding "{} + {}" in Ruby or JS. But no one ever mentions Scheme or Lisp:

  scheme@(guile-user)> (eq? "test" "test")
  $1 = #t
  scheme@(guile-user)> (eqv? "test" "test")
  $2 = #t
  scheme@(guile-user)> (define x "test")
  scheme@(guile-user)> (define y "test")
  scheme@(guile-user)> (eq? x y)
  $3 = #f
  scheme@(guile-user)> (eqv? x y)
  $4 = #f
Of course, if you read the RxRS specs then it's all documented and to be expected. But the same is true for JavaScript. As much as I hate typing the "===", there is precedence.

> breaks an important mathematical property

Even mathematicians get lazy and create new syntax and short cuts to express their ideas. Programming is ultimately a human UI. It's easy to see why automatic type coercion was once popular (and probably will be again, I can almost guarantee this).

Re:Rust Is the Future of JavaScript Infrastructure by filoeleven on Thursday November 11, 2021 @07:57PM (#29195180)
This does work in Clojure. Edit: and Clojurescript, which is more relevant.

  (let [x “test” y “test”]
   (= x y))
  ; returns true with both (let) and individual (def)
https://clojure.org/guides/equality
Re:Rust Is the Future of JavaScript Infrastructure by tialaramex on Thursday November 11, 2021 @06:35PM (#29194656)
I was surprised that I was OK with that fact that in Rust a vector and an array with the same elements compare equal. It felt completely reasonable, and I definitely didn't feel that way about it in some other languages where that's true.
Re:Rust Is the Future of JavaScript Infrastructure by bsder on Friday November 12, 2021 @02:47AM (#29197172)
Erm, no, that doesn't work. I created a quick check in the Rust Playground: https://play.rust-lang.org/?version=stable&mode=debug&editio...

Do you have some more context? I suspect somehow things are getting coerced to slices and then compared.

Re:Rust Is the Future of JavaScript Infrastructure by Measter on Friday November 12, 2021 @07:07AM (#29198507)
The implementation isn't symmetric, it'll work if you compare `b == a`. Apparently[0] it's something to do with avoiding code bloat.

[0] https://github.com/rust-lang/rust/blob/e4c23daeb461ac02413eb...