4 ms·
Personally, I would have gone with Kotlin for a translation like this. It's a closer match to Python than Go, and I think his rule swarm [1] approach to semi-au
by mwcampbell 5y ago
Personally, I would have gone with Kotlin for a translation like this. It's a closer match to Python than Go, and I think his rule swarm [1] approach to semi-automated translation would have been effective. But then, he might not have liked the fact that, like Python 3 and unlike Go, the Java platform treats strings (particularly filenames) as a sequence of Unicode code points rather than bytes.
[1]: http://esr.ibiblio.org/?p=8153 http://esr.ibiblio.org/?p=8153
- colin_mccabe 5y agoGo treats strings as a sequence of unicode code points.
- fnoof 5y agoI believe they’re treated as byte sequences: https://go.dev/ref/spec#String_types https://go.dev/ref/spec#String_types
- ustolemyname 5y agoNot treated as, only backed by byte sequences. If you range over them you get a series of rune values that can be multi-byte code points. There's a few other differences, strings cannot be directly mutated or have the address of their elements taken.
- dbt00 5y ago> It's a closer match to Python than Go I like Kotlin, but I really think of Go as the most probable outcome of someone saying "I'd like a staticly typed, concurrent/parallel Python", and then mumbled "but I hate exceptions". Go is very close to python in many respects.