Live data from Hacker News

What’s New in ES2019

blog.tildeloop.com

91–100 of 411 posts

Re: What’s New in ES2019

#92

Earlier quoted context omitted.

JS already has immutable objects with `Object.freeze()`. Personally I just use TypeScript which can enforce not mutating at compile time (for the most part).

Thanks. But can I then add and remove items from an immutable object to create new objects? Part of the immutable value proposition is being able to work with the objects. Based on [0] Freezing feels more like constant than immutable. And the 'frozenness' isn't communicated through the language - I could be passed a frozen or unfrozen object and I wouldn't know without inspecting it. And freeze isn't recursive agains…

Object.freeze is kind of constant, but you can still easily copy and work with the objects if you need to, for example, the following is valid for most objects:

    const foo = Object.freeze({ a: 1, b: 2 })
    const fooCopy = { ...foo }
And you are right that Object.freeze doesn't work recursively (although making it work recursively is fairly easy to implement yourself if you use it a lot).

But like it or not JS isn't a language with a powerful type system, and it doesn't pretend to have one so knocking it for that is like knocking Python for using whitespace, or knocking Rust for needing a compiler.

Luckily, Typescript and Flow have most of what you are asking for, and they work pretty damn well across the entire ecosystem.

Off the top of my head, I know typescript has the ability to mark things as read-only even at the individual property level. [1] And they have tons of the type checking nice-ness that you can expect from other "well typed" languages like Rust.

[1] https://basarat.gitbooks.io/typescript/docs/types/readonly.h...

Re: What’s New in ES2019

#93
post #38

Why did they create a flatMap method? What is wrong with .map(...).flat()? Can they improve the performance by combining it that much?

Let me preface this with acknowledging that you're entirely correct that you don't really need flatMap. The following is just some background that might explain why it was included.

If you're familiar with C#'s linq and it's reliance on SelectMany it's somewhat easier to see the significance.

In C#'s linq you might write something like:

    from host in sources
    from value in fetch_data_from(host)
    select create_record(value, host)
with flatmap (and some abuse of notation) you can more easily implement this as:

    sources.flatmap( host => fetch_data_from(host)
           .flatmap( value => create_record(value, host))
If you dig even further you'll find that what makes this powerful is that the flatMap, together with the function x => [x], turns arrays into a Monad. The separate functions map and flat also work, but this adds more conditions. Haskell folks tend to prefer flatMap because most of the conditions for a Monad can be encoded in its type signature (except [x].flatMap(x => x) == x, but that one is easy enough to check).

Re: What’s New in ES2019

#94
post #19

Earlier quoted context omitted.

Thanks for sharing. I think this is the kind of thing you just have to learn when you use any language. But when you're switching between half a dozen, being able to rely on consistent founding design principles really makes things easier. And when there aren't any, this kind of guide helps.

I really like Python's design here, if we are not talking about full on language features to enforce immutability, where functions that mutate never return a value and are named with verbs (e.g. 'sort()'), while functions that don't mutate return their value and are named with adjectives (e.g. 'sorted()'). This feels natural - mutations are actions, while pure functions are descriptions. The only real downside is the…

i used to like that distinction as well but verbs are too useful to let mutating stuff use them all up! and pure functions are actions as well, they just result in a new thing. also, some verbs sound awkward adjectified: take, drop, show, go, get ...

Re: What’s New in ES2019

#95
post #11
post #3

It's great to see JS getting some of the features of better planned languages. But I'm still very nervous about some of the stuff mentioned here with regard to mutation. Taking Rust and Clojure as references, you always know for sure whether or not a call to e.g. `flat` will result in a mutation. In JS, because of past experience, I'd never be completely confident that I wasn't mutating something by mistake. I don't…

Yes, this is a real problem and I've been bitten by it more times than I can count. Now I always keep this handy website ready: https://doesitmutate.xyz/

TypeScript does a pretty good job here if you're willing to add a bit of extra syntax:

  const a = [1,2,3]
  a.push(4)

  const b: readonly number[] = [1,2,3]
  b.push(4) // Property 'push' does not exist on type 'readonly number[]'.

Re: What’s New in ES2019

#96

Can someone please point me to the rationale behind the new toString() function?

If you are interested in all the gory details, take a look at the TC-39 proposal (especially the Goals section) and associated GitHub issues:

https://tc39.es/Function-prototype-toString-revision/

https://github.com/tc39/Function-prototype-toString-revision...

Re: What’s New in ES2019

#97
post #19

Earlier quoted context omitted.

Thanks for sharing. I think this is the kind of thing you just have to learn when you use any language. But when you're switching between half a dozen, being able to rely on consistent founding design principles really makes things easier. And when there aren't any, this kind of guide helps.

I really like Python's design here, if we are not talking about full on language features to enforce immutability, where functions that mutate never return a value and are named with verbs (e.g. 'sort()'), while functions that don't mutate return their value and are named with adjectives (e.g. 'sorted()'). This feels natural - mutations are actions, while pure functions are descriptions. The only real downside is the…

That sounds pretty reasonable. I can see the case for mutation support, but the unpredictable nature of it is what is frustrating and dangerous.

Re: What’s New in ES2019

#98

Earlier quoted context omitted.

> for(let e of arr) e = b Is that just arr.map( e => b ) ?

Providing It was syntactically correct the first call would assign e to a variable b for each iteration ( pretty pointless ) The arr.map providing you had a variable on the left side would output the result of each iteration into said array ( so an array containing all b values - however I guess you meant arr.map(e => e)

Nope. I meant arr.map(e=>b) .

I try to reimplement pointless code, I get more pointless code.

Re: What’s New in ES2019

#99
post #91

It's very exciting to see how JavaScript is evolving!

Honest question, not playing. What is exactly exciting about it? 2020 is around the corner and the language created back in 1995 is only now getting features that have been standard in many other languages, either as part of the core language or the standard library for decades.

Re: What’s New in ES2019

#100
post #78

That array.flat() and array.flatMap() stuff is great to see. Always having to rely on lodash and friends to do that type of work. Exciting to see how JS is evolving.

it should be faster than lodash too, i should hope
Post reply on HN