The best time to move your docs to your repo was 30 years ago. But now that they are written by LLMs, tomorrow's LLM will be able to write an even better doc than today's LLM. Nothing is gained in caching them now.
Unless you're doing something wrong, the "why" is already captured in your test suite/type system. While you can fairly call that documentation (that is the point of it!), the linked story is about natural language documentation. That can be extracted from your tests/types at will, and as models keep getting better extracting later will be better than extracting now.
Don't get me wrong, I'm sure future historians appreciate when you document that John, when trying to determine how to figure out how to exchange data in your application, took a drink from his Diet Coke that happened to have a fly in it and as he spit it out eureka struck: Data can be pushed to the client like a firehose.
But let's be real, that's never going to happen. No matter what format you give someone, they're not going to write that kind of thing down. They will, however, encode why a firehose approach is necessary to both document it for future readers and to ensure that the program doesn't accidentally (or possibly on purpose by an eager junior dev) move to, say, a pull method that won't meet the business/technical requirements. Which LLMs can extract a natural language version from.
And, really, that's the only "why" that actually matters to other developers trying to get their job done. The forest, while perhaps full of fun stories that I am sure are entertaining to read, doesn't matter all that much.
So you understand that a MrBeast burger isn't made by, or from, the person known as MrBeast, but when one pays to join the MrBeast YouTube channel you are certain the comments from user MrBeast are made by the person known as MrBeast? What's the difference?
Feels like you're making this more complicated than it needs to be. The elements of fraud are quite simple:
1. a false statement of material fact
2. knowledge that the statement is false
3. intent to induce reliance
4. justifiable reliance by the victim
5. resulting damages
The "buying a burger from a MrBeast cafe" fails to meet element 1, because nobody at MrBeast burger is falsely claiming to be MrBeast himself.
On the other hand, falsely passing oneself as a model in order to earn revenue for them meets elements 1, 2, and 3. Elements 4 and 5 will depend on whether the victim fell for the scheme.
> nobody at MrBeast burger is falsely claiming to be MrBeast himself.
Nobody said that they were. You must have forgotten to read the thread. When 'MrBeast' comments on YouTube to those who pay for a subscription to his channel, it is claiming to be MrBeast, however. But is it him? You completely understand he doesn't have time to flip burgers, and thus would never expect him to, so why do you think he has time to chat to random internet customers?
The issue here comes down to money and therefore reliance and damages. Nobody's paying "MrBeast" in response to his (or his delegates') YouTube comments. So there's no material reliance and no damages; the 4th and 5th elements above aren't satisfied.
On the other hand, people are paying money thinking that they're talking to the model herself. Thus the 4th and 5th elements are satisfied, in addition to the other three.
There's no need to interpret words through the arbitrary lens of silly feelings, yet here we are.
> Nobody's paying "MrBeast" in response to his (or his delegates') YouTube comments.
According to what? Is this something you made up?
If someone is willing to pay to talk to an internet figure, as you asserted they are, why not MrBeast? We can probably find agreement in MrBeast not being "herself". Is that the difference you find? The white knights only consider it fraud if the figure identifies as "her"?
> people are paying money thinking that they're talking to the model herself.
I'll have to accept your personal experience for what it is, but what in the marketing suggests the model is anything more than a brand? You even literally call it a model, not a person. That is quite telling that you understand the business at play, even if you want to pretend you don't for the sake of the fake argument.
We all know full well that MrBeast is a brand. Why are you treating MrsBeast differently?
> but the people commenting on YouTube aren't paying.
MrBeast is allegedly the highest paid YouTuber and yet, I guess, you think he works for free? While not exactly public information, industry analysts estimate that $5MM per year revenue is generated from direct fan funding to support his channel, so that, you know, "he" can do things write comments to the patrons.
> That's the name of the job.
Exactly. "Model" is used in recognition of the dehumanized object. In art, a human model is considered to be no different than a clay model. In fashion, the human model is considered to be no different than a clothes rack. The point of using the word is to separate the person from what the person is displaying. Otherwise you could simply say "person". "Model" is also used in this context because the concept is the same — the product isn't the person.
I think what you're missing here is the difference in the communication dynamics and what people are paying for.
In the model-customer dynamic, a customer is giving money to a model on a quid pro quo basis: the model -- or so the customer believes -- is promising the customer personal attention and customized content in exchange for money. No money, no attention.
In the MrBeast example, nobody is paying MrBeast specifically in exchange for his YouTube comments, which are public. Paying MrBeast is not a precondition for his engagement; he (or his agents) are responding spontaneously. His fans may be inspired to contribute to funds, although MrBeast gets a lot of money from ad revenue. But there's no quid pro quo arrangement here.
> I think what you're missing here is the difference in the communication dynamics and what people are paying for.
Exactly. I asked for details on exactly how the models are being marketed for that very reason. It was fully recognized be me that we cannot meaningfully discuss this without understanding the communication taking place. What I'm missing is the answer.
No doubt the other commenter realized that it is actually made clear to the buyer exactly what they are getting and that's why the response devolved into off-topic ad homiem and then disappearance. Funny how people react when their worldview crumbles, isn't it?
Honestly, I think this was just a case of other folks already understanding the nature of the issue discussed in the article (pay for DMs), while you did not. This isn't an insult or anything, just an observation.
A little humility is, I think, helpful for everyone here. Let's be kind to one another.
> but you need moderators to define and adjust the guidelines
The comments above you are suggesting that global guidelines are unnecessary. Instead, they suggest you don't need moderation at all when LLMs now give us the technology to filter out the stuff individual users don't want to see based own their own personal policies. I am sure you can come up with reasons to dispute that, but "you need moderators to do the thing you say is no longer necessary" doesn't add to the discussion.
For sure, advanced difficult topics were never really their forte', although it was really common to get great book or blog recommendations via comments. For me, the golden combination was a good book on the language/framework/topic I was stuyding, supplemented with specific Q&A from Stack Overflow. I have extremely fond memories learning C++ and Qt that way (although that Qt book was a little rough, but at least there was a Qt book. Nowadays every book just seems too outdated to be helpful).
A democratic election requires that the elected be your employee, where you work with him on a regular basis to direct him in his job. That works (ish) in government where people doing the hiring have heavily invested life interests in it succeeding.
Does a subforum offer the same? Once the mod is elected, are you going to sit down with him each day to make sure he is doing the job to your wishes and expectations? I say (ish) in government because it often doesn't even work there, even where people have heavily invested life interests, with a lot (maybe even the vast majority!) of people never getting involved in democracy. A subforum? Who cares?
If there were to be elections, it is unlikely they could be anything other than authoritarianly, with the chosen one becoming the ultimate power.
Don't distract. I'm genuinely trying to help us figure out how to build quality software, using AI, while avoiding all the problems we're seeing on so many teams.
No distraction. Genuine question. The whole point of the Agile Manifesto is to encourage removal of VP and similar roles from an organization; turning to a flat organizational structure. What motivates you, a VP, to latch onto that? How do you think that will help (with or without amendments)? Do you, perhaps, think in the age of AI your org will be better off if you 'step down' into a development/AI steerer role?
I was around when the agile manifesto was drafted. It wasn't about eliminating hierarchy in organizations. That's something that started happening later, around and after 2010. The agile manifesto was singularly focused at helping people see how to deliver software without leaning on the old waterfall methodologies.
The Agile Manifesto was published in 2001. You asserted earlier your software career began in 2006. What brought you to the Wasatch Mountains at that time when you had no ties to the industry?
Winston Royce, in his book, invented the waterfall methodology as a hypothetical of what not to do in order to help explain his core thesis. It is not a real thing. Why do you suggest the Agile Manifesto was created to help avoid leaning on a strawman?
The whole thing? That is what Agile Manifesto, and the associated 12 principles, is about: A thought experiment about flat organizational structures. Each of the 12 principles outline the things one needs to consider when they don't have a manager taking watch.
Where you find a VP, Agile isn't applicable. At least not in its entirety. It it is likely that you can still cherry-pick some ideas from it to apply to your non-Agile situation. "Do your manager's job for them" is often considered common wisdom after all.
You must have worked in some very unhealthy teams where psychological safety wasn't present. I'm sorry that happened. But don't confuse your experiences with that of everyone else's. There are lots of teams that are agile from the top down, including those that happen to hold a title with VP in the name.
Rust is the older project of the two, kicking off in 2006. Go, which set sail in 2007, duplicating the work of Rust would have been pointless. We already had Rust.
Go's objective was to become a faster Python. Which was something we also desperately needed at the time, and it has well succeeded on that front. Go has largely replaced all the non-data science things people were earlier doing with Python.
If you saw the early presentations, they complained about the slow compile times and high complexity of C++. It seems that they were targeting that, not Python.
I did see the early presentations. And since you did too, you will recall that one of the primary priorities was for it to "feel like a dynamically-typed language". You know, because it was trying to be a faster Python.
What you might be confusing that with is that their assumption was that Google services were written in C++ because those services needed C++ performance, not because the developers wanted to write code in C++, and that those C++ developers would jump at the chance to use a Python-like language that still satisfies them performance-wise. It turns out they were wrong — the developers actually did want to write C++ — but you can understand the thinking when Google was already using Python heavily in less performance-critical areas. Guido van Rossum himself was even on the payroll at the time.
For what it is worth, Google did create "Rust" after learning that a faster Python doesn't satisfy C++ developers. It's called Carbon. But it is telling that the earlier commenter has never heard of it, and it is unlikely it will ever leave the heap of esoteric languages because duplicating Rust was, and continues to be, pointless. We already had Rust.
It would be helpful for you to share a link to the Github issue you created. If the TLA+ spec you no doubt put a lot of time into creating is contained there, that would be additionally amazing, but more relevant will be the responses from the maintainers so that we're not stuck with one side of the story.
Of course, expecting you to provide the link would be incredibly onerous. We can look it up ourselves just as easy as you can. Well, in theory we can. The only trouble is that I cannot find the issue you are talking about. I cannot find any issues in the Go issue tracker from your account.
So, in the interest of good faith, perhaps you can help us out this one time and point us in the right direction?
I’m not interested in contributing to go. I tried once, was basically ignored. I have contributed to issues there where it has impacted projects I’ve worked on. But even then, it didn’t feel collaborative; mostly felt like dealing with a tech support team instead of other developers.
That being said, I love studying go and learning how to use it to the best of my ability because I work on sub-ųs networking in go.
When I get home, I’ll dig it up. But if you think it’s a fair scheduler, I invite you to just think about it on a whiteboard for a few minutes. It’s nowhere near fair and should be self-evident from first principles alone.
There are also multiple issues about this on GitHub.
And an open issue that is basically been ignored. golang/go#51071
Like I said. Go won’t fix this because they’ve optimized for throughput at the expense of everything else, which means higher tail latencies. They’d have to give up throughput for lower latency.
> And an open issue that is basically been ignored. golang/go#51071
It doesn't look ignored to me. It explains that the test coverage is currently poor, so they are in a terrible position of not being able to make changes until that is rectified.
The first step is to improve the test coverage. Are you volunteering? AI isn't at a point where it is going to magically do it on its own, so it is going to take a willing human hand. You do certainly appear to be the perfect candidate, both having the technical understanding and the need for it.
Heh. I've had my fair share of mailing list drama. This is political AND technical. Someone saying "let’s cut throughput" is going to get shot down fast, no matter the technical merit. If someone with the political clout were to be willing to champion the work and guide the discussion appropriately while someone like me does the work, that's different. That's at least how things like this are done in other communities, unless go is different.
> If someone with the political clout were to be willing to champion the work and guide the discussion appropriately while someone like me does the work, that's different.
There is unlikely anyone on the Go team with more political clout in this particular area than the one who has already reached out to you. You obviously didn't respond to him publicly, but did he reject your offer in private? Or are you just imaging some kind of hypothetical scenario where they are refusing to talk to you, despite evidence to the contrary?
You must not have read all the comments yet? One of Go's key runtime maintainers sent you a message. Now is your opportunity to give him your plan so that he can give you the political support you seek.
reply