What is PoE programmed in?

BTW, the days of C++ are coming to an end. The biggest issue with C in general: memory leaks, segfaults, and thread safety. No matter how careful you are, the potential to really f things up is there.

For example, there's a relatively new language out there that solves a lot of this: Rust. And there may be others over the coming years that do the same. But the most important upcoming changes in languages like Rust will be native adoption of more and more OpenGL and DirectX.

• Memory safety: prevents segfaults, no corruption, single ownership
• Guaranteed thread safety
• Amazing dependency management (Cargo)
• No-cost abstraction
• Built-in unit testing
• ...and more

To give you an example: Mozilla is adopting Rust for their next browser rendering engine. They're tired of memory leaks and squashing bugs related to their existing code.

C++ and Python is a match made in heaven. Use C++ for all the binaries and libs and use python for all the automation, devops, squishy scripting stuff.

I can't imagine writing any other kind of code nowadays.

---

Rust won't kill C++.

The concerns about resource errors are extremely outdated. Writing modern C++ insulates you so much from that by following extremely simple heuristics like RAII and Ro5, or by using smart pointers or by using move semantics.

Rust is, in some sense, late to the game. If it had come out around C99, it would've been praised as the second coming of Christ. Nowadays it's old hat. The only way to offset decades of high quality libraries would be a massive improvement which Rust isn't.

I imagine it'll rock the world about as much as D did.

Separately, for gaming dev, giving up any amount of performance for a possible reduction in already-rare crashes isn't worth it. Games aren't critical systems -- they are allowed to die in horrendous ways. The performance loss in the non-erroneous path isn't nearly as palatable.

"

pneuma wrote:

C++ and Python is a match made in heaven. Use C++ for all the binaries and libs and use python for all the automation, devops, squishy scripting stuff.

I can't imagine writing any other kind of code nowadays.

---

Rust won't kill C++.

The concerns about resource errors are extremely outdated. Writing modern C++ insulates you so much from that by following extremely simple heuristics like RAII and Ro5, or by using smart pointers or by using move semantics.

Rust is, in some sense, late to the game. If it had come out around C99, it would've been praised as the second coming of Christ. Nowadays it's old hat. The only way to offset decades of high quality libraries would be a massive improvement which Rust isn't.

I imagine it'll rock the world about as much as D did.

Separately, for gaming dev, giving up any amount of performance for a possible reduction in already-rare crashes isn't worth it. Games aren't critical systems -- they are allowed to die in horrendous ways. The performance loss in the non-erroneous path isn't nearly as palatable.

I agree. I wasn't familiar rust and checked it out. Moreover, if it can, it wasn't clear in the 5 minutes I spent looking at it, but it looked like it requires the use of macros and third party plugins to do inline ASM.

It would be interesting to know what kind of performance benchmarks there are but I suspect, anecdotally that managed code is always going to be a bit slower.

If I were going to build a game engine, Rust would probably not be my first choice.

spaghetto

idk about builds prior to 2.0, but since that time... in a hurry.

"

cipher_nemo wrote:

BTW, the days of C++ are coming to an end. The biggest issue with C in general: memory leaks, segfaults, and thread safety. No matter how careful you are, the potential to really f things up is there.

For example, there's a relatively new language out there that solves a lot of this: Rust. And there may be others over the coming years that do the same. But the most important upcoming changes in languages like Rust will be native adoption of more and more OpenGL and DirectX.

• Memory safety: prevents segfaults, no corruption, single ownership
• Guaranteed thread safety
• Amazing dependency management (Cargo)
• No-cost abstraction
• Built-in unit testing
• ...and more

To give you an example: Mozilla is adopting Rust for their next browser rendering engine. They're tired of memory leaks and squashing bugs related to their existing code.

Oh my god stop necroing year old threads.

"

cipher_nemo wrote:

To give you an example: Mozilla is adopting Rust for their next browser rendering engine. They're tired of memory leaks and squashing bugs related to their existing code.

that probably has other reasons

^ james mickens (microsoft) about browser programming, very interesting read.

"

cipher_nemo wrote:

BTW, the days of C++ are coming to an end. The biggest issue with C in general: memory leaks, segfaults, and thread safety. No matter how careful you are, the potential to really f things up is there.

sorry, this is nonsense.

memory leaks and segfaults (aka memory access violations) are a problem of programmers, not C.

thread safety is absolute nonsense. c++ has had really good threading libraries for ages as opposed to other languages. again, making sure things are safe is programmers job. if a programmer is doing multithreaded programming and doesn't know how to use locks, mutexes, semaphores and deal with thread, it's the programmer's problem


yes, the potential to fuck up is there. so? there's a potential to fuck up driving a stick shift vs an automatic. yes stick shift will give you infinitely more control over a car, and if your auto transmission sedan gets into a big enough hole, you'll need a tow truck.

a well designed, written and tested c++ program will have very minimal memory leaks if any.

a perfectly written complex program in a managed memory language will usually still have optimization problems and be inferior in performance because garbage collector even with all hints does not optimize as much as you need or give pinpoint control for object destruction.

sorry, an unmanaged memory system is still superior when writing a real-time complex engine which cares about performance.

im not even going to talk about system level, good luck writing a Linux kernel in non c. good luck doing a context switch in a managed language.