FWIW, the Odin compiler seems to be written in C++. Are there any plans to make it self hosted?
I like Odin
91–100 of 211 posts
Re: I like Odin
#92Re: I like Odin
#93Earlier quoted context omitted.
By "manual memory management", I think of explicitly allocating and freeing memory. Assuming you're thinking of the same thing, are you suggesting that the compiler (or other static analysis) could catch all of the issues you listed? If so, the natural question is, why is it necessary to manually insert the allocations and frees, if the compiler knows where they are supposed to go? This path leads you to something li…
An additional tradeoff is that many safe data structures or algorithms are impossible to implement in safe rust. Doubly linked lists being the canonical example. However I feel like the juice is very much worth the squeeze and most rust developers won’t run into these limitations regularly.
Yeah, but I think this is also captured under the complexity trade off. It is possible create a correct safe interface over an unsafe data structure, but it is complex to do so.
Re: I like Odin
#94Earlier quoted context omitted.
You can have safe manual memory management. The main cases of bugs are: 1. Null pointer deref. Can be fixed by having optional types and requiring that possibly null pointers have to be wrapped in them. 2. Out of bounds references. Can be fixed by making the type system track how big all objects are, and having the compiler insert bounds checking. 3. Use after free. Can be fixed by the free function zero'ing heap obj…
By "manual memory management", I think of explicitly allocating and freeing memory. Assuming you're thinking of the same thing, are you suggesting that the compiler (or other static analysis) could catch all of the issues you listed? If so, the natural question is, why is it necessary to manually insert the allocations and frees, if the compiler knows where they are supposed to go? This path leads you to something li…
GP's solutions to problems 1 and 2 are the same as Rust's; the difference is problem 3 ("temporal memory safety"). Rust solves this problem with statically analyzed lifetimes, which, in addition to the safety and correctness advantages of compile-time checking, also permit RAII (which answers your "natural question" with "no, it's not necessary to do that"), which makes programming more pleasant. The disadvantage is, as you said, language-level complexity, since it's not enough for the programmer to be personally satisfied that the lifetimes are correct; they have to be represented in the code in a way that satisfies the borrow checker.
GP's proposal is to drop lifetimes and RAII (thereby simplifying the language semantics), make the programmer responsible for allocations and frees (as in C), and solve the temporal memory safety problem by doing additional work at runtime to ensure that use-after-frees reliably crash the process instead of overwriting return addresses or doing other arbitrarily bad things. Whether this is more fun to program in than RAII depends on whether you think it's better to suffer from too much abstraction or too little; people have sharply diverging intuitions on this and it's been a holy war since forever and it probably always will be.
The clearer-cut problem is that such a language would be slower than C or Rust, both because freeing memory involves extra work that C and Rust programs don't have to do, and because the requirement that use-after-frees must reliably behave a specific way inhibits optimization, since the compiler can't assume that use-after-frees don't occur. Also, using memory from a small allocation that's been zeroed out doesn't reliably crash the process unless a pointer in that allocation is dereferenced, and even then, this (contra point 1) would require the compiler to assume that null pointer dereferences can happen and must segfault, which, again, inhibits optimization.
Re: I like Odin
#95Earlier quoted context omitted.
Either a reference to Abstract Machine from the standards, or something suggesting the processor is a C virtual machine.
Interesting article: "C Is Not a Low-level Language" ( https://queue.acm.org/detail.cfm?id=3212479 )
I have read that.
While I feel that article is being too harsh on C, it would be interesting to have cache intrinsics just like we have SIMD intrinsics. I would imagine that would be more complex to implement, however.
Re: I like Odin
#96I'm happy to see Odin chose snake_case instead of camelCase. At one time Zig debated switching to snake case, but that ship has sailed [0], sadly. It seems like a small bike-shed level comment, but when I consider the code I have left in me, I'd like it to look as nice as possible. 0 https://github.com/ziglang/zig/issues/1097
curious, why do you prefer snake_case to kebab-case?
Re: I like Odin
#97Earlier quoted context omitted.
You can have safe manual memory management. The main cases of bugs are: 1. Null pointer deref. Can be fixed by having optional types and requiring that possibly null pointers have to be wrapped in them. 2. Out of bounds references. Can be fixed by making the type system track how big all objects are, and having the compiler insert bounds checking. 3. Use after free. Can be fixed by the free function zero'ing heap obj…
By "manual memory management", I think of explicitly allocating and freeing memory. Assuming you're thinking of the same thing, are you suggesting that the compiler (or other static analysis) could catch all of the issues you listed? If so, the natural question is, why is it necessary to manually insert the allocations and frees, if the compiler knows where they are supposed to go? This path leads you to something li…
> Assuming you're thinking of the same thing
Yes.
> are you suggesting that the compiler (or other static analysis) could catch all of the issues you listed?
Yes, the compiler for the first two and the standard library's heap implementation for the third.
> This path leads you to something like Rust
There are stops along this path before you get to Rust. If you just add the 3 things I mention above to a C like language, it would still be perfectly possible to leak memory. But that isn't a safety problem.
The 3 things don't include a borrow checker. You could still make doubly linked list and graph data-structures.
Re: I like Odin
#98I think Odin just doesn't do enough. The improvements over C are there, but imho too small to justify/motivate a large-scale change.
And personally I think (!) there is no reason to introduce a new programming language without RAII these days. If you don't solve memory management any more than C did (not), then you are ignoring the biggest problem that needs solving and every replacement that does address this problem looks more attractive.
Re: I like Odin
#99Earlier quoted context omitted.
How is telling you exactly what was fixed not informative? I don't understand what you want.
What was broken? How it was broken? Why it was fixed this way? That information is vital during "git blame". Take a look at the commit histories of the other projects I've linked. Their commit messages are much more elaborate.
>What was broken?
Re: I like Odin
#100Drats, not the Norse deity. In case you're also disappointed, I recommend Votan by John James
https://books.google.com/books/about/Votan.html?id=y-OlAwAAQ...
"""
In the second century AD, a Greek nobleman is travelling and living abroad in Germany while carrying on an affair with a military man's wife. When discovered, he takes an emergency business trip to save his life and packs amongst his belongings certain items that lead the people he encounters to think him a Norse God, a fortuitous point of view which he does little to dispel. Forced to keep up the pretence of being a god while staying one step ahead of his lover's jealous husband, Photinus must juggle the severity of his situation with the enjoyment of being a God.
"""