I think I'm over "C but better" as a language design premise. C is really good as a low level language. The control you give up over assembly is well chosen. The syntax is fine. You have to tell the compiler to now screw you which is crazy as a default but doesn't matter much in practice.
I've just spent a week doing ~ nothing other than writing C. It's been great. The language does exactly what you tell it to. Generating C to do things from tables of data is very easy. I especially like the zero context switching that comes from being able to remember the language. Python or C++ involve far too much looking up documentation.
It's the wrong tool for solving most problems but the right tool for telling a computer what to do.
C may be the best example of "worse is better", but every time I do something non-trivial with it, I wish there was something better:
* Undefined behavior, there are apparently over 100 of them. I can probably name about 5, maybe 10. Will the compiler warn me if I accidentally trigger undefined behavior? Of course not, it assumes that I am super-human who never makes a mistake.
* Code sharing using '#include', god I hate 'em.
* No namespaces, which means a single global namespace for all functions.
* Strings: every time I have to manipulate strings in C, I want to shoot myself.
* Arrays decaying into pointers, very clever, causing so much misery.
* Array length decoupled from the array pointer. No way to pass around both of them together, and checked automatically by the compiler.
* The C preprocessor #define magic. Love 'em when they are mine, hate 'em when they are someone else's. Hate 'em even more when they are mine 6 months later.
* The #define/#ifdef spaghetti code. There ought to be better ways to support multiple architectures.
Those are just off the top of my head. I'm sure I could come up with a few more items.
The UB is a lot more manageable if you pass nostrict-aliasing and similar to the compiler, or if you use a compiler that doesn't do that style of trickery.
The includes and raw pointers are a build your own abstraction thing. Annoying if the abstraction you're building is the one a different language gives you to work with. For example, a struct with multiple arrays of the same length - in C that's multiple pointers and one size, in other languages that's probably multiple sizes and asserts that they haven't diverged.
It's not a perfect language but it's really rather good.
I like the Odin language because it is really joyful to programming with it. Hope there are more resources and mature packages besides gaming development.
In this, they make a good point about refactoring more with Rust than other languages. In some cases, "fighting the compiler" is not always want you want to do, especially when mocking some code/game state.
Garbage Collections destroys any real-time guarantees you might need, since the GC can be triggered at any time. So for some classes of applications a GC is not an option (e.g. in 3D-video games you don't want your rendered frames per second to drop under 60 frames per second).
Rust doesn't generally have a garbage collector though. This doesn't apply to the general case (ie. unless you go out of your way to add a GC into your runtime)
Like what? I'm seeing that the Union is by-type and not by-name (such as C vs Rust enums). I didn't see good support for preventing null pointers, but maybe I missed that. And it wasn't clear if RAII works.
While it has been a number of years since I last used Pascal (Delphi 5 or Turbo Pascal before that) -- I do like the language but I find the code syntax to be bloated at times. Maybe better to say harder on the eye when looking at large source code compared to C.
Of course - modern Pascal (Free Pascal, Delphi, etc) might have evolved a lot since.
// C
void some_func(int a) {
int b = a + 10;
printf("hello %d\n", b);
}
{ Pascal - Going by memory, so might be a tad wrong }
procedure SomeFunc(a : Integer)
var
b : Integer;
begin
b := a + 10;
WriteLn('hello ', b);
end;
I have been playing around with Odin for a little while, now. It may have been inspired by Pascal in a number of ways but it certainly isn't as cumbersome to write. I am liking the syntax much more.
// Odin
some_func :: proc(a : i32) {
b := a + 10
fmt.println("hello ", b)
}
I investigated both for a side project. I ended up going with Odin. Primarily because despite them both being non-GC languages, Odin felt higher level to program in. Also Odin has official Direct3D and Metal support.
> Odin inherits a lot of warts from horrible languages like Go
Still waiting on you to list what those "warts" may be. I mean sure golang may be overly conservative in its design but calling it "horrible" is a very wild take.
The only evil I know of that golang has perpetuated is making an unused-variable error an compile error that will block compilation instead of an linter error. This makes prototyping much more annoying.
Ironically a design mistake that Zig has copied as well. Not sure if Odin does actually
Odin is pretty nice, except for its RTTI, bloated executable as a result with the name of your types in clear, author of the language is against having compile time type introspection, so you are stuck with having to do reflection at runtime..
It could have been the perfect language for me, it's unfortunate
> the morality of memory allocation as it relates to market economics … that you could only produce if you are truly clueless
I’m actually very curious to see that! I’m not sure what the angle espoused there is, but it seems fun at least from the perspective of academic science and technology studies to consider. This person might be going through a few too many scales to make meaningful commentary there though… In any case, there can be interesting connections and bidirectional influence found between technical systems and social organizations/politics/commercial industry, especially when it comes to things like how standards are defined over time. Even selecting the standardized sizes of containers for shipping and the technical design of connectors between shipping containers/cranes for picking them up has an interesting social and economic history that touches on questions of changing relationships to labor in post-war America!
This guy might be spouting total nonsense, but it seems interesting and fun to read either way!
Edit: I’m also not sure why trying to understand relationships between technical entities (like a programming language) and the systems it exists within, even if misguided, disqualifies the outputs of this person? Maybe there are plenty of other reasons, and maybe what they were saying was in fact batshit, but with zero context, I’m genuinely curious to learn more about what was said that was so crazy!
His logic was less of a deep introspection and more of a random ramble. The video in question is https://youtu.be/LKNBkSvFcZU
It's a reaction video to John Blow reacting to a Rust game-dev talk. He talks about how ownership is an economic concept, hence not applicable to programming and that's why he doesn't like the borrow checker from Rust. His personal philosophy is that "if you make the mess, you clear it up", so GC is bad because you are flouting responsibility for the memory you allocate. Exceptions are also bad for similar reasons (you shouldn't propagate errors so it's bad to have a convenient syntax for doing so).
Everything I've seen from him has been miles from the creators of Zig. To be frank, I think a lot of Odin's good features are just copied from Blow's previews of his Jai language. Not a bad thing in isolation, but it's a huge contrast to Zig which seems inspired by actual problems faced by programmers instead of crack-pot philosophy and a sense of righteous sense of superiority.
Comments like this are why HN comments have a bad rep. I'm so sad this comment is at the top.
You could have criticized the language itself. Instead you completely dismiss the language because you didn't like an analogy the creator made. You don't even bother to link the video where the author made the supposedly bad analogy!
I would encourage readers to consider the language for what it actually is. Please don't dismiss anything because a random internet commenter claims the person made a bad analogy.
It's beyond absurd to call someone "truly clueless" when that person has in fact created a programming language that is moderately successful and in production use. That's a far bigger accomplishment that virtually everyone here, myself included, can claim! https://jangafx.com/software/embergen/
My time on this Earth is sadly finite. In light of this, I cannot learn every language. I must employ heuristics to decide whether something is worth doing. One of those for programming languages is: "Do the people who make this seem like they have good ideas?" In this case, the answer was no. When I listened to the creators of Zig, the answer was yes. I don't think it's at all unfair to make people aware of this conclusion, especially when I am clear that it is not one reached from actual study of the language. It is a sign to the creator of the language that he should present it and his ideas surrounding it in a better way so as not to drive people off. If he cannot do this, then the ideas are likely bad and so not worth looking into.
I'm judging the book by its cover, because that's what covers are for.
Sorry, I think comments like your root post make the internet a strictly worse place.
There is no one who has created anything for which there isn’t some detractor who has deemed the creator to have bad ideas or communicate in an unacceptable way. Literally every single HN post ever could have someone reply with “this person said an unrelated bad thing and therefore should be ignored”.
Comments like yours simply aren’t helpful and make HN worse. IMHO.
> Literally every single HN post ever could have someone reply with “this person said an unrelated bad thing and therefore should be ignored”.
This is a deep mischaracterisation of my perspective. It is not that has said a singular unrelated thing, but that he has made a pattern of saying many bad related things, such as "I will not support convenient error propagation because you shouldn't propagate errors", or "OOP and FP are bad concepts practised by dogmatic people who don't know what they're doing".
I think your issue here is one of trust. I have reached a conclusion based on what I've seen, and you don't trust that it's accurate. You think I'm being disingenuous in some way, cherry picking bad quotes or whatever. It's fine not to trust people, but you should actually look into the matter instead of just making a fuss. When you see someone giving their opinion on something and you don't like it, here are some more productive things you can do: ask for evidence, provide a counter argument (supported by evidence), or even simply express that you disagree (what is asserted without evidence can be dismissed without evidence). Telling someone "you shouldn't have said that" is the worst of these options.
Re-read your initial comment and my initial reply. You solely complained about a bad analogy and called the author totally clueless. Then I specifically called you out for not criticizing the language itself.
I don't think you're being disingenuous at all. I think if you have complaints about the language you should express them directly. Attacking the author as a means to dismiss the language is lame. And if you're going to do that you should provide a lot more evidence than a vague, non-specific comment about a supposedly bad analogy. If you want to criticize the philosophy of the language (anti-OOP, amongst other things) that's great. But you didn't do that.
Let me re-iterate: in the future you should avoid posts that attack the author rather than the idea, call someone totally clueless, and don't present actual evidence. It sounds like you have an opinion formed from a variety of factors. Next time I would recommend you criticize the language at face value. If you haven't spent enough time with the language because you've dismissed it based on a proxy heuristic then I would recommend simply not posting that comment on HN.
> Attacking the author as a means to dismiss the language is lame
If this is your view, then my comment was not intended for you.
> If you want to criticize the philosophy of the language that's great.
I did not want to do that. I wanted to express the true sentiment that I am not going to use this language because I do not trust its creator.
> I would recommend simply not posting that comment on HN
> you should avoid posts that attack the author rather than the idea
That is your opinion. With respect, I do not care and you make no strong case for it. Many people use my same heuristic. They are my target audience and they would like to know about stuff like this. Just because you don't care about some piece of information doesn't mean it should be suppressed.
All you have said here is that I shouldn't express my opinions because you disagree with them.
If you've reached that conclusion from my comments, fair enough. But I would suggest the difference between what I do and what you do is that I genuinely have listened to and had conversations with the creator of Odin, and I have concluded that I don't want to use a language designed in that way. Also that I don't really like him as a person.
In that same video I was talking about, he dismisses all users of OOP and FP as dogmatic and clueless. He is willing to call others' intelligence into question to sell you his language, so I will do the same for him to sell you on not using his language. Fair, no?
I stand not corrected, but reminded to spend less time on Internet. My comment was entirely based on the parent and now yours and now this very comment in a chain are nothing but a waste of time which could have been better spent.
It's Sapir-Whorf applied to programming: people developed programming constructs that mimic their society structure so while borrow checking may have been developed as a response to problems programmers face directly when developing software, they approached the problem by thinking of their programs in ways that mimic a market-based society and developed solutions that reflect market-based society solutions.
Just like Sapir-Whorf, likely the influence of our society isn't as pronounced as they're suggesting but there's likely a grain of truth that many people approach problems by using ideas from their collected experiences. Similarly, approaching problems in different ways from what we're used to can also be equally challenging due to our lack of prior experience.
They just used a common word that was vaguely applicable to an almost entirely unrelated abstract system of object lifetime verification. Ownership has basically the same semantics as C++'s destructors and moves, just enforced statically. It isn't people looking to the real world for a real-world solution for programming problems.
Another one to collect dust. The problem I run into with new languages are the often dissolving community when they first gain popularity and then run into a critical design flaw. How is a person who goes about learning a language to find extendability of a language if it never gets out of the early-alpha stage and has more than 5k followers?
Seems EmberGen (and all products JangaFX produces) are made with Odin, so one can be fairly confident it won't disappear over night. I'd probably consider Odin production ready already since EmberGen works pretty well for its use cases, and is blazing fast.
I've just spent a week doing ~ nothing other than writing C. It's been great. The language does exactly what you tell it to. Generating C to do things from tables of data is very easy. I especially like the zero context switching that comes from being able to remember the language. Python or C++ involve far too much looking up documentation.
It's the wrong tool for solving most problems but the right tool for telling a computer what to do.