Language is not package-friendly

[Namek]

One cannot:

• make private/internal functions in modules. Some code is not useful to package users at all. Having too many functions available makes actual API unreadable.
• put records into module's namespace. Module records should not be available by default in application code. Thus, some import construction would be needed. Also, probably not exposing some of internal records should be possible.
• specify data processing algorithms for user data types using records because records do not support generics/type holes. Workaround: enums or tuples.

Additionally, any record should be distinguishable by it's namespace+name and not by it's structure. Otherwise, we'll easily have collisions. To support casting between values of same structure or substructure we would need as operator, as I have discussed in #188 (comment)

[luncheon]

For application scalability, I also want to create internal functions/getters in modules/stores.

[itsgreggreg]

Here's the best I could come up with with the current lack of restrictions.
https://www.mint-lang.com/packages/itsgreggreg/mint-murmur3

Everything private is in a ..Private.. namespace with documentation not to use it.
This is probably less that ideal for the reasons mentioned above but also because semantic versioning becomes hard to work with. Since everything is public altering how the internals work easily leads to a required major version bump.