> I think the problem is there is an existing paradigm of libraries allocating their own memory.
That is a problem, and the biggest reason for why the arenas proposal failed. But if you were willing to accept that tradeoff in order to use the Go built-in arenas, why wouldn't you also be willing to do so for your own arenas implementation?
> If there was a paradigm of libraries not doing allocations and requiring the caller to allocate this wouldn't be such an issue.
I suppose that is what was at the heart of trying out arenas: To see if everyone with bespoke implementations updated them to use a single Go-blessed way to share around. But there was no sign of anyone doing that, so maybe it wasn't a "big miss" after all. Doesn't seem like there was much interest.
> How many things would you have to "just" rewrite?
The same ones you'd have to rewrite using the (experimental) arenas implementation found in the standard library. While not the only reason, this is the primary reason for why it was abandoned; it didn't really fit into the ecosystem the way users would expect — you included, apparently.
"Memory regions" is the successor, which is trying to tackle the concerns you have. Work on it is ongoing.
Not all that interesting when you think about it. Doing so would lead to having to admit that the Go team was right that the proposed arena solution isn't right; that there is a better solution out there. Which defies the entire basis of the blog post. The sunk cost fallacy wouldn't want to see all the effort put into the post go to waste upon realizing that the premise is flawed.
The post could have also mentioned that the Go project hasn't given up. There are alternatives being explored to accomplish the same outcome. But, as before, that would invalidate the basis of the post and the sunk cost fallacy cannot stand the idea of having to throw the original premise into the trash.
> I understand the desire of academics to help agriculture, but they really need to check in with the field before coming up with prototypes like this
Do they? Academia is about the individual. It is not about others. Sometimes what an academic comes up with ends up being applicable to a larger audience, but that's not the goal. Industry is where people try to do things for others.
I mean, if you're an academic and you don't care if anybody uses your technology, that's fine, I guess, but the folks publishing these papers want the industry to use their ideas: "In the agricultural sector, labor shortages are increasing the need for automated harvesting using robots." is the very first sentence.
That's a product of coming up through a school system that emphasizes writing engaging content to please teachers. "Oh no, the farmers can't find help" sounds alarming and draws you in. But as you point out, it ends there. Beyond that, the academic goes off and does whatever is interesting to him personally without concern for what anyone else might actually need. And fair enough. He'd be working in industry if he were trying to please others.
And a farmer myself, I can tell you there is no "labor shortage". Quite the opposite. I can't find enough farm work to do! I could easily grow my operation tenfold without breaking a sweat. But there are so many other farmers who want that work as well, it is hard to compete.
I mean, many of us in academia (I was previously) have made things for industry only to learn that we ignored something important and obvious that was already known. I wish I could find the nice article that gave a bunch of examples of papers and concluded "John Deere already sells this product and it's being used at scale today; if you want to do better, at least be aware of what's going on in the field"
I'll grant you that people who don't understand the difference between academia and industry might mistakenly push themselves towards academia when they really want to be in industry, but we shouldn't take that as an understanding that academia and industry serve the same function. They have different names exactly because they are expected to be different. Academia is where one goes to explore oneself in pursuit of one's interests. Industry is where one goes to explore others in pursuit of serving their needs.
Unsuccessful experiments have no end unless motivation to keep trying runs out — but Rust seems to have no end to motivation behind it. Besides, if it were to ever reach the point of there being no remaining motivation, there would be no remaining motivation for those who have given up to announce that they have given up, so we'd never see the headline to begin with.
We've done unsuccessful experiments on HN over the years, in the sense that they failed to achieve anything we'd hoped for and caused enough damage that we had to call them off.
Isn't that ultimately a loss of motivation? With enough buy in there would be a lot of reason to keep iterating towards the desired outcome despite any setbacks. That is the nature of experiments, after all. Things going horribly wrong while you are in the iteration process is an expected part of experimentation.
Imagine a world where the Rust experiment hand't been going well. There is absolutely nothing stopping someone from keeping at it to prove why Rust should be there. The experiment can always live as long as someone wants to keep working on it. Experiments fundamentally can only end when successful, or when everyone gives up (leaving nobody to make the announcement).
That said, consider me interested to read the announcements HN has about those abandoned experiments. Where should I look to find them?
> people are demonstrating a new behavior that is disrupting social norms
The social norm has always been that you write comments on the internet for yourself, not others. Nothing really changes if you now find enjoyment in adding AI output to your work. Whatever floats your boat, as they say.
The issue isn't people posting AI generated comments on the Internet as a whole, it's whether it should be allowed in this space. Part of the reason I come to HN is the quality of comments are pretty good relative to other places online. I think it's a legitimate question whether AI comments would help or hinder discussion here.
That's a pretty good sign that the HN user base as a rule finds most enjoyment in writing high quality content for themselves. All questions are legitimate, but in this circumstance what reason is there to believe that they would find even more enjoyment from reducing the quality?
It seems a lot like code. You can "vibe code" your way into an ungodly mess, but those who used to enjoy the craft of writing high quality code before LLMs arrived still seem to insist on high quality code even if an LLM is helping produce it now. It is highly likely that internet comments are no different. Those who value quality will continue to. Those who want garbage will produce it, AI or not.
Much more likely is seeing the user base shift over time towards users that don't care about quality. Many a forum have seen that happen long before LLMs were a thing, and it is likely to happen to forums again in the future. But, the comments aren't written for you (except your own, of course) anyway, so... It is not rational to want to control what others are writing for themselves. But you can be responsible for writing for yourself what you want to see!
Has it? More than one forum has expected that commentary should contribute to the discussion. Reddit is the most prominent example, where originally upvotes were intended to be used for comments that contributed to the discussion. It's not the first or only example, however.
Sure, the motivation for many people to write comments is to satisfy themselves. The contents of those comments should not be purely self-satisfying, though.
Reddit was originally just one guy with 100s of accounts. The epitome of writing for oneself.
> upvotes were intended to be used for comments that contributed to the discussion.
Intent is established by he who acts, not he who observes. It fundamentally cannot be any other way. The intent of an upvote is down to whatever he who pressed the button intended. That was case from conception of said feature, and will always remain the case. Attempting to project what you might have intended had you been the one who acted onto another party is illogical.
> The contents of those comments should not be purely self-satisfying, though.
Unless, perhaps, you are receiving a commission with detailed requirements, there is really no way to know what someone else will find satisfying. All you can do is write for yourself. If someone else also finds enjoyment in what you created, wonderful, but if not, who cares? That's their problem. And if you did receive a commission to write for another, well, you'd expect payment. Who among us is being paid to write comments?
Oh? I've had great luck with LLMs and homemade ILs. It has become my favourite trick to get LLMs to do complex things without overly complicating my side of the equation (i.e. parsing, sandboxing, etc. that is much harder to deal with if you have it hand you the code of a general purpose language meant for humans to read).
There is probably some point where you can go so wild and crazy with ideas never seen before that it starts to break down, but if it remains within the realm of what the LLM can deal with in most common languages, my experience says it is able to pick up and apply the same ideas in the IL quite well.
> Rust has lots of checks that C and assembly don't, and AI benefits from those checks.
Fil-C gets you close in the case of C, but we can ignore it because, of course, F* has significantly more checks than Rust, and AI benefits from those checks. Choosing Rust would be as ridiculous as choosing C if that was your motivation.
But if you don't find the need for those checks in order to consider Rust, why not C or even assembly instead?
Well, that's what the checks are for: So that hallucinations are caught by said checks and can be fed back into the LLM to ruminate on.
If you don't find importance in those checks, you wouldn't choose Fil-C anyway. But, of course, it remains that if do find those checks to be important, you're going to use a serious programming language like F* anyway.
There is really no place for Fil-C, Rust, etc. They are in this odd place where they have too many checks to matter when you don't care about checks, but not enough checks when you do care about checks. Well, at least you could make a case for Fil-C if you are inheriting an existing C codebase and need to start concerning yourself with checks in that codebase which previously didn't have concern for them. Then maybe a half-assed solution is better than nothing. But Rust serves no purpose whatsoever.
That is a problem, and the biggest reason for why the arenas proposal failed. But if you were willing to accept that tradeoff in order to use the Go built-in arenas, why wouldn't you also be willing to do so for your own arenas implementation?
> If there was a paradigm of libraries not doing allocations and requiring the caller to allocate this wouldn't be such an issue.
I suppose that is what was at the heart of trying out arenas: To see if everyone with bespoke implementations updated them to use a single Go-blessed way to share around. But there was no sign of anyone doing that, so maybe it wasn't a "big miss" after all. Doesn't seem like there was much interest.
reply