_7bxa

I really like that for loops can be expressions. It seems obvious in hindsight, but hindsight is always 20/20 :)

This makes sense but also seems very annoying to do? E.g let's say you are storing state in the URL, and now the user wants to save it to their profile. You need to upgrade the state from "encoded into the URL" to "stored in my database", which seems annoying.

To all people complaining about bugs: 1. It's easy to find flaws in hard, ambitious projects. All ambitious projects start out as WIPs. 2. It is much harder to do an ambitious project.

Try to be in the 2nd group.

Nothing you say is credible unless you tell me you have tried copilot. Without you having tried copilot and seen its capabilities we have no common ground. So get back to me once you have used it.

I claim copilot is capable of creating. When copilot writes an amazing lodash one liner in my code --that isn't regurgitating an existing lodash snippet, it's creating something new to fit my use case. This is undeniable and there is nothing to argue here. Copilot regularly looks at my code and writes new code that is highly specific to my existing code. It's honestly better than me at languages I don't know well (like C).

And yes, 0.1% of the time copilot is spitting out existing code verbatim; the other 99.9% of the time copilot is not overfitting and is synthesizing new code. Luckily most companies don't needs clean room implementations.

Copilot writes code that is adapted to my existing code base. This is quite obviously and undeniably not just regurgitation because my codebase is unique to me.

Lastly copilot is a better programmer (locally) than many of my peers. It can write better lodash one liners, amongst other things, and while that's embarrassing it's true.

Yeah, using Copilot in a clean room implementation is bad. Luckily, many things don't have to be clean room implementations!

Yeah, there are probably some edge projects where Copilot can't be used. For the vast majority? Seems fine.

IMO, all these concerns about licensing ignore a pretty important fact: Copilot is (in most cases) no different from a human.

If I read the code for, I don't know, some GPL-3 library and then write my own MIT-licensed version--that's totally fine.

A programmer can read strictly licensed code and then use that knowledge to write their own non-strictly licensed code.

Copilot is not different from a human. It has knowledge & it uses it. It isn't copy-and-pasting (there are 1/2 edge cases where it is; but for the most part it's new ideas).

It's the same thing as saying "Dall-E 2 is plagiarizing art".

When I write a quicksort algorithm, I don't give any attribute to the code I saw for the algorithm in some random library.

Fundamentally, there's no real difference between Copilot and a human. I've watched Copilot write crazy lodash one-liners that were clearly contextual to my code.

I think what is fundamentally happening here is that older people / people of the last generation are realizing that just as sys admin jobs / etc. are going away, soon many rote coding jobs will be taken away since Copilot will automate them. And that's fine, but it is producing backlash which comes in the form of licensing issues.

Basically, there's no difference between Copilot and Dall-E and it's pretty clear that Dall-E has no licensing issues, thus Copilot should also be in the clear.

Rather than do the typical HN thing of commenting on something irrelevant (like the landing page), I'll comment on the actual thing being presented:

First, I really like that this leverages Typescript to its fullest. I'm a big fan of doing things like runtime reflection of compile time types.

However:

``` id: number & PrimaryKey & AutoIncrement = 0; ```

One thing that seems confusing is, (presumably) -- these compile time types are being translated into runtime type behavior. (I'm guessing by your Typescript transformer?). While this is very cool and concise, I suspect it could be super "magical".

In your case, has Deepkit felt too magical?

There's something that scares me about Rome: it's lack of plugins.

I really like Babel because of its plugins. My project typecheck.macro, could not exist without Babel plugins.

How will Rome support compile time transformations like graphql.macro or typecheck.macro?

Compile time plugins allow JavaScript to evolve super rapidly & make the creation of frameworks that act as compilers instead of traditional frameworks possible.

[1] https://github.com/vedantroy/typecheck.macro

As a man, I agree sharing emotions is important. Too many males in society don't have someone to cry with or listen to their problems.

On the other hand, I do worry about "emotional masturbation". Simply put, sometimes we indulge ourselves in sadness/fear/anger because it makes us feel something and feeling something is better/more exhilarating/exciting than feeling nothing at all.

For example, I have some insecurities. Sometimes I feel like talking about them may be pro-actively bad because I am indulging myself and making my insecurities occupy more mental space/brain power.

There's nothing to memorize here, or there shouldn't be, because "filter" is a standard array function in JS that I imagine most JS developers have encountered.

Knowing how "filter" works is valuable because now you can use that knowledge in the future on any project that uses JS, unlike "_.compact" which is only applicable in projects that use lodash. You can be relatively confident that you can write "filter(elem => <some function>)" and that other developers will know what "filter" is doing.

The second part is more tricky, but still useful.

The !! operator is just two "!" operators. That's pretty normal too. The first "!" converts an object/number/whatever into the opposite of its boolean value. The second "!" negates the first boolean, thus turning the opposite of the boolean value into the object's original boolean value.

Even if figuring this out on your own is slightly more difficult, it gives you valuable insight into the language (JS is very dynamically-typed and the not operator can cast objects to booleans), which will help you write better/safer/more concise/clearer code in the future.