I'm genuinely asking; any anecdotes out there?
Odin has aided them with a huge amount of productivity and sanity of life which other languages such as C or C++ cannot offer, such as a strong and comprehensive type system, parametric polymorphism which is a pleasure to use, the implicit context system, extensive support for custom allocators, the `using` statement, the `defer` statement, and much much more.
With all of the advantages you listed, what do you think the possibility of Odin becoming more widely accepted in other fields who could benefit from using it?
I'm more on the scientific side of CFD (so CUDA more so than shaders), but always interested in improving upon the kind of orthodox C++ I usually write.
> This starts ridiculously, then it gets worse
...
> looks like a solid way to produce abysmal quality code
...
> just learn the fucking language like everybody else
...
> The trolls from r/javascript are brigading us again It seems
I would say in my experience that Odin is definitely preferable as a client language for the simple reason that it's a nicer systems programming environment than other languages, but it's not (at least right now, future developments could always change this) equipped to run native GPU code.
Things like SPIR-V and "shader ASM" open up some interesting possibilities once the custom backend is implemented, but the complexity of integrating GPU execution means making it a first-class feature it probably unlikely.
In both cases the interoperability is excellent imo.
I can't speak to Zig as much, but Odin's type system makes working with C APIs much more of a pleasure than doing so in C itself.
I'm working with language development where we're deploying a custom language built with another custom language.
>who's actually using these languages, and in what contexts?
Compare it to using C in 1970 or Ruby in 1995. It's people who have a real problem they're trying to solve for which existing tooling and widely used languages are a poor fit - as well as people who genuinely enjoy developing their own PLs that have their own ways of doing things.
>Where does the build complexity/hiring difficulty/lack of tooling tradeoff make sense
With VC money, anything is possible...
>build complexity
Fairly nil. Contemporary build systems are language agnostic, and the steps to make one that functions good enough are well known and can be thrown together in a week or so. Not to mention it's become increasingly common for "widely used" PLs to fallback on things like python scripts to handle builds.
>hiring difficulty
It's actually a fantastic way to weed people out and find good candidates. In my (limited) experience, people willing and able to learn a new language (or have a few under their belt) are generally the exact kinds of people you want to hire anyway. Code switching between languages on a daily basis is a fantastic skill, and leads to good developers and mindshare, helps create a diverse technical background.
>lack of tooling
This is a legit problem, and one that a lot of folks stumble on. But luckily building tooling is a great way to dogfood your language - and it's never been easier to integrate with various tool frameworks via standard protocols.
But that said - every company just getting off the ground lacks tooling. For language devs it's a language server, debugger, disassembler, and what have you. For your bootstrapped startup it's build systems/procedures and code review, ERPs and CRMs, etc. Building your own tooling is a part of the growth of a business, tech or otherwise, it's just that when you work on a custom language you have to build some different tools than a SaaS might.
I'll throw one more in though that's the biggest hurdle - wheel reinvention. Stuff you take for granted in any language or have great packages for are the biggest blockers to being productive. But you do the ROI math and decide if it makes sense, so hopefully your lang has good FFI.
Also worth mentioning - if you're working in an esoteric language with heavy contribution by your own team, you're probably doing it because you have a lot of work that looks nothing like putting together a CRUD app or developing a backend for your latest API for your SaaS idea.
I highly recommend you read the overview (https://odin-lang.org/docs/overview/) and many of the Odin wrappers and bindings for more information on this topic https://github.com/odin-lang/odin-libs
It's good to see you took FFI seriously and made it low friction, it's absolutely critical for younger languages.
That's not the category I'm talking about, though. C (and I believe Ruby) was a major shift from what came before. Those two are better compared to Clojure or Go: dramatically different value-propositions that can make it worth the time and effort to take a chance on a new, green technology. What I'm talking about is languages that are "like X but with improvements to Y and Z".
Algol 60 had a number of obvious deficiencies, which needed to be addressed. Both Algol 68 and CPL were designed to fix these issues, but had a level of complexity that made them impractical to implement.
Pascal, which Predates C slightly, grew out of of Wirth's much simpler (compared to Algol 68) set of changes to Algol 60.
The CPL people were having trouble with implementation, so Richards created a stripped down version (BCPL). Thompson apparently didn't have access to the full specification, but samples of it greatly informed the the design of B, which eventually begat C. Apparently the "killer-feature" of C over B at the beginning was byte-addressing, which is arguably no more or less niche than what any of these new languages claim.
Almost memory safe systems programming languages (not fully safe due to use-after-free) were already a thing since 1961.
In fact ESPOL was probably the very first systems programming language with unsafe code blocks.
In this case, small minds discuss libraries/frameworks, average minds discuss language details, great minds still discuss ideas.
All of the best, most interesting, and most insightful programmers I have talked to express ideas in language and tool-agnostic terms, with written language, and only use code as an implementation or demonstration detail. This isn't to say that tooling and languages are not important of course, but the best programmers can pick up new tools and languages quickly and express their ideas in any given medium. If a programmer is limited by thinking in terms of the language(s) they know, they're basically a bricklayer. Still respectable, but they're doing tedium rather than manipulating the idea space.
There's also something to be said for language idioms as a means of communication and shared documentation within a team. Someone who speaks French and Italian may have no trouble picking up Spanish, but might say things that lose meaning when translated literally until she's gotten more immersed in the culture surrounding the language. One of your "great minds" may pick up C# and try to use it like Clojure, or vice-versa, and create enormous friction within the codebase.
Not that this is necessarily the dominant factor in these decisions, but it is a factor, no matter how intelligent and experienced your hires are.
Yes, but it never matters at first. The first thing you do, always, is hack a prototype together. Computers are fast. Basic algorithms and data structures are usually good enough. You don't optimize until you've got what you want in principle. And sometimes you don't optimize at all. The internet is full of prototypes that escaped into the wild and then attracted enough users that they became irreplaceable.
Javascript is a good example. The version we have is several versions too early, and it's warty. JS would be a much better language if someone had paid more attention to the low-level details. But I would argue that JS is a huge success in spite of this. An awful lot of work has been done in JS, including work that couldn't have been done in most other languages.
The grandparent of this post is right that ideas are the important thing. JavaScript succeeds because it borrows good ideas from Scheme and Self.
When I say boring, I mean relatively; there is some "puzzle solving" merit to programming per se. But this is mere mechanics and minor compared to the experience of manipulating ideas into practicable forms before writing them out in code.