Standard library priorities

[matthewmueller]

In this issue, I'd like to start prioritizing the standard library functions, so we can tackle the most important ones first.

I'm hoping to have people post something like this:

10 time.Now
4 strings.Join
1 filepath.Rel
...

Would be great to create a script that looks at the call expressions and counts them.

But for now, any format would be helpful and I can combine manually.

[shaban]

Actually that needs further thought. If you want to be 100% compatible with the go datatypes you will end up with something close to gopherjs. The other extreme to be 100% compatible with JS data types you will end up with a stdlib that creates interoperability by mirroring the javascript type definitions with interfaces, structs.

So which way do you want to go? e.g time.Now() vs javascript Date()? Although go's stdlib is way richer than JS one it might be beneficial to have a uniform interface that leans on the JS side for default representation of the underlying data.

So a middle road would be to represent go's stdlib types by default same as in JS when possible. This way you will have better js interoperability while still retaining the type safety and completion support of go. Often it might just be about the default representation a stringer method will output not necessarily about how it is realized in go.

I hope what i said makes some sense :)

P.S. i just took a look at your Println and Printf implementations and they don't work for me.

Println doesn't honour "\n" and Printf doesn't seem to do any placeholder formatting like %s and so on. My 2 cents is that gopherjs transpiles the standard library on a much more fundamental level. Maybe sticking to a sane typesafe compatibility layer on top of JS looks much more manageable than really porting the stdlib.

The drawback is that the stdlib is obviously a big plus in go's books, but at least you would get something like typescript in go.

Don't want to discourage you i just think these hundreds of kilobytes the fmt library alone transpiles to in gopherjs means really a lot of work if porting by hand.

[matthewmueller]

Absolutely! I've given this some thought too. What do you think about supporting both?

The JS core API is actually really small, and I think having it would make it easier to translate existing JS libraries to Go. One downside of this is approach is that it might be confusing where there's overlap, the date is a good example.

I think we're on the same page of where this is heading, I'd rather show compiler errors than to try forcing Javascript to have the same output as Go. That being said, coming from Node.js, I'm very weary of tons of little incompatibilities that make it think like the Joy code you wrote will work with Go.

In your example of fmt.Printf(...), I need to see what Gopher does with that, but I don't really think there's an equivalent in JS, there's no console.print(...), so in that case maybe we just error out and say, use fmt.Printf(...) instead.

[shaban]

So as a milestone having a typesafe JS core API and then go from there sounds good to me. Especially considering that you can still use go on the backend for the heavy lifting with lots of nice interfaces between like micro-services, REST, html/template etc.

On gopherjs i already tried out what println does with a \n inside and it prints a newline on the command line output. The only thing halfway similar to go's fmt was a sprintf implementation in javascript that i stumbled on. But for now this all shouldn't worry you too much.

[matthewmueller]

So as a milestone having a typesafe JS core API and then go from there sounds good to me.

Awesome, yep. I think that make sense to me. I'll probably just implement these as I need them and hopefully others can help implement when they need them. There will need to be a concerted effort to fill in the gaps, but I'd rather focus on the biggest value adds right now.

The only thing halfway similar to go's fmt was a sprintf implementation in javascript that i stumbled on.

I think we'd use that for https://golang.org/pkg/fmt/#Sprintf, but perfectly replicating fmt.Printf doesn't seem possible if we assume that stdio is the console in the browser.

[shaban]

Awesome, yep. I think that make sense to me. I'll probably just implement these as I need them and hopefully others can help implement when they need them. There will need to be a concerted effort to fill in the gaps, but I'd rather focus on the biggest value adds right now.

I might contribute once i see some implementations to learn from.

I think we'd use that for https://golang.org/pkg/fmt/#Sprintf, but perfectly replicating fmt.Printf doesn't seem possible if we assume that stdio is the console in the browser.

Yes shouldn't be an issue it seems like most of the joy/stdlib will follow the JS callback way of doing things, so streams won't be a topic until stuff like Streams API becomes stable.

[matthewmueller]

Yes shouldn't be an issue it seems like most of the joy/stdlib

Right now I'm thinking joy/stdlib will follow Go's stdlib, joy/dom will likely be more 1:1 with the DOM so things like websocket.OnMessage = func () { ... }. And this JS API will probably be under joy/js and have things like js.SetTimeout(fn func(), ms uint)

[shaban]

makes sense.

a bit offtopic i tried out to install joy the go way and it went really good there was one issue though.

I am mentioning this because the steps necessary to have more people contribute are imho.

• weed out some oddities at install we talked about
• update the documentation regarding that
• describe your mental image of the project
• make stubs for where the pieces should fall into place
• write some more documentation or well commented examples