Hey Ryan, thanks for all the work. I am noticing that the AsyncRandom class in Random.mo doesn’t have all of the fun methods such as nat64, nat64Range, natRange, intRange, even though it’s in the documentation https://internetcomputer.org/docs/motoko/core/Random, will this be added soon?
I am using core@0.6.0
Let me know!
Checking the lib out quickly. Looks like
Vector → List
List → Stack, Queue, pure/List
Map and Set look great - Btree based. No need for hashmaps? How do they perform compared to Zhenya’s Map and Set?
Changes are looking great. I like the ‘pure’ libraries idea. Also that there are no classes, just functions. Random libs look great too.
Is there a way to add initial capacity to List like Buffer had. Many times with my code i have an item count estimate/upper bound/exact number, so i would like to be able to use that for efficiency
Thank you for pointing this out! I opened this PR to add the missing methods.
There currently isn’t a way to specify an initial capacity for List (same as with the original Vector). For situations where performance is critical and the maximum size is known beforehand, using a var-array with optional values is going to be the most efficient option. For example:
import VarArray "mo:core/VarArray";
let array = VarArray.repeat<?Text>(null, 3);
array[0] := "A";
array[1] := "B";
array[2] := "C";
assert array == [var "A", "B", "C"];
We considered adding a wrapper data structure around this pattern into the standard library but decided that this would be better suited for an external Mops package.
It’s worth noting that it is possible to continue using Buffer and the other original data structures by importing both base and core into a project. The goal is to give enough time for the package ecosystem to fill in the gaps before fully dropping support for the original base library.
We were thinking of doing that (providing a reserve function) but in the end decided against it. The problem is that List has a shrinking logic to free unused space if the List shrinks. Reserving large unused space would interfere with that logic because the logic would try to shrink it again. We didn’t see the performance gain as significant enough to justify the additional complexity. List should be efficient enough even without reservation.
Are there any types that are getting deprecated and if so is there a legacy library we will be able to import ? Are there clear instructions regarding this somewhere ?
AFAIK the base library will stay around so that’s your legacy library. In that sense nothing would be “deprecated”.
I’ve been working on a larger project for several months using the “old” base library. Would it be advisable to upgrade to the new one at this point, or should we continue using the existing version?
We encourage switching to the new core package if possible. This will reduce the complexity in the long run when we eventually drop support for the original base library.
Including both base and core as parallel dependencies is one way to gradually make this transition. LLMs are also beginning to pick up the core package and could be useful (with caution) in combination with the migration guide.
Let me know if you run into any issues if you end up migrating in case we can assist.
Thanks for your response. I’m in the final weeks of the project, with a due date at the end of August. I will try to migrate the project. It consists of four different Motoko canisters that work together for various tasks, such as backend services for task management, documentation, user management, indexing, time tracking, and file storage.
Are you completely done with everything else? Otherwise I wouldn’t migrate in this time.
I’m mostly done, but there are still a few small functions that the frontend needs which have to be added.
Today, I tried refactoring a module and realized that migrating will require a significant amount of work. I use OrderedMap and Buffer extensively, and several inter-canister calls from the module functions will also need to be refactored due to the new OrderedMap behavior.
Hello all, we just published version 1.0.0 of the core package! Formal announcements are on the way, most likely starting next week.
This release includes a few breaking API changes to account for early adopter feedback. Here is the changelog and API diff for reference.
Let us know if you run into any issues so we can address them prior to the big announcement.
Cheers!
Where is my Debug.trap? 
Do you all have a better recommended way of handling this? I really don’t want to import Prim.
Debug.trap() is now Runtime.trap(). We moved it to a separate module so that Debug is now specifically for debugging-related functions.
Ahhh….nice…I hadn’t noticed runtime.
New forum topic for core:
I finally managed to migrate all canisters in the project to the new core base library. 
