Earlier quoted context omitted.
There’s an official http package coming out and native tls support as well.
Yeah, but OP has built web applications without those. So, I wonder how they went about it.
I used WASM
Understanding the Odin programming language
71–80 of 163 posts
Re: Understanding the Odin programming language
#72Earlier quoted context omitted.
Casey worked on tooling for AAA games that most certainly needed “that level” of optimization. Jon Blow worked on numerous AAA games that required “that level” of optimization. And he’s one of the very few developers in the last 15 years who have managed to sell more than a million copies of a game running on a scratch built 3D engine. You can disagree with their opinions, but they certainly have the experience to ba…
Well, Minecraft sold far more and it's a scratch built 3d engine isn't it? Popularity is certainly not a technical achievement.
Minecraft doesn't use an off the shelf engine, but I wouldn't really call Minecraft scratch built. It's built on top of LWJGL.
Popularity isn't a technical achievement in itself. But what is a technical achievement is that he built a visually impressive 3d engine that worked well enough for over a million people to buy it at a time when almost no one else was doing this. Minecraft was released nearly 10 years earlier--before Unity and Unreal had completely taken over.
I'm also not saying that the witness engine is somehow better than anything else out there, but it's a significant enough technical accomplishment that along with Jon Blow's other work, he has the experience to back up his opinions.
I've also never seen the critique that Jon Blow is just an influencer with no relevant experience from anyone with equivalent relevant experience. I've seen other experienced game devs who disagree with him, but I've never seen them say that he doesn't have the experience to have them.
Re: Understanding the Odin programming language
#73Earlier quoted context omitted.
Maybe I'm missing something but when would the 500 geese instances ever be stack allocated in Rust? That comparison seems unfair, the lifetime of that kind of object isn't going to be compatible with stack allocation. Allocations are really really cheap in Java by the way, so I don't get how 500 allocations would even be an issue.
When you make a local variable with a Goose in Java, that's a heap allocation Goose jim = make_a_goose_somehow(); // Java, so jim is on the Heap, no way around it When you make that variable in Rust... let jim : Goose = make_a_goose_somehow(); // Rust, jim is on the stack Now, if we make a bunch of geese, maybe in a loop, and we put them into our growable array type... ArrayList geese = new ArrayList (); // ... some…
Memory is memory, stack is not a unique hardware element. It just tends to be hot, but so can certain part of "the heap".
Of course this is a toy example, but were the compiler not smart enough (it is surely smart enough in this case) then the "too simple rust" version may actually be slower - it would allocate a Vec on the stack, but only a length, capacity and a pointer is stored there, the actual backing array is on the heap. Then it would create stuff on the stack, and copy over those bytes to the heap, object by object (it's a move).
Meanwhile the java version would have a continuous region of memory, next to it it would have objects, and it would just write pointers to said objects without moving/copying anything.
Surely enough rust is smart enough to optimize out this useless move in this case, but I think you are painting a way too simplified picture here.
Re: Understanding the Odin programming language
#74Re: Understanding the Odin programming language
#75Earlier quoted context omitted.
From what I understood, their critique of RAII is twofold: coupling of allocation and initialisation, and enforcement of deallocation. The ease of use of smart pointers makes it tempting to allocate/free of temporary structures even within one single function. Given enough number of such occurrences, it kills performance by a thousand cuts. Also I remember they mentioned it’s not necessary to free memory if you’re ab…
most of that criticism only works on C++. rust does enforce RAII but uses stack allocation for locals by default instead of touching the heap so it skips the slow part. on the other hand there are no constructors (just normal functions) so you cant initialize values in place, only stack allocate and return. i think rust needs to add in place init and change the rules from "always init at declaration site" to "must be…
> honestly thats the biggest problem with rust, they come up with a lot of useful changes but then take ages to stabilize because the core team is overworked
On the contrary, that has been one of Rust's biggest strengths. My impression when reading through stdlib was that they got so many things right, and for that to happen, things need to be thought out properly.
Case in point, it'd be such a shame if they stabilized the allocator API, only for us to forever regret never getting the storage API [1] instead, or vice-versa, depending on which one turns out to be more pragmatic.
> they also have a kind of perfectionist culture as a reaction to all the half baked features shipping in C++.
And that's a good thing! Some people really dislike the constant influx of new features due to the overwhelming complexity it leads to. So if we do have new features, they better be worth it.
Re: Understanding the Odin programming language
#76Earlier quoted context omitted.
Odin is not like JS or something where you'd need a VM or transpilation process to target an embedded system. It's just C with nicer syntax and modern data structures, there's no "squeezing" required. You just compile for the target you want to run on. Here's a UI framework, if you scroll down you'll see it on a Raspi Pico: https://github.com/MadlyFX/Ansuz
I think you missed "native development". I'll rephrase: Could a toolset to develop in Odin be made to run on (not just target) an STM32 microcontroller like you used? > It's just C with nicer syntax and modern data structures That suggests the above would (in theory) be possible for any device that's roughly in the same class as "can run a C compiler". Correct?
> STM32 microcontroller
The answer is "yes" depending on what you mean by STM32 :D
But if it's one we don't currently support officially, it should be pretty easy to support too, with probably a little extra assembly.
Re: Understanding the Odin programming language
#77Earlier quoted context omitted.
Casey Muratori and Jon Blow have pushed this concept frequently. They largely don't deeply elaborate, which is sad because I am a professional game developer who is interested in precisely presented knowledge so I can apply it to my work. My interpretation is that games want to allocate large pools of resources, like GPU buffers, cpu memory, etc, and reuse that memory over and over. Ie: Reinitialize it. In my experie…
> Casey Muratori and Jon Blow have pushed this concept frequently Ah... The school of what I like to call "maximum opinions and minimal evidence". Aggressive arrogant dismissal of anything except their exact view (and for Muratori, you're also "woke" for good measure), coupled with a complete lack of _hard evidence_ to back up their views. In that regard, they're not unlike "investment advice" instagram influencers.
Apparently you're the school of dismissive person who can't even be bothered to look up their technical achievements.
Re: Understanding the Odin programming language
#78Earlier quoted context omitted.
> My angle is systems programming, and there, it absolutely matter. If you are performance sensitive, then you try to avoid crossing the user-space -> kernel boundary more than you have to. Eg, ask for lots of memory, manage with arenas. This gives the misleading impression that ordinary memory allocators are materially different from arena allocators. They aren't. Both types of allocators first ask for a big block o…
Agreed. IME the main reason to choose arena allocators is for correctness, not speed. They make similar time/space tradeoffs to garbage collectors in that they grant higher allocation throughput in exchange for more memory usage. The perf argument against RAII is very abstract and is less "RAII causes bad performance" and more "the kind of design that leads you to reach for RAII is the kind of design that's bad for p…
Correctness (the kind that comes from simplicity and maintainability) and performance pretty much always go hand in hand. The only additional ingredient to "bridge the gap" between the two is detail.
Re: Understanding the Odin programming language
#79[flagged]
Data-oriented is a programming paradigm, just like object-oriented and procedural and functional. It has nothing to do with Big Data. It's about the way things are done. It prefers something like an ECS (data-oriented) rather than a class hierarchy (object-oriented). "Graphics oriented" isn't a thing. Also, i disagree with your point about "promoting what you can do with it, rather than the language itself and its qu…
Ok well good luck!
Re: Understanding the Odin programming language
#80Earlier quoted context omitted.
Casey spends a lot of effort on what he considers an anti-pattern where you're making a huge number of separate objects. I think a lot of this comes from Java, a language where all the user defined types actually are obliged to be heap allocations. If I make a Goose type, and I say I want a Goose, Java will allocate space on the heap for the Goose and put my Goose there, that's really how Java works. If I make a grow…
Java doesn't mandate the usage of a heap - it can in certain cases avoid doing so and allocate on the stack (escape analysis). Besides, as mentioned java's allocations are much closer to something like using an arena in a low-level language, then a "slow" malloc. It uses thread-local allocation buffers, where you have a large buffer with a pointer pointing to the start of the free region. Allocation is just a pointer…
You're correct that by an "as if" rule the JIT may in some cases be able to do this trick, but the specification says you're getting a heap allocation and so in most cases, including the example I gave that's exactly what happens.
It doesn't matter that you say this is "much closer to something like using an arena". It's definitely work that we needn't do at all and that's AFAICT that's how Casey ends up over-correcting so badly.
> This is pretty much the most efficient one can be after per-object type arenas and simply not allocating.
Sure. "A C is pretty much the highest grade one can get in this class, after grades A and B".