(untitled)

I know everybody is not fond of C/C++ replacement here. But I'm curious, what does Lain think about Odin ?(USER WAS WARNED FOR THIS POST, Why are you asking about Norse gods in programming ? If you are referring to some sort of programming language, please provide more information about it and why you want to discuss it. You should always elaborate on your opinions rather than just spilling the soykaf.)

Mod, are you trolling or just plain stupid? https://odin-lang.org/

>>32397 It seems like a vapid language. The creator makes vague promises about empowering the programmer but doesn't really add much to make that happen. It seems like it just copied the Go syntax and passed some code down to LLVM to get stuff done, then it uses the Go "simplicity" argument to get away with not having features. I know the creator watches John Blow, and it seems to ripoff a lot of JAI features as well. It could be good as a preview of that language. Overall it seems very unoriginal and I don't see much that makes it worth using.

I played around with it briefly. It's okay. The docs are good for how early it is. I don't see it gaining traction in the future though. >>32400 Why would you complain that it copies features from Jai? Why do you care? What was the last truly original language you used? Forth? APL?

>>32407 Expecting something truly original would be unreasonable, but when something is almost entirely copied I begin to have doubts. Can the person copying interpret their source correctly? (I've seen a few videos from the creator of Odin and they are mostly responses, they also often fail to grasp the subject they are responding to.) Why do I want a middle man? Surely it would be better to get these things from the source. Why did they bother to create this at all? Surely some form of creative vision beyond "I saw things and then did the same things" is needed to produce something well designed. I really hate things which are just blind copies of other, better things. If you have nothing to add beyond doing the thing again, you probably did not engage with it to begin with. This is why I dislike a lot of content from places like Tik Tok. It's just people seeing something, liking it, then copying it wholesale without thinking. It's like someone wants to be creative, but doesn't understand how. Even the website that they use to advertise looks copied and generic. (And I've just noticed that the Hello World example has the wrong code.)

i don't think about it at all. i looked at the homepage, seems like it aims for computer graphics stuff. it doesn't say why the language is a good fit for the task though. i saw the "context" example: that seems a horrible idea to me, an implicit global state just to avoid passing a simple struct for function calls. i haven't gone past the homepage though so my opinion is not really worth anything. why is it interesting to you, OP?

it just looks kinda like C with a little little little bit more syntactic sugar. what's the difference?

>>32407 Not him, but there's a difference between designing a character that takes inspiration from a previous one, and going into GIMP, tracing over a piece of official art, and saying "this is mine now". Odin is paramount to a Deviantart recolor of Jai, which is itself one of many "C++ killer" non-starters. Here's some advice to anyone looking to replace C and/or C++; don't make C again with some features backported from C++ and the current FOTM programming paradigm bolted on. C and C++ have persisted for the same reason UNIX has in the face of technically superior rivals like Plan 9 and Inferno; it works for what people need it for, and the strong ecosystem, built up over decades of use, strongly outweighs the advantages of switching to something completely new that, when you break it down isn't that much better. If you want to beat C and C++, make something that's differnet than C at a fundamental level. Nobody cares that you cloned C and added strong typing and foreach loops. Less Rust and more Mercury please.

>>32423 Well said. Incremental improvement isn’t good enough for discarding substantial investments in time with conventional languages. Odin is OK, but it’s a tailoring of the same approach to writing programs to the taste of the creator. I don’t know what comes next, but I don’t think it involves for-loops.

Dumbass Captain Ginger doesn't understand how LLVM's optimization passes interact with undefined behavior, gets miscompilations, blames LLVM, news at 11

>>32399 Looks like a wannabe rust. Still sticking to C.

>>32407 >Why would you complain that it copies features from Jai? Why do you care? It's a 1:1 copy with the exact same syntax.

>>33993 >C weenie defending undefined behavior nonsense as infallible >on a board called lambda If I speak I am in big trouble. Seroiusly, though, I just said in another thread that C++ had gotten past this behavior. Either I was wrong, or C++ acolytes has matured much faster than C's. Either way is probably an endorsement of developing a new language, no matter how incremental.

>>34000 I won't defend C, but if you're going to use an optimizer that was specifically built for C without understanding the restrictions that imposes on your memory model, you're a huge doofus, and pulling the Surprised Pikachu face when it backfires just makes you an even bigger doofus

For a while there I forgot this language existed. Looks like everyone else did the same. >>32400 I fully expect Jai's eventual release to be a repeat of this wet fart. Jon Blow's overconfidence and savior complex won't translate to a better quality of life for programmers. In that sense, Odin really is a preview.

>>37654 Jon's definitely a blowhard, but I wouldn't be so fast to dismiss JAI. It has a clear target audience and a good bit of technical know-how behind it. I would say the three possible outcomes for JAI are that nobody cares, it turns into some Perl-esque abomination comprehensible only to Blow himself, or it gains a comfortable niche as a language for game engine development. I don't expect it to be some runaway success like Rust, but it isn't intended to be (and wasn't really a good thing for Rust anyway).

>>32397 Seems fun, just haven't found a good excuse to use it over Rust, C, or Go yet. It's in my toy box with Nim and Zig until I find a good excuse to use it more often... >>32400 don't be mean lain. Odin is it's own thing, no language is a "ripoff", that gets into really bad corpo thinking about languages and how "unique" they have to be. And don't take what Blow has to say or think seriously, man's only accomplishments were two mildly successful indie games. He takes himself way to seriously. If you're Blow, then you can BLOW my massive co-USER WAS derezzed FOR POST

>>37663 >really bad corpo thinking about languages and how "unique" they have to be >it's bad (and corporate) to think that a new tool should offer something unique over existing tools I'd love to see you justify how evaluating things based on their merits is a bad mindset. It's not even particularly corporate since even in the world of art, works that are highly derivative are seen as less valuable. Also the dude who made it is just straight up a goober. If you want to see the sort of person who takes blow seriously, that's the guy.

>>37666 mainly, corporate entities consistently push the "merits" of something based on how it solves a specific problem (often horribly; see also "one-issue voting"). we're largely circling a drain with language design, with each "revolutionary" new thing rarely more than a half-baked derivative with extra headache-inducing functionality. that isn't universal, I'm sure everybody can think of a few things that claim to disprove the broad assumption, but in the end that's just rationalizations to eat half-baked bread that will definitely not do as well as something either more radically different, or at least is refined enough to justify the hype.

>>37692 >if I say it again, maybe he'll believe me That isn't how you convince people of things. >each "revolutionary" new thing rarely more than a half-baked derivative with extra headache-inducing functionality Odin. >we're largely circling a drain with language design Not really. I struggle to think of anything to back up this claim beyond the existence of some crappy programming languages. >more radically different And Odin achieves this "radical difference" by copying from other languages? You may want to look up the definition of "different". >I'm sure everybody can think of a few things that claim to disprove the broad assumption, but in the end that's just rationalizations Any claim will appear correct when you ignore all evidence to the contrary.

I hate the odin creator so much. He's active in some discord servers and he always act so smug and arrogant about anything he knows.

Enjoy using the language, think it's quite fun (and the first actually pleasant "modern C" I've used). This thread makes me mildly excited to finally look at Jai once I can. Never really looked into Jai since I will consider it vaporware until I can actually use it. The main issue I have with Odin is its lack of comprehensive pattern matching (except on its sum types, explicitly). What makes it worse is that the reason why they're missing is because the creator just "doesn't like them". The languages ability to easily create compile-time function generators and such using nested procedures and compile time values is very elegant however, not to mention it's very decent type system. Frankly, I think the argument of dismissal due to "copying" to be a little silly. The concept of a modular, imperative procedural language is quite literally from 1960s, and most of the functional concepts lifted into "modern C" languages are similarly old. If the main complaint is that the coat of paint around the paradigm looks like another I frankly couldn't care less. >>37666 The latter part of this is what frustrates me the most with the language, and is what puts me off it. The creator of Odin is a nuisance, and as said a "goober". He acts very contemptuous to any idea he doesn't personally like, and certainly won't entertain any counter-point if he's convinced of himself. Not a great look for the head of a programming language if you ask me.

>>38618 >I think the argument of dismissal due to "copying" to be a little silly Copying an idea is good when you can justify that decision. I just feel that many of the ideas copied by Odin are done so without said justification. This is what makes it derivative, rather than inspired. As a rule, I try to avoid derivative things because they have a tendency to trick you. The copied portions can appear appealing, but you will almost always get to a bit where the creator ran out of stuff to copy and had to go off-script. At this point, the cracks begin to show and often cause quite a bit of headache. You are often better sticking with the original, even if the derivative fixed some personal gripe its creator shared with you. The argument here is mostly heuristic: I will, in the long run, save myself time by ignoring things made by stupid people. There is also a personal aspect to my distaste. The more I've programmed, the less I've seen the use in languages without a garbage collector. As such, one would have to do something quite impressive to wow me. The kinds of marginal improvements you see here just won't tip the scales. The main reason I would use C for anything is because it's popular (hence users can likely compile your software, and it is easier to find people to work on it). These languages would need a pretty strong offering to compete with that.

>>38619 As someone predominantly working in Scala nowadays I certainly agree with your last point. As I've furthered my venture into computation and programming I've found myself getting more and more exhausted managing state. Eventually I'm sure I'll reach Haskell enlightenment but I'm not there yet. As for your points around Odin, its justifications are quite clearly laid out in my opinion: Bring Pascal concepts into a modern syntax, give proper tools to manage state (basic parametic polymorphism, deferred execution, sized strings and slices, real sum types, etc), and "what the creator likes". The last point, as you pointed out, is by far the weakest part of the language; But I wouldn't call every feature it has unjustified. Truth be told I think its a very consistent and low friction language. I hope someone with more time than me will fork and bring it into its best state, away from its initial creator.

>>38619 i find the garbage collector mostly being useful for student projects as noob safety. If you do anything realtime where you drop ~10k objects/s it fails keeping up and then you are forced to write your own garbage collector reusing objects to make it fast again. Now I'm still using java but for a different reason: web soykaf like crawler/bots and cross platform tools are way less painful in it. That said c++ direct memory access and pointers make it superior for other usecases. So i remain using both on case by case basis.

>>38636 >~10k objects/s What is this number based on? It seems quite small.

>>38636 The modern JVM not only has an extremely fast (dare I say best in class) GC that remains parallel in most cases, you can also write code in a GC language that avoids garbage collection outright. There are high frequency trading algorithms running effectively on Java as well as C++, and both are achieved using subsets of the language to avoid any memory management (among other things). Not to mention things scaled at the size of Amazon & Google rely on Java for a good portion of throughput. The GC is a good noob safety net sure, but its far from a hindrance if you know how to use it, and how to avoid abusing it.

>>38638 Number is just a guesstimate because that was ~5years ago. What i remember is that i had to rewrite original code because garbage collector didn't keep up with a "let just gc handle it" style to a "homemade gc solution" that was simply reusing old objects instead of constantly creating new ones and dropping old ones for gc to pick up. >>38639 gc purpose was always to automate away handling memory freeing. If you are manually writing gc instructions whats the difference to straight up doing it in c? Sure you have a mem leak safety net but if your concern is performance you might as well go full control with c. And i dont think trading algos run on c++ or java in the performance critical segments, afaik they are using assembly microcode because that's faster. Also java is peculiar in one aspect - the jvm gets faster with long runtime. That's what makes java way more performant on servers where it can run semi permanent. If you are in that environment then its indeed competitive to other languages.

>>38643 >If you are manually writing gc instructions whats the difference to straight up doing it in c? You'll notice that there are two different kinds of code in most projects – performance critical, and not. The vast majority of code is not performance critical. Java makes this vast majority of code much easier to write at only a minor cost to the performance critical sections. C is a language optimised for the rare case of performance critical code, where Java is optimised for the common case of regular code. >that was simply reusing old objects instead of constantly creating new ones and dropping old ones for gc to pick up. And that you can do this is one of the reasons GC is good. If your code was well structured, it likely would have been relatively easy to change how object allocation happened. By uncoupling code from memory allocation, GC allows you to easily tune parameters of allocation in your entire program without changing much (or any) code. For instance, GC will perform better the more memory you give it, and so you can increase the total allocation as a setting of the JVM and improve your entire program's performance without changing any code.

>>38643 Writing with the GC in mind is not the same as "writing GC instructions" as you say. In any performance critical code it is imperative to minimize or remove any memory management, allocation or freeing. C's "malloc" is extremely slow compared to an arena allocator or the JVM's heap. So if you have to already keep memory management in mind when writing performant code, there is less difference than you might expect between avoiding GC hits on a garbage collected language, and avoiding any explicit malloc/frees in a language like C. I have written GC code that processes 40k+ objects/s, with the constraint being the underlying DB I was writing to. And I was able to do so easily due to being able to work in a higher level language that provides higher order logic (Scala). Doing the same thing in C would be a massive pain by comparison, and I say this as someone who has used C in the past quite extensively. >>38644 The latter part of this is another fantastic point I would like to echo. Decoupling direct memory management from your logic is the first step to achieving more tunable, composable logic. Taken to an extreme, it's why purely function logic can be scaled freely with fibers or actors, while stateful code has to rely on mutex locks and careful balancing of shared state.

>>38644# >And that you can do this is one of the reasons GC is good. value of gc = how much it can automate for you. The moment you start writing your own memory management is the moment gc loses value.

>>32397 what do you think? is it any different from rust or zig?