Is there something inherent to Lisp that allows it to be implemented in so little code?
I believe I saw someone demonstrate that almost nothing in a Lisp implementation was written as a "built-in" language feature that required the underlying interpreter to provide the functionality.
I always think of this HN post every few years, as an aside, someone really needs to archive that page it links to because I wont be surprised when that site shuts down or deletes old content:
First off, you wouldn’t write an actual interpreter for lisp like this if you wanted to use it for anything serious, it’s very slow.
The parser is very simple thanks to the s-expressions, and the only builtin special forms really needed are quote, cond and lambda, that’s pretty much it. The only data structure is a list, so functions are just lists, function calls are lists etc.
Yes there's something inherent. Namely this: the ability to drop all sorts of requirements off the table, yet still call it some kind of Lisp.
It does not need to be compiled to be a Lisp. It doesn't need arbitrary precision integers. It doesn't need hash tables. Garbage collection doesn't have to work; it can just run out of space and terminate. It can just crash on errors without a trace. It doesn't need to report the line number where a syntax error likely began. You get the picture.
Whereas in contrast, you cannot have a race this kind of race for the bottom with most other languages; tripping over the other contestants to see who can remove the most features, yet still have Python or Java.
See?
There you go, mrweasel; I think we hit the nail on the head.
Lisp (and similarly, Forth) is closer to a mathematical construct than an actual language. We've had to wrap it in parentheses and named symbols to help make sense of it, to talk about it. Pairs, atoms, GCs, are all an implementation detail.
This is my project! I made the Odin version to learn the language, not to create a 1:1 comparison. I 100% prefer Odin over C and will use it wherever I can where I would have otherwise used C.
My impression of Odin is that it's a better C while still very much retaining the same flavor as C. It adds very little (no classes, no runtime) so porting from C is very straightforward, and it fixes a lot of the dark corners of C. It also seems to be pretty much finished as far as the language goes, so no big incompatible changes coming as far as I can tell.
I would say though that while the memory management story is vastly better than C^, it's still manual as fuck, so be prepared for that.
^: There's builtin test support, bounds checking and an optional leak detection allocator, plus as far as I know no UB.
Yes. There is no undefined behavior in Odin (afaik), and I haven’t seen many monoletter identifiers. There is a slice type and a for … in loop statement so that gets rid of most i:s and j:s.
This mostly just ends up meaning that Odin's creator Ginger Bill will engage in pointless semantic arguments in which he defines away your problem.
There are places where C could reasonably have chosen to define what happens, or to make it Unspecified rather than Undefined, and so that's what Odin chooses, which is a meaningful benefit. However there are plenty of situations left in which what you've written would be UB in C and absolutely anything might happen, while in Odin absolutely anything might happen but Bill insists it isn't UB.
This brief example makes a hash map, then it demonstrates that if we call a sub-routine which makes its own distinct hash map, that doesn't change ours, but, once we destroy our hash map and call the sub-routine again, we can still use the variable for our (destroyed) hash map (!) but doing so reveals the contents of that other hash map from the sub-routine instead in the cases I saw.
Now, in C or C++ if you do this that's Undefined Behaviour and the symptoms I saw (and which you're likely to see if you follow the link) are just one of arbitrarily many ways that could manifest.
In Rust of course the equivalent code won't compile because the hash map is gone so we can't just go around using it after that.
And in Odin, well, as Ginger Bill has explained Odin does not have Undefined Behaviour so... this has behaviour which er, Odin has not defined ? Does that make you feel warm and tingly or do you feel like Bill just wasted time arguing semantics?
Well, sure. If that’s what you mean by having UB then it’s trivially true for any language with a C FFI for example, or rust with unsafe. I guess what I consider UB is when the compiler exploits UB for optimizations, like discarding code that could invoke UB, which as far as I know odin doesn’t do.
> I guess what I consider UB is when the compiler exploits UB for optimizations, like discarding code that could invoke UB, which as far as I know odin doesn’t do.
This statement is incoherent. UB is undefined behavior, and it existed long before any compiler exploited it and isn't (circularly) defined by whether the Odin compiler exploits it.
Well, the statement is circular, colloquial speech doesn't have to be coherent. It's my understanding of what people generally mean when they complain about UB in the C standard, and it seems to be what gingerbill means too.
My take on what he is saying is that the odin compiler won't try to exploit that there is some behavior which is platform-defined or only knowable at runtime to do aggressive optimizations etc.
To point out that use after free is possible in Odin is not really a gotcha unless you really are just arguing semantics. That's by design, just like use after free is possible in C or C++ or Rust too.
> To point out that use after free is possible in Odin is not really a gotcha unless you really are just arguing semantics
In a language with UB, the use after free is UB. Which explains the nonsensical results.
If you're pretty sure this all makes sense, I recommend one tiny tweak to further unsettle you, change either (but not both) of the int types in my example to u8 instead. Now the use after free also results in type confusion - Odin has no idea this isn't the same type and so the machine code generated is for one type but the actual bits are for a different type with a different layout.
Bill's go-to is to blame somebody else, it's the operating system, or even the CPU which should define what happens and so it's not his fault. The thread you linked does this. But for type confusion those are Odin's types, nobody else can define how Odin works, the answer must come from Bill. What is supposed to happen here? Linux didn't define your programming language, Intel didn't define your programming language, this is your fault Bill.
Your understanding is completely wrong. UB means "undefined behavior" -- behavior that is not specified by the language standard or the implementation. UB being exploited by the compiler is a separate issue. Saying that there is no UB is saying that there's no undefined behavior; it is certainly not merely saying that the compiler doesn't exploit it.
I programmed in C for over 30 years and was a member of the C Standards Committee, which originated the language about undefined behavior ... I know what I'm talking about.
> To point out that use after free is possible in Odin is not really a gotcha unless you really are just arguing semantics. That's by design, just like use after free is possible in C or C++ or Rust too.
This completely misses the point and is a failure to understand at every level. Being able to use memory after being freed is not by design -- no one intends it, no one wants it. It's undefined behavior, and a program that does it is buggy. The reason that it's possible is because it's so hard to detect or prevent. To do so requires escape analysis, lifetime declarations, borrow checking, etc. etc. And no, use after free is not possible in Rust--not in safe code. It's hard to respond to that statement without being rude, so I will say no more.
Well, first of all, I guess I am wrong! Hey, I'm not Bill, just a user of the language.
A couple of clarifications, though: I did mean unsafe rust, not the safe subset. No need to get rude!
Second of all, I am of course not under the illusion that Odin prevents use-after-free (and thus, technically, it does allow UB I guess). I just don't think Bill is either. So clearly he doesn't mean UB by the same definition as you do.
_My_ use of UB has always been in the context of what a compiler will do during optimization, and the discussion I've seen in the context of C compilers is that they perform optimizations that remove code or change code in surprising ways because the way the code was written technically resulted in UB. But I'm neither a spec writer or a compiler author, so I don't really care that much about the actual definition of the term.
Anyway, best of luck in convincing Bill to use the term correctly as well! I won't mention UB when talking about the benefits of Odin in the future. :)
As someone who knows what they're talking about, I'm curious to hear from you, why you consider use-after-free an undefined behavior and not an unspecified behavior instead?
Because as far as I know both undefined behavior and unspecified behavior are the behaviors that aren't specified in the language standard nor the implementation. So what's the difference?
A useful example to consider might be an uninitialized integer in C++
In C++ 98 "int x; foo(x);" is Undefined Behaviour. We said there's an integer named x, then, without initializing x, we passed it as a parameter to the function foo, evaluating the uninitialized value, literally anything is allowed to happen. Program crashes, deletes all the JPEGs large than 15 kilobytes, displays "Boo!" on the screen, anything the program could have done is something it might now do.
In C++ 26 "int x; foo(x);" is merely Erroneous Behaviour. The value of x is Unspecified, but it does have a value. This program might pass any integer to foo -- perhaps your compiler provides a nice compiler setting to choose one, maybe the person building the program picked 814 and so this calls foo(814)
This constraint is an enormous difference. In a sense the Unspecified behaviour is defined, it's just not specific. That variable x will have some integer value, so, maybe zero, or 814, but it can't be a string, or negative infinity, and evaluating it will just do what it would do for its value, whatever that was.
If you don't find that example illuminating enough, try another from a very different language, a data race in Java
Now, in C++ (or Odin though of course Ginger Bill will insist otherwise ad nauseum) the data race is UB. Game over, you lose, anything might happen.
But in Java the data race has Unspecified behaviour. Specifically, when the race happens the variable we raced has some definite value and it's a value it definitely could have had at or before this moment in a sequentially consistent program. So e.g. maybe we're counting clowns, we started from zero, thread A is counting 800 clowns, thread B is counting 600 clowns, but the threads race the same counter, legitimate values we might see at the end include zero all the way through 1400 clowns. -1 isn't possible, 1600 isn't possible, but 1234 is entirely plausible. That's Unspecified behaviour.
Sorry to pop in but I kind of need to clarify my own position even further here:
Odin has "undefined behaviour". SHOCK! HORROR!
The thing I bring up that people think I go "ad nauseum" about (like yourself) is just that the term "undefined behaviour" is in itself "undefined". This is why I try to make as many distinctions about the different kinds of "UB" out there, and even what the "U" means in "UB".
To quote you from earlier:
> ...Ginger Bill will engage in pointless semantic arguments in which he defines away your problem.
Yes... the entire discussion about "UB" is fundamentally a semantic thing, LITERALLY it's an argument about semantics. And if I can "define away [the] problem" in certain cases, then it's literally not Undefined Behaviour. I am not sure what else to say to your point here. The entire discussion around UB is fundamentally a semantics game and always will be. And when people complain about the "semantics game" part, they have not understood the problem in the first place.
Interestingly, the C++26 example you give is a brilliant example of this, it's an Erroneous Behaviour, not necessarily "undefined" or "unspecified".
In the case of race conditions in Odin? This is pretty much a brilliant example of _Unobservable_ behaviour because Odin shares a similar memory model to C, and thus it has to make assumptions. And when the programmer violates certain assumptions, the compiler cannot observe the broken code that easily, and thus it can easily produce unexpected behaviour due to it being unobservable.
I know have said things in passing, but it's a question of what to tell people. A lot of the people who bring up examples of UB bring up are usually TRIVIALLY definable, and things we have probably already defined in Odin (e.g. integer (under|over)flowing, integer division by zero, etc), but when I say what Odin's defined it to, they usually go one of two ways, either "I don't like that definition" or "but I wanted to use these specific passes in the compiler backed to do 'optimizations' with", both of which actually annoys me because I am not discussing with someone serious. In the latter case, "passes" are just algorithms that do things; they are not intrinsically "optimizations". To "optimize" something, you need well defined rules to optimize within, if the rules are ill-defined or arbitrary chosen, then how the heck can anyone call that "optimization"?
Even the case of "use after free" that you brought up earlier, it is something which is not a language thing in certain cases, especially when Odin has custom allocators which are defined at the user-level. The language itself knows nothing about of the allocators and how they work, it cannot. So yes, Odin allows for "use after free" but and? We are not enforcing a specific memory allocation strategy at the language level, like other languages. But it could be technically well defined at the algorithm level of that specific allocator. Which leads to my many problem with this discussion: are flawed algorithms/code considered Undefined Behaviour now and thus make the language "UB"? Why is not just shitty code?
And I will literally go... your "nonsensical results" are just... allocator specific behaviour. Yes it's "nonsensical" to you, but Odin isn't C so stop applying its approach to things to it. C has its standard library as part of its spec and defines how `malloc` et al work. Odin doesn't have its core library as part of the spec and never will (base library will to a certain extent with room for implementation specified behaviour for certain defaults, e.g. what is the default `context.allocator` or `context.assertion_failure_proc`, etc).
> Bill's go-to is to blame somebody else...
No... my go-to response is to say where it should be defined, and if it is possible to define at _any_ level (if at all). So even in your case, you are blaming the compiler for something it cannot know if this is undefined or erroneous because it cannot know what you are doing, but the allocator itself could allow for it. `delete` could be a complete no-op and is for many allocators.
It's all about responsibility. What is responsible for what. So if you thin that's "blame", whatever, but that's the question. Is the compiler _responsible_ for "use-after-free" bugs? In some languages, yes. In other languages, no.
> Linux didn't define your programming language, Intel didn't define your programming language, this is your fault Bill.
No but they all put bounds on what is possible in the first place. They literally define the arena the language takes place in, and thus you are subject to their whims, regardless of my feelings about them. No it's not "my fault" anywhere, it's just a thing.
----------
If you want to discuss with me further on this, I'd be happy to do so. Other mediums other than a comment on Hacker News would be preferrable.
----------
P.S. nowhere on the Odin website itself do we say Odin has no "UB" nor even suggest it. So there is no official position on "UB" for Odin anywhere. My comments on Twitter or other social medias should not be taken as official in any way, and be considered closer to "conversation", especially Twitter.
P.P.S. Some of possible meanings of "U": Undefined (i.e. not-defined), Undefinable, Unspecified, Underspecified, Unobservable, Unknown, Erroneous (I know it's not a U), Unimplemented, Ill-Defined (different to Undefined or Underspecified, and again not a U), Defined-At-A-Different-Level (e.g. language, compiler, platform, core library, user's code, etc, and again it's not a U). It's an absolutely mess and things just need to be defined better about what you are talking about.
Ordinarily you'd be correct that you need the weird make overload, but I had no cause to invoke make I just told Odin that we don't care and it's fine, check the first line. Whether that feature is a good idea in this language I couldn't say.
Odin's decision to zero initialize local variables isn't relevant here.
I didn't fully flesh out the initializing local variables: What part of your code is undefined? You deleted the memory, and the compiler reused it. Then you re-accessed that same memory. That's just part of working with computers. The initialization comment was supposed to be from creating data to releasing it is defined. To be compliant with the Odin compiler spec, it's defined from start to end.
Using a variable (`some_map` in this case) after `delete`ing it doesn't seem something languages usually define in their specification. Does Odin define that?
I don't really get the distinction between adding the dynamic-literals feature flag and using unsafe in Rust? Like, if he had called it #+unsafe dynamic-literals, would that have been better?
I'm going to guess that you've never written, and perhaps never read, any unsafe Rust, because you (in common with several Rust critics) seem to be imagining it like a switch you can turn on somehow to disable the safety rules, and that's not what it is at all.
This Odin feature flag just allows me to write what I meant in Odin, I can write it all out by hand using make and so on without the feature flag, but it's more annoying to spell that all out which presumably was the impetus for this feature flag in the first place. The flag didn't somehow "cause" the unsafety, that's an insane take.
Odin isn't very well documented, so as somebody who was writing Odin just to explain the problem here, the easier option avoids trying to guess which of a dozen undocumented functions with names that may be related to hash maps is the "right" function to do what I meant, I can just write what I meant and turn on the feature flag to acknowledge that it involved allocation.
I can't reply to the reply to this one (guess the thread is getting too deep), but I just wanted to clarify that I'm not a rust critic, I use rust, I like rust, I have no problem with rust. OK great, moving on...
The lack of reply is probably because the thing you wanted to respond to was new.
This is a deliberate HN behaviour to discourage frantic conversations, like you might have if this was a Zoom call for example, or we'd had this disagreement in a bar (presumably a bar where there's a Compiler Explorer built in, or maybe literally Matt Godbolt is sat there with a laptop?)
Maybe it works? I have had some positive experiences.
If you know unsafe Rust the comparison to this Odin feature feels odd, but OK. Surely the Odin feature is more like when let-chains was unstable but you could tell the Rust nightly compiler you want that feature anyway ? Or... explicit_tail_calls which gives you a way to write explicit tail calls† in nightly Rust ?
† This is a very cool feature if you're a functional programmer using the "become" keyword, you get tail call optimisation but it's mandatory, if what you've written can't work as a tail call then it won't compile, if it could work it does.
First, that's whataboutism. Second, you are, actually. And what the other fellow said is not at all baseless, and he did back it up. GB is well known for being argumentative, highly opinionated, and rude. But people make allowances for those who put in the work, and GB certainly does.
Me being "well known" in general is news to me. However, the people I am that way are usually people like yourself. I am argumentative with people like yourself, however I try not to be "rude" but I am not always "nice". I think this is probably a cultural distinction where I make a distinction between Niceness and Politeness. Rudeness is the not-being-polite, rather than not-being-nice.
As for my "highly opinionated" things, honestly, I don't think I am that opinionated about many things, but I guess the ones I am on, they are the "well known" aspects. If I am wrong about something, I will gladly change my opinion given a good argument or set of facts.
First, no it isn't. What baseless accusation did I make?
I haven't seen the conversations he is referring to, he didn't link to or quote anything. It's just some general complaint about Bill, which may be true but who cares?
Thanks for sharing. Not knowing Odin's syntax yet, having had a quick look at the code, a few things are strange:
Are there two types of assignment?
p1[0] = 0
...
n := 0
What should this mean? The comma notation usually indicates a pair or left-to-right control flow (Python and C, respectively), but why (appear to) assign a pair to itself?
This probably means something else, but it reads odd.
car, cdr := car, cdr
If Odin is so similar to C, what are the "dark corners" where it outshines it?
>What should this mean? The comma notation usually indicates a pair or left-to-right control flow (Python >and C, respectively), but why (appear to) assign a pair to itself? This probably means something else, but it reads odd.
= is assignment and := is assignment and declaration.
x := 1 // create a new variable x with the value 1
x = 2 // assign 2 to x
y = 3 // error: y does not exist
You can explicitly give the variable a type by adding it before the =
x : u8 = 1 // a one byte unsigned integer with the value 1
There is also :: for constants.
> car, cdr := car, cdr
Odin has multiple assignment like Python, so this is a swap without temporary. edit: No, it isn't! Didn't read carefully. Swap would be
car, cdr = cdr, car
This one is because parameters are immutable in Odin, so to get a mutable copy in the function we have to declare it.
> If Odin is so similar to C, what are the "dark corners" where it outshines it?
Off the top of my head:
- No undefined behaviour
- Builtin string type, dynamic array type, slices
- Builtin map type
- Excellent tooling for 3D math: swizzling, matrix math, array programming
> When I posted this to lobste.rs, gingerBill (creator of Odin) was kind enough to make a more direct translation of the C code into Odin.
Glad he has helped you. Maybe he listened to me, maybe not, but last time (almost year ago?) I saw an interaction with him on GitHub, he was nothing short of an a**hole, and not in the sense of Linus or Theo. In fact, he was not educational, he was just like "Many problems. I could write this better, GTFO". I saw it on GitHub, so I am reluctant to submit a PR of any sort myself in before he tells me he can implement it better and rejects my PR with this reasoning as he did with someone else. Like yeah, of course you may be able to implement it better, whereas someone new to the language might not, even though I tried it (the rejected PR, which was supposed to end up in vendor/ not the core library, AFAIK) and it was fully functional (and without any leaks), and to my eyes it seemed fine as well, but maybe I do not know Odin enough. In fact, I probably do not know it as much as he does, but by his logic, everything should be implemented by him because he knows better. This experience (albeit not mine) was enough to put me off of Odin. The C3 lead developer, on the other hand, was extremely helpful here on HN and on GitHub as well.
I have a feeling he has helped you because of the article and some fame along with it. :)
So my comment reflects a negative publicity. I cannot find the GitHub link right now, but it is there as it cannot be deleted, AFAIK. Look around rejected PRs in / for vendor/, I think. I am not logged in to GitHub and I cannot do so at the moment.
Just my second-hand experience. Feel free to down-vote but please leave a comment afterwards. Not everyone and everything is sunshine and butterflies. The down-votes DO NOT invalidate anything. Or perhaps Bill's bots / fans are in play here. ;) God forbid someone voices negative experiences with a person. Only positives are allowed! I forgot...
> "The down-votes DO NOT invalidate anything. Or perhaps Bill's bots / fans are in play here"
"Please don't post insinuations about astroturfing, shilling, brigading, foreign agents, and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email hn@ycombinator.com and we'll look at the data." - https://news.ycombinator.com/newsguidelines.html
You half remember one blunt interaction that you conveniently can't find and you're dedicating your life to shitting on him and his project. How is that on-topic here?
First, I want to be clear that Ginger Bill has put in the work and stands behind his convictions. But convictions he does have, and being strongly and forcefully opinionated has consequences. Here's a summary from Gemini ... which really isn't objectionable at all. If you want specific examples of him getting into arguments with people or being dismissive, you'll have to dig for them yourself.
"Ginger Bill" refers to Bill Hall, the creator of the Odin programming language, who is known for his outspoken and opinionated comments on programming and software development. His argumentative style can be seen in his blog posts and social media, particularly on X (formerly Twitter), where he often presents strong opinions on programming aesthetics, language design, and the open-source software movement.
Examples of his argumentative style
Software is not traditional property: In a blog post titled "Unstructured Thoughts on the Problems of OSS/FOSS," Hall argues that intellectual property, specifically software, is not "property" in the traditional sense because it is "trivially copyable". This is a provocative stance that challenges common views on intellectual property rights.
Criticism of open-source ideals: In the same article, he asserts that the open-source software (OSS/FOSS) dream is just a "dream that cannot live up to its 'ideals'". He argues that many of the perceived benefits of OSS are merely hypotheses and that the movement is based on "blind-faith".
Aesthetics in programming: Hall has made seemingly non-negotiable declarations about coding style. On X, he once posted, "Code indentation that is anything but 2, 3, 4, or 8 characters wide, is objectively a bad style from a pure aesthetics standpoint". While humorous, it exemplifies his tendency to make definitive statements
on subjects that are often matters of convention.
Language semantics over syntax: He argues that the focus of language design should be on core semantics rather than "syntactic sugar". He believes that when the core semantics are good, the syntax will naturally follow and feel "joyful" to use.
Arguments against common practices: Hall is also known for taking firm positions against widely used programming practices, such as his blog post "Exceptions—And Why Odin Will Never Have Them".
Overall, his argumentative nature stems from a deep-seated philosophical position on software design and engineering, which he shares to provoke discussion and advocate for the principles he believes are best for the craft.
I did not personally mind Odin's exceptions, to be honest. I prefer Odin's way, and Go's way, too.
> you'll have to dig for them yourself.
Yeah I was referring to such specifics, but I will take a look at Discord perhaps.
> "Code indentation that is anything but 2, 3, 4, or 8 characters wide, is objectively a bad style from a pure aesthetics standpoint"
Those are just opinions. I prefer 2 spaces, or tab with 2 column width. I tend stick to one style in my codebase, consistently. I do not like anything longer than 2, because I have a small screen and I think it is just simply redundant. I can follow 2 column width indentation just fine. This is just my opinion. If I use tabs, people can choose their own, it is up to them.
Dude, I find it utterly offensive that you and the other guy keep referring to all these interactions with Bill where he was a mean boy, and yet the closest to an actual quote or reference is some Gemini slop? If you're going to be that lazy, it would be easier to not post anything at all.
> I am closing this PR because it would be quicker for me to write my own bindings than explain everything wrong with it and then hope they get fixed correctly.
The funny thing is that we are talking about a vendor library, one that does actually work (I tested it as I needed curl in Odin)! Seems like the major issues were purely stylistic.
BTW "Please try to keep the original naming conventions and DO NOT change it to Odin's core convention." and "Maybe remove the CURL prefix?" are contradictory.
It is "CURLOPT" in curl.h. "OPT" seems out of place. I am not even sure what I would have named it were I to follow his advice. You?
Is that really the whole reason for this grudge? He gave you a bunch of comments to work from! I was expecting a lot less from your description.
I don't find it too hard to figure out what he meant - he doesn't want to you change the case style of procedure calls, but he _does_ want you to remove redundant namespacing as in the CURL prefix.
Maybe you could have looked at some other vendored libraries to see how they handled things like constant naming and other formatting?
I posted the link and now the PR is getting filled with comments. Lord. This is why I did not want to look for and post the link to begin with!
Some guy did ask questions I would have asked, at least.
Back to the CURL prefix, what is wrong with it? It is how it is in curl.h and without it, it looks kind of meh. What would the "CURL" distinct type be without the CURL prefix? :P
I hope I did not make a mess just by posting the URL. I will remove it. I do not need more (supposedly trolls) in there and make more of a big fuss than I did on here.
I did, thank you. Please explain why would anyone (end user of library) ever want "curl.CURL_GLOBAL_ALL", for example? If anything, it should be private. If you really want to go there, sure. I think it is YOU who should think things through. I get that you are filled with hatred, but come on man. Think. Why would anyone want to call "curl.CURL_GLOBAL_ALL" from a binding which is supposed to be used as a high-level curl library? If it is possible (I have no idea) to make it private, then it should be made private. It is not intended to be used by the users of the library, is it? The higher level functions are the ones supposed to be used by them, and they seem to be named correctly from a quick glance.
If you reply, do so without ad hominems and with some respect. Thank you.
I used the word "childish" to describe posting comments about someones personality without any references or examples, and here you are doing the same but adding Gemini to the mix... and I'm the troll? :)
So there is me, jibal, who else is a troll according to you? And who is the one trying to restrict knowledge just because of trolls? I saw the questions on GitHub. They make sense and I am sure people would like to hear the answer. I know I do. Perhaps the PR guy does, too, Lord knows. I think it is unfair to everyone just because of your allegations, and kind of confirms the things that have been said, but the scope extends. Unfortunately.
What in the world... jibal was the one who called _me_ a troll, I never called anyone a troll. Lord knows what is happening in this comment section at this point.
I lost the plot, too, both on here and on GitHub. The PR got locked, too. This was not my intention, I hope it will not affect anyone, I kind of feel bad for the PR guy now. sighs. He has no idea about this mess.
Sorry to hear that! I haven’t had any such experience, quite the opposite.
But I’m also an old. If someone tells me my code is shit, 1) they are probably right, and 2) I don’t really care. I can probably look at their code and find flaws in it.
In the end, Odin is Bills project and he decides what goes into it, I’m fine with that.
From what I remember, it was supposed to land in vendor/ which is not the core standard library though. Additionally, it is one thing to say the code is shit, and another to say "too many things wrong, fuck off", all while the code did work properly! From what I recall the person said he will continue working on it anyway in his own git repository. I think he could have given pointers of these major flaws (I checked the code and I could not find anything either[1]), which could have not been too major if the code worked properly (there were test cases, it did actually work and there were no memory leaks either, FWIW).
> In the end, Odin is Bills project and he decides what goes into it, I’m fine with that.
Me too. I am just not going to contribute. No big deal.
> I haven’t had any such experience, quite the opposite.
Just to add some positive, too: I have had positive experiences with other contributors.
In any case, I follow the programming language's developers before I contribute, as you may have noticed.
[1] But then again, I do not know the language too well either. Those pointers would have helped me and many others.
My question to you, however, is this: what would have you done if he were to tell you that he can write your code way better (without any pointers) and that concludes the conversation? Would you not have expected at least SOMETHING as to what is wrong with it? Of course ultimately what he says and does is his own business, but I am asking you.
> Plenty of other languages and projects out there.
You are right. I do like Odin though, as a language, so it is a pity.
I don’t think he works for me. I am not paying him. To the contrary, if anything _I_ am in debt since I am using all this code that he put out there for free.
I guess there are a few things I could do in that situation. Move on to something else, try to figure out why he didn’t like it on my own, fork the language if it’s big enough and important enough to me.
But yeah, maybe he is busy? Maybe he thinks you are capable of working it out yourself?
Not to be too harsh about it, but yeah, that’s just the way it is sometimes. Maybe he was having a bad day, that happens to people.
> "what would have you done if he were to tell you that he can write your code way better (without any pointers) and that concludes the conversation?"
Depends on my mood; maybe go to the Odin Reddit, Discord or CodeReview StackExchange and say "GingerBill has rejected my PR for 'many problems' can I get some hints what, so I can make a better PR?" and then take my better PR back and update the original making it as clear as I can that I have made a good faith effort to improve it.
Or wait a couple of days (weeks?) and review my code with fresh eyes (and wait for the reviewer's mood to change).
Or reply "I'd be happy for you to rewrite it better, I just want the feature it doesn't have to be my code"
Or ask "Many problems, but how many of them are dealbreakers? Is there a route to a minimally viable commit which settles on a good enough interface, and the rest of the implementation can be improved later?"
Or ask "I'd hope you can write it better, you've been Odinning a lot longer than I have, can you point out some of the problems so I can learn more?"
Or if I was giving up on getting it committed, "You say you can write it better, so are you going to?"
> "Would you not have expected at least SOMETHING as to what is wrong with it?"
I have been on the internet long enough to be on both sides of "it's nice to be nice" and "where to start it's not even wrong" and to expect busy, capable, computer people to be time crunched and terse/blunt. There's a difference between "many problems" and "many problems, Get The Fuck Out". A difference between what Linus Torvalds and Erik Naggum used to do and a 3 second glance "too many problems to commit, rejected". Have you seen the accusations of what goes on behind closed doors in the C++ standards committee? Or Scheme world?[1] Does that put you off the languages or is that fine because it only happens to other people?
Progressive disclosure could say that if you cared and wanted to fix up the PR you would have engaged and asked, and if you didn't ask that suggests you weren't interested and that saved Bill's time writing a longer comment. I guess I expect that the Thing_I_Want is not something others care about and if I want to 'change the world' I will have to push some boulders up hill to get there, or push some people to drag their attention to my thing instead of whatever they are doing, and Thing_I_Want generally is not world changing enough to warrant that.
[1] I could go and find them and link them here, but I'm not going to because you might a) know, b) not care, and if I do then I'll get dragged into HN arguments about those accusations which isn't really relevant, but your grudge would be stronger if you had many documented examples showing a pattern of rude, cruel, damaging behaviour, rather than one example which you remember as being unfairly rude but can't find.
It is not my code, but since I want to know what is wrong with it, might as well ask around.
> it only happens to other people?
What I am talking about did happen to someone else, not me.
In any case, I will take your advice and ask around despite it not being my code, but I genuinely want to know what is wrong with it because I took a look at the code and I could not spot any issues with it, and I tested it, it works, so I wonder what really is wrong with the code despite its test cases passing, and the code seemingly being organized and seems to be Odin-style. He mentioned something about the person not knowing what "distinct" is, but he also said "many things are wrong, so many that he would rather just rewrite it himself" (which I doubt he has any intentions of doing). These issues surely cannot be such deal-breakers considering the code does run (without any memory leaks). I will ask around when I can be bothered.
> I genuinely want to know what is wrong with it ... when I can be bothered.
https://odin-lang.org/community/ - here's the forum, the IRC channel, the Discord invite, the subReddit link, or you could have commented in GitHub in the PR while you were looking at it.
All of these would be less effort than the comments you've made here in this thread, instead you've taken a second hand grudge and used it to give a small project a good kicking based on an exchange you haven't linked here for any reader here to form a judgement about, for reasons you don't understand and can't be bothered to find out, and then accused people of being bots and astroturfing. [I have followed two of Karl Zylinski's videos in Odin last winter; I have not used Odin in months. I have no stake in Odin].
How is that reasonable behaviour, a useful HN comment for HN readers, fair to GingerBill / Odin, or a step towards getting you the information you "genuinely want to know"?
It has been almost a year since I witnessed the incident. Ever since then I did not get back to it, but it stuck. As for reasonable, well that is debatable. Many people use the down-vote feature for shilling or the opposite of shilling. I do not find that reasonable, but it happens anyway. I have been down-voted to oblivion by bots before. Can I prove they were bots? Not really, but many people seemed to think so, too.
I am not going to continue on this conversation. Someone else have also said that he is famous for the thing I have brought up, so I am not alone with it, apparently.
Is it fair to him? No. Was he fair to the person submitting the PR? That is another no. Minimizing it by "probably had a bad day"? Is that reasonable? No, not to me. But then again, seems like it was not the only instance.
> All of these would be less effort than the comments you've made here in this thread
Fair enough. Perhaps I am just afraid of the reactions.
That explains why the C code is so neat. You don't see young'uns write such compact C code any more. Well done.
After years using higher-level languages, my C code has become verbose and clunky, when it doesn't necessarily have to be (and memory safety is no concern)
The antivirus program forced to be installed by my company does not allow .odin file to exist, as there is a ransomware which encrypts files into *.odin.
Of course, git cloning the ALE plugin (linter + languageserver) for VIM also fails as ALE has an .odin file in its repo.
Is there something inherent to Lisp that allows it to be implemented in so little code?
I believe I saw someone demonstrate that almost nothing in a Lisp implementation was written as a "built-in" language feature that required the underlying interpreter to provide the functionality.
I always think of this HN post every few years, as an aside, someone really needs to archive that page it links to because I wont be surprised when that site shuts down or deletes old content:
https://news.ycombinator.com/item?id=9699065
https://speakerdeck.com/nineties/creating-a-language-using-o...
This is super cool!
I could imagine writing a very basic forth or lisp compiler in assembler, but even that would be quite the project.
First off, you wouldn’t write an actual interpreter for lisp like this if you wanted to use it for anything serious, it’s very slow.
The parser is very simple thanks to the s-expressions, and the only builtin special forms really needed are quote, cond and lambda, that’s pretty much it. The only data structure is a list, so functions are just lists, function calls are lists etc.
Yes there's something inherent. Namely this: the ability to drop all sorts of requirements off the table, yet still call it some kind of Lisp.
It does not need to be compiled to be a Lisp. It doesn't need arbitrary precision integers. It doesn't need hash tables. Garbage collection doesn't have to work; it can just run out of space and terminate. It can just crash on errors without a trace. It doesn't need to report the line number where a syntax error likely began. You get the picture.
I’ll remove even more and _still_ call it a lisp and there is nothing you can do to stop me.
Any memory management solution will run out of space and terminate unless there is literally infinite memory available.
But I guess hash tables is what people think about when thinking about what makes something a lisp or not.
Whereas in contrast, you cannot have a race this kind of race for the bottom with most other languages; tripping over the other contestants to see who can remove the most features, yet still have Python or Java.
See?
There you go, mrweasel; I think we hit the nail on the head.
Lisp (and similarly, Forth) is closer to a mathematical construct than an actual language. We've had to wrap it in parentheses and named symbols to help make sense of it, to talk about it. Pairs, atoms, GCs, are all an implementation detail.
see previous discussions at https://news.ycombinator.com/item?id=14727881
quoting the submission verbatim:
The original paper of LISP by John McCarthy http://www-formal.stanford.edu/jmc/recursive.html
Or the more accessible explanation by Paul Graham http://www.paulgraham.com/rootsoflisp.html
This is my project! I made the Odin version to learn the language, not to create a 1:1 comparison. I 100% prefer Odin over C and will use it wherever I can where I would have otherwise used C.
Also I've moved it from Github to my own Forgejo instance: https://git.liten.app/krig/LISP
My impression of Odin is that it's a better C while still very much retaining the same flavor as C. It adds very little (no classes, no runtime) so porting from C is very straightforward, and it fixes a lot of the dark corners of C. It also seems to be pretty much finished as far as the language goes, so no big incompatible changes coming as far as I can tell.
I would say though that while the memory management story is vastly better than C^, it's still manual as fuck, so be prepared for that.
^: There's builtin test support, bounds checking and an optional leak detection allocator, plus as far as I know no UB.
Maybe the most interesting part is the semi-space garbage collector. The whole thing fits in a single screen:
https://git.liten.app/krig/LISP/src/branch/main/komplodin.od...
Andy Wingo has a good summary of how a very similar implementation works:
https://www.wingolog.org/archives/2022/12/10/a-simple-semi-s...
Does it get ride of undefined behavior and the tradition of obfuscating the code with monoletter identifiers?
Yes. There is no undefined behavior in Odin (afaik), and I haven’t seen many monoletter identifiers. There is a slice type and a for … in loop statement so that gets rid of most i:s and j:s.
> There is no undefined behavior in Odin
This mostly just ends up meaning that Odin's creator Ginger Bill will engage in pointless semantic arguments in which he defines away your problem.
There are places where C could reasonably have chosen to define what happens, or to make it Unspecified rather than Undefined, and so that's what Odin chooses, which is a meaningful benefit. However there are plenty of situations left in which what you've written would be UB in C and absolutely anything might happen, while in Odin absolutely anything might happen but Bill insists it isn't UB.
Well, without concrete examples this just sounds childish TBH.
But I haven’t looked very closely at it myself, hence the afaik qualifier.
So as a concrete example:
https://odin.godbolt.org/z/8onn4hxP1
This brief example makes a hash map, then it demonstrates that if we call a sub-routine which makes its own distinct hash map, that doesn't change ours, but, once we destroy our hash map and call the sub-routine again, we can still use the variable for our (destroyed) hash map (!) but doing so reveals the contents of that other hash map from the sub-routine instead in the cases I saw.
Now, in C or C++ if you do this that's Undefined Behaviour and the symptoms I saw (and which you're likely to see if you follow the link) are just one of arbitrarily many ways that could manifest.
In Rust of course the equivalent code won't compile because the hash map is gone so we can't just go around using it after that.
And in Odin, well, as Ginger Bill has explained Odin does not have Undefined Behaviour so... this has behaviour which er, Odin has not defined ? Does that make you feel warm and tingly or do you feel like Bill just wasted time arguing semantics?
Well, sure. If that’s what you mean by having UB then it’s trivially true for any language with a C FFI for example, or rust with unsafe. I guess what I consider UB is when the compiler exploits UB for optimizations, like discarding code that could invoke UB, which as far as I know odin doesn’t do.
> I guess what I consider UB is when the compiler exploits UB for optimizations, like discarding code that could invoke UB, which as far as I know odin doesn’t do.
This statement is incoherent. UB is undefined behavior, and it existed long before any compiler exploited it and isn't (circularly) defined by whether the Odin compiler exploits it.
Well, the statement is circular, colloquial speech doesn't have to be coherent. It's my understanding of what people generally mean when they complain about UB in the C standard, and it seems to be what gingerbill means too.
My take on what he is saying is that the odin compiler won't try to exploit that there is some behavior which is platform-defined or only knowable at runtime to do aggressive optimizations etc.
https://xcancel.com/TheGingerBill/status/1495004577531367425
To point out that use after free is possible in Odin is not really a gotcha unless you really are just arguing semantics. That's by design, just like use after free is possible in C or C++ or Rust too.
> To point out that use after free is possible in Odin is not really a gotcha unless you really are just arguing semantics
In a language with UB, the use after free is UB. Which explains the nonsensical results.
If you're pretty sure this all makes sense, I recommend one tiny tweak to further unsettle you, change either (but not both) of the int types in my example to u8 instead. Now the use after free also results in type confusion - Odin has no idea this isn't the same type and so the machine code generated is for one type but the actual bits are for a different type with a different layout.
Bill's go-to is to blame somebody else, it's the operating system, or even the CPU which should define what happens and so it's not his fault. The thread you linked does this. But for type confusion those are Odin's types, nobody else can define how Odin works, the answer must come from Bill. What is supposed to happen here? Linux didn't define your programming language, Intel didn't define your programming language, this is your fault Bill.
Your understanding is completely wrong. UB means "undefined behavior" -- behavior that is not specified by the language standard or the implementation. UB being exploited by the compiler is a separate issue. Saying that there is no UB is saying that there's no undefined behavior; it is certainly not merely saying that the compiler doesn't exploit it.
I programmed in C for over 30 years and was a member of the C Standards Committee, which originated the language about undefined behavior ... I know what I'm talking about.
> To point out that use after free is possible in Odin is not really a gotcha unless you really are just arguing semantics. That's by design, just like use after free is possible in C or C++ or Rust too.
This completely misses the point and is a failure to understand at every level. Being able to use memory after being freed is not by design -- no one intends it, no one wants it. It's undefined behavior, and a program that does it is buggy. The reason that it's possible is because it's so hard to detect or prevent. To do so requires escape analysis, lifetime declarations, borrow checking, etc. etc. And no, use after free is not possible in Rust--not in safe code. It's hard to respond to that statement without being rude, so I will say no more.
Well, first of all, I guess I am wrong! Hey, I'm not Bill, just a user of the language.
A couple of clarifications, though: I did mean unsafe rust, not the safe subset. No need to get rude!
Second of all, I am of course not under the illusion that Odin prevents use-after-free (and thus, technically, it does allow UB I guess). I just don't think Bill is either. So clearly he doesn't mean UB by the same definition as you do.
_My_ use of UB has always been in the context of what a compiler will do during optimization, and the discussion I've seen in the context of C compilers is that they perform optimizations that remove code or change code in surprising ways because the way the code was written technically resulted in UB. But I'm neither a spec writer or a compiler author, so I don't really care that much about the actual definition of the term.
Anyway, best of luck in convincing Bill to use the term correctly as well! I won't mention UB when talking about the benefits of Odin in the future. :)
> So clearly he doesn't mean UB by the same definition as you do.
Wrong.
> so I don't really care that much about the actual definition of the term.
Yes, it's evident that you don't care what's true or about being accurate.
> Anyway, best of luck in convincing Bill to use the term correctly as well!
He does use it correctly, but his claims that Odin has no UB are incorrect.
Over and out.
As someone who knows what they're talking about, I'm curious to hear from you, why you consider use-after-free an undefined behavior and not an unspecified behavior instead?
Because as far as I know both undefined behavior and unspecified behavior are the behaviors that aren't specified in the language standard nor the implementation. So what's the difference?
A useful example to consider might be an uninitialized integer in C++
In C++ 98 "int x; foo(x);" is Undefined Behaviour. We said there's an integer named x, then, without initializing x, we passed it as a parameter to the function foo, evaluating the uninitialized value, literally anything is allowed to happen. Program crashes, deletes all the JPEGs large than 15 kilobytes, displays "Boo!" on the screen, anything the program could have done is something it might now do.
In C++ 26 "int x; foo(x);" is merely Erroneous Behaviour. The value of x is Unspecified, but it does have a value. This program might pass any integer to foo -- perhaps your compiler provides a nice compiler setting to choose one, maybe the person building the program picked 814 and so this calls foo(814)
This constraint is an enormous difference. In a sense the Unspecified behaviour is defined, it's just not specific. That variable x will have some integer value, so, maybe zero, or 814, but it can't be a string, or negative infinity, and evaluating it will just do what it would do for its value, whatever that was.
If you don't find that example illuminating enough, try another from a very different language, a data race in Java
Now, in C++ (or Odin though of course Ginger Bill will insist otherwise ad nauseum) the data race is UB. Game over, you lose, anything might happen.
But in Java the data race has Unspecified behaviour. Specifically, when the race happens the variable we raced has some definite value and it's a value it definitely could have had at or before this moment in a sequentially consistent program. So e.g. maybe we're counting clowns, we started from zero, thread A is counting 800 clowns, thread B is counting 600 clowns, but the threads race the same counter, legitimate values we might see at the end include zero all the way through 1400 clowns. -1 isn't possible, 1600 isn't possible, but 1234 is entirely plausible. That's Unspecified behaviour.
Sorry to pop in but I kind of need to clarify my own position even further here:
Odin has "undefined behaviour". SHOCK! HORROR!
The thing I bring up that people think I go "ad nauseum" about (like yourself) is just that the term "undefined behaviour" is in itself "undefined". This is why I try to make as many distinctions about the different kinds of "UB" out there, and even what the "U" means in "UB".
To quote you from earlier:
> ...Ginger Bill will engage in pointless semantic arguments in which he defines away your problem.
Yes... the entire discussion about "UB" is fundamentally a semantic thing, LITERALLY it's an argument about semantics. And if I can "define away [the] problem" in certain cases, then it's literally not Undefined Behaviour. I am not sure what else to say to your point here. The entire discussion around UB is fundamentally a semantics game and always will be. And when people complain about the "semantics game" part, they have not understood the problem in the first place.
Interestingly, the C++26 example you give is a brilliant example of this, it's an Erroneous Behaviour, not necessarily "undefined" or "unspecified".
In the case of race conditions in Odin? This is pretty much a brilliant example of _Unobservable_ behaviour because Odin shares a similar memory model to C, and thus it has to make assumptions. And when the programmer violates certain assumptions, the compiler cannot observe the broken code that easily, and thus it can easily produce unexpected behaviour due to it being unobservable.
I know have said things in passing, but it's a question of what to tell people. A lot of the people who bring up examples of UB bring up are usually TRIVIALLY definable, and things we have probably already defined in Odin (e.g. integer (under|over)flowing, integer division by zero, etc), but when I say what Odin's defined it to, they usually go one of two ways, either "I don't like that definition" or "but I wanted to use these specific passes in the compiler backed to do 'optimizations' with", both of which actually annoys me because I am not discussing with someone serious. In the latter case, "passes" are just algorithms that do things; they are not intrinsically "optimizations". To "optimize" something, you need well defined rules to optimize within, if the rules are ill-defined or arbitrary chosen, then how the heck can anyone call that "optimization"?
> In a language with UB, the use after free is UB. Which explains the nonsensical results. [https://odin.godbolt.org/z/8onn4hxP1]
Even the case of "use after free" that you brought up earlier, it is something which is not a language thing in certain cases, especially when Odin has custom allocators which are defined at the user-level. The language itself knows nothing about of the allocators and how they work, it cannot. So yes, Odin allows for "use after free" but and? We are not enforcing a specific memory allocation strategy at the language level, like other languages. But it could be technically well defined at the algorithm level of that specific allocator. Which leads to my many problem with this discussion: are flawed algorithms/code considered Undefined Behaviour now and thus make the language "UB"? Why is not just shitty code?
And I will literally go... your "nonsensical results" are just... allocator specific behaviour. Yes it's "nonsensical" to you, but Odin isn't C so stop applying its approach to things to it. C has its standard library as part of its spec and defines how `malloc` et al work. Odin doesn't have its core library as part of the spec and never will (base library will to a certain extent with room for implementation specified behaviour for certain defaults, e.g. what is the default `context.allocator` or `context.assertion_failure_proc`, etc).
> Bill's go-to is to blame somebody else...
No... my go-to response is to say where it should be defined, and if it is possible to define at _any_ level (if at all). So even in your case, you are blaming the compiler for something it cannot know if this is undefined or erroneous because it cannot know what you are doing, but the allocator itself could allow for it. `delete` could be a complete no-op and is for many allocators.
It's all about responsibility. What is responsible for what. So if you thin that's "blame", whatever, but that's the question. Is the compiler _responsible_ for "use-after-free" bugs? In some languages, yes. In other languages, no.
> Linux didn't define your programming language, Intel didn't define your programming language, this is your fault Bill.
No but they all put bounds on what is possible in the first place. They literally define the arena the language takes place in, and thus you are subject to their whims, regardless of my feelings about them. No it's not "my fault" anywhere, it's just a thing.
----------
If you want to discuss with me further on this, I'd be happy to do so. Other mediums other than a comment on Hacker News would be preferrable.
----------
P.S. nowhere on the Odin website itself do we say Odin has no "UB" nor even suggest it. So there is no official position on "UB" for Odin anywhere. My comments on Twitter or other social medias should not be taken as official in any way, and be considered closer to "conversation", especially Twitter.
P.P.S. Some of possible meanings of "U": Undefined (i.e. not-defined), Undefinable, Unspecified, Underspecified, Unobservable, Unknown, Erroneous (I know it's not a U), Unimplemented, Ill-Defined (different to Undefined or Underspecified, and again not a U), Defined-At-A-Different-Level (e.g. language, compiler, platform, core library, user's code, etc, and again it's not a U). It's an absolutely mess and things just need to be defined better about what you are talking about.
This is a simple use after free on the stack. Is that UB?
Yes, of course ... the content of freed memory, on the stack or otherwise, is not defined. (And this is not in fact on the stack.)
1. I'm fairly certain you have to use make to get into heap.
2. Odin 0s out memory when declaring a variable unless you explicitly state so with ---. This defines the state of memory when allocated.
Ordinarily you'd be correct that you need the weird make overload, but I had no cause to invoke make I just told Odin that we don't care and it's fine, check the first line. Whether that feature is a good idea in this language I couldn't say.
Odin's decision to zero initialize local variables isn't relevant here.
Huh. Wasn't aware of that feature. Good to know.
I didn't fully flesh out the initializing local variables: What part of your code is undefined? You deleted the memory, and the compiler reused it. Then you re-accessed that same memory. That's just part of working with computers. The initialization comment was supposed to be from creating data to releasing it is defined. To be compliant with the Odin compiler spec, it's defined from start to end.
Not OP but:
> What part of your code is undefined?
Using a variable (`some_map` in this case) after `delete`ing it doesn't seem something languages usually define in their specification. Does Odin define that?
I don't really get the distinction between adding the dynamic-literals feature flag and using unsafe in Rust? Like, if he had called it #+unsafe dynamic-literals, would that have been better?
I'm going to guess that you've never written, and perhaps never read, any unsafe Rust, because you (in common with several Rust critics) seem to be imagining it like a switch you can turn on somehow to disable the safety rules, and that's not what it is at all.
This Odin feature flag just allows me to write what I meant in Odin, I can write it all out by hand using make and so on without the feature flag, but it's more annoying to spell that all out which presumably was the impetus for this feature flag in the first place. The flag didn't somehow "cause" the unsafety, that's an insane take.
Odin isn't very well documented, so as somebody who was writing Odin just to explain the problem here, the easier option avoids trying to guess which of a dozen undocumented functions with names that may be related to hash maps is the "right" function to do what I meant, I can just write what I meant and turn on the feature flag to acknowledge that it involved allocation.
I can't reply to the reply to this one (guess the thread is getting too deep), but I just wanted to clarify that I'm not a rust critic, I use rust, I like rust, I have no problem with rust. OK great, moving on...
The lack of reply is probably because the thing you wanted to respond to was new.
This is a deliberate HN behaviour to discourage frantic conversations, like you might have if this was a Zoom call for example, or we'd had this disagreement in a bar (presumably a bar where there's a Compiler Explorer built in, or maybe literally Matt Godbolt is sat there with a laptop?)
Maybe it works? I have had some positive experiences.
If you know unsafe Rust the comparison to this Odin feature feels odd, but OK. Surely the Odin feature is more like when let-chains was unstable but you could tell the Rust nightly compiler you want that feature anyway ? Or... explicit_tail_calls which gives you a way to write explicit tail calls† in nightly Rust ?
† This is a very cool feature if you're a functional programmer using the "become" keyword, you get tail call optimisation but it's mandatory, if what you've written can't work as a tail call then it won't compile, if it could work it does.
Isn't there a cheap way to implement a gentle refusal to compile a code if it is not garantee that it won't prevent such a behavior?
No, definitely not. The solution is something like Rust, with its lifetimes and borrow checker ... not cheap at all.
You mean a borrow checker? That exists, but not for Odin.
> Well, without concrete examples this just sounds childish TBH.
Please don't be pointlessly insulting. The description matches many people's experience.
I'm not the one throwing baseless accusations around.
"He was mean to me once" isn't that interesting, especially without anything concrete to back it up.
First, that's whataboutism. Second, you are, actually. And what the other fellow said is not at all baseless, and he did back it up. GB is well known for being argumentative, highly opinionated, and rude. But people make allowances for those who put in the work, and GB certainly does.
Me being "well known" in general is news to me. However, the people I am that way are usually people like yourself. I am argumentative with people like yourself, however I try not to be "rude" but I am not always "nice". I think this is probably a cultural distinction where I make a distinction between Niceness and Politeness. Rudeness is the not-being-polite, rather than not-being-nice.
As for my "highly opinionated" things, honestly, I don't think I am that opinionated about many things, but I guess the ones I am on, they are the "well known" aspects. If I am wrong about something, I will gladly change my opinion given a good argument or set of facts.
First, no it isn't. What baseless accusation did I make?
I haven't seen the conversations he is referring to, he didn't link to or quote anything. It's just some general complaint about Bill, which may be true but who cares?
Can we stop digression and keep the thread focused on undefined behaviors and practices that makes code less straight forward to read, please?
Nothing you say is true. I'm done with you.
Thanks for sharing. Not knowing Odin's syntax yet, having had a quick look at the code, a few things are strange:
Are there two types of assignment?
What should this mean? The comma notation usually indicates a pair or left-to-right control flow (Python and C, respectively), but why (appear to) assign a pair to itself? This probably means something else, but it reads odd. If Odin is so similar to C, what are the "dark corners" where it outshines it?> Are there two types of assignment?
>
> p1[0] = 0
> ...
> n := 0
>What should this mean? The comma notation usually indicates a pair or left-to-right control flow (Python >and C, respectively), but why (appear to) assign a pair to itself? This probably means something else, but it reads odd.
= is assignment and := is assignment and declaration.
You can explicitly give the variable a type by adding it before the = There is also :: for constants.> car, cdr := car, cdr
Odin has multiple assignment like Python, so this is a swap without temporary. edit: No, it isn't! Didn't read carefully. Swap would be
This one is because parameters are immutable in Odin, so to get a mutable copy in the function we have to declare it.> If Odin is so similar to C, what are the "dark corners" where it outshines it?
Off the top of my head:
- No undefined behaviour
- Builtin string type, dynamic array type, slices
- Builtin map type
- Excellent tooling for 3D math: swizzling, matrix math, array programming
- Bounds checking
- Tooling for memory management: leak detection, temp allocator, arena allocators
- Builtin unit test framework
- Tagged unions with exhaustiveness checked switch statement
- for ... in loop syntax
It lacks a conclusion, except I can see that 750>500
At first look the Odin version seems less verbose.
The function/struct definition in C could be placed in a header.
> When I posted this to lobste.rs, gingerBill (creator of Odin) was kind enough to make a more direct translation of the C code into Odin.
Glad he has helped you. Maybe he listened to me, maybe not, but last time (almost year ago?) I saw an interaction with him on GitHub, he was nothing short of an a**hole, and not in the sense of Linus or Theo. In fact, he was not educational, he was just like "Many problems. I could write this better, GTFO". I saw it on GitHub, so I am reluctant to submit a PR of any sort myself in before he tells me he can implement it better and rejects my PR with this reasoning as he did with someone else. Like yeah, of course you may be able to implement it better, whereas someone new to the language might not, even though I tried it (the rejected PR, which was supposed to end up in vendor/ not the core library, AFAIK) and it was fully functional (and without any leaks), and to my eyes it seemed fine as well, but maybe I do not know Odin enough. In fact, I probably do not know it as much as he does, but by his logic, everything should be implemented by him because he knows better. This experience (albeit not mine) was enough to put me off of Odin. The C3 lead developer, on the other hand, was extremely helpful here on HN and on GitHub as well.
I have a feeling he has helped you because of the article and some fame along with it. :)
So my comment reflects a negative publicity. I cannot find the GitHub link right now, but it is there as it cannot be deleted, AFAIK. Look around rejected PRs in / for vendor/, I think. I am not logged in to GitHub and I cannot do so at the moment.
Just my second-hand experience. Feel free to down-vote but please leave a comment afterwards. Not everyone and everything is sunshine and butterflies. The down-votes DO NOT invalidate anything. Or perhaps Bill's bots / fans are in play here. ;) God forbid someone voices negative experiences with a person. Only positives are allowed! I forgot...
> "The down-votes DO NOT invalidate anything. Or perhaps Bill's bots / fans are in play here"
"Please don't post insinuations about astroturfing, shilling, brigading, foreign agents, and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email hn@ycombinator.com and we'll look at the data." - https://news.ycombinator.com/newsguidelines.html
You half remember one blunt interaction that you conveniently can't find and you're dedicating your life to shitting on him and his project. How is that on-topic here?
Many people have had similar experiences with GB ... he's famous for it.
And here I thought this was a one time thing (someone said he may have had a bad day). :|
Do you have any specifics?
First, I want to be clear that Ginger Bill has put in the work and stands behind his convictions. But convictions he does have, and being strongly and forcefully opinionated has consequences. Here's a summary from Gemini ... which really isn't objectionable at all. If you want specific examples of him getting into arguments with people or being dismissive, you'll have to dig for them yourself.
"Ginger Bill" refers to Bill Hall, the creator of the Odin programming language, who is known for his outspoken and opinionated comments on programming and software development. His argumentative style can be seen in his blog posts and social media, particularly on X (formerly Twitter), where he often presents strong opinions on programming aesthetics, language design, and the open-source software movement.
Examples of his argumentative style
Software is not traditional property: In a blog post titled "Unstructured Thoughts on the Problems of OSS/FOSS," Hall argues that intellectual property, specifically software, is not "property" in the traditional sense because it is "trivially copyable". This is a provocative stance that challenges common views on intellectual property rights.
Criticism of open-source ideals: In the same article, he asserts that the open-source software (OSS/FOSS) dream is just a "dream that cannot live up to its 'ideals'". He argues that many of the perceived benefits of OSS are merely hypotheses and that the movement is based on "blind-faith".
Aesthetics in programming: Hall has made seemingly non-negotiable declarations about coding style. On X, he once posted, "Code indentation that is anything but 2, 3, 4, or 8 characters wide, is objectively a bad style from a pure aesthetics standpoint". While humorous, it exemplifies his tendency to make definitive statements on subjects that are often matters of convention.
Language semantics over syntax: He argues that the focus of language design should be on core semantics rather than "syntactic sugar". He believes that when the core semantics are good, the syntax will naturally follow and feel "joyful" to use.
Arguments against common practices: Hall is also known for taking firm positions against widely used programming practices, such as his blog post "Exceptions—And Why Odin Will Never Have Them". Overall, his argumentative nature stems from a deep-seated philosophical position on software design and engineering, which he shares to provoke discussion and advocate for the principles he believes are best for the craft.
I have read the post about exceptions: https://www.gingerbill.org/article/2018/09/05/exceptions-and....
I did not personally mind Odin's exceptions, to be honest. I prefer Odin's way, and Go's way, too.
> you'll have to dig for them yourself.
Yeah I was referring to such specifics, but I will take a look at Discord perhaps.
> "Code indentation that is anything but 2, 3, 4, or 8 characters wide, is objectively a bad style from a pure aesthetics standpoint"
Those are just opinions. I prefer 2 spaces, or tab with 2 column width. I tend stick to one style in my codebase, consistently. I do not like anything longer than 2, because I have a small screen and I think it is just simply redundant. I can follow 2 column width indentation just fine. This is just my opinion. If I use tabs, people can choose their own, it is up to them.
Dude, I find it utterly offensive that you and the other guy keep referring to all these interactions with Bill where he was a mean boy, and yet the closest to an actual quote or reference is some Gemini slop? If you're going to be that lazy, it would be easier to not post anything at all.
https://anthonymoser.github.io/writing/ai/haterdom/2025/08/2...
So you feel offended on behalf of someone else?
I found the comment(s):
[REDACTED]
> I am closing this PR because it would be quicker for me to write my own bindings than explain everything wrong with it and then hope they get fixed correctly.
The funny thing is that we are talking about a vendor library, one that does actually work (I tested it as I needed curl in Odin)! Seems like the major issues were purely stylistic.
BTW "Please try to keep the original naming conventions and DO NOT change it to Odin's core convention." and "Maybe remove the CURL prefix?" are contradictory.
It is "CURLOPT" in curl.h. "OPT" seems out of place. I am not even sure what I would have named it were I to follow his advice. You?
Is that really the whole reason for this grudge? He gave you a bunch of comments to work from! I was expecting a lot less from your description.
I don't find it too hard to figure out what he meant - he doesn't want to you change the case style of procedure calls, but he _does_ want you to remove redundant namespacing as in the CURL prefix.
Maybe you could have looked at some other vendored libraries to see how they handled things like constant naming and other formatting?
I posted the link and now the PR is getting filled with comments. Lord. This is why I did not want to look for and post the link to begin with!
Some guy did ask questions I would have asked, at least.
Back to the CURL prefix, what is wrong with it? It is how it is in curl.h and without it, it looks kind of meh. What would the "CURL" distinct type be without the CURL prefix? :P
I hope I did not make a mess just by posting the URL. I will remove it. I do not need more (supposedly trolls) in there and make more of a big fuss than I did on here.
> Back to the CURL prefix, what is wrong with it?
It prevents stuttering when using it `curl.CURL_*`.
> What would the "CURL" distinct type be without the CURL prefix?
`CURL` isn't a prefix there.
Take more time to think things through.
I did, thank you. Please explain why would anyone (end user of library) ever want "curl.CURL_GLOBAL_ALL", for example? If anything, it should be private. If you really want to go there, sure. I think it is YOU who should think things through. I get that you are filled with hatred, but come on man. Think. Why would anyone want to call "curl.CURL_GLOBAL_ALL" from a binding which is supposed to be used as a high-level curl library? If it is possible (I have no idea) to make it private, then it should be made private. It is not intended to be used by the users of the library, is it? The higher level functions are the ones supposed to be used by them, and they seem to be named correctly from a quick glance.
If you reply, do so without ad hominems and with some respect. Thank you.
Last question I'll answer, because you aren't doing any of this is good faith.
You mean `curl.GLOBAL_ALL`, and it's for https://curl.se/libcurl/c/curl_global_init.html
My question still stands and has not been answered.
> So you feel offended on behalf of someone else?
It's called trolling. He hasn't made a single productive comment.
I used the word "childish" to describe posting comments about someones personality without any references or examples, and here you are doing the same but adding Gemini to the mix... and I'm the troll? :)
I do not disagree.
I'm offended by the Gemini slop!
So there is me, jibal, who else is a troll according to you? And who is the one trying to restrict knowledge just because of trolls? I saw the questions on GitHub. They make sense and I am sure people would like to hear the answer. I know I do. Perhaps the PR guy does, too, Lord knows. I think it is unfair to everyone just because of your allegations, and kind of confirms the things that have been said, but the scope extends. Unfortunately.
What in the world... jibal was the one who called _me_ a troll, I never called anyone a troll. Lord knows what is happening in this comment section at this point.
I lost the plot, too, both on here and on GitHub. The PR got locked, too. This was not my intention, I hope it will not affect anyone, I kind of feel bad for the PR guy now. sighs. He has no idea about this mess.
If I find it and I post it, would that make it OK?
I did, I posted it, and someone already commented to each one of the reviews and comments. :|
I removed the link now.
Sorry to hear that! I haven’t had any such experience, quite the opposite.
But I’m also an old. If someone tells me my code is shit, 1) they are probably right, and 2) I don’t really care. I can probably look at their code and find flaws in it.
In the end, Odin is Bills project and he decides what goes into it, I’m fine with that.
From what I remember, it was supposed to land in vendor/ which is not the core standard library though. Additionally, it is one thing to say the code is shit, and another to say "too many things wrong, fuck off", all while the code did work properly! From what I recall the person said he will continue working on it anyway in his own git repository. I think he could have given pointers of these major flaws (I checked the code and I could not find anything either[1]), which could have not been too major if the code worked properly (there were test cases, it did actually work and there were no memory leaks either, FWIW).
> In the end, Odin is Bills project and he decides what goes into it, I’m fine with that.
Me too. I am just not going to contribute. No big deal.
> I haven’t had any such experience, quite the opposite.
Just to add some positive, too: I have had positive experiences with other contributors.
In any case, I follow the programming language's developers before I contribute, as you may have noticed.
[1] But then again, I do not know the language too well either. Those pointers would have helped me and many others.
> Me too. I am just not going to contribute. No big deal.
Makes sense! Plenty of other languages and projects out there.
My question to you, however, is this: what would have you done if he were to tell you that he can write your code way better (without any pointers) and that concludes the conversation? Would you not have expected at least SOMETHING as to what is wrong with it? Of course ultimately what he says and does is his own business, but I am asking you.
> Plenty of other languages and projects out there.
You are right. I do like Odin though, as a language, so it is a pity.
I don’t think he works for me. I am not paying him. To the contrary, if anything _I_ am in debt since I am using all this code that he put out there for free.
I guess there are a few things I could do in that situation. Move on to something else, try to figure out why he didn’t like it on my own, fork the language if it’s big enough and important enough to me.
But yeah, maybe he is busy? Maybe he thinks you are capable of working it out yourself?
Not to be too harsh about it, but yeah, that’s just the way it is sometimes. Maybe he was having a bad day, that happens to people.
> "what would have you done if he were to tell you that he can write your code way better (without any pointers) and that concludes the conversation?"
Depends on my mood; maybe go to the Odin Reddit, Discord or CodeReview StackExchange and say "GingerBill has rejected my PR for 'many problems' can I get some hints what, so I can make a better PR?" and then take my better PR back and update the original making it as clear as I can that I have made a good faith effort to improve it.
Or wait a couple of days (weeks?) and review my code with fresh eyes (and wait for the reviewer's mood to change).
Or reply "I'd be happy for you to rewrite it better, I just want the feature it doesn't have to be my code"
Or ask "Many problems, but how many of them are dealbreakers? Is there a route to a minimally viable commit which settles on a good enough interface, and the rest of the implementation can be improved later?"
Or ask "I'd hope you can write it better, you've been Odinning a lot longer than I have, can you point out some of the problems so I can learn more?"
Or if I was giving up on getting it committed, "You say you can write it better, so are you going to?"
> "Would you not have expected at least SOMETHING as to what is wrong with it?"
I have been on the internet long enough to be on both sides of "it's nice to be nice" and "where to start it's not even wrong" and to expect busy, capable, computer people to be time crunched and terse/blunt. There's a difference between "many problems" and "many problems, Get The Fuck Out". A difference between what Linus Torvalds and Erik Naggum used to do and a 3 second glance "too many problems to commit, rejected". Have you seen the accusations of what goes on behind closed doors in the C++ standards committee? Or Scheme world?[1] Does that put you off the languages or is that fine because it only happens to other people?
Progressive disclosure could say that if you cared and wanted to fix up the PR you would have engaged and asked, and if you didn't ask that suggests you weren't interested and that saved Bill's time writing a longer comment. I guess I expect that the Thing_I_Want is not something others care about and if I want to 'change the world' I will have to push some boulders up hill to get there, or push some people to drag their attention to my thing instead of whatever they are doing, and Thing_I_Want generally is not world changing enough to warrant that.
[1] I could go and find them and link them here, but I'm not going to because you might a) know, b) not care, and if I do then I'll get dragged into HN arguments about those accusations which isn't really relevant, but your grudge would be stronger if you had many documented examples showing a pattern of rude, cruel, damaging behaviour, rather than one example which you remember as being unfairly rude but can't find.
It is not my code, but since I want to know what is wrong with it, might as well ask around.
> it only happens to other people?
What I am talking about did happen to someone else, not me.
In any case, I will take your advice and ask around despite it not being my code, but I genuinely want to know what is wrong with it because I took a look at the code and I could not spot any issues with it, and I tested it, it works, so I wonder what really is wrong with the code despite its test cases passing, and the code seemingly being organized and seems to be Odin-style. He mentioned something about the person not knowing what "distinct" is, but he also said "many things are wrong, so many that he would rather just rewrite it himself" (which I doubt he has any intentions of doing). These issues surely cannot be such deal-breakers considering the code does run (without any memory leaks). I will ask around when I can be bothered.
> I genuinely want to know what is wrong with it ... when I can be bothered.
https://odin-lang.org/community/ - here's the forum, the IRC channel, the Discord invite, the subReddit link, or you could have commented in GitHub in the PR while you were looking at it.
All of these would be less effort than the comments you've made here in this thread, instead you've taken a second hand grudge and used it to give a small project a good kicking based on an exchange you haven't linked here for any reader here to form a judgement about, for reasons you don't understand and can't be bothered to find out, and then accused people of being bots and astroturfing. [I have followed two of Karl Zylinski's videos in Odin last winter; I have not used Odin in months. I have no stake in Odin].
How is that reasonable behaviour, a useful HN comment for HN readers, fair to GingerBill / Odin, or a step towards getting you the information you "genuinely want to know"?
It has been almost a year since I witnessed the incident. Ever since then I did not get back to it, but it stuck. As for reasonable, well that is debatable. Many people use the down-vote feature for shilling or the opposite of shilling. I do not find that reasonable, but it happens anyway. I have been down-voted to oblivion by bots before. Can I prove they were bots? Not really, but many people seemed to think so, too.
I am not going to continue on this conversation. Someone else have also said that he is famous for the thing I have brought up, so I am not alone with it, apparently.
Is it fair to him? No. Was he fair to the person submitting the PR? That is another no. Minimizing it by "probably had a bad day"? Is that reasonable? No, not to me. But then again, seems like it was not the only instance.
> All of these would be less effort than the comments you've made here in this thread
Fair enough. Perhaps I am just afraid of the reactions.
> But I’m also an old.
That explains why the C code is so neat. You don't see young'uns write such compact C code any more. Well done.
After years using higher-level languages, my C code has become verbose and clunky, when it doesn't necessarily have to be (and memory safety is no concern)
That's the nice thing about a little side project, I can just have fun and noodle away at it without worrying about safety or comments ;)
750 lines and 0 comments.
Some day I might write a walkthrough of it, but it’s just a toy really.
The antivirus program forced to be installed by my company does not allow .odin file to exist, as there is a ransomware which encrypts files into *.odin.
Of course, git cloning the ALE plugin (linter + languageserver) for VIM also fails as ALE has an .odin file in its repo.