An HN-classic-esque review of the pitch: I don't know what Darklang is. I click through to the Darklang link, and I get: "no cruft: no build systems, no null,

An HN-classic-esque review of the pitch: I don't know what Darklang is. I click through to the Darklang link, and I get: "no cruft: no build systems, no null, no exception handling, no ORMs, no OOP, no inheritence hierarchies, no async/await, no compilation, no dev environments, no dependency hell, no packaging, no git, no github, no devops: no yaml, no config files, no docker, no containers, no kubernetes, no ci/cd pipelines, no terraform, no orchestrating, no infrastructure: no sql, no nosql, no connection poolers, no sharding, no indexes, no servers, no serverless, no networking, no load balancers, no 200 cloud services, no kafka, no memcached, no unix, no OSes" May I feed back that using your valuable first impressions time to hit me with a large list of what your language isn't is completely useless to me. I never assumed that "Darklang" would be "sharding" or "containers" in the first place. (Yes, I get the point, but I hope you get mine too.) I don't even know how to suggest an improvement. I see that Darklang seems to be excited about some FP buzzwords, but for example citing "Option" types as your number two feature is actually very unappealing, not because it's a bad feature, but because a compelling language pitch ought to have a dozen things more unique to stick in front of that. I can get Option types all over the place and adjoin them to even more languages reasonably. I recommend using that valuable space to demonstrate what is most unique about the language. To give you more concrete guidance and elaborate on that, you're looking for things that are true of as few other languages as possible. Option types, for instance, don't score terribly well on that metric. I get the sense that "easy deployment to the cloud" may score well, though. I'm not sure what "Copilot integration" is but there's a hint of something unique there you might want to bring out. "Self-updating exe" supported at the language level would definitely be unusual. (I've seen libraries for it but if you don't have an OTP-like sense of restarting services gracefully updating is generally violent; language-level built-on-day-1 support for graceful updates would be legitimately unique.) "Has record types" is not. Not a good first feature. To give you something else to pitch, as well as any other burgeoning language designers, another important aspect to a language is what I was alluding to with the self-updating exe point, which is that even if your language itself isn't very unique, you can build features into your standard library and set the pattern for the rest of the community to build things that other languages can do, but don't, because the pattern was missing and the community diverged too far, too quickly. I've written before about how Go's io.Reader/io.Writer is very nice to use, but it isn't about the language features at all: https://news.ycombinator.com/item?id=28368080 https://news.ycombinator.com/item?id=28368080 It's not just about langauge features, you can also pitch the patterns you want to establish early. The Erlang community is another good example; many langauges could theoretically have "applications" like it does and run multiple applications in a single process, but the Erlang community expects people to package applications up that way and be able to start as many as they like in one OS process with "application:start". There's a rich vein of unique value propositions to pitch in the standard library of a new language that is underutilized by other language pitches right now. And it's a strong pitch; generally this stuff gets nearly set in store in the first 5-10 years of a language and the opportunity to fix it diminishes rapidly, to the point that it is literally easier to bring up a new language than fix the old one.