Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal
I have no doubt there is huge amount of people who love the exceptions, and I agree with you that is precisely this crowd that pushed this agenda forward. But I found following true, anything that can fail will fail. E.g. any type of IO operation. It's not a question of if but when. What that means I have a problem when people think IO Error is an exceptional state of some kind. It is not, it's just valid return value of the given IO operation, if I think of it as such I write code that is more reliable and testable. As for panic/recover - given the above when would I really want to panic? If I treat my errors as first class citizens, I don't ever need to panic. And for the record I myself have on few occasions reached for panic (this will never happen type of thinking) - and I found myself going back and replace it with proper error handling every single time. So now I just know better. As for the argument that it is possible to use try/catch type of error handling successfully. I say I don't doubt it - I just never had the pleasure to work with (or after) anyone that was able to do that. And I include my own try/catch code in that group. On Sunday, July 7, 2019 at 5:37:38 AM UTC, Lucio wrote: > > On 7/6/19, Jakub Labath > wrote: > > "And yes go does have panic/recover - but I never use them for the same > reasons I > > dislike exceptions. It's just really hard to reason about such jumps in > logic especially > > in massively concurrent programs that go allows us to write." > > I agree with everything else you state, except the above. > > Those who are comfortable with try/catch and similar should seek their > comfort zone in panic/recover and teach some of us why they find them > useful. > > Note that I am not one of those. But a lot of the needling that led to > "try - the function" almost certainly originates from those quarters > and only a little social engineering in the form of great > documentation may be needed to put that dragon back to sleep. I vote > we encourage that. > > Lucio. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/4052c175-b34e-476b-8e31-90695bed924e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal
But it's not a binary question. If you ask me Would like go to have Maybe/Option type instead of val, err - then I can say yes. Would you like to have something such as Rust's Result instead of val, err - then I can say yes (even though I understand this may not be possible due to generics etc). But what is being asked here is would you like to have error handling and flow of control functionality baked together - and then my answer is no. I know from several years of experience writing both go and python/java that my go code is more stable than my python/java code is and the big part of it is the proper error handling. And yes go does have panic/recover - but I never use them for the same reasons I dislike exceptions. It's just really hard to reason about such jumps in logic especially in massively concurrent programs that go allows us to write. On Friday, July 5, 2019 at 10:30:43 PM UTC, andrey mirtchovski wrote: > > > So I was quiet on the topic then - I am not now. > > i guess you missed the point where I advocated for a new survey, well > advertised, where all the people who are fervent Go programmers but > somehow neglected to fill out the Go surveys for three years running > can cast their voice. "does go error handling need change: ◻️yes ◻️no > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/3c8fc5c2-923f-46cd-965d-86889141dccb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: the Dominance of English in Programming Languages
Back in the 90ies someone at Microsoft had the brilliant idea to translate Visual Basic that came with the Czech version of Excel into Czech. So e.g. IF became KDYZ (well it's not Z it's Z with caron - which also was a problem if character encoding was not set properly) The results were that no one was able to re-use any code or documentation to learn it. It created numerous problems for IT support as any macros written in English were broken. So in the end rather than creating an army of Czech visual basic programmers we were specifically requesting English version of the software to replace the Czech ones. Let's not do that ever again I say. On Monday, April 29, 2019 at 5:36:37 AM UTC, Chris Burkert wrote: > > I recently read an article (German) about the dominance of English in > programming languages [1]. It is about the fact that keywords in a language > typically are English words. Thus it would be hard for non English speakers > to learn programming - argue the authors. > > I wonder if there is really demand for that but of course it is weird to > ask that on an English list. > > I also wonder if it would be possible on a tooling level to support > keywords in other languages e.g. via build tags: // +language german > > Besides keywords we have a lot of names for functions, methods, structs, > interfaces and so on. So there is definitely more to it. > > While such a feature may be beneficial for new programmers, to me it comes > with many downsides like: readability, ambiguous naming / clashes, global > teams ... > > I also believe the authors totally miss the point that learning Go is > about to learn a language as it is because it is the language of the > compiler. > > However I find the topic interesting and want to hear about your opinions. > > thanks - Chris > > 1: > > https://www.derstandard.de/story/2000101285309/programmieren-ist-fuer-jeden-aber-nur-wenn-man-englisch-spricht > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/3c016ce9-bc76-4d3a-8549-68d4e1769ea7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Priority cases in select?
Glad someone mentioned reflect.Select. Implemented simple round robin
solution with a timeout case (if no data is available at all) using just
that .
To add to some priority would be just be a matter of setting the
channel/cases to nil after several writes, rather than just after one like
I do. Lower priority cases would get set to nil sooner.
The other reason I needed reflect.Select was because the number of channels
being polled changes at runtime.
I agree with Wim that you can probably implement quite a few things using
that - with priority just being one of them.
It does seem like use of reflect.Select would be really wasteful to use
inside a loop but in my case at least I did not notice any problems (sorry
don't have more scientific numbers than that).
Cheers
Jakub
On Thursday, January 26, 2017 at 12:20:50 AM UTC, Wim Lewis wrote:
>
>
> On Jan 25, 2017, at 8:00 AM, 'Axel Wagner' via golang-nuts <
> golan...@googlegroups.com > wrote:
> > It's also a feature rabbit-hole. I'd predict, that next up, someone who
> experiences starvation wants to add weighted scheduling ("give this case an
> 80% chance of succeeding and this other case 20%, so that eventually either
> will proceed") or more complicated scheduling strategies.
> >
> > I think such edge-cases for scheduling requirements should rather be
> implemented separately in a library. Yes, it's complicated code, but that's
> all the more reason why it shouldn't be in everyone's go runtime.
>
> Since it is an edge case, but one which has legitimate (if idiosyncratic)
> uses, maybe the best approach would be to implement only enough in the go
> runtime to allow people to implement what they want. It seems to me that
> the minimal functionality needed would be a "non-receiving select". In
> other words, an addition to the reflect package which would allow people to
> efficiently wait for any of N channels to become receivable, without
> actually receiving anything.
>
> Straw-man suggestion: a function reflect.TestSelect(cases []SelectCase) ->
> []int
>
> which blocks until at least one case can proceed, and then returns a list
> of all cases which could proceed without blocking. Given that primitive,
> people can implement whatever behavior they want, and the primitive itself
> is fairly simple and well-defined.
>
> Another option that occurs to me is to add a bool to the SelectCase struct
> which tells select, "block on this, but don't actually perform the action",
> but I think that would be less clean.
>
>
>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Do you guys use ORMs when working with SQL?
Hi,
When I gave some thought to the whole ORM, I concluded it was not the SQL
that bothered me it was these items
1. Adding a new column to table means having to revisit every
query/insert/update that could be affected
2. Serializing and de-serializing as things get saved/read from DB (dealing
with null values, date time conversions, blobs that should be parsed into
e.g. json etc.)
So rather than create some magical layer above SQL I simply attempted to
abstract the above items into one place.
So that when adding a new column one only has to adjust the serializer and
de-serializer methods, and when querying one simply omits listing the
columns.
Here my attempt at the above - https://github.com/jlabath/dbi
Cheers
Jakub Labath
On Tuesday, December 27, 2016 at 10:00:05 PM UTC, Zippoxer wrote:
>
> I haven't written SQL for years. I was enjoying MongoDB with the awesome
> mgo package, and what saved me a lot of headache was the natural
> programmatic interface of MongoDB.
> mgo maps your data (structs, maps, slices) to MongoDB queries and from
> MongoDB results, and you can write any MongoDB query possible with the
> mgo/bson package exclusively.
>
> I've seen the sqlx package which only does mapping of results from the
> database, but not the other way around -- so you still have to type some
> queries like this:
> func InsertFoo(v Foo) {
> db.Exec(`INSERT INTO x (bla, bla2, bla3, bla4, bla5, bla6, ...)
> VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ...)`, v.bla, v.bla2, v.bla3,
> v.bla4, v.bla5, v.bla6, ...)}
> }
>
> I can live with this verbosity, but that's not my problem. What happens
> when you add a field to the struct *Foo*? You have to modify the query
> above in three places and make sure you typed every character correctly.
> And there are probably more queries updating *Foo*. Seems like too much
> manual maintenance to do -- and I believe this increases the chance of bugs.
>
> A classic solution to this problem would be to use an ORM. I've looked at
> SQLBoiler <https://github.com/vattle/sqlboiler> and I'm very excited to
> see an ORM that generates Go code instead of using reflection. However, it
> still has the classic problem of ORMs that we all discuss from time to time.
> Like any ORM, due to it being an additional layer on top of the database,
> it adds complexity (instead of verbosity and the manual query maintenance
> above) and you might have to write raw SQL anyway (what if you only want to
> select 2 fields of Foo instead of all of them? what about complex queries?)
>
> Considering all that, I still cannot reach a conclusion. I'm going back
> and forth on that issue.
>
> Since I appreciate the opinions of this community more than any other
> community I know right now, can you guys pour your opinions on the matter?
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: unmarshaling json to byte type
While you can use the solution suggested by Viktor.
I do wonder what exactly is the point of the byte type?
I mean byte is just uint8 just like it says above.
So really if you want number between 0 and 255 you can just send along the
number.
This is gonna be more readable than some text encoding of byte using base64
or similar.
If you are concerned about space I feel compression will serve you better.
But who knows maybe you have perfectly valid reason for sending along byte
as string and then converting it back to byte.
Cheers
PS: just in case this was not about byte but []byte
https://golang.org/pkg/encoding/json/#RawMessage
On Wednesday, September 14, 2016 at 3:06:41 PM UTC, Luke wrote:
>
> Hi,
>
> i have something like: https://play.golang.org/p/j5WhDMUTI-
>
> type A struct {
>Name string `json:"n"`
>Typ byte `json:"t"`
> }
>
> JSON string:
>
> j := `{"n":"test", "t":"x"}`
>
>
> When I try to do
>
> a := A{}
> json.Unmarshal([]byte(j), )
>
> I get error like: *json: cannot unmarshal string into Go value of type
> uint8*
>
>
> Any idea how to force unmarshaler to treat one character string as byte
> using standard json lib?
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
