TheMakeA

> Unfortunately now those 250K people who reserved a Model 3 could be driving a EV right now and making an impact instead of waiting for 3 more years.

This is a false dichotomy. As an anecdote, I started a 3 year lease on an EV two weeks before the Model 3 was announced and still put in a reservation.

Who cares if I can get a Volt for 33k right now? It still burns dinosaurs and has a terrible electric range.

Tesla is the press "darling" because it's doing something that the other manufactures aren't: Good looking, All Electric, High Range, Affordable Price. These are things people clearly want.

Every other vehicle sacrifices at least one of those.

PropType checking is compiled out of the production version of React.

Does anyone know if Docker Toolbox supports NFS (or something faster than VBox Shared Folders) yet?

> Yep, it is easier to make languages target DEX than suffer the pain of the NDK.

So what does this look like in practice? Genuinely curious :-)

So you're saying it costs as much as a down payment on a house in the Bay Area to own my own airplane?

I'd rather do that and then live nearly anywhere in the 400 mile range that it provides, and probably be happier.

> I'd have to disagree in that it's not a query language, there is definitely ability to query different parts of the data

For sure. If I could still edit the post, I would probably change it to be something closer to "it's not really a general purpose query language like the name might imply"

It's definitely a query language, but folks start looking for the sorting/filtering/etc and get confused.

Let me clarify a little: I think the name GraphQL for sure makes sense from a technical point of view. But from a marketing point of view, it has been a nightmare and makes it _unusually_ difficult for others to initially grasp.

You totally can. One restriction (that you might be confused with) is that Relay currently only supports root fields with a single argument (which would typically be an ID).

But arbitrary arguments on any other field are totally supported.

It's important to realize that you're essentially defining an API for your product. If something is expensive to access, you should either not expose it directly through your API, or add appropriate levels of caching to mitigate the costs.

Anecdote: when Relay/GraphQL were first announced, we tried to get Relay without GraphQL by writing JSON. This had some advantages (a query was a valid/renderable response!)

...but we had some really ugly JSON. It was worth it for us to get the readable syntax to just use GraphQL.

With client tooling like GraphiQL and editor plugins, it should just get better.

To expand on lgas' answer, you can certainly over fetch with Relay/GraphQL if your product needs to.

The intent is to prevent accidental/unintentional over or under fetching that leads to bugs or poor experiences.

Every time there's a new post about GraphQL, I become even more concerned that "GraphQL" was the wrong name to use publicly. It seems like most people assume it's just another combination of two buzzwords, Graph and QL, and incorrectly pattern match it.

In an attempt to help resolve this issue, I suggest that you think of it as ProductQL or ProductAPI instead.

It's not a storage layer. It's not really a query language. It's an alternative way to define an API that more closely matches the typical mental and product domains than REST.

It's critical to realize that you're implementing an API. GraphQL does not concern itself with sorting or fetching data as the name might lead you to initially believe. It has little to actually do with graphs (except they are more easily expressed). It is designed to be added on top of your application layer and business logic to provide a single, well defined API for your product and tools.

It primarily targets product developers. From the scheme/API side, it is up to the server developer to decide what to expose and how, based on the product and any technical considerations that need to be made.

It sounds like what you're looking for is Business Intelligence. There are a couple of cloud tools like Chartio, Tableau, Looker, etc that provide similar functionality.

This seems really close to what YC started as. Why the spinoff?

Joe Savona says August.

I agree. It also seems like they had a relatively straight forward migration path that worked out really well.

Sounds like good decisions were made at the right times.

There seems to be an awful lot of gratuitous negativity going on here.

The site was on Reddit yesterday, now it's on the front page of HN. Maybe the author can't throw a lot of resources at it, or they used the project as an excuse to learn a new stack. Who knows.

Maybe it was slow for you. Maybe it's not a mathematically sound idea. Maybe the questions aren't ideal. The CAPTCHA isn't ideal.

Who cares? There's no need to be mean about it.

> they haven't really offered any strategies I can implement

I think I made two mistakes the first time I sought help:

* I stayed on the first medication I tried for far too long

* I stayed with my first therapist/psychiatrist for far too long

My new doctors are far more helpful and push me further than my old team ever did. If it's not clicking, don't give up, but maybe see if there's someone else that might be better for you.

If you write most of your code in JS, you technically don't even need to build this on a Mac. For development, you could get away with just updating the bundle and re-signing the app locally.

Absolutely. My primary concern is with the controls feeling native. Reimplementing controls with UIViews doesn't seem much better than reimplementing them with HTML/CSS (save for performance). There's still surface area to break the illusion.

Some food for thought: what if you kept HTML and CSS but instead of using a WebView to render it, you rendered the DOM manually using UIViews? You could even make overflow: scroll; turn into UIScrollViews automatically.

For some definitions of "100% native UI."

I'm a little concerned because, for example, a button is not implemented as a native UIButton, and a ListView doesn't use UITableView. Instead they are composed of native UIViews with a lot of JavaScript glue.

That being said, Facebook has more experience writing iOS apps than me, so it may be possible that those things don't really matter (and doesn't preclude 1:1 components from being added down the road).

I actually independently discovered Nightmare today while this was open in another tab... very cool!

How much? IMO Level Frames seems pretty expensive... A 6x9 frame starts around $41, not including $15 for shipping.

Wow, UCSF has a pretty long list of requirements before this is an option!

Are any of these resources available for anyone who isn't already a YC founder? Does that make sense?

Wouldn't it be valuable to give interested folks who aren't yet in YC a place to do their prototyping, get discounts, and help, and then use it as lead gen for the next batch?

Think of all the companies that could exist but don't because they don't have access to these resources.

Looks nice! Found a typo:

  Refund receipts are of course avaiable

Small correction: The W15 applications did ask for gender.

You might have experienced a brief moment of depersonalization[1]. It can be a desirable state for some, but for others (like myself), it has caused the past six years to be hell.

[1] http://en.m.wikipedia.org/wiki/Depersonalization_disorder

> Very few people, even programmers, seem to know the difference. Some even claim to program in C/C++

At least in game development, you will usually use a sort of "C, with classes" approach. You use a C++ compiler and the class, and namespace keywords, but shun the rest of the C++ features like exceptions, virtual functions, and the STL for most of your code.

At that point, it's not really C and it's not really C++...