> I wonder what's the responsibility of various factors behind their success. Is it mainly the people? Strategic location? Great governance and policies?
It's mainly its strategic location and it's always been the the busiest maritime route chokepoint since recorded history between east and west, specifically between India and China two of the most populous nations in the world.
It sit right at the tip of the Strait of Malacca, the busiest and the longest strait in the world. This one famous quote by a 16th CE Portuguese explorer Tomé Pires, who declared: "Whoever is lord of Malacca has his hand on the throat of Venice".
Secondly is the people, and the third is the governance policy. Essentially, you must have be a bone-headed to screw up Singapore, like the one who can bankrupt a central bank.
My original top most comment on the great lie of Singapore was just an obscure fishing village during the early colonial time but it's has already downvoted to oblivion, you can check them out if you want.
The reason for your last point is that Singaporeans are taught in school that we were nothing but a fishing village until first colonialism (and Chinese immigrants) arrived and turned us into a major port, then the PAP (Lee Kuan Yew's party) turned us into a first world nation. It's really propaganda, and of course you wouldn't bother looking up information that you were taught to see as truth when you were a young child
Many post-colonial societies (Arabs, Indians, etc.) puff up their supposed past wealth and success, but that’s the real propaganda. Even when these countries were on important trade routes or whatever, the per-capita GDP of these places never went much above the subsistence level. High estimates of the per-capita GDP of the Roman Empire have it at around half of modern India. These societies were very poor in pre-colonial times.
> Essentially, you must have be a bone-headed to screw up Singapore
The place that is now Singapore had less than 1,000 people when Raffles got there. So what happened?
There’s lots of places with strategic locations or natural resources or such advantages. The U.S. has the largest contiguous stretch of fertile land connected to one of the largest navigable river systems in the world. But the north american indians did essentially nothing with it. It’s not easy to make a modern civilization out of even a favorable geographical situation.
Need to check the veracity of this 1000 population claim by the master colonial no less.
The British took over Malaya from Dutch with minimum effort, by exchanging some of their Indonesia colonies after an agreement with another colonial power. Fun facts, that's how Batam Islands got under Indonesia.
The first thing they did was to create Strait Settlements with strategic and rich Malayan States including Penang, Malacca and Singapore, definitely any of these was not an obscure fishing village [1]. These are the major trading ports for Asian major empires including Langkasuka, Srivijaya, Majapahit, Chola, Malaccan Sultanate, etc.
>Stamford Raffles stands – according to the plaque attached to the plinth – on the ‘historic site’ where he first landed as an agent of the British East India Company on 28 January 1819 and, thereafter, ‘with genius and perception changed the destiny of Singapore from an obscure fishing village to a great seaport and modern metropolis’.
This is one of the greatest lies ever told, that Singapore was an obscure fishing village when the colonial powers came to "modernise" Singapore.
Read the history books, Singapore is bang in the middle of ancient super powers of India and China. It's has been and always has been for most of its history a successful entreport for several thousand years before the colonials first visited, and the later Chinese immigrants settled in Singapore.
The founder of Malacca, where the Strait of Malacca name originated from, was himself a prince from Singapore and at the time better known as Temasek.
The people who originally settled in the Malay Archipelago several thousands years ago were successful maritime explorers. Their descendents discovered and migrated to wider Austronesia including Madagascar to the west, and New Zealand and Hawaii to the east several thousand years before the colonial powers "re-discover" these places. They also who speak their ancestors derivatives languages until now, that at one time US government tried to ban.
That’s a different kind of misleading narrative, the “$PLACE was rich in pre-modern times” narrative. Places decline. Heck, by the middle ages, Rome’s population had dropped to just 30,000.
I can assure you Ptolemy never been to India let alone Singapore.
But hey you just deleted your Ptolemy narrative, are you misleading a narrative?
Ironically although Ptolemy never been to Singapore it's apparently recorded in his book as Sabana [1]. Perhaps that the reason you deleted your Ptolemy entry.
It's also recorded in ancient Chinese record in the 3rd CE Chinese traveller's record describing an island at the same location called Pú Luó Zhōng a transcription of Singapore's early Malay name Pulau Ujong, literally meaning Tip End Island because it's located at the southern most tip of Malaysian Peninsular.
The famous Indian Emperor Chola also said to briefly conquer Singapore/Temasek in the 11th CE [1].
Singapore by any definition for the past two thousands years was not an obscure fishing village. It's always has been a bustling metropolitan with international entreport status. Anyone who said otherwise is lying through their teeth and pushing their own wicked narrative.
I edited because I realized Rome was a much easier example. But at least according to Wikipedia, chittagong was one of the major seaports of the ancient world and appeared on Ptolemy’s world map: https://en.wikipedia.org/wiki/History_of_Chittagong. The map was based on Greek knowledge of Asia through trade. But Ptolemy also described the Malay peninsula.
As to your other point, again, you’re overlooking that places change over time. The Arabs built a huge civilization a thousand years ago. But by the 19th century, there wasn’t much left.
>As to your other point, again, you’re overlooking that places change over time
Not much change for Singapore, I know this because I learnt my history and geography properly, I hope you too.
Strait of Malacca has always been the busiest maritime trade route in the world continously since recorded history even until now, and at the heart of it is Singapore Strait where Singapore or Temasek is located.
Even until now most of the world's trade are performed via maritime route even with advent of aircraft, and guess what most of these trades when through Malacca and Singapore Straits. Maritime industry called these Straits the world's busiest trading choke-point. I'm not even exxagerating to say that Strait of Hormuz is nothing compared to this chokepoint, especially in the ancient time.
On top of that, more than quarter of the world's population since recorded history are living in China and India, and in between these two most populous nations are connected via maritime sea route through Straits of Malacca and Singapore.
In the old days, or most of our maritime trading history for thousand of years, we do not have engine for ships neither steam nor fuel, only for very short period recently starting from late 19th CE [1].
During most of our maritime history we use sails. People or sailors travelling between India and China, and returning back rely entirely on wind power that are based on alternate monsoon seasons. This where we got the famous saying of "time and tide wait for no man".
For one season (half a year) they used for travelling westward and another half season they travelling eastward. Either way, ancient sailors from Europe/India/China/Arab/Japan they need to stop over somewhere (read Malay Peninsular or Singapore/Temasek) while waiting for monsoon to change before returning back home. Since Singapore/Temasek at the end of this Peninsular, it's the most natural transit point for these ancient/modern sailors. Whenever you fly over Singapore take a look down to see these multitude of these ships. Although now in theory they don't need to stop for monsoon due to fuel, but realistically the ships still need for refuel/rest/transit/etc.
By the time the Europeans arrived Singapore had long since declined:
> However, by the time the Portuguese arrived in the early 16th century, Singapura had already become "great ruins" according to Alfonso de Albuquerque.
How far back and how much context is required for a simple narrative to not constitute lying? And for a narrative about national origin, is it not also misleading to insinuate that successive settlements and polities constitute a singular, shared history?
And Europeans were not the first colonial powers to land on and assert control over the peninsula. In fact, the incumbent Muslim powers the Europeans encountered had colonized the peninsula only a couple of centuries beforehand. Aboriginal peoples (pre-history "colonizers") still live in Malaysia, and they're still as isolated and impoverished by the state as they were before Europeans arrived. Malaysia even has its own Plymouth Rock-like monument (on the coast somewhere near Malacca, IIRC), and it's not where Europeans first stepped ashore. And it seems a little odd to presume Singaporeans would identify with the political and social history of their Malay and aboriginal predecessors when Singapore, a majority Chinese community, was kicked out of Malaysia precisely because of racist and xenophobic sentiments of many Malays.
The racial politics of Malaysia and Singapore are at least as complicated as in the US if not more so. I count South Africa and Malaysia as the two countries where racial politics are not only as complicated, but open and explicit as in the US, and like the US the relationship between European colonizers and the "native" groups constitutes only a portion of that complexity. Many other countries have similarly diverse groups, but usually one group is unchallenged in its power and there's very little open discourse about the subject. But contemporary anti-colonial rhetoric whitewashes (figuratively and literally) all of this.
Not sure about Singapore but Malaysia's racism is not complicated. It is discrimination into law. It makes things rather clear. About discourse of course there is not discussion to have.
The most amusing part of Malaysia's discrimination is in the term "bhumiputra," which is Sanskrit for "son of the soil," but today it's used for Malay muslim.
All these lands were Dharmic originally, all the way to Japan, before the various cults arrived.
What nonsense, colonizers do not live and settle there for thousand of years. Would you called majority Japanese now a colonizers since the originally come from Korea/China and before them they were people there?
>Singapura had already become "great ruins" according to Alfonso de Albuquerque.
Albuquerque was the first European colonial who conquered Malacca in the early 16th CE, later Dutch and then British. They all came because they wanted to bypass what they considered "trading bottleneck" created by Ottoman, the most powerful maritime empire in the Mediterranean and Europe for many centuries.
The local authorities most probably very well deployed a typical scorched-earth strategy to prevent the Albuquerque to fully utilize Singapore infrastructure. The British did exactly this to most part of Singapore including totally damaging the very important causeway when the were defeated by Japanese in the mid 20th CE. Fun facts, the world busiest causeway still not return to the its original sophisticated design with elegant pass-thru water design until today, thus pollution side effect are still happening and not being solved [2].
> Would you called majority Japanese now a colonizers since the originally come from Korea/China and before them they were people there?
Depending on context, yes, especially considering that (AFAIU) there still exist identifiable (socially, not just genetically) ethnic groups on the Japanese archipelago who predate that colonization event, and who still experience forms of ostracization typical of such colonization. There'd be no cognitive dissonance for me because I refuse to internalize a definition of colonialism that tacitly presumes European exceptionalism and supremacy through a sort of reverse White Man's Burden logic of moral accountability and historical criticism.
For the same reason, I recognize that groups we (i.e. westernized, globalist, cosmopolitan, what-have-you types) typically call aboriginal in a homogenizing, undifferentiating manner were often colonizers themselves thousands of years ago, displacing other aboriginal groups that may or may not still exist today. There are multiple such groups in Southeast Asia. And the first such modern human aboriginal group may have colonized an area occupied by pre-modern, archaic humans. (Or possibly vice versa!)
Buying into the logic of modern anti-colonialism critical theory is not required to appreciate and criticize the harms European colonization inflicted and continues to inflict. But rejecting that logic might be a prerequisite to recognizing and appreciating the exact same dynamics and harms that played out and still play out today among non-European ethnic groups.
Here is a piece of history trivia. Not trying to have an argument.
> they wanted to bypass what they considered "trading bottleneck" created by Ottoman
The Ottomans didn't exactly close the Silk Road, but they made it harder and more expensive to use it.
But the major reason for the maritime routes taking over the cargo traffic was that it's much more efficient to sail to Asia with your cargo than to walk it on camels.
So when the Portugese found the way around Africa and landed in Calcutta on May 20 1498, the trade patterns changed forever.
>So when the Portugese found the way around Africa and landed in Calcutta on May 20 1498, the trade patterns changed forever.
This new route discovery actually significantly increased the importance of Strait of Malacca and Singapore, not decreasing it.
Actually even before that important turning point event, the European already knew about about the importance of Strait of Malacca including both the metropolis Malacca and Singapore/Temasek. The is one famous quote by a 16th CE Portuguese explorer Tomé Pires, who declared: "Whoever is lord of Malacca has his hand on the throat of Venice".
To say that Singapore was an obscure fishing village is disengenious by the colonial powers and those believing this wicked narrative are in denial.
My once top comment about this "elephant in the room" has been downvoted to oblivion, but hey c'est la vie. There's a very popular saying, "you can fool some people all of the time, and all people some of the time, but you simply cannot fool all of the people all of the time".
There's also a narrative that if the tea via land it's called chai and if if the via sea it's called tea [1].
The Ottoman controlled both the land and sea route to Europe creating the trading bottleneck from the European perspective for many centuries to the far East, they never close it. Thats's why both Dutch and British created their very own East India Companies about the same time around 1600 CE as the vehicles to trade in Asia once they found the new trading route around Africa to Asia. Due to their highly profitable business endeavour, their governments willingly become the side-kick colonizers for their new companies and becoming complicit to wrestle and overcome any countries that refused to their own unfair business arrangements, terms and conditions including trading monopolies.
[1] Tea if by sea, cha if by land: Why the world only has two words for tea (317 comments):
> The people who originally settled in the Malay Archipelago several thousands years ago were successful maritime explorers.
That comment upset me as a Melanesian. I'm sorry, but I need to challenge the above statement as it is factually incorrect. What you are claiming is widely spread in a politicized way in Malaysia and Indonesia, and in a similar but different context in Thailand and Phillipines. Firstly, I'm sure you know that the actual original first peoples (called as "orang asli negrito" or "sakai" (derogatory) by "Malay" settlers) are Melanesian/Negrito/Aboriginal tribes. Again, Malay settlers are not the the 'people who originally settled' as you claimed, they took the land from Melanesians. To be precise, the original people are MT Haplogroup P, MT Haplogroup M/sub-R, Y Haplogroup K/F. They have predominantly jet black skin and curly hair or straight hair in the case of some Aboriginal tribes in Australia. These are the genuine first peoples. They were in South and South East Asia, Papua and Australia first prior to the Toba eruption 70ka ago. Today, they have been mostly genocided by 'Malay' (sometimes used to cloud the term Austronesian term) settler populations. You can see this process happening even today in West Papua where 'Malay' soldiers and settlers brought over from Java, Indonesia are genociding Melanesian men in West Papua and taking over their land. The indigenous Melanesians are now a minority in their own land. There's brutal horific videos you can find online of Javanese settlers attacking and skinning a Melanesian man alive inside an oil drum. Truly barbaric stuff. It is a slow genocide but you don't hear much about it, probably because the mines of Freeport McMoran and Grassburg supply a huge chunk of the copper/gold that's key for EV and other modern technologies. That's as much time as I can spend on communicating this right now. I hope this information will help you and others correct your misunderstanding and stop spreading such disingenous claims intended to enable land grab by settlers. Thank you.
Naturally they inter-married, the first wave from out of Africa people (e.g Perak man) and the second wave from the Taiwan diaspora [1]. This as you probably know happened over many thousands of years.
The word one to ten in most Austronesian countries from Madagascar to Hawaii, spanning more than 17,000 km or 10,000 miles (about half of earth's perimeter of 40,000 km). These countries main languages including Malagasy, Malay, Indonesian, Javanese, Tagalog, Sulu, Palau (Micronesia), NZ Maori, Hawaii (Polynesia), etc are very similar. In particular, "Lima" meaning five/hand is the common and signature Malay/Austronesian world, even in Hawaii.
Based on your throw away name, most probably you're from Papua Island, you probably know that one of its original main languages, apart from the recent colonial based Tok Pisin, is the Malay Austronesian based Hiri Motu [2].
>Today, they have been mostly genocided by 'Malay' (sometimes used to cloud the term Austronesian term) settler populations.
What nonsense, as they said the proof is in the pudding. If genocide happened as you claimed most of these people are gone but they're everywhere. Please check Borneo Island for example, ruled by the Malay Brunei Kingdom for several centuries until the colonial Brooke the White Rajah came. This third largest Island in the world probably has the most diverse demographic population of indigenous peoples in the world [3].
Fun facts, as comparison the Champa Malay people were genocided by the Vietnamese warlords mainly by the Nguyen lords. They controlled majority of Vietnam for about two thousands years but now you hardly find this Champa Malay people, similar to what happened in muslim in Spain. The highly contested South Chinese Sea original name was Champa Sea [4].
>I hope this information will help you and others correct your misunderstanding and stop spreading such disingenous claims intended to enable land grab by settlers.
Since we are in the Singapore topic, by your own definition of land grab by settlers, the Chinese immigrants where the first PM LKY are from, that constitute majority of Singaporean were performing land grab by settlers because just 200 years ago majority were Malay?
Earlier you claimed 'originally settled by Malays' now you're saying Malays inter-married with the actual indigenous population. That's like saying European Americans inter-married with actual native population and therefore European Americans are now the first peoples in America. I'm unsure if it is worth discussing further with someone that would manipulate facts in this way.
I'll also ask you to google about Y-haplogroup and MT-haplogroup statistics to see how it shows the disappearance of male Melanesian contribution to the population in Phillipines, Indonesia, Malaysia, Thailand. Countries like Malaysia and Indonesia had official policies even going on today where indigenous Melanesian women were targeted to be impregnated by settler 'Malay Muslim' men. For example:
I noticed you refused to address what is happening in West Papua.
Sadly, I think our conversation can't really continue effectively since you're starting to bring in unrelated topics like Spain and then you started talking about 'land grab by Chinese immigrants in Singapore' which is unrelated to the claims you originally made. Again, I sought to correct your statement claiming 'originally settled by Malays' which I notice you've now softened to 'Malays intermarried with the actual indigenous people'. I think that's the extent of the possible communication with you.
>Earlier you claimed 'originally settled by Malays' now you're saying Malays inter-married with the actual indigenous population.
I said what you have quoted of me previously:
"The people who originally settled in the Malay Archipelago several thousands years ago were successful maritime explorers."
>you started talking about 'land grab by Chinese immigrants in Singapore' which is unrelated to the claims you originally made.
Please check your own comments regarding land grab (see below), that's why I asked you about that, I didn't mentioned about land grab earlier but you did. But since you have mentioned it yourself in the comments that's why I asked your opinion because we are in Singapore OP topic. If you do not want to answer the question that's fine with me, however personally I think it's very much relevant to the topic at hand.
>>I hope this information will help you and others correct your misunderstanding and stop spreading such disingenous claims intended to enable land grab by settlers.
> "The people who originally settled in the Malay Archipelago several thousands years ago were successful maritime explorers."
You are again attempting to claim that 'Malays' or perhaps you're trying to imply 'Austronesians' are the first people to populate Phillipines, Malaysia, Indonesia, Papua. I think it isn't possible to have a useful conversation if you are repeating that falsehood. That's the exact equivalent of claiming 'the people who who originally settled the Americas were succesful maritime explorers' in an attempt to convince everyone that Europeans and Native Americans are now the same thing.
I have to remind you again since you refuse to acknowledge the issue. What is happening in West Papua is horrific. It is what 'Malays'/Austronesians have done repeatedly (to different extents) throughout South East Asia and Oceania and the world has let it happen because Melanesian lives don't even make the front page when one of us got skinned alive by 'Malay' settlers. [1]
It's just earlier this week we have an HN front-page news on the sophisticated Rubin telescope [1].
According to its Wikipedia entry, "Rubin is expected to catalog millions of supernovae, more than five million asteroids (including ~100,000 near-Earth objects), and image approximately 17 billion stars and 20 billion galaxies." [2]
I guess this this reported meteor is the one that got away, or perhaps it's beyond its scope of monitoring the Southern sky. But even if it's monitoring the Northern hemisphere it will most probably going to miss it due to the puny size of the meteor, more like a small tent instead of a skyscrapper.
>The meteor was about five feet wide, according to the space agency, with a mass of 5.6 metric tons (that's about the weight of a large elephant.)
[1] Rubin Tracks Skyscraper-Size Asteroids and Failed Supernovas:
Honest question, in the era of vibe and AI assisted coding is there any advantages of using untyped programming languages, apart from the fact that non-typed languages has more traning data for the LLM?
This probably controversial, but personally I consider untyped languages as technical debts that need to be fixed sooner or later, and the OP article is partly addressing this very issue.
Rewriting critical software infrastructure (infostructure) to more reliable typed languages happened to most of the Ruby on Rails (RoR) software unicorn stacks for examples Twitter, Airbnb and Shopify to name a few [1],[2],[3].
The main reason provided for these migration is transitioning away from monolith architecture, but almost all of the new programming languages being used are typed thus make it obvious that the untyped languages are not performant and difficult to scale even by changing the architecture.
> Honest question, in the era of vibe and AI assisted coding is there any advantages of using untyped programming languages, apart from the fact that non-typed languages has more traning data for the LLM?
Author here.
Type systems restrict which programs can be expressed and increasing expressiveness often requires increasing type-system complexity (which, speaking from experience, both humans and agents will struggle with). Plus they are not the only mechanism to assert correctness (they only validate a subset of your program correctness and do not replace tests) and you are still on your own when it comes to actually recovering from unexpected errors (something Erlang/Elixir were designed for).
I'd say there are two flip sides to your question:
1. Given types do not replace tests, if you can use AI to automate full test coverage, are there actual benefits in static typing for coding agents? The downside of tests for humans is that we suck at writing them (but guided agents can do better) and they can take time to run (which agents do not care)
2. Do we actually have any data or evaluations that show which typing discipline is better for agents? The only benchmark I am aware of [AutoCodeBenchmark] has Elixir come first (dynamic) and C# as second (static), so it doesn't answer the question. There are other benchmarks that show dynamic languages require fewer tokens to solve problems (but that's not a metric I particularly care about)
My gut feeling is that local structure, documentation, quality and quantity in the training data, etc are likely to play a more important role than typing for coding agents. I'd also love to measure how agents perform on specific domains. If you are writing concurrent software, how does Elixir/Java/Rust/Go compare? But without data, it's hard to say.
In my experience restricting programs that can be expressed is a good thing, even more so with agentic engineering. The more guardrails there are, strong typing/TDD/computer use/..., the solution space shrinks and chance of a robust solution increases. Sure maybe this burns more tokens going in circles but it feels less like a slot machine more like a robot searching for a solution for a well-defined problem.
Devs have very strong opinions about dynamically typed programming languages. But reasons such as "exploratory programming", "expressiveness", "taste" that makes them feel good to program in for humans does not matter for agents. Agents don't care that the language "limits them" and prevents them from expressing the code in a succint way because it would not type check.
Agreed on the guardrails bit. My point is that we still don't have much evidence that static types are an effective way to constrain the search space for coding agents, or how much value they add on top of other mechanisms. Redundancy can certainly be beneficial, but how much and at what cost?
On expressiveness, people often frame it as a dynamic-language goal, but a large portion of type system research is precisely about making type systems more expressive so they can describe a wider range of programs and invariants. This is clearly something both camps value. I suppose another interesting benchmark could be: how do coding agents perform across languages with different degrees of type-system expressiveness?
We may directionally agree, but it is hard to draw conclusions without measurements. Overall, I'd say this is much more of an open question than people give it credit for.
> if you can use AI to achieve full test coverage, are there actual benefits in static typing for coding agents?
Full test coverage doesn’t tell you if the tests behave correctly. So you could prompt an AI agent to write 100% test coverage where those tests could be exercising all code paths yet contribute 0% to the story of what the code does. You need human understanding of what the desired contract is that the tests check.
Imagine a contract lawyer who blindly signs any contract that they are given: they aren’t doing their job. They ought to have an idea in mind of what their client’s goals and limits are so they can determine if a given contract fulfils those needs.
Types are a declarative contract, so they can be a lighter yet more limited way to enforce a contract. The compiler can verify if all the declared types across the program agree with each other. This is especially helpful with refactoring, such as ensuring the adding a field has been rolled out everywhere.
Types aren’t to be just checked by the compiler, but checked by the human authors too. That’s why explicit type signatures are valuable, especially if they are kept intelligible. They encode the different variations in state and possible branching on that state. So you can whittle your types down as a way of whittling the solution down to be more focused. The problem in your head is reflected in the types, and any simplifications in the types then simplify the problem in your head, and any tests derived from that understanding.
I don't think these articles fully cover (pun intended) the claims being made.
First of all, we need to separate "types" from "static type checking". Elixir always had types and types by themselves won't eliminate tests. You can combine types with type checkers, as well as tests themselves (as described in the first article), to aid software verification. Plus many of the techniques discussed in the article (property-based testing, static analysis, etc) are available to dynamically typed languages too.
Some notes on the first article:
> For example, there is no test we could write that would show that our function never throws an exception or never goes in to an infinite loop, or contains no invalid references. Only static analysis can do this.
Static analysis is doing a lot of heavy lifting here. When applied to type checking, where it can prove absence of exceptions depends entirely on how expressive the type system and checker are.
For example, this Haskell function can fail at runtime even though it type checks:
maxPosInteger :: (Ord a, Num a) => [a] -> a
maxPosInteger xs = maximum (filter (> 0) xs)
If `xs` contains no positive elements, maximum fails. The type system does not rule this out.
As the article itself later discusses, proving stronger properties requires more expressive type systems, such as dependent types. Those systems can prove the absence of additional classes of failures, but they come with their own costs in complexity, ergonomics, inference, compile times, and so on. My recent ElixirConf talk touched on these trade-offs: https://www.youtube.com/watch?v=Ay-gnCqDw9o
But overall the article does not discuss coverage. Under some of the scenarios it presents, such as finite domains, exhaustive testing guided by coverage can prove the absence of bugs too. Additionally, some of the concerns the article has about Python, such as runtime redefinition and excessive polymorphism, do not really apply to dynamic languages like Elixir and Clojure.
> Correctness oracles abound. We have test suites, fuzzers and property-based testers, runtime sanitizers, static analyzers, linters, strong type systems, and formal verifiers. Any time such a tool can be made available to the LLM, we’ll reap the benefits in terms of not dealing with bugs the hard way, later on.
I completely agree with that framing. Static type systems are valuable tools, but they're one tool among many. My overall point is that I wouldn't draw the line at static typing as the "must have" mechanism for software quality, especially in the context of AI-assisted development where multiple correctness oracles can be composed together.
>Type systems restrict which programs can be expressed and increasing expressiveness often requires increasing type-system complexity (which, speaking from experience, both humans and agents will struggle with). Plus they are not the only mechanism to assert correctness (they only validate a subset of your program correctness and do not replace tests)
This articulates a lot of my own thinking wrt type systems, speaking as a downstream user without a lot of exposure to prog language theory, and I wish this debate were more often framed in these terms.
Another reply to this comment hinted that it might be more about giving LLMs feedback loops and that to me also seems like a more likely mechanism.
I'm not an elixir user but I've watched it from a distance over the years – thank you for your efforts and your experimentation.
>Type systems restrict which programs can be expressed and increasing expressiveness often requires increasing type-system complexity (which, speaking from experience, both humans and agents will struggle with).
I used to hold similar opinion but D language, and this article by Patrick Li (HN JITX co-founder) who's the original author of little known but very powerful language Stanza changed my mind [1],[2].
He argued that Ruby has enabled a very expressive language that enabled RoR, and when it was originally written other languages are less capable, and accordingly the proof is in the pudding.
In his new language Stanza for his PhD thesis he has designed an optional typed system supporting both typed and untyped, it seems very similar in concept to the OP article that you've written on Elixir. Groovy also deserved a special mention, and the pudding is Grails.
Interestingly both Elixir and Stanza have GC, but Stanza also support non-GC namely LoStanza in which Stanza GC is written.
Interestingly, D language pioneered this combination both GC (by default) and non-GC more seamlessly, even before Stanza.
In addition to Ruby, these four languages namely Elixir, Groovy, Stanza and D all have similar to or better expressive power than Ruby. Notably both Stanza and D are compiled languages. Above all D is an anomaly in a good way since it's a fully type programming language. Kudos to Walter and the team for giving birth to a highly expressive fully typed modern language, very fast in compilation and runtime, truly one of a kind [3].
Regarding the issue of comparatively smaller corpus for these languages as mentioned by others, I think the new self-distillation technique for LLM and code generation as proposed by Apple, MIT-ETH and UCLA can overcome this limitation [4].
> Groovy also deserved a special mention, and the pudding is Grails.
I vaguely remember that when Groovy became more typed (statically typed that is. I believe you could always put the types in but they were not checked.) there was a theory that it kind of hurt possible uptake of the language.
The reason being is that people felt well if we are adding types and a project is requiring it why don't we just use: Java, Scala, Kotlin etc. Like did Java getting more features or Kotlin coming really hurt Groovy or just that it became more of a typed language.
An analog (typed language stealing users) could happen to Elixer but I'm not really sure which language it would be.
> I think the new self-distillation technique for LLM and code generation as proposed by Apple
Speaking of Apple and eventual typing Dylan was an amazing language that just never got traction. Open Dylan still exists but few know about it. Its eventual typing is unique because Dylan does CLOS-like multimethod dispatch instead of pattern matching.
> Groovy also deserved a special mention, and the pudding is Grails.
Not sure it is much of a success. Groovy gets unreadable very fast, and the editor won’t help you. Gradle moved to Kotlin, and it’s 10x better in readability and maintainability.
> 2. Do we actually have any data or evaluations that show which typing discipline is better for agents? The only benchmark I am aware of [AutoCodeBenchmark] has Elixir come first (dynamic) and C# as second (static), so it doesn't answer the question. There are other benchmarks that show dynamic languages require fewer tokens to solve problems (but that's not a metric I particularly care about)
I am actually writing a paper on this right now so nothing I can point you to yet but yes. LLMs are better (produce working code in fewer attempts controlling for the relative size of training corpus) when using type systems with inference and global unification. It is largely about the quality of the error feedback channel so languages with very good compiler errors (accurate, localized, include the correction with the failure) can close a lot of ground.
But inference + sound type system gives you a constraint propagation that genuinely restricts the ability of the LLM to get into trouble. Type systems that require annotation give up most of the benefit, since the annotations are themselves surface area for LLM mistakes. Unification also puts heavy limits on the expressiveness of the language which is a confounder and may actually be a big part of the benefit too.
Everyone has been on the "the training data is better" thing but I actually don't think so. All of the languages that people report as being better because of good training data actually have fairly restrictive type systems. Elixir is an exception, but it has exceptionally good error messages! And also, along with erlang, pretty unique runtime semantics that may contribute but that's outside my domain I'm on type systems. Debunking the training quality thing is not what I'm working on but I have deep suspicions about that common wisdom.
That’s very exciting! Is there anywhere I could follow you for updates? If you don’t want to share it publicly, and is ok with sharing it privately, my email is my username on gmail. Thank you!!
One thing something like AutoCodeBenchmark cannot demonstrate is what happens when you have human-written type definitions defining the domain before the LLM writes a line of code.
That is something I have found very effective in F#, that I model the domain with types, I know what the type signatures of the functions I need are, and the LLM does the work of actually implementing those functions.
Here is a concrete example:
I have been playing around with a program to assist me with projects I make at home on my hobby-grade CNC router, which does not have an automatic toolchanger. I use a mix of Vectric VCarve and some older handwritten programs to generate GCode files. I end up with a USB drive with maybe 6 to 12 GCode files on it and a model in my head of "to make this product, I start with a board here, gotta install this square nose end mill and zero on this corner of the board, run files A and B. Then install a ball nose end mill and run file C. Then flip the board over lengthwise, switch to a smaller square nose end mill, zero here, run file D. etc. etc."
Although I try to name the GCode files in a self documenting way like 01_TopSide_25square.ngc, if I come back in 1 year and want to make the same thing again, I pretty much always have to open VCarve and eyeball what the hell all the files did and confirm where to zero, what size board to use, etc. So I'm making a tool where I can define those human-operator steps that go with the G-Code files, save it as a "project file", preview in 3d what each step will look like, and export to a printable PDF with screenshots and step-by-step instructions. Hopefully this will reduce the amount of rot that these projects suffer and the cognitive overhead of picking up an old one.
Modeling the steps as F# types was the very first step, like (small excerpt):
type WorkpiecePlacement =
{ Id : WorkpieceId
/// Corner of the workpiece we'll attach to the machine.
WorkpieceCorner : WorkpieceSpace.Corner3D
/// Point in machine-space we'll anchor this corner to.
MachinePoint : MachineSpace.Point
/// Which face of the workpiece is on top.
FaceUp : WorkpieceSpace.Face
/// Rotation around the up-axis.
Yaw : WorkpieceSpace.Yaw
}
type OperationType =
| PlaceWorkpiece of placement : Operation.WorkpiecePlacement
| InstallTool of id : ToolId * slot : int option
| ZeroAt of point : MachineSpace.Point
| RunGCode of source : GCode.Source
| RemoveWorkpiece of id : WorkpieceId
For the GCode simulator I needed a parser for GCode files, which produces a type with 1:1 equivalence to the GCode instruction set:
type GCodeInstruction =
// --- Motion ---
| G0_RapidMove of axisMoves : (Axis * float<gcodeunit>) array
| G1_Move of feedRate : float<gcodeunit/minute> option * axisMoves : (Axis * float<gcodeunit>) array
| G2_ClockwiseArc of ArcParams
| G3_CounterClockwiseArc of ArcParams
| G4_Dwell of seconds : double
// --- Plane selection ---
| G17_SelectXYPlane
| G18_SelectXZPlane
| G19_SelectYZPlane
// --- Unit selection ---
| G20_Inches
| G21_Millimeters
// --- Distance mode ---
| G90_AbsoluteDistance
| G91_RelativeDistance
// ... etc truncated, more instructions in real code
But my tool supports doing transforms on toolpaths, like rotating 90 degrees or offsetting so I can easily define that I want to make tiling copies of the same project.
To implement those transforms straight up as GCodeInstruction[] -> GCodeInstruction[] is a bad call. GCode is very stateful and lets you switch units, relative vs. absolute coordinate spaces, etc. in instructions. That makes the transform awkward and tricky to write.
So I have a ToolPath type that makes the transforms clean. It normalizes the many ways of expressing the same toolpath in GCode to a single representation with all absolute coordinates in metric units.
type ToolPathInstruction =
| Rapid of From : Point * To : Point
| Linear of From : Point * To : Point * Feed : FeedRate
| Arc of
From : Point *
To : Point *
Center : Point *
Plane : Plane *
Direction : ArcDirection *
Feed : FeedRate
| ... etc truncated
That is the appropriate level for the transforms like offset, rotate, scale, etc. to operate on.
Yet there is still ANOTHER level of toolpath-related operations that deserves its own type. When I'm doing simulation of material removal to check for crashes, or rendering the toolpath in 3d, I don't want to deal with arcs! The rendering/simulation is inherently an approximation. It will break down each arc into line segments. So sim code and rendering code shouldn't take a toolpath, it should take basically a line segment list, or in other words...
type ApproxMove =
{ From : Vector3
To : Vector3
FeedRate : double<m/minute>
IsRapid : bool
}
type ToolPathApproximation =
{ StartPosition : Vector3
Moves : ApproxMove[]
}
Having defined all these types it's clear that I need operations like:
And so on. An LLM is absolutely awesome at one-shotting the implementations.
I would find it quite frustrating trying to model the same domain without any types, either having all methods working on a single toolpathy data structure that's not really the right fit for any of the places it's used, or having them work on multiple data structures without any clear delineation of which layer is expecting which toolpathy-thing that are all subtly but importantly different.
I’ve been using Ruby and Elixir for over a decade. Pre-AI I used them for aesthetic reasons. The code was beautiful, and I disliked dealing with types.
People without experience in dynamic languages tend to overestimate the number of bugs their type system is saving them from. It’s pretty rare that I run into a bug in production that a type system would have caught.
They also overstate how much types help their AI agents write code. I haven’t seen AI write a type related bug in years at this point.
I work with typescript on the front end, and my experience is totally different there. AI is constantly introducing type errors, but only because the original type wasn’t declared properly. Agents waste a ton of time and tokens appeasing typescript. Ruby and Elixir are very token efficient in comparison.
That said, now that I am not writing code by hand anymore, I am considering switching to something like Go. Mainly so I can run my side projects on smaller machines
> It’s pretty rare that I run into a bug in production that a type system would have caught.
Well yes, surely because you’re not designing your system around the type system. You need to architect your project to lean heavily on types, pattern matching, etc to actually gain the benefits. If you move a JS project to TS and just rename the files, yeah there’s going to be no difference, you must reengineer the entire codebase to leverage the type system.
Personally, after moving to TS I’ve been completely sold on types and am currently planning to migrate my app to F# so I can gain even more benefit.
> It’s pretty rare that I run into a bug in production that a type system would have caught.
Wow, how different our experiences are. In Javascript/Typescript land, so so many bugs are null/undefined-related and really should have been caught at type level.
In fact, I'd say (without actually measuring it) that _most_ bugs I've ran into in Typescript are due to someone having bypassed the typing (casting, ts-ignore...), or a type mismatch at IO boundary.
Anecdotally, it is very much different in Elixir land. I occasionally see bugs related to something being unexpectedly `nil` but it's pretty rare IME.
I'd love to evidence what I'm saying with specific numbers since this kind of discussion would benefit from being as objective as possible. Sadly I don't have them. But I still believe what I'm saying and I have a few guesses about some of the causes:
1. Immutable data - so, so many bugs are caused by data mutating out from under you in subtle ways. If you write `x = 1` in your Elixir function, nothing can change the value of `x` except an explicit rebinding. You can then write e.g. `y = f(x)` and know `x` remains unchanged after. Note: this is also true even if the variable is a composite type. `my_struct = blah()` will remain the same in it's entirety no matter what you do with `my_struct`. This is different than in JS where e.g. you can change the contents of an object even if it's declared `const`.
2. Assertive style - the Elixir community favors writing things in an "assertive" fashion [1]. Briefly, this a way of writing code that will fail the moment an assumption is broken rather than letting the issue propagate.
3. Pattern matching (somewhat like destructuring in JS) - Elixir code actually ends up feeling "typed" with pattern matching. E.g. `%Time{} = today = Date.utc_today()` will attempt to bind `today` to the result of `Date.utc_today()` and will raise a `MatchError` when the result, a `%Date{}` struct, fails to be a `%Time{}` struct. Or `[a, b] = [1, 2, 3]` will raise a `MatchError` because `[1, 2, 3]` isn't a list of length exactly 2. You can use pattern matching to write very assertive code quite tersely.
These reasons are all local properties of code. But when all its parts are written in this way, a program as a whole gains a level of correctness that's hard to achieve in a dynamically typed language without them.
Also these reasons aren't exhaustive, but they're top of mind when thinking about this topic.
Not all dynamically typed systems are equal. Just like not all statically typed systems are equal. Python and Javascript are a mess. But languages like Elixir aren't just Java without types.
javascript is like… unusually messy and weird, so maybe that colours most people's perspective. you don't have to worry about type coercion and weird kinds of equality and so on in python and ruby to anywhere near the same extent.
I tried doing my side projects in Go and one thing I miss is the rails console which is so helpful. I guess I could have it write a go console or something but it’s not quite the same
C is among the most token efficient languages out there and is statically typed.
Typescript is very verbose thus it cannot compete with much denser languages on token efficiency.
By the way, the biggest reason many love statically typed languages, especially those that are quite expressive like TypeScript is for the domain and data modelling. Makes it easier to reason about the program and to refactor.
This framing is misleading. I'm not sure what AI has to do with any of the examples you cited. All of the examples you cited are moves - and in some cases, not even moves, as Shopify is not ditching Ruby - to more performant runtimes and architectures in response to operational concerns at scale, which have a tenuous link to language, and no link to AI that I can see, as these companies all significantly predate LLMs.
Ruby's runtime in the early 2000's compared poorly against the JVM or the BEAM. People used Ruby then and now because it worked well to get products to market quickly. Even after a ton of investment in Ruby's implementation, the JVM and the BEAM are still better able to handle the types of high-traffic, high-concurrency workloads those companies serve, which makes them relevant to mature, high-scale companies.
Tellingly, there are dynamic language implementations that are performance-competitive with static language implementations, like Javascript's V8/Bun/Deno, Lua's LuaJIT, and Common Lisp's SBCL (among others, this is not an exclusive list).
> to more performant runtimes and architectures in response to operational concerns at scale, which have a tenuous link to language
The runtime performance and the language are deeply linked. None of the dynamically typed runtimes you mention are actually performance competitive with JVM languages.
They absolutely are. Maybe not if the only thing you’re benchmarking is something completely CPU bound like signal processing/math, but they’re definitely competitive for tons of real use cases.
Not necessarily. Since the word "typed" language is not well-defined.
For example, typescript is a fantastic language for marshalling data and UI state since it uses substructural typing instead of nominal typing. Libraries like kysely / other ORM libraries are great examples too and easy to use, whereas in fully typed languages like Rust you would end up having to use a macro library like sqlx or having to define structs for each of your types (which would increase compile time & size)
> Not necessarily. Since the word "typed" language is not well-defined.
This depends entirely on context. In the Benjamin C. Pierce school of thought (a common choice in programming langauges research; see his book Types and Programming Languages, 2002), "typed" means what we typically call statically typed, i.e., the language employs a static analysis to prevent the compilation/execution of (some subset of) faulty programs. Meanwhile, languages that are commonly called "dynamically typed" are, in this school of thought, not typed (or "untyped"). (TAPL provides a more rigorous definition, but it's in the other room and I am lazy.)
As I understand it TypeScript does not enforce types at runtime. Am I correct? If so that would signify to me it is not a "typed language", like say Java for instance. Types in TypeScript are more like "annotations" for docujmenting the program. Am I correct?
I have never worked in Java. But you can certainly ship TypeScript code that does not pass typecheck and it'll run fine in the browser because the browser runs Javascript, not typescript. Obviously a decent build process will prevent code that fails typecheck from shipping, but that's not a language feature.
For runtime types I've leaned on Zod or Effect schema,which can also generate static types for you.
its more than annotations, your code fails to compile when you get a type error at least with strict settings. if it type checks and fails at runtime that means youre missing input validation or using bad declarations for third party/legacy untyped code. or using some escape hatch like `myValue as unknown as MyType` in the wrong way.
> is there any advantages of using untyped programming language
without any evidence, i claim the corpus might have higher quality variable names and conventions that are "human crutches" around not having types.
LLM knowledge in your non public codebase must be strictly local, and so checking on details and identities of types incurs a cost for the LLM to go fetch that info. if the LLM can "just know" (guess with very high confidence) then thats better for the LLM.
> non-typed languages has more traning data
as per anthropic "poisoning llms with 250 examples" finding, i suspect that corpus size does not really matter that much for any language that is reasonably well used.
Rather than having the LLM and human devs all guessing from verbose variable names, can't they both use a language server that observes the code and can surface that kind of structure info cheaply?
Part of the point of types is enforcing more of the contract at various code boundaries (function, module, etc), and that enforcement is specifically so that you don't have to keep the whole codebase in your head / context window in order to be able to work on it.
I've used untyped languages extensively, and even built my own, and the errors I get at runtime are almost never type-based, and that's even more true now that LLMs can pump out code. For all the additional ceremony types add, I can't say I've personally realized their benefit.
> the errors I get at runtime are almost never type-based
That surprises me, but everyone's experiences are different. I've been in the statically typed language space for so long and enjoyed it so much, I find it pretty irritating to go back to Python (my long-ago favorite) but many people are in the exact opposite frame of mind. I'm curious: what kinds of errors do you classify as a type-based error? I think that varies from person to person.
For example, null references. A C programmer would say dereferencing a null is not a type-based error, because it's not feasible to encode non-nullable pointers in the C type system. A Haskell programmer would say it is a type-based error because Haskell makes it difficult not to encode this in the type system, you really have to go out of your way to create a runtime null dereference error.
A C# or TypeScript programmer could answer differently depending on who you ask, because both of those languages make it possible to leverage the typechecker to prevent null-deref at compile time, but neither one makes it required (you can turn those checks off or make them warnings if you like), so it depends on the programmer's build settings and how much typechecking they personally have chosen to use.
> I find it pretty irritating to go back to Python (my long-ago favorite) but many people are in the exact opposite frame of mind.
As someone who works exclusively in typed languages for formal methods, what is it you find lacking about modern Python + PyLance? IMO there's still a tiny verbosity issue, and there's no real replacement for fancier polymorphism or (G)ADTs, but I'm very satisfied with it for most things. In particular, null checks are trivial.
It has been about 10 years since Python was a daily driver for me and at that time I wrote it the old fashioned way with no type hints and no static checking, just like grandma used to make. The times I have needed to dig back into it have involved working on old code, so I haven't kept up with modern tooling.
However, in principle any dynamically typed language can be tolerable to me if it can be turned into a statically typed language ;)
But I think I'd still prefer the ergonomics of a language designed that way from the start vs having bolt-ons. My favorite language for the past several years has been F# and I think ML-family languages in general strike a great balance of being able to write terse code when you want to, and being able to model a domain really well with types when you want to.
This reminds me of the analogy of the smoking grandpa. I had a grandpa that was chainsmoking his whole life and managed to reach 90 and died of other causes. This does not mean smoking is "relatively safe".
This analogy is absolutely absurd and inappropriate on multiple levels. It reflects a parochial mindset that can't fathom contexts where dynamic type systems can be advantageous, such as a breadth of data processing applications. My favorite irony is how dynamic languages excel at concise translation between opposing type systems -- a very common data processing scenario.
I've been working with typescript for the past ten or so years.
A couple of years ago I did some contract work for a client who used Javascript.
I did some basic smoke testing to understand the state of the app and I was able to get lots of fun type errors on the server and client at runtime just by QAing the damn thing.
I've definitely found LLM code to be syntactically/semantically correct in one-shot pretty much all the time. It's usually the functional specification/behaviour that's found wanting.
Typing probably makes sense where memory-correctness needs to be enforced (e.g. Rust), and inferring those semantics require a much wider context. But memory-correctness isn't really something that afflicts BEAM languages.
I thought a big part of the reason for type systems was a sort of self documentation/contract? Especially if you need to work on an unfamiliar system with bad documentation. Also what about system boundaries? I prefer typed languages personally.
The benefit is not only about "documenting the contracts" but documenting the contracts in a way that we can trust those contracts can not be violated when the program is running.
That is a very good thing to help us reason about the program, we have invariants we know must hold true if the program does not stop in a type-error.
when i was programming elixir by hand i was making typing errors about 1 every half year or so. none took production down, most were caught and corrected quickly from logs. now im doing mostly llm elixir, almost all typing errors are caught in integration tests and only one has made it to prod.
I don’t understand this question at all. Types are there to prevent human programmers from making a certain class of mistakes. But is the same true for AI. Because if not, static types are just needless cruft.
Types always have to be checked. Either at compile time or at runtime. And if you're weakly typed you still check them to see if you use normal or backup behaviour.
If you're statically typed you can remove the actual check from the binary. They are therefore also a performance thing.
Honestly, I think you're framing this incorrectly. Twitter, Airbnd and Shopify all managed to get massive using Ruby on Rails. Maybe that was part of the reason why? I.e. they were able to move fast and developers were happy.
I don't use Rails, so don't have any skin in the game. But who cares if you have to do a re-write once you get to that size?
Having been at a several places that have gone from framework-makes-us-fast to too-massive-for-the-framework, engineering velocity works as a function of how much mental context is needed and how many people/teams have to collaborate.
As orgs grow, the only way to maintain velocity is to reduce mental context. Humans have to reason about their systems.
In the half a dozen engineering orgs I have worked, each and every one became a quagmire of slow eng velocity and saw increased velocity and less bugs as they reduced context needed by teams. Separation of concerns, allowing individual services that run independently, more and better tests and observability, and, yes, better typing.
Lots buy into the view "the old system got us here and now we can afford to rewrite and do things 'right'." The real cost is, literally, moths to years of dev efforts to unwind tangled concerns. Million to tens of millions in developer salaries that are going towards keeping the ship afloat as the hull is changed out. The opportunity cost is truly mind blowing.
To avoid that cost: keep concerns separate, define data domains, and use a language that allows you to keep logic localized. If you have to jump files to understand your incoming parameters, you're gonna have a bad time when things no longer fit in your head, and esp. when new to the code as a new hire.
Elixir, I still had to know my whole call chain to know what I could do with my incoming parameters. The more call sites, the more mental context. I choose static types because I can KNOW what my function is receiving locally: it is the type signature.
I would like to validate my experience against other static typed languages like c#; so far, I have seen wins at every org that switched from dynamic languages to Go. Go seems to get a lot right for helping eng orgs move faster.
There is almost nobody in startup world that will put the failure of a product/startup to choosing a dynamic language. Probably there are some exceptions where it matters but very few to count and in those cases yes use the most performant strongly typed, with string tools for static analysis and performance optimisations.
The real truth is that language preference (typed or dynamic) are more of a fashion choice in most companies where I was present than a pure technical consideration.
if you build your product by accumulating technical debt without any focus and effort toward simplicity and trying to make it do anything then the solution after many years is rewriting. But if you have the same culture and keep the same customers you will be in the sample place where you have started but now having different category of problems (eg network latency vs N+1s).
Maybe this is the "way of the startup" but lets not pretend that types can fix culture, engineering practices or product vision and good customer management.
Sure, but it stops being that with multiple teams stepping in the same codebase as business needs expand. You revisit an area of code to find Sam in the billing department (who you don't know) interjected something or other and now there can be assumptions about the shape of data that were different than before. For us, it was data report shapes.
Elixir is amazing when the system fits in your head.
> Rewriting critical software infrastructure (infostructure) to more reliable typed languages
Instagram (and Threads) is still using Django, which is even slower than Rails. Once you get to unicorn scale, your app is going to bespoke, with some microservices, and super custom stuff. If you can go faster in a gradually typed language, that can be a very good reason to choose one.
> untyped languages are not performant
Typing generally slows down languages, not speed them up because of all the additional checks that must be done. The dynamic stuff is part of what slows down languages like Python and makes them tricky to optimize.
> Typing generally slows down languages, not speed them up because of all the additional checks that must be done.
Source? You seem to be talking about compile-time versus runtime, and I've not even heard of compile times being significantly slowed by type checking.
> The dynamic stuff is part of what slows down languages like Python and makes them tricky to optimize.
That seems to harm rather than help your previous claim. In untyped languages, in principle every object has to be treated as dynamic.
> You seem to be talking about compile-time versus runtime
Yes 100%! I was talking runtime in reference to Ruby and later Python.
> That seems to harm rather than help your previous claim. In untyped languages, in principle every object has to be treated as dynamic.
It is rather confusing and even counterintuitive, but being dynamic does not mean a language must also be untyped. For example, Python is both strongly typed and dynamically typed at once. [1] It's objects have a definitive type, but you can swap out objects of any type out at any time (a=1 ... a="foo") using the same variable. That makes optimization rather tricky as you can imagine.
The thesis that you're making is biased. Huge tech corps can move away from Rails, but it's similar to argument of "why the most successful people in the world don't drive Toyotas". Which is true, but it doesn't mean people should stop using Toyotas and buy
Koenigsegg instead.
Typed languages have consequences. Some designs are either non-ergonomic or impossible. Rust: if you want to have a swappable adapter you're in Box<dyn> world. Many apps don't have to live in Box<dyn> at all but they need to test which is the sole reason to change architecture and wrap in boilerplate.
None of these reasons matter if you're multimillion tech corporation with unlimited resources.
But these are very important reasons to consider when you have small-medium sized team and cannot afford to fight language.
I use rails because it makes thousands of good choices that I never have to make. If build apps the rails way I don't have to deal with a mountain of tech debt (in the form bad or ever changing choices).
I think most people that dismiss BEAM right off the bat either don’t understand the built-in beam process/supervisor/etc. model with its inherent fault tolerance, etc, or assume its not useful because it doesn’t address their use cases.
That or it’s a evangelist from the church of AI speaking based on faith rather than reason.
>The Only Programming Language Built on Mathematics, Not Fashion
As a modern array language D4M is the natural successor for SQL [1].
D4M is based on mathematics like SQL, specifically associative array algebra but not relational unlike SQL. It's more generic since can it caters to most modern data abstractions including spreadsheets, database tables, matrices, and graphs [2].
You can achieve 100M database inserts per second with D4M and Accumulo more than a decade ago back in 2014 [3].
[1] D4M: Dynamic Distributed Dimensional Data Model:
Applying the Lindy effect [1]: after half a century of SQL we can expect it to survive for at least as long.
Disruption/displacement of SQL is like attempting to replace email. It's not going to happen. At best an alternative technology can carve out a small niche (and there's nothing wrong with that).
That wikipedia article was super interesting, I'd never heard of the Lindy Effect before. A bit difficult to wrap my noggin around but really fascinating to think about.
Read the books of Nassim Taleb. They are full of this kind of interesting stuff. Sadly, he blocked me on twitter back when I asked him why he had a paid subscription for a self-described communist hardcore-Putinist hardcore-Antisemite :/
The power of SQL is not because it is "based on mathematics" - it's because anyone (really, anyone, even with the most basic English skills) could understand it quickly enough to start using it productively with not much technical knowledge. Business analytics, managers of all sorts, manual QA people could grasp the basics in a minute and more complex queries within a few hours. It is very user-friendly and such tools win over anything else. Each time I see an overengineerd/overcomplicated solution that is hard to read/understand - I know it's only "good luck" to the creators.
The rest of the paragraph explanations are more important.
"The goal to make longer unattended sessions safe enough to be useful without fully removing the human from the loop. It should also reduce the number of low-quality PRs your teammates have to review for details the agent should have caught itself."
>safe enough to be useful without fully removing the human from the loop
This is the fundamental concept for AI usage, assistance and adoption for every fields not only code generation.
Essentially AI including LLM, ML, DL, is just a tool, like any other automation tools operating based on the principle of expert-in-the-loop as safety and quality gatekeeper, for sensible and responsible decision making [1].
[1] Domain expertise has always been the real moat (brethorsting.com) (519 comments):
>We regularly invent things like 4GL, graphical programming and frameworks and engines such as Unity just to enable more people to do programming.
You're right on the money on this.
Earlier this month I went to visit a company for a complete demo prototype of a full one-to-one train simulator trainer mostly designed and programmed by a former civil engineer using Unity engine. According to the company, they could not do it if Unity engine (or similar) is not around because it will be prohibitively expensive to develop.
In a related news, Unity recently released AI eco-system namely Unity AI Suite [1].
Please check the recent self-distillation work by MIT-ETH, UCLA and Apple [1],[2],[3],[4],[5].
Given the release timelines I suspect all 4.x after Opus 4 are probably self-distillation based fine-tuned models. The latest paper by Apple is focusing on code generation using the simple technique hence the name simple self-distillation (SSD) [4],[5].
I've got a strong feeling that self-distillation is the second best thing happened to LLM after transformer breakthrough.
So first - these are terrific papers and I'd not seen some of them before.
Having said that, I don't think these are classic student teacher distillation from random (which was my point). In fact, the "Embarrassingly Simple Self-Distillation" paper is using exactly what I was talking about "fine-tune on those samples with standard supervised fine-tuning".
It's worst than useless, it's borderline criminal /s
The fabricated title targeted the sensation rather than substance, typical scenario whenever "All" is in the title, and the worst when it's in the very first word.
It's mainly its strategic location and it's always been the the busiest maritime route chokepoint since recorded history between east and west, specifically between India and China two of the most populous nations in the world.
It sit right at the tip of the Strait of Malacca, the busiest and the longest strait in the world. This one famous quote by a 16th CE Portuguese explorer Tomé Pires, who declared: "Whoever is lord of Malacca has his hand on the throat of Venice".
Secondly is the people, and the third is the governance policy. Essentially, you must have be a bone-headed to screw up Singapore, like the one who can bankrupt a central bank.
My original top most comment on the great lie of Singapore was just an obscure fishing village during the early colonial time but it's has already downvoted to oblivion, you can check them out if you want.
reply