Hacker Newsnew | past | comments | ask | show | jobs | submit | xh-dude's commentslogin

Pretty much. It’s a counting semaphore underneath.


Sort of in the middle, id games always felt tight. The engines were immersive not only because of graphics, but basic i/o was excellent.


Go particularly is a sort of fixed ceiling project.

Ian recently had a really pleasant error handling proposal that nonetheless wasn’t going to change the core philosophy of error handling, or memory arenas are another area where the current tradeoffs are fine and not worth reengineering, etc.

IMHO Go is in excellent shape as far as hitting needs when it’s a good technical fit - it’s supposed to be a really stable language - and paradoxically this also may mean not everyone who’s been involved would have the same job description in the future.

That’s fine. A lot of really excellent Go team members have come and gone over the years. Russ and Ian may be some of the late leavers in a sense, so I really, really appreciate their dedication and followthrough. The culture they stewarded has payed off for the community and the kinds of upcoming things that look promising are less about the core language, more about improving and maintaining the standard library.


Petulantly, I’d observe Trump hates or doesn’t believe in knowledge economies. He’s delivering pain to a lot of people in my circles.

For all that, a strategic goal of ensuring trade is sustainable is probably worth sane discussion.


> Trump hates or doesn’t believe in knowledge

shortened that for you


There’s also a regression-to-the-mean problem, the systems really shouldn’t optimize just for the easier cases. I wonder if that’s a direct tradeoff, I think maybe it is with the kinds of things I see used to tweak out hallucinations.


The author makes a great case for machine-interpretable standards but there is an enormous amount of work out there devoted to this, it’s been a topic of interest for decades. There’s so much in the field that a real problem is figuring out what solutions match the requirements of the various stakeholders, more than identifying the opportunities.


Thanks for helping the OEIS site stay alive. I was absolutely delighted by it the first time I visited it, decades ago. Equally delighted when I visited recently and saw some “Russ Cox” contributed.


They discuss dogfooding “Sensor Content”, which isn’t “Rapid Response Content”.

Overall the way this is written up suggests some cultural problems.


I’m confused. ISTM Wu arguing that companies’ right to moderate shouldn’t be constrained by a reading the 1st Amendment too broadly. Am I getting Wu wrong or do you think the 1st should sharply prescribe moderation?


I don't know what internet you are on. That's the dead ass opposite of what Tim Wu is saying. He's saying very clearly that companies have too much power & saying very clearly he thinks algorithmic & other limitations trample in free speech rights.

> By presuming that free speech protections apply to a tech company’s "curation" of content, even when that curation involves no human judgment, the Supreme Court weakens the ability of the government to regulate so-called common carriers like railroads and airlines — a traditional state function since medieval times.

He's saying we should regulate these companies like common carriers. He's saying we shouldn't be allowed to have our news feeds be generated or curated by systems. He's saying the broadcaster has a right to send stuff to our feed whether we want it or not.


I don’t see where he’s saying we can’t have automated moderation, though. Rather, just that there’s no 1A rights assumed for BigCorps’ systems, and that there’s a danger to individuals’ rights if the court really concludes that BigCorps do have these 1A rights.


He's saying Big Corps don't have a 1A right to moderate. If you take that away, I'm not sure what your hoping will happen.


Julia has good ideas, interesting trade-offs here as well. ISTM the deep problem is that there’s so much room for optimization under composition of operations or with invariants not captured in types that the typical LinAlg library will never capture. But I agree most languages should be anticipating that users need something helpful here.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: