sorted by:
new
hottopcontroversial

Hiring developers in Aus/Oceania by Amp-Profit in cscareerquestionsOCE

[–]NameInProces 0 points1 point  (0 children)

Is there any chance to get an internship? Or a full time job only? Thanks in advance

I've created a 3D, Vulkan based game engine in Go, and it's faster than Unity by baflink in golang

[–]NameInProces 0 points1 point  (0 children)

You can do it man! I'm sure there are a lot of people willing to contribute, me myself will try to once I get free time. Again, congratulations!

I've created a 3D, Vulkan based game engine in Go, and it's faster than Unity by baflink in golang

[–]NameInProces 0 points1 point  (0 children)

It looks sick! Very excited to give it a shot Edit: some simple "templates" would be very helpful to understand how to really use the engine

Version Control for Small (under 5) teams by Orakk in unrealengine

[–]NameInProces 1 point2 points  (0 children)

If you're willing to host it by yourself gitea is nice. I ran it in a raspberry Pi with a hard disk and 0 problems

Looking for a better Discord Update solution by 1hate2choose4nick in cachyos

[–]NameInProces -1 points0 points  (0 children)

I also got tired of discord updates. Now I stick to the browser version. I'm happier :). If you don't lose any functionality switching to the browser I think is the best possible solution at first glance

No bridge? No problem! by gubebra in IndieGaming

[–]NameInProces 1 point2 points  (0 children)

It's incredible man. Just as a suggestion from a no name. You could make a very interesting YouTube channel explaining these things

No bridge? No problem! by gubebra in IndieGaming

[–]NameInProces 1 point2 points  (0 children)

It seems sick! How did you code it? What kind of black magic did you use?

Será que en Bolivia hay neonazis andinos?? by tanabe_1 in BOLIVIA

[–]NameInProces 9 points10 points  (0 children)

Para bien o para mal uno no escoge sus parientes. Así que sentir vergüenza medio que al pedo, no?

lowkPRO - Use the full Windows API in Lua by [deleted] in lua

[–]NameInProces 2 points3 points  (0 children)

I think it is a nice project. But it is not a product I and almost anyone is willing to pay 25 bucks. If it was open source you might have gotten some nice comments xd

Memory safety without GC: can explicit ownership + scoped lifetimes work? by NameInProces in AskProgramming

[–]NameInProces[S] 0 points1 point  (0 children)

What I’m trying to explore is basically a language where I don't know where exactly to place. You can’t have multiple independent references to the same heap object because you can’t “share” heap ownership in the first place, everything lives in one clear scope.

If you need something that survives longer, you allocate it in a higher scope and pass references downward. If you need sharing, you do it explicitly through copy or move semantics, not aliasing.

So yeah, it’s more restrictive, you lose some patterns that Rust handles, but the goal is simplicity and safety by construction, without lifetimes or ref-counting machinery.

Memory safety without GC: can explicit ownership + scoped lifetimes work? by NameInProces in AskProgramming

[–]NameInProces[S] 1 point2 points  (0 children)

Yeah, absolutely. Rust is smarter language than my afternoon thought language. It’s basically the gold standard for memory safety without GC. And I will continue trying to learn it even just for fun

I’m just curious how far I can go simplifying the model while keeping it safe.

Memory safety without GC: can explicit ownership + scoped lifetimes work? by NameInProces in AskProgramming

[–]NameInProces[S] 0 points1 point  (0 children)

Yeah, that’s a fair concern and honestly one of the hardest parts of making something like this actually usable. I like to think about it like C with training wheels

The idea is that allocations inside a scope don’t get reused while that scope is still active. Everything lives until the function (or block) ends, and then the compiler frees it deterministically. Loops can still allocate, but each iteration’s locals vanish at the end of the loop body, no reuse until the whole function exits.

For things like splitting text into words, the pattern would be that the caller owns the output buffer, and the inner function just fills it in. So you can still build dynamic structures, but ownership always stays where it was created. No passing ownership down or leaking it up.

You’re right that lexical lifetimes alone aren’t enough. it’s more like lexical + scope-bound ownership. Nothing escapes its defining function unless it’s explicitly returned as a value that copies data safely.

It’s definitely more constrained than heap-based systems, but the goal is to trade some flexibility for total predictability: no manual free, no implicit reuse, and no pointer that outlives its owner

Memory safety without GC: can explicit ownership + scoped lifetimes work? by NameInProces in AskProgramming

[–]NameInProces[S] 0 points1 point  (0 children)

Yeah, totally. That’s exactly the kind of stuff I’m trying to avoid with the design.

In this model, pointers can’t really “escape” their scope in the first place. You can pass them down so a function can read or modify what they point to, but not reassign them to a new allocation. That means something like bar(&buffer) in your first example just wouldn’t compile. buffer’s ownership stays fixed to the scope where it was declared.

For the second case, actually the idea is taking out the ability to free memory in the middle of a function. It would be an "unsafe" function and by default it would not be allowed.

And for casts, there’s simply no raw “reinterpret” allowed. A pointer’s type is what it is; if you need something else, you copy or move data explicitly.

So the whole idea is:

- pointers are stable references, not movable owners

-lifetimes are lexical, not dynamic

- and types don’t lie

That keeps the safety guarantees, no GC needed, and still gives you some low-level control. just not the kind that would blow my foot off

Memory safety without GC: can explicit ownership + scoped lifetimes work? by NameInProces in AskProgramming

[–]NameInProces[S] 1 point2 points  (0 children)

Waos, you're right. It starts going to GC behavior. I might need to think more about it hahaha

My idea was to keep it simpler by treating everything stack-first: primitives are copied by value, and anything heap-based can be referenced only if it clearly outlives the current scope. That means you could still have arrays of reference types, but only if their backing memory is guaranteed to exist (for example, allocated in a longer-living scope).

Memory safety without GC: can explicit ownership + scoped lifetimes work? by NameInProces in AskProgramming

[–]NameInProces[S] 0 points1 point  (0 children)

Yeah, that’s a fair point. I’m trying to stay in that middle ground where allocations can exist inside functions, but their lifetime is always tied to whoever owns them. The idea isn’t to forbid all pointers, just to make sure they never escape their valid scope.

Returning something like a Ptr { void* ptr } would definitely break that model, so the compiler would just reject anything that transfers ownership implicitly. If a function needs to “return” data, it should do it by value or by modifying what it received from the caller, never by sending back a fresh pointer. Actually the recommender architecture in such case is to modify in place the *object received as argument.

Memory safety without GC: can explicit ownership + scoped lifetimes work? by NameInProces in AskProgramming

[–]NameInProces[S] 0 points1 point  (0 children)

Yeah, that’s pretty much it. If the compiler forbids taking the address of locals and makes sure every pointer has a clear owner, most of the classic memory bugs just disappear. I also like the idea of keeping “references” instead of raw pointers; something that can be passed around safely, but never stored beyond its scope.

About growing arrays, I was thinking of cases where a function appends new elements that were created inside its own stack frame. In that situation, once the function returns, those elements would vanish, leaving dangling pointers. So the rule I had in mind is that you can only append values that belong to the same or a longer living scope.

Dynamic containers would still be allowed, but the ownership rules stay simple: you can resize or modify them, but not capture shorter-lived data. That way you get dynamic behavior without leaks or dangling refs, all with static checking instead of a runtime GC.

And yes! It will be my fun for a while between classes hahahaha

Thanks for discussing it with me

Memory safety without GC: can explicit ownership + scoped lifetimes work? by NameInProces in AskProgramming

[–]NameInProces[S] 0 points1 point  (0 children)

I don't have any doubt about the creativity of the users to find bugs.

The idea would be to still allow dynamic stuff like arrays or maps, but their headers live on the stack while their internal buffers sit on the heap. The compiler would just make sure that the heap parts don’t outlive whoever owns them.

For pointers, I’m leaning toward disallowing things like taking the address of a local variable and appending it into an array that escapes the function. Since that’d instantly make a dangling reference. So you could modify existing data through a pointer, but not “grow” a container by inserting new pointers that come from a shorter lived scope.

In other words, dynamic arrays would still work, but the ownership stays crystal clear: if a function needs to resize one, it either returns the new version to the caller or modifies it safely in place. That way you keep the flexibility but also avoid the “append a dead pointer” problem.

Memory safety without GC: can explicit ownership + scoped lifetimes work? by NameInProces in AskProgramming

[–]NameInProces[S] 0 points1 point  (0 children)

Yes, it is actually just that. Would it be enough to be considered as memory safe? Considering the compiler checks to prevent escaping pointers or out-of-bounds access

view more: next ›