New port almost ready

[jesperoman]

I have a scala version of this here
It has some polishing, publishing of artifacts and stuff left, but let me know if you want it pushed here.
Should I fork and make a pull request?

[4kimov]

Oh cool. How about I give you maintainer rights to this repo and you push your code here?

[jesperoman]

Yeah, sure!
Works fine for me!

[4kimov]

Cool, invite sent.

A few notes:

• If you'd like to use one of the existing READMEs, you can copy these and just replace examples: Go, Rust, Python
• I can see you got most tests there which is great, perhaps just this one missing?
• If you need to store secrets in the repo (for testing or publishing package), please let me know
• When you're ready with the repo + package, just let me know and I'll update the site

And of course, I'm here if you have questions about anything 👍

[jesperoman]

Also thinking about using Long's instead of Int's, Actually already have a branch with that implementation, since javascript version have a much larger maxValue than scala, it could produce id's not decodable by the current scala version, possibly bad.
It's a pretty significant difference:

scala> Int.MaxValue
val res0: Int = 2147483647

scala> Long.MaxValue
val res1: Long = 9223372036854775807

[4kimov]

I see, so according to spec, encode function is capable of throwing an error (during an overflow), and decode function is not (it will just return an empty array if anything fails). I don't think we should estimate the likelihood of encode hitting the blocklist limit because we don't control the constructor/input params (the user does), so it should def be designed with the expectation that it can fail easily (imagine the user giving a giant blocklist of all possible values). I leave it up to you how to design it in Scala (via Either or exceptions).

Regarding int vs long, personally I just use the largest unsigned integer the language supports (eg: u64 for Rust, uint64 for Go). I'm guessing you're not using only Long everywhere because of performance? If that's the case, I'd just suggest to do whatever the Scala community recommends regarding safely + efficiently handling large numbers.

[jesperoman]

That settles it, Long in scala is basically a 64 bit integer the scala equivalent of rusts u64.
From the scaladoc:
Long, a 64-bit signed integer (equivalent to Java's long primitive type)
Unsigned integers dont exist in the jvm world.

When handling lengths of strings and such, of course I'm using regular ints (32 bit) since that's the default.

[4kimov]

Ok, sounds good. Then the only thing to handle is manual checks for negative numbers (I believe the spec repo shows examples of those, in the library and in tests).

[jesperoman]

Yes there is already checks for that and tests as well