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.
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.
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.
Iirc Ubuntu names their home files “Downloads”, “Documents”, and so on. Same with windows (there are a lot of uppercase letters in windows files). I’ve had issues with Cargo.toml before. And not just cargo, many config files use case to signal priority (so if both Makefile and makefile exist, Makefile will be used (or other way around)). Downloaded files are a gamble. Files created by user input (so for example if I wanted my user to be “Calcopiritus”, my home would be “/home/Calcopiritus”.
Uppercase letters might not be common in filenames, but they are not nonexistent.
They are not created by people. They are created by programs.
I can make MY files all lowercase, but 99.999% of files on my computer are not created by me. And some of them have capital letters.
When you say "canse insensitive file*, do you mean lowercase files? Or is there an option?
Idk why we talking about mouses. When I’m on Linux, most of the time it’s through ssh.
This is the first time I’ve seen uppercase denoting scope. Usually it is done with a “_” or “__” prefix.
Casing styles usually mean different identifier types.
snake_case or pascalCase for functions and variables, CamelCase for types, UPPER_SNAKE_CASE for constants, and so on.
If we want to apply this to file systems, you could argue something like: CamelCase for directories, snake_case for files, pascalCase for symlinks, UPPER_SNAKE_CASE for hidden files.
I’m with windows on this one. Case insensitive is much more ergonomics with the only sacrifice represented by this meme. And a little bit of performance of course. But the ergonomics are worth it imo.
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.
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).
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.
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.