That is because when you’re a beginner, you read everywhere that you should be using anaconda and jupyter notebooks. I know because I did so. Neither of them lasted more than a week on my computer though.

Anything that’s not an integer or a range doesn’t belong inside []. Much more readable to use zip, map, filter, etc. And more powerful.

EDIT: that was meant for indexing lists. Strings inside [] for indexing ducts are fine.

I haven’t used npm. But pip is horrible. Some times I’ve used a well-known library that only works on linux, but there is no mention of it whatsoever, and it installs without problem. The error only happens at run-time (not even when importing!) and says nothing about platform-dependency. I only learned that it was a linux-only library because I happened to try running it on a Linux machine to see if it worked.

Many times you have to set up your environment a specific way (environment variables, PATH, install dependencies outside of pip) for it to work, and there’s no mention of it anywhere. Sometimes you install the library with pip, sometimes with apt, and there is no way to know which one. And sometimes the library is both in apt and pip, but the pip one does nothing.

Furthermore, good luck importing a library. You might have installed it with “pip install my-library” but to import it you have to do “import MyAwesomeLibrary3”. And pip won’t tell you about that.

The mistake was choosing a language, and afterwards searching for a use to the language you just learned.

My screen gets dimm enough that it’s almost impossible to see outside with the slider at the left.

The solution is extremely easy though. Put an option in the settings so pressing volume up/down while the screen is locked changes the brightness instead of the volume.

I don’t think changing a profession’s terms to “prevent stupid jokes” is a smart move.

To be fair, in that article mentions the way to get rust from C. Sure, there is not a compiler written in C, but C is down there in the list of compilers needed for rust, so “just” need to compile some other compilers in the middle.

The bedrock of modern civilizations is expensive to develop, buggy and unergonomic though.

If you make C run, you probably (I’m not sure, would have to verify) can make rust run. And if there isn’t yet, there will probably soon be a C compiler written in rust, so you can choose to bootstrap from wherever you prefer.

C’s ABI will probably last longer than C, since there is not a stable rust ABI though.

At this rate, the US government won’t even consider it as an option! Rust is practically a hippie language.

To be fair, mechanic items, and especially electronic ones were far more repairable back then.

You could see, desolder and solder components without issue. Nowadays most of the electronics are inside chips, and only the components that need to be physically big (like those responsible for the power supply) are human sized. Sure, there are some small SMD that can be manually diagnosed and replaced, but even then you often need a lot of skill and equipment.

This is the talk that convinced me that C is the only language more cult-like than rust.

The good thing about Box::leak() is that it returns a raw *mut pointer. So you need unsafe{} to dereference it. Might as well: let my_ref = &mut unsafe{*ptr}; while you are at it, so you have a perfectly normal rust reference, so the function signatures don’t need any change.

The problem with Rc is that it would also require a RefCell most of the time. So the whole thing would be filled with Rc<RefCell<T>>. With the required .borrow_mut(). It would both do a pain to do and undo.

And of course I want to undo it, because RC is a shitty GC.

I’ve re-thought about the problem and I think for prototyping I should just Box::leak() and work with raw pointers.

This approach also doesn’t allow you to not learn the borrow checker, since leaking everything is not a good memory management strategy, but might be fine for rapidly iterating on a design.

EDIT: maybe use a leak!() Macro that does Box::leak(Box::new()) in debug mode but panics on release (as long as you execute once in release it should be fine).

I did.

Another user already proposed Odin, but no one yet Jonathan blow’s unnamed programming language (people call it jay). Those are the 2 programming languages that came to mind when I think of game development.

I haven’t tried either so I don’t know if they fit you, but they are new languages so they should avoid java’s and C++'s pitfalls.

Interfaces (traits in rust) are the best imo. Way better than raw structs in C or the mess that is inheritance.

What I don’t like about go’s interfaces is that they’re implemented implicitly. I much prefer java’s and Rust’s way to implicitly say which classes/structs extend/implement which interfaces.

Using “clever” ways to disable the borrow checker is one of the few things I don’t like about rust. I much rather it having a “borrow checker version” and a “garbage collector version”. That way we could rapidly iterate through design choices with the GC, and once the design has proven good, apply lifetimes and such to use with the borrow checker. The only downside to this I can think of is that most would just leave it in the GC version and not bother to move to borrow checker. But that’s fine by me, rust has many other features to take advantage of. As long as no GC libraries are allowed in crates.io, it should be fine.

You can just. Have datastruct be mutable if you want. Immutable by default doesn’t mean you can’t make variables mutable.

Vscode too

HTML is hard to parse because it allows mistakes.

I don’t know the answer to your question. But if it was me, I’d run the HTML parser until it encounters an error, manually fix the error, then try to parse again. Until it parses correctly.