I feel like learning the import system is the worst part of learning any language because literally all of them suck for different reasons:

in Python you can’t import from parent directories without jumping through hoops and adding unnecessary __init__.py files everywhere. also the syntax for importing is really unintuitive and documented across multiple PEPs, each of which is a heavy read on its own

C-family languages generally don’t have proper import systems at all and what they have instead is probably a headachey clusterfuck

Java.

in Clojure if you want to import a file from another file at all you have to use a command called lein to generate a massive overcomplicated structure of directories and config files and then edit the config files and even then you have to import them using a fully-qualified namespace and every single file must manually specify which namespace it’s part of, but the namespace must also perfectly match its directory structure or it will silently fail to be imported. it’s like this confusing halfway point between a proper module system and a com.java.www.java.src.code.style.clusterfuck.system

I don’t know what’s going on with Common Lisp’s import system but it scares me, just like everything else about that language

Racket doesn’t have a proper concept of namespaces. if you import rackunit then by default everything from that module will be dumped into your current file, but you can choose to prefix those names with something like rackunit:so that they become named things like rackunit:check-eq? and rackunit:check-false. this isn’t a separate namespace though - it’s literally just renaming every import to start with rackunit:

one of JavaScript’s many, many import systems actually seems pretty nice - but I couldn’t tell you which one it is because I was relieved just to convince package.json to let me import anything at all and left it at that. good luck finding any documentation on your chosen import system btw, or even information on how the import systems differ or which to use. oh also if you install Node packages then have fun figuring out how to import them too. here’s a hint: it involves bashing your head against package.json some more

TypeScript somehow makes the package.json thing worse. like so much worse

IIRC Lua’s import system is based on the current directory instead of the directory of the current file, which means that you have to be cded to exactly the right directory when you run Lua code or you’ll get import errors and not know why. also the only clear description of how the import system works is in Programming In Lua which is outdated and missing some important details. and this isn’t even getting into the clusterfuck of trying to use someone else’s Lua library - especially if luarocks is involved

every time I learn a new language I dread when I’ll have to figure out how to import something, because there’s always some bullshit like this. every time

@kasdeya I like the "Java." No explanation needed.

Yeah, when I was learning Rust, I think the hardest thing to understand was lifetimes, but the import system (really, the whole module system) was a close second. I don't think any language has a good import system.

@emberquill to be honest I don’t remember having too much trouble with imports in Rust, but that might’ve just been because I was overwhelmed by everything else lol. it is by far the most difficult language I’ve ever tried to learn

but omg I’m glad I’m not the only one who struggles with import systems - they drive me crazy most of the time

@kasdeya my problem was that people apparently didn't agree about module filesystem structure yet while I was learning, so when I looked up how to do stuff it was a toss-up whether the answer would involve extern crate or not. And I can't remember what the exact issue was, but I remember having problems with relative imports to such a degree that I started using absolute imports for everything instead.

That pales in comparison to trying to figure out lifetimes, to be honest, but there were at least a few stumbling blocks.

@kasdeya yeah js's imports are admittedly a mess — there's like four different module environments it can be working with and a wide range of old and new standards that are only partially compatible with each other. if you end up needing to fight with that again let us know, we'd be happy to help untangle things

(it's less related to package.json than you're thinking though, that's for the npm package format, not basic language module / import semantics, so you can usually ignore it unless you're publishing a module)

@tempest thank you! I would definitely love the help if I do end up using JS again 💙

@kasdeya it enjoys lua a lot, but luarocks is just... awful

and yea normal importing is just java classpath but Different Kinda

@0x57e11a I hate luarocks so much T_T I totally agree with it that Lua is amazing - I love how elegantly it’s able to encapsulate all kinds of useful functionality in just a few concepts, like tables and metamethods. and I find it so beautiful that the require() function just runs an entire file like it’s a function, and returns whatever it returns. and the distinction between table.function() and table:function() is so elegant to me - I love it

but yeah I’ve had such a difficult time getting luarocks to work basically at all, and there’s so little help available on using it. plus even getting Lua to run on Windows can be kind of a nightmare - especially since it asks you to manually set environment variables that aren’t properly/fully explained anywhere that I could find

@kasdeya yeah!! lua can be clunky at times, but it builds so much off of simple those simple concepts, which is very neat

from what it's gathered, lua's module loading is:
- `require` replaces dots with slashes
- `package.path` / `LUA_PATH` env, which contains semicolon separated paths to search for lua files, replacing question marks with the argument to require. so `./?.lua` would resolve `require("doll.awawa")` to `./doll/awawa.lua`
- `package.cpath` / `LUA_CPATH` env, same as above except for loading native modules. so `./?.so` would resolve `require("doll.awawa")` to `./doll/awawa.so`.
- lua doesnt know abt luarocks, and doesn't automatically load luarocks paths into path/cpath, so you have to use `require("luarocks.loader")` (which requires having luarocks on lua path, which. yeah)