HN user

geoffschmidt

2,588 karma

Co-creator of Apollo GraphQL and before that MeteorJS, and CEO of those companies for 14 years.

My email address is geoff (symbol) geoffschmidt (symbol) com. The first symbol is '@' and the second symbol is '.'.

Posts12
Comments215
View on HN

That wasn’t my takeaway from it at all. I think he’s quite precise in his definitions and the point he’s making about Rust, even if I found the prose a bit fatiguing due to the LLMisms.

Personally I think that the world needs more of your optimism. But what does your crystal ball say about energy costs and political stability?

It’s one thing to say that AI will help everyone create immersive games, but skyscrapers won’t be free unless energy is free. Do you also assume that AI will solve fusion?

What happens to the individuals who are not “strong” and how do they hold onto their remote work jobs? Why will the biomedical research technology you’re positing not be used to create biological weapons, or do you assume that AI also creates universal peace and harmony? If so, how does it do that while also preserving our ability to have our own ideas and disagree with each other?

If we want the great future you’re imagining, I think history teaches that we need to give at least as much attention to these questions as we do to making the technology work.

I think their work earns "theory" because it makes specific predictions both about how to make more effective prompt injection attacks and what activations you'd observe in the LLM during those attacks, and can also be plausibly extrapolated to suggest useful future research directions.

Claude is already shockingly good at reverse engineering. Try it – it's really a step change. It has infinite patience which was always the limited resource in decompiling/deobfuscating most software.

I think the origin is in the phrase, "Will the dogs eat the dog food?" which was common VC-speak in the 90's and 00's, referencing dog food commercials that once ran on TV, and meaning something like "this has been made to sound great in an internal powerpoint presentation, but will customers actually like it?"

Attributed to a Microsoft exec in the 80s: https://www.geekwire.com/2025/eat-your-own-dog-food-how-micr...

In 2015, Marc Andreessen memorably said of Mixpanel's success at product-led growth: "The dogs are fucking jumping through the screen door to eat the dog food. And he hasn’t done any marketing yet." https://www.newyorker.com/magazine/2015/05/18/tomorrows-adva...

That then led to the idea of "eating your own dog food", because if even you won't eat it, what credibility do you have saying that the other dogs will?

It's not "the largest representable number" because you're not representing numbers in any rigorous sense. If I give you 64 bits, you can't tell me what number those bits represent (first, because the rules of the game are ambiguous - what if I give you 8 bytes that are a valid program in two different languages; and second, because even if you made the rules precise, you don't know which bitstrings correspond to programs that halt). And if I give you a number, you can't tell me which 64 bits represent that number or even if the number is representable, and that's true even for small numbers and even if I give you unbounded time.

It seems far more natural to say that you're representing programs rather than numbers. And you're asking, what is the largest finite output you can get from a program in today's programming languages that is 8 bytes or less. Which is also fun and interesting!

enclose.horse 7 months ago

Click the sandwich icon in the top right, then either Past Puzzles or Browse, and you can play more puzzles. (Or even create and submit your own.)

The GraphQL ecosystem has grown amazingly quickly over the last year. It's definitely not a single-vendor technology at this point. Check out this list of GraphQL libraries, tools, and implementations: https://github.com/chentsulin/awesome-graphql

The majority of people who are using GraphQL are using an implementation from someone other than Facebook (on either the client or the server, or in many cases both).

(And for what it's worth, I did see a "Why not RDF" slide in one of Lee Byron's decks, and those of us at Meteor who are working on GraphQL are definitely aware of the RDF/SparQL roots. I think what's driving GraphQL's growth is, first, it addresses a very timely problem - fetching all of the data for a screen in a mobile app in a single round trip without coupling your backend to your UI - and second, the focus on tooling and developer experience which has been a weakness for SparQL.)

Hi, Meteor cofounder and CEO here :)

Our Meteor business is thriving and we beat our 2016 revenue goal by almost 40%, driven by strong Galaxy growth. We expect that to continue into 2017 based on what we heard from a survey of Meteor/Galaxy users that we did recently – they are using Meteor for mission critical apps and most of them plan to write more Meteor apps in 2017. In line with this, we are growing our Meteor open source team while also continuing to ramp up our work on Apollo.

The big difference between Meteor and Apollo is that Meteor is about new app development (specifically in JavaScript), and Apollo is about a data system that you can add to already-existing apps that are running in production at meaningful scale. There's a place for both of these things and a lot of overlap between them.

Meteor isn't going to take over all JavaScript development the way Rails took over Ruby development, at least not anytime soon. That's just not how the JavaScript ecosystem works. However, I think it will be the #1 full stack JavaScript framework for a long time to come and will continue to be a really great option for teams that want to build JavaScript apps quickly, especially apps that have a realtime or collaborative element.

There are a variety of theories of copyright infringement in the US: direct infringement, contributory infringement, vicarious infringement, and inducement to infringe. I don't remember exactly which would apply to the circumstance you're describing, but in general, if you're making money off of someone else's infringing activity, if you are tolerating infringement that you have ability to stop, or if you have a landing page that suggests that people use your product to infringe copyright, you're probably in hot water, even if you're not infringing copyright yourself.

I dropped out of MIT after a term (in 1999), raised venture capital for my first startup shortly after that, and went on to have a successful career.

I never recommend skipping college to anyone. If you have a unique opportunity that can't wait, you have a solid plan, AND you have unique skills, then it might make sense. Or maybe if you have a very strange combination of strengths and weaknesses such that you are mature enough to succeed on your own, but not capable of making school work for you. Or if you can't find a way to get to a school where you will be with a good set of intellectual peers.

I know quite a few people who have dropped out of or skipped college, and in all but one or two cases I think they're worse off for it, or at least, they spend many years struggling to replace or replicate the college experience.

There are three big things you have to replace if you skip college: The social experience (learning how to exist both socially and intellectually in a group of peers). The material (in some hypothetical sense you can learn it all on OpenCourseWare, but in practice, most people find this to be a serious grind). The intellectual discipline (learning to think clearly and maturely, filing down your rough edges).

Your best bet is to find a group of really smart people who will be absolutely merciless in instilling intellectual discipline in you (constantly challenging you be rigorous, to know your field, to fully back up your ideas), and that will also be your close friends and romantic interests, and then find a way to have lots of spare time to hunker down and work through OCW or your favorite MOOC or textbooks. I know several brilliant people who have created these situations for themselves, and I think they've all found that it takes a huge input of energy to even approximately replicate what is readily available at top colleges, even for people that are smart enough to breeze through or basically intuit/rederive the course material.

Logistically, dropping out will close some doors forever. People with degrees can switch fields later in life by going to grad school; it is harder to switch fields if you don't have a degree. Immigration situations are far more difficult without a degree. There are ways around the closed doors but you will have to fight very very hard for them and become the top in your field. On the other hand, you also have a huge advantage (at least if you skip college entirely) which is that you don't have student loans and that may significantly increase your freedom during a period of your life when freedom is critical. In my own life I think these logistical factors came out about even.

In the end, I think it was right for me to leave in '99 and dive into startups, but, like, I made that decision in Stockholm, at the Nobel prize ceremony, where the establishment sent me after winning the top prize at world science fair, so I had every possible advantage and it was still a very difficult road. Do it only if you really don't see a future for you at college.

Hazel thinks George looks exhausted and urges him to lie down and rest his "handicap bag", 47 pounds (21 kg) of weight placed in a bag and locked around George's neck. He says he hardly notices the weight any more. Hazel suggests taking a few of the weights out of the bag, but he says if everyone broke the law, society would return to its old competitive ways. Hazel says she would hate that. A noise interrupts the conversation, and George cannot remember what they were talking about.

http://en.wikipedia.org/wiki/Harrison_Bergeron

It's not normally how classification works, but then there's the Born Secret doctrine that was (is?) applied to information about nuclear weapons:

http://en.wikipedia.org/wiki/Born_secret

The NSA isn't going to swoop in and claim that the results of the Truecrypt audit were born secret. But the answer to nabla9's question is yes, legal precedent exists in the United States for restraining the publication of original research when it is perceived to damage vital national security interests.

Yeah, we have several big projects in flight, and we're shipping them in the order that they're ready.

We push them out first as prereleases (which you can run by passing a --release flag to meteor, and it will automatically download and install everything) and announce them to meteor-core and see what people think. In this case both oplog tailing and Meteor UI were out as prereleases, but there was more feedback and more feature requests for Meteor UI, so oplog tailing ended up winning the race.

We are rationing version numbers before 1.0, since we have multiple major projects that're slated to land in between now and then, including Meteor UI and integrated package management. (Though as Node has shown, an 0.10 wouldn't be the end of the world.) But we decided that oplog tailing is a big enough deal that we should bump the middle number.

Meteor core dev here! We are super excited about Rethink and Slava and I have been talking for a while about an official integration. We scoped multidatabase support out of the upcoming Meteor 1.0 release just to get it out the door faster -- we need to support people using Meteor in production with frozen APIs, and we need to do it yesterday -- but support for Rethink is something I'm very interested in exploring in 2014.

As for the polling on Mongo, you'll love what Meteor is shipping this week. Meteor now by default connects to Mongo as a replication slave and slurps up the replication log to drive your realtime queries.

I was really skeptical about Oculus, but I had a chance to try out a demo by Amir Hirsh that combined an Oculus with simple Kinect-based limb tracking. I could look down and see my own hands and they really felt like my hands. I have no idea how this is going to work in practice (are we going to have to play games in large empty warehouses) but it is magical in a way that is hard to describe if you haven't had a chance to try it.

Not exactly. Credit card authorization happens instantaneously, even though it takes the money a while longer to actually move between accounts. And this is separare from the chargeback mechanism, which can claw the money back after it's actually moved.

A 0-confirmation bitcoin transaction is more like writing down someone's credit card number and charging it later when you have access to your credit card terminal, which was common (in the form of those carbon copy credit card impressioning machines, which are why credit cards have raised digits) in the days before ubiquitous mobile Internet.

I'm totally there with you, and my hope with DDP 1 was to make some progress on that first step: decoupling code from data, so that a standard DDP client can connect to any DDP server and pull data out of it.

In the future, I'm super excited about investigating ideas like DDP discovery (asking a DDP server what data and methods it has) and description (having a DDP server publish metadata in some standard format that explains the semantics of the other data that it's publishing in terms of microformats). I think the main place we differ is that I think that these formats should use something more like a relational model rather than a hypermedia model, or a formal knowledge representation model like RDF. Isomorphisms exist between these models, and used properly they are all equally powerful, so really this just a design decision about what will be easiest to implement and adopt. And of course I believe that it has to be server push (websockets) rather than poll (HTTP), and that it has to support server-side joins (doing 1 query rather than N+1 queries, and taking 1 roundtrip rather than 2, to retrieve your newsfeed stories plus the comments on them.) I can't tell from your comment whether you agree with that or not, but like I said, these are two of the main things that motivate DDP.

All of that said, I think that by far the hardest part of the puzzle is the product design and federation issues. In your federated Github and HN, the technical work is the first 10%, the next 90% is finding a user experience for it that makes sense to and is ergonomic for a large number of real users, and the final 90% (really should be more like 9000%) is convincing the industry (read, creating incentives to force the industry) to cooperate with the federation and to resolve all of the political squabbles about advertising, control of the data, licensing, and so on. I mean, Google pulled out of XMPP federation -- all practical evidence suggests that keeping these federation together is wicked hard.

So that's why we're just trying to build the first 10% of that first 10%, which has a very clear use case for building rich browser apps and mobile apps -- and hoping that we will be a stepstool that others such as yourself can stand on to build the full solution that everyone dreams of.

Anyway, if you are sympathetic to this line of argument, I hope you'll check out DDP and see what interesting discovery and self-description features could be built on top of it, or suggest how its semantics could be strengthened!

Doing AV right is hard! You can devote your whole career to learning how to do AV well, and I have a ton of respect for the skills of the people that choose this path. It's a lot more than plugging in a microphone.

We do try to improve AV with every Devshop, and we have recently started to bring in AV professionals to help. But honestly, pre-1.0, I think it's way more appropriate for us to be spending our time and money on advancing the framework than on super slick video presentations. In many ways it's more like the Meteor community's time and money.

Well, all of Meteor is under a MIT license, so if we think we're going to "monetize that codebase" we're pretty stupid :) I'm not a lawyer but I think that under the MIT license there's basically nothing that we can do with the code that you can't do too. Our actual plan is to sell operational tools for larger companies that have mission-critical Meteor apps in production.

The incredible amount of work that we've put into JavaScript build tools over the last two years has all been with the aim of creating a radically easier, faster developer experience, because we know that that's incredibly powerful marketing for the rest of our crazy ideas. In other words, we did it because we thought that the UX of the existing JavaScript tooling was just too janky. Seriously, try Meteor for yourself and see what you think -- maybe you think our work sucks and that we wasted our time, but if so, I wish you would just tell me that (I would genuinely love to know) instead of reading ulterior motives into what was a labor of love and a ton of hard work.

Of course there are many rough edges and it's not done (that's why it's not 1.0 yet) but from people that have actually used it for a while, we actually get the opposite feedback, which is that they want us to go much further down this path, and that's why we continue to slave away at what is by far the least fun part of building a framework.