Hi George,
I highly suggest you check out the Fiber web framework. You will find the
framework interesting.
This repo has a list of many examples using Fiber –
https://github.com/gofiber/recipes
Scroll through the repository, and you will most likely find what you are
looking for.
On Monday, J
with a different keyword and
> *that* got rejected for the "magical" control flow.
>
> On Mon, Aug 31, 2020 at 9:00 AM Axel Wagner
> wrote:
>
>> On Mon, Aug 31, 2020 at 7:32 AM Zakaria wrote:
>>
>>> If the objections on the too magical handle part, why
.
Pada tanggal Sen, 31 Agt 2020 10.34, Ian Lance Taylor
menulis:
> On Sun, Aug 30, 2020 at 7:16 PM Zakaria bin Haris
> wrote:
> >
> > Idk if this has been proposed or discussed before.
> >
> > Given the last error handling abbreviation proposal is rejected. How
Cause the objection for previous error handling is code coverage, the
solution is for code coverage tools to desugarize *rinn* syntax.
The objective to minimize error handling "noise" from human eyes.
On Monday, August 31, 2020 at 9:29:44 AM UTC+7 Zakaria bin Haris wrote:
> For co
For completeness if the function is something like:
func x() (data *Data, err error) {
}
then *rinn* should be smart enough to assign error to err variable and just
do return instead return err
On Monday, August 31, 2020 at 9:19:48 AM UTC+7 Zakaria bin Haris wrote:
> Sorry, I mean ret
Sorry, I mean return if not nil, so it should be *rinn* or please find some
better keyword for this :^).
On Monday, August 31, 2020 at 9:15:31 AM UTC+7 Zakaria bin Haris wrote:
> Hi, gophers!
>
> Idk if this has been proposed or discussed before.
>
> Given the last error handli
Hi, gophers!
Idk if this has been proposed or discussed before.
Given the last error handling abbreviation proposal is rejected. How about
some simple syntactic sugar like this:
*rin* Something()
Which is just a sugar for:
if err := Something(); err != nil {
return err
}
To make it
That's not bad and good to know.
Thanks for sharing !
Fundamentally I want to include the tests in the main though executable and
then run testing.T myself in the normal main
(Through a CLI command)
I'm willing to accept it can't be done because ts not idiomatic but thought
I'd inquire.
On Tue,
We've written some diagnostic tests that we execute during the test phase
(go test) however I was wondering if there's an established
pattern for how to include tests in the final binary and execute them
afterwards.
The analogous version in Java would be that you could create a "test JAR"
which
I am curious if there's anyone that has tackled integrating Yubikey
(PKCS#11) solution with crypto.Signer such that it can be plugged into
ssh.NewSignerFromSigner (https://godoc.org/golang.org/x/crypto/ssh#Signer)
--
You received this message because you are subscribed to the Google Groups
"go
those indexes when starting godoc (*.db)
Farid Zakaria
On Fri, Sep 29, 2017 at 11:23 AM, Ayan George wrote:
> farid.m.zaka...@gmail.com wrote:
>
> > Is there a reason why GODOC only indexes packages it finds in $GOROOT ?
> I
> > would like to create indices of my personal package
Is there a reason why GODOC only indexes packages it finds in $GOROOT ?
I would like to create indices of my personal packages + the standard
library.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop recei
12 matches
Mail list logo
