When I look at a programming language site, especially for a "new" language, I want a quick way to navigate to a reasonably sized decent code sample, ideally documented, showing off significant language features, idiomatic syntax and usage patterns etc...
Sites which do this well (just from the top of my head):
https://odin-lang.org/
immediate code sample visible
"See the Full Demo"
"See More Examples"
https://ziglang.org/
immediate code sample
scroll down a bit, "More Code Samples"
Here on red-lang.org... I can barely find a consecutive meaningful chunk of code... ?
"Getting Started" Nope
"Documentation" Nope
"Official Documentation" link to github
https://github.com/red/docs/blob/master/en/SUMMARY.adoc
"Home"
merely a chronologically sorted blog
newest entry links to 50 line "script" by chance
showing off multi-monitor support
(doesn't seem like a super helpful sample)
?
But no one has bothered to write a complete manual like Carl did for Rebol, and the language is a partial implementation in Rebol which has a hybrid Rebol/Red syntax that must ultimately be bootstrapped in Red. In short, you have the scaffolding around it and if you are not a total fan or a dev of the project it is not even worth it.
They used to promise that proper docs and everything would come when the language reaches 1.0. That was 7 years ago. The language is at version 0.6.6 today, and the state of docs is the same as 7 (and 10) years ago.
There are at best two people working on the language, and they both don't have the time and have a very weird approach to docs (like posting extensive google docs or pastebin explanations, but never actually having any proper documentation)
Can't benefit from them patching a security issue, but don't suffer from
- them breaking something
- a supply chain attack
- them making a change which breaks your program
- you having accidentally relied on a bug or an unintended behavior of their code
(which they may fix at any moment)
- many unneeded LOC in your codebase
- absolution of ownership
- relying on a dependency versus having written it yourself
- in the latter case you'll automatically take responsibility
- think much more about code's security/quality
- have the knowledge to fix it and know exactly where to
(in your 35-lines of code you yourself wrote)
- more burdensome upgrades of your software
- longer compilation speeds
- having to monitor their program
- is it abandoned, ownership transferred to dubious party
- did the maintainer have a late night drunken stupor accepting bad pull requests
- did they react to a CVE or not
- did they change the license
- do they have a license but added their own problematic paragraph
- does the program "develop badly"
(change its target scope in any problematic way)
(take on more and more bloat, more unneeded functionality)
- having worse of an overview of your total dependencies
(since they may themselves rely on further crates you don't expect)
- ...
C is liked particularly, even considering all its shortcomings, for being a relatively limited language in scope, being raw but flexible.
D's scope seems to go far beyond what your average C programmer would want in a language; "use only 15% of the language and you'll be fine" (paraphrasing: "use only the 'better-C' subset", if that is what you meant, and it does seem to be a subset of D) seems a weird proposition; it still complicates things, as in collaboration, idiomatic feel and look of code, the amount of knowledge required to be competent in the language, complexity of a compiler implementation, portability of code etc... and by that logic you'd have to prefer C++ over C as well (since a lot of C is valid C++), or prefer C plus one safety feature added over C; but the "rawness"/limited scope/small size/procedural nature of C is what's appealing for many to begin with.
I for one think that a proper C replacement (C's strength also being the simplicity in which to implement a compiler for example, being the reason it's so ubiquitous in the embedded world) will be a much more limited proposition than D is.
RAII
Full metaprogramming
Nested functions, nested structs, delegates and lambdas
Member functions, constructors, destructors, operating overloading, etc.
...
Where to draw the line will be different person to person, but D doesn't seem to be a language "in the spirit of C", or a "modern version of it", at all.
Viewing it as a C++ alternative makes much more sense. A `Better-C` "limit yourself to a subset of the language" compiler flag doesn't change that much.
I wouldn't like RAII, and why I didn't add it to Odin. It's not a feature C programmers want. And you've just agreed that C don't want ctors/dtors, which is necessary for RAII to work... ctors/dtors are bad for their own reasons (mainly because you cannot handle error cases except through exceptions, which many people disable too).
Yeah, I have used Odin before, I am thinking of giving C3 a try as well.
At a quick glance though:
> Enum support various reflection properties: .values returns an array with all enums. .len or .elements returns the number of enum values, .inner returns the storage type. .names returns an array with the names of all enums. .associated returns an array of the typeids of the associated values for the enum.
I do not like that the length is named ".elements" instead of just ".len". And why are there two ways, or are they not the same? Etc.
FWIW I have spent the weekend testing out C-replacement languages and their interop (linking to libsdl3 and libtcl) with D, Go, Rust, Odin and C3. My quick impressions:
- D is featureful, but too much so. It feels an unfocused kitchen sink worse than C++. Overall the actual dev experience was nice.
- Go I know pretty well, but saddened that CGo is very slow, so I cannot consider it truly a C replacement
- Rust I also know decently well, but writing types and lifetimes isn’t my idea of fun. I’d rather have less safety when playing with code, I’m not always writing mission critical apps. Overall walks the fine line between excellent and unergonomic; pulls half a gig of dependencies just to include SDL3 which is pure madness.
- Odin I have played with before, excellent for the gamedev world, but some features seems like they have been added just because the author liked them. Having to explicitly set up the context variable in cdecl callbacks feels bad. I dislike the whole context thing actually, because it is rigid though convenient.
- C3: documentation is bad but feels the closest to a better C. Still in the breaking phase, I sent a PR this morning to adapt the SDL3 library to the latest release. Has macros which I haven’t tested but it’s a big plus. Some syntax makes no sense, like block labels and generic in {braces} but it’s the one I will keep playing with for this project. No one seems to use or know about it, which doesn’t bode well for its future.
- Zig I haven’t used this weekend, I loathe that unused variables are errors and it is very verbose. Docs and stdlib are way undercooked. comptime is a brilliant idea. Could be decent past 1.0 release.
- Jai: I’d love to try it, if I had access to the beta.
A lot of paper cuts and small issues, nothing is really worthy of being called a C replacement, but I do not want to write another header file again so these will make do for now.
Thanks for sharing! I think there is hope for C3, if they do not mind breaking backwards compatibility, which I hope they do not, for now!
We have similar experiences I would say. I do like Go a lot, but I rarely had to touch CGo though. The language does not get in the way of being productive. Rust seems like it does.
I would give Jai a try, too!
Have you tried Zig, or perhaps even Nim? Curious about your thoughts.
Nim I played a bit with, I don’t really like the syntax but I admit I need to dive deeper. My other issue is that it is so different syntax wise to C, and sometimes so high-level, it’s hard to tell what construct is efficient, and what allocates and takes 500 instructions to run. This is pretty crucial for a low level system language.
Oh `.elements` would you believe that this is a remnant of C2's builtin function `elemsof`? Its used so rarely (I think two uses in the entire stdlib), so it hasn't come up. I opened an issue for it: https://github.com/c3lang/c3c/issues/2130
This is a good example of the sharp edges I hope to smoothen out in 0.7-0.9.
Excuse me for not having much to add to the discussion but two interesting references for people to check out, if so inclined of course:
a) Ginger Bill (the Odin language creator, no affiliation) stated on a podcast that Odin will never have an official pkg manager, since what they're, in his opinion, mainly automating is dependency hell, and this being one of the main reasons for rising software complexity and lower software quality; see https://www.youtube.com/watch?v=fYUruq352yE&t=11m26s (timestamped to the correct position) (they mention Rust explicitly as an example)
b) another programmer rather seriously worried about software quality/complexity is Jonathan Blow, who's talk "Preventing the Collapse of Civilization" is worth watching in my opinion: https://www.youtube.com/watch?v=ZSRHeXYDLko (it's not talking about package managers specifically, but is on topic regarding software complexity/quality as a whole)
Addendum: And sorry, I feel like almost everyone knows this xkcd by now, but since no one so far seems to have posted it; "obligatory xkcd reference": https://imgs.xkcd.com/comics/dependency_2x.png
> a) Ginger Bill (the Odin language creator, no affiliation) stated on a podcast that Odin will never have an official pkg manager
The cognitive dissonance for how one can believe that Rust preventing you from derefercing freed memory at compile time is overzealous nannying by the language authors -- while at the same time deliberately making code reuse harder for users because they could make engineering decisions he doesn't like is staggering.
> a)... Odin will never have an official pkg manager
Perhaps this explains why Odin has found such widespread usage and popularity. /s
> b)... Jonathan Blow, who's talk "Preventing the Collapse of Civilization"
With such a grandiose title, before I first watched I thought it must be satire. Turns out, it is food for the credulous. I believe Jonathan Blow is less "seriously worried about software quality/complexity" than he is about marketing himself as the "last great hope". At least Blow's software has found success within its domain. However, I fear Blow's problem is the problem of all intellectuals: “An intellectual is a person knowledgeable in one field who speaks out only in others.” Blow has plenty of opinions about software outside his domain, but IMHO very little curiosity about why his domain may be different than your own.
My own opinion is there is little evidence to show this is a software quality problem, and any assertion that is the case needs to compare the Rust model against the putatively "better" alternatives. Complex software, which requires many people to create, sometimes across great distances of time and space, will necessarily have and require dependencies.
Can someone show me a material quality difference between ffmpeg, VLC, and Samba dependencies and any sufficiently complex Rust program (even which perhaps has many more dependencies)?
~ ldd `which ffmpeg` | wc -l
231
Now, large software dependency graphs may very well be a security problem, but it is a problem widely shared with all other software.
"Perhaps this explains why Odin has found such widespread usage and popularity. /s"
What an unnecessarily snark and dismissive comment to make about someone's work.
- I'd say within a certain niche Odin is becoming well known and gets its use
- you do realize using an `Odin package` is putting a program into a sub-folder and that's it
- It comes with a rich stdlib + vendor libraries out of the box
- and isn't it kind of up to the creators how to design and promote their language
I'd even argue it's laudable a language doesn't promote itself as a "fixes everything use me at all costs" kind of technology. The creator himself tells people it might not be the right tool for them/their use case, encourages them to try other languages too, sometimes outright tells them Odin doesn't fit their needs and xyz would probably do better.
Odin is pragmatic & opinionated in its language design and goal. Maybe the lack of a package manager is the basis for you to disregard a programming language, for plenty of others (and likely more Odin's target group) it's the least of their concerns when choosing a language.
> What an unnecessarily snark and dismissive comment to make about someone's work.
The snark was intended, however any dismissiveness concerning Ginger Bill's effort was not. However, when you make a decision like "Odin will never have a package manager", you may be choosing to condemn your project to niche status, in this day and age. Now, niche status is fine, but it definitionally comes with a limited audience. Like "this game will only ever be a text based roguelike."
Seems needlessly harsh and also misplaced in some way. Zig is super non-ergonomic to any C-developer, and its explicitness at all costs is also non-C-like (meaning a rather big shift for someone actually liking C). Rust is a completely different beast altogether.
Odin is a rather simple, performant, pragmatic, procedural language, fixing especially things in C with regards to its type system and infrastructure (such as packages), adding niceties such as `defer` while being at it. I, as a C programmer, have it far higher up my list of languages to try than Zig or Rust by a rather large margin.
btw: "C alternative means a language that will last for 50 years" seems a snide that could be applied to any language less than 20 years old? I'm not sure what that's concretely meant to criticize here? Is Zig more a 50-year language than Odin, if so how? Odin is used for rather serious commercial products at JangaFX btw: https://jangafx.com/ and is quite beloved by some people using it.
I have long been aware of that particular user of Odin, after all the creators mention it frequently. The fact remains that the US government has warned against the use of languages such as Odin [1]. As such, it is competing in the extremely small niche of "languages best suited for embedded computing and operating systems". Suffice to say that most of its users likely do not use it for that. Finally there is the matter of trust. A while ago I was shopping around these new languages that have sprouted out of LLVM and watched a few talks from the creators of various languages. The Zig team were both ambitions and clear in their presentation. They gave me the impression of an experienced and motivated team. By contrast the Odin presentation I saw was utterly directionless and filled with fluff. I like to think I have a good nose for BS, and Odin trips it. That great wall of random corporate logos of companies which don't use Odin on their website doesn't help. Upon investigating, I find that the creator of the language is also a developer at JangaFX, so is either using the Odin website to advertise his own software, or hoping to obtain clout by mentioning large companies as if they used Odin when they do not. You might think I'm being overly critical, but I've learned the hard way to avoid things like this. It's a mighty pain depending on something which ends up abandoned or unused. The Zig compile supports multiple codegen backends, compiling C/C++ code, and easy cross-compilation. It is a considerable feat of engineering and shows a lot of dedication on the part of the creators. I can see nothing comparable on the Odin front.
Additionally, I don't think a C replacement should be immediately intuitive to someone who has only ever used C. To entice people away from on of the most popular and stable programming languages ever created, you must offer more than an incremental improvement. There needs to be a paradigm shift, which necessitates some degree of learning on the part of the developer.
> The fact remains that the US government has warned against the use of languages such as Odin
That goes for Zig as well. But, the NSA is only classifying based on most well-known languages, and additionally a lot of those aren't 'memory-safe' they just have GC, the reason they don't believe you should use C is because they don't have built in memory safety checks at all, whereas Odin does. They have Pascal on that list, which is a primary inspiration of Odin, and is also technically an unsafe language.
> By contrast the Odin presentation I saw was utterly directionless and filled with fluff.
I am not sure why a presentation has anything to do with performance or credibility of a language, plus I am always impressed by their talks. Good chance you saw their live coding/development sessions? They live stream development fairly often.
> I like to think I have a good nose for BS, and Odin trips it.
Odin is used in production, hard production today. I use it to run 6000+ retail locations doing embedded automation work in security, it's highly proficient and accessible. There is no BS here, everything has been defined and they are honest about their shortcomings when there are those (which are minimal).
> The Zig compile supports multiple codegen backends, compiling C/C++ code, and easy cross-compilation.
That's because they bundle the entirety of LLVM in their builds, they didn't do a lot of extra work for C/C++ code compilation, they just built an alias (with a set of internally defined better default flags) to the clang compiler, it's just a passthrough.
re: cross-comp: Odin is in the same boat, both Zig and Odin compile out to assembly via LLVM, they can reach the same targets practically.
> That great wall of random corporate logos of companies which don't use Odin on their website doesn't help
They do use Odin, they use JangaFX, that is less a 'this is a code written by these companies' (which some do send upstream changes, so they do) and more of a declaration of "We are used in production in these companies, you have likely ran Odin code in your favorite games, or seen in your favorite movies". That's fairly obvious for any tech-oriented project or company, especially for a language.
> Additionally, I don't think a C replacement should be immediately intuitive to someone who has only ever used C
Again, automation systems architect for one of the largest companies in the world here, I have people who have never even _programmed_ writing proficient code to use in production (after checks, of course). As an embedded developer, its insanely intuitive to C developers, and anyone who has ever programmed.
---
Check out the language, write some code, try it out, seriously, I was on the fence when I first heard about it several years ago, I think you might enjoy it. If you're not an LLM chatbot, then you might even find it invigorating to try something new. Doesn't hurt, and you learn some new things.
"originated as a re-engineering of C++"
"influenced by Java, Python, Ruby, C#, and Eiffel"
"design by contract, ranges, built-in container iteration concepts, and type inference"
"array slicing, nested functions and lazy evaluation."
"Java-style single inheritance with interfaces and mixins"
"function overloading and operator overloading"
"supports five main programming paradigms" (including OOP)
... et cetera
Though it does support things like in-line assembly and the like, I'm sure most C programmers would pass on it, as a C-alternative, based on those factoids.
Yes, I understand the C++ aspect, but I was never a C++ coder, and D "fit in my hand" in a way which made me certain that its creator had coded extensively in C and understood the aspects which made it so perfect for its time. It really felt like D, not D++ to me.
(Oh, disclosure, I'm just a D user, no organizational or financial interests here.)
Since this thread, rightfully so (and in full agreement), has people complain about the bloat of today's software stack, is it only me in thinking there may be sincere potential profit streams for high quality paid software?
I would happily pay for software that
was high-quality
was fast
was privacy preserving
had sane defaults
had/provided reasonable support/insight
(forum and developer blog)
had a fair pricing models
(non-subscription, x-years of updates etc)
as in
an e-mail client
an office suite
a scheduler
(scheduling learning, tasks, various deadlines, calendar, ...)
photo/video editor
(wouldn't need to be of the scope of a professional suite)
a browser
(earnestly, one that wasn't a mere chrome re-skin, wasn't run by a bloated paid by Google organization like Mozilla, and would take fingerprinting prevention and privacy seriously)
...
or am I underestimating the problem? How many full-time developers working how many hours, building on open-source software where sensible (as in you wouldn't hand-roll your own cryptography, networking protocol implementations, GUI libraries) would it take, for e.g. a good cross-compatible Desktop E-Mail Client? (there's little in terms of software that I hate more than Outlook)
And given competitive non-US, maybe even non EU-wages for such developers, how many 'customers' with fair pricing would such a company/startup need?
You could open-source part of your stack (as in singular libraries) for exposure and good will, could maybe offer free-tiered versions, potential fair pricing models could be similar to Sublime's https://www.sublimehq.com/store/text you could build upon technologies people are exited about and willing to take pay cuts for if that's what they could work in (Odin, Zig, Rust, ...) etc...
Even considering vendor lock in, market dominance of existing solutions, the dominance of smartphones over desktops, isn't there still a viable market? Maybe what's left is even more so, given Desktop use seems (besides gamers) consist (to a significant extent) of power users, semi-professionals/professionals & businesses?
And, even though this place here is of course a highly niche bubble, the plights of modern's software lack of quality are real and I'm sure felt beyond us.
There is a viable market, it exists as a word + excel combination like Notion, Coda and Monday. Notion just recently had an email and calendar client.
And I don't think non-US or non EU-wages, or being open source would help. Microsoft's success is due to the lock in and GTM sales org that Microsoft has. Just see how Teams eclipsed over Slack despite the latter being a first-mover and a better quality product.
Nowhere have I claimed that the whole product would need (nor should) be fully open source and why wouldn't non-US wages help?
Assuming it takes me X-amount of software engineering hours to produce an alpha version of a given product and now let's imagine a rented office space plus four developers; consider renting in a major US city, and paying competitive US-major-city-wages versus doing so in a significantly smaller city in Eastern Europe (Czechoslovakia, Romania, Estonia).
In both cases you could develop an English-Language version of your product for global use and you can distribute software cheaply over the internet; you'd still charge customers in the US US-prices, yet would have saved on development costs.
I'm sure this comes with its own set of difficulties, especially regarding US business customers, but initially it could be an advantage in certain scenarios.
There also seems to be a current push towards non-US (sometimes even specifically from-EU) products in tech, which might give one an interesting market position, albeit I'm lacking details here, and it's yet to pan out how viable this trend is long-term of course.
Hope this doesn't come off as disrespectful, as in that I don't believe you, but out of personal interest, would you consider expanding on that? I'd love to hear about the particular example you were thinking of, or in what ways self-taught coders surprised you over academically-taught ones, if you've had experience working with both over a meaningful span of time. Also, if the case, in what ways self-taught coders were/are maybe lacking on average.
If you've ever given answers to that in another comments on HN or elsewhere, feel free to link.
It's certainly true in my experience. The main thing that makes a difference is simply how curious and interested you are.
Plenty of graduates simply got into to it to make money, and have no real deep interest. Some of them love the theory but hate the practice. And some of them are good at both of course.
By contrast, self taught people tend to have personal interest going for them. But I've also worked with self taught people who had no real understanding (despite their interest), and who were satisfied if something just worked. Even if they are motivated to know more, they are often lacking in deeper theoretical computer science (this is a gap I've had to gradually fill in myself).
Anyway, the determining factor is rarely exactly how they acquired their skills, it's the approach they take to the subject and personal motivation and curiosity.
Makes sense, out of all the potential differentiators the source of skill attainment simply isn't the necessarily dominant one. Thanks for the answer :)
Not disrespectful at all. I agree with the sibling comments, I think what allows someone to become a great software developer, to have great intuition, and to understand systems and abstractions on a really deep level is their curiosity, hunger for knowledge, and a lot of experience.
There are many college educated software developers who have that sort of drive (or passion, if you will) and there are just as many who don't, it's not something college can teach you, and the same is true for self-taught developers.
At the end of the day "self-taught" is also a spectrum that ranges from people who created their first "hello world" React app 2 months ago to people who have been involved in systems programming since they were 10 years old, and have a wealth of knowledge in multiple related fields like web development, systems administration, and networking. That's why I think it's silly to generalize like that.
Software development is extremely broad so depending on the discipline self-taught developers might not be missing anything essential, or they might have to learn algorithms, discrete mathematics, linear algebra, or calculus on their own. I learned all of that in college but I'd probably have to learn most of it again if I really needed it.
Thanks for the answer, very nice of you to take the time even hours after.
Guess it makes sense; I'm self taught myself, but thought academically taught developers should have a leg up in theory and mathematics, at the same time though, at one point I considered further formal education for myself (in at least paid courses and such), I realized that I don't think there's much I can't teach myself with the resources available (which includes high quality university lectures which are available for free).
Not the GP, but here is my N=1 (N=3, actually, as you'll see).
I have a Master's in Economics. After 3 years of economics, I started a Master's program in maths (back then the Master's degree was the standard thing you achieved after 4.5–5 years of studying in my country, there was basically nothing in-between high school and that). 9 years later I got a PhD in mathematical analysis (so not really close to CS). But I've been programming as a hobby since late 80s (Commodore 64 Basic, Logo, then QBasic, of course quite a bit of Turbo Pascal, and a tiny bit of C, too). I also read a bit (but not very much) about things like algos, data structures etc. Of course, a strong background in analysis gives one a pretty solid grasp of things like O(n) vs O(n log n) vs O(n^2) vs O(2^n). 9 years ago I started programming as a side job, and 2 years later I quit the uni.
I lack a lot of foundations – I know very little about networks, for example. But even in our small team of 5, I don't /need/ to know that much – if I have a problem, I can ask a teammate next desk (who actually studied CS).
Of course, _nemo iudex in causa sua_, but I think doing some stuff on the C64 and then Turbo Pascal gave me pretty solid feeling for what is going on under the hood. (I believe it's very probable that coding in BASIC on an 8-bit computer was objectively "closer to the bare metal" than contemporary C with all the compiler optimizations.) I would probably be able to implement the (in)famous linked list with eyes closed, and avoiding N+1 database queries is a natural thing for me to do (having grown up with a 1 MHz processor I tend to be more frugal with cycles than my younger friends). Recently I was tasked with rewriting a part of our system to optimize it to consume less memory (which is not necessarily an obvious thing in Node.js).
Another teammate (call them A) who joined us maybe 2 years ago is a civil engineer who decided to switch careers. They are mainly self-taught (well, with a bit of older-brother-taught), but they are a very intelligent person with a lot of curiosity and willingness to learn. I used to work with someone else (call them B) who had formal CS education (and wasn't even fresh out of a university, it was their second programming job, I think), but lacked general life experience (they were 5-10 years younger than A), curiosity and deep understanding, and I preferred to work with A than with B hands down. For example, B was perfectly willing to accept rules of thumb as a universal truths "because I was told it was good practice", without even trying to understand why, while A liked to know _why_ it was a good practice.
So – as you yourself noticed – how you acquire knowledge is not _that_ important. IMHO the most important advantage of having a formal CS education is that your knowledge is more likely (but not guaranteed!) to be much more comprehensive. That advantage can be offset by curiosity, willing to learn, some healthy skepticism and age. And yes, I think that young age – as in, lack of general life experience – can be a disadvantage. B was willing to accept even stupid tasks at face value and just code his way through them (and then tear the code apart because it had some fundamental design problem). A, as a more mature person, instinctively (or maybe even consciously) saw when a task did not fit the business needs and sometimes was able to find another solution which was for example simpler/easier to code and at the same time satisfied the actual needs of the customer better.
Sites which do this well (just from the top of my head):
Here on red-lang.org... I can barely find a consecutive meaningful chunk of code... ?