Is there a relationship between how good a programming language is for coding agents and how popular it is among humans? If so, wouldn't Python be the best language for agents, since it's is the most popular (and hence has the most context available for models)?
Pick something slightly esoteric (eg Haskell) and the quality of public code is very high, because you only have enthusiasts writing it. Choose something taught in schools (Python) and you are going to find 10,000 traveling salesmen homework problems and Django todo applications.
Not sure how you thread the needle on the quality vs quantity dynamic.
Your point is a good one: Exotic, difficult languages attract enthusiasts with deeper skills than a median developer.
Haskell also has a confounding issue: Because of its focus on research and experimentation, standard best practices don't exist like they do in languages optimized for real-world use. Because there are few community guidelines, engineering practices vary widely, and unfortunately at the same time, Haskell's public codebase resources are small.
To see this playing out, check out Haskell discussions about choosing a SQL library, effect system, monad transformer stack, or web framework. The answers are all over the map because that diversity is baked into Haskell's culture and practice.
Was going to ask what is the Numpy equivalent in Haskell. Cause Python has a thousand decent examples of how to do everything you might want to do in Numpy.
There is definitely a relationship. But I personally believe that once the training corpus reaches a certain scale, the returns exhibit diminishing marginal effects, to the point that multiplying the data volume cannot surpass something essential inherent in language design. (Asked an LLM to help me with the translation, so forgive my expression)
there is a relationship there, but there is also a relationship to the safety of the language and the guard rails in place.
it's a lot harder to experience an agent telling you with certainty that something incomplete is totally finished if there is a comprehensive test suite, a hard failing compiler, a strict type system, etc.
LLMs like to produce a lot of JS and python that silently fails in a graceful way -- why is that? because those languages support that kind of a failure.
when using something like go/rust the LLMs are more likely to re-iterate rather than declaring a victory when they get a strict compiler barking in their face, refusing to output.
Honestly, after ~13y in this, I only know a handful of items from the famous latency table, notably those I've used a lot (mutexes cost 25ns, is only 1/4th of main memory reference tho, then disk seek is x100K of that). I'm "DevOps" (and titular variants thereof) in most of my resume.
That said, I'm not above your bar as each cloud provider have their own pricing model. I'm not even above your bar for AWS---which I've used the past six years---just for the sheer diversity of their offerings, not to mention regional variations. I know how EC2 servers are priced relative to each other but when we include ECS, DynamoDB, Lambda, etc., I'm gonna need a cheat sheet.
It's not clear to me from the article how Mantle was porting the build scripts, infrastructure config files, etc across languages. Typically these files don't cleanly translate from one framework to another. Was this considered as part of 20% of project for human engineering effort?
No. Designing a system that is always up and running and can process small amounts of data constantly is a completely different problem from designing a system that runs occasionally with a lot of data. For one thing, your output formats are usually different in the latter case (maybe you're creating a PDF for example). Also the high availability requirement just makes things different at the design level.
Finally, the author claims it's not hard to switch between batch and streaming. With a large volume of preexisting data, this is just not true. For example, if you make a REST API call for each document in a DB, it can take days or months to load that. If batching together documents isn't a possibility, how do you move data between stores easily? (This data movement is often required when switching between batch and streaming.)
I'm seconding this, and I have first hand experience in exactly this problem, in finance. My first boss also had the view that "batching is a special case of streaming where you stream N and streaming is also a special case of batching where the batch size is 1 and so it doesn't matter which one you implement". This was never performant enough and he was eventually asked to leave.
The key is working incrementally, not sitting idle for months and then hammering production as hard as possible trying to get all the deferred work done in exactly one batch.
It's certainly true that LinkedIn is the go to for white collar professionals seeking to make their resumes visible passively to recruiters. But isn't life still easier with LinkedIn than in the before times, when recruiters would dig deep to get folks' phone numbers and then have to call each of those people individually? (I think the modern equivalent would be email addresses.)
It's true that LinkedIn makes recruiting much easier to scale to a mass market. And it's also true that it has a monopoly on that scaling for professional employees. But is it fair to call them an economic termite when it's still possible to do sourcing in an admittedly clunky and old fashioned way? Just because they have a monopoly on scaled recruiting doesn't mean that they hold all the cards the way Linde (also in the profile) would in the gas market. This is particularly borne out by the existence of Indeed or Stack Overflow as options for posting your resume for recruiting.
Maybe it is, maybe it isn't. It's not the point. Lawyers tend to puff their smokescreens, convincing people antitrust agenda is difficult. It isn't. Once you start eating a certain amount of the pie, the rules of the game change for you, and you only, because you become too strong, causing imbalance and threatening stability.
I'm sure LinkedIn's legal department employs an army of antitrust specialists frequently dealing with accusations from their competitors. That's a good thing.
There's one position you never wanna be in: When you don't have a choice, and it doesn't matter whether you're a company or an individual. Autodesk is one prime example of a long-term nasty sales behavior significantly distorting the market. Last but not least, democratic governments around the globe have been failing to enforce these laws, not to mention these are in many cases too permissive in the first place.
I wouldn't use Stack Overflow as an example of the market not being viable. 2022 SO had a horrible reputation problem, and their main value proposition (that is, qualifying the candidates) used a metric that was completely broken and probably counterproductive in practice (but we can't know that one for sure).
Is there someone on HN who can speak to how fast gene editing technology is improving? I was a bit skeptical of the author's claim that construction of a mammoth genome would require 5000 years, but I couldn't find any information in a cursory search on what the technology improvement speed is.
Well it used to take ~infinity years as the technique didn’t exist to do it at all.
Claims like “it’ll take 5000 years” are always funny because they’re so incredibly status quo biased, without the least bit of self consciousness of how remarkable the progress has been in the last 50 years on things like this.
Humans overestimate progress in the near term and underestimate progress in the long term.
Had a lot of spammers with Russian language. Implemented expanding xml-bombs, Google Captcha, hidden input fields and a couple of other things against bots.
But the block on the russian language was most effective ( and since I was dogfooding it, I didn't see the harm at the time. But it's out of scope at this very moment, yes).
