[go-nuts] Re: [generics] Thank you Go team
Also big +1 from my side and kudos to Ian for always answering to this
storm of objections and suggestions with patience and objectiveness
Am Freitag, 19. Juni 2020 04:17:16 UTC+2 schrieb Michael Jones:
>
> I doubt this will help, but I have to try...
>
> Really smart and accomplished people have worked for a year to refine the
> generics approach--as the impressive updated design draft and the scholarly
> FeatherweightGo paper both demonstrate. The design is accompanied with
> tools to allow development and experience by any interested Go developer.
> This is marvelous. Thank you Go team and helpers!
>
> Let's post about substantial things in the design ("generic type switch
> necessary at day one" maybe, whatever) and not only about parenthesis. I'm
> going crazy here seeing all the comments about that. I mean, think of how
> hard they are working on this; parenthesis posts read like *More Cowbell *to
> me.
>
> Sorry for the outburst,
> Michael
>
> P.S. I challenge you to fully read the Featherweight Go paper and the
> design draft, as I did, and then come away thinking about the expression of
> the idea rather than the idea. I just can't comprehend it -- it is the
> ideas that hold power and beauty, that will transform our daily work.
>
> --
>
> *Michael T. jonesmichae...@gmail.com *
>
--
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/143db862-eb49-4ea1-aec6-6d23987b5e4ao%40googlegroups.com.
[go-nuts] Re: go2go (generics) and function binding
I didn't know you can already play around with early access releases of Go2
including generics. This is awsome! I promised myself to start working with
Go once it has generics. Therefore, could someone tell me where to download
the latest version of Go2 or tell me where the branch of it resides? This
is a little off-topic, sorry. But I thought it is not worth creating a new
topic just for this lilttle question.
Thank you.
Am Samstag, 30. Mai 2020 11:33:37 UTC+2 schrieb Sebastien Binet:
>
> hi there,
>
> I was trying out the generics proposal
> https://github.com/golang/go/issues/15292, via the "Go2 playground":
> https://ccbrown.github.io/wasm-go-playground/experimental/generics
>
> the thing I am trying to solve is, basically, a generic way to:
> - pass a function with any number of parameters and a single return value
> - "bind" that function to a slice of pointers to values (that will point
> to, e.g., values extracted from a db)
> - create a closure that returns the value from evaluating the function
> with the bound paramaters.
>
> basically, I am defining this interface:
> type Formula interface {
> Vars() []string
> Bind(ptrs []interface{}) error
> Func() interface{}
> }
>
> that people would be able (in Go-1) to implement like so:
>
> type FormF64F32ToI64 struct {
> vars []string
> arg0 *float64
> arg1 *float32
> fct func(x1 float64, x2 float32) int64
> }
>
> func (f *FormF64F32ToI64) Vars() []string { return f.vars }
> func (f *FormF64F32ToI64) Bind(ptrs []interface{}) error {
> // check number of args elided.
> f.arg0 = ptrs[0].(*float64)
> f.arg1 = ptrs[1].(*float32)
> return nil
> }
>
> func (f *FormF64F32ToI64) Func() interface{} {
> return func() int64 {
> return f.fct(*f.arg0, *f.arg1)
> }
> }
>
> so some "framework/library" code can work in terms of this Formula
> interface and let clients register formulae (with a set of column names to
> read from the database) in a relatively type-safe way, and quite performant
> one too (you pay the price of the type-assert once when you retrieve the
> function closure):
>
> usr, err := db.Formula({
> names: []string{"col1", "col42"},
> fct: func(x1 float64, x2 float32) int64 { return int64(x1) + int64(x2)
> },
> })
> check(err)
>
> fct := usr.Func().(func () int64)
>
> err = db.IterRows(func(tx Tx)error {
> fmt.Printf("row[%d]: %d\n", tx.ID, fct())
> })
> check(err)
>
> implementing the Formula interface from a given func is a pretty
> mechanical job.
> right now, I am doing it with a little go/types-based command.
>
> today, I tried to do the same with the generics proposal:
>
>
> =
> package main
>
> type Formula interface {
> Names() []string
> Bind(args []interface{}) error
> Func() interface{}
> }
>
> type Form2 (type T1,T2,U) struct {
> names []string
> arg1 *T1
> arg2 *T2
> fct func(t1 T1, t2 T2) U
> }
>
> func (f *Form2(T1,T2,U)) Func() interface{} {
> return func() U {
> return f.fct(*f.arg1, *f.arg2)
> }
> }
>
> func (f *Form2(T1,T2,U)) Names() []string { return f.names }
> func (f *Form2(T1,T2,U)) Bind(args []interface{}) error {
> if len(args) != 2 {
> panic("invalid number of arguments")
> }
> f.arg1 = args[0].(*T1)
> f.arg2 = args[1].(*T2)
> return nil
> }
>
> var (
> _ Formula = (*Form2(float64,float32,int64))(nil)
> )
>
> func main() {
> arg1 := 42.0
> arg2 := float32(42)
> args := []interface{}{, }
>
> form := (float64,float32,int64){
> names: []string{"f64", "data"},
> fct: func(x1 float64, x2 float32) int64 { return int64(x1) +
> int64(x2) },
> }
> err := form.Bind(args)
> if err != nil { panic(err) }
>
> fct := form.Func().(func() int64)
> println("fct=",fct())
> }
>
>
> it's definitely an improvement: I "just" have to write the generics code
> for functions with a given arity (say, 0, 1, ... 5) w/o having to
> pre-generate all the functions I (or my users) may need for all
> combinations of (types x arity).
>
> it's not completely satisfactory, though, as:
> - it's not "as general" a solution as what one could come up with, say,
> std::function (from C++), where you "just" have to give a function pointer
> and it handles everything else for you (arity, in this case)
> - there's probably the issue of "generic type argument" collision:
> how to differentiate (in the current scheme) between 'func(x1 float64)
> (float64, int64)' and 'func(x1, x2 float64) int64'?
> (this could perhaps be addressed w/ a different way of describing my
> Form2 generic type.)
>
> perhaps there's a better way of doing this? (perhaps even w/ "just" Go1)
>
> it'd be great to just have to write:
> var f Formula = (func(float64,float64)int64){
> names: names,
>
[go-nuts] Re: Why isn't there strings.reverse("str") function?
Maybe the implementation in Java is something you could steal to save time. Have a look into class StringBuilder where there is a reverse() method. It does the reversion differently depending on whether dealing with UTF16 or not. Am Samstag, 15. Februar 2020 17:37:15 UTC+1 schrieb Amarjeet Anand: > > Hi > > I was wondering why isn't there built-in string reverse function. Is it > left intentionally because of some reason? > > Although strings are immutable in go, there are multiple ways to achieve > this pretty easily. But having this function inbuilt will save our time > because we need it quite often. > > > -- 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/934265f6-666b-446b-aa5e-73f0b2bdcd78%40googlegroups.com.
[go-nuts] Re: Why Discord is switching from Go to Rust
They have very strict latency requirements. So they can't use a language with a GC. That's fine, no language is totally universal. You have to pick the right tool for the job. Aside from that it would be nice if that 2-minutes GC trigger, that is mentioned in the text, could be removed or lessened. Reminds me a bit of Oberon where the GC is triggered on every 20th mouse move. That was a smart "trick" back then, because Wirth and Gutknecht had only very little time to develop Oberon. Developing an algorithm that finds out when to trigger the GC is said to be very challenging and thus they saved the time for that and made the development of Oberon still possible (I would say Go is very much in a similar mindset than Oberon). Am Freitag, 7. Februar 2020 13:24:50 UTC+1 schrieb Everton Marques: > > I think Go is way better than Rust, but it is amusing to see why people > pick one over another. > > "Remarkably, we had only put very basic thought into optimization as the > Rust version was written. Even with just basic optimization, Rust was able > to outperform the hyper hand-tuned Go version. This is a huge testament to > how easy it is to write efficient programs with Rust compared to the deep > dive we had to do with Go." > > > https://blog.discordapp.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f > > -- 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/f0ed8e8a-60cd-4eee-b8b3-ee3f17f903f4%40googlegroups.com.
[go-nuts] Re: Error checking in Go: The `try` keyword
f, err := os.Open("file.dat")
try errors.Wrap(err, "couldn't open file")
You approach has some merits to it. In addition to that some error handling
solution needs to provide a way how to figure out what error happened, e.g.
openening a file could fail because it does not exist or because of missing
read permissions. How do you figure that out in a elegent way without
lengthy if-then-else blocks?
--
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/1147a5ff-a2b9-493b-9162-bea0176fb84c%40googlegroups.com.
[go-nuts] Re: distributed runtime
> > However, if you want to apply supervision for distributed Go channels you > have to change from channels to actors - at least behind the scenes of the > distributed channels. AFAIK, no one has done something like that for > anything writen in Go. Nats is very reliable, but does not provide > guaranteed "all or nothing" delivery. > Coming to think of it you could make use of Rabbitmq as the distributed channel provider. It is written in Erlang and fulfills this "all or nothing" requirement. Bindings for Go already exist: https://godoc.org/github.com/streadway/amqp -- 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/52a565de-6c95-4a28-b8fd-1fc5bb6b1fb6%40googlegroups.com.
[go-nuts] Re: distributed runtime
Am Montag, 6. Januar 2020 09:54:49 UTC+1 schrieb Brian Candler: > > On Monday, 6 January 2020 08:36:56 UTC, ffm...@web.de wrote: >> >> in Amoeba a thread can be suspended, thereafter be sent to some other >> machine where it is resumed. >> > > Thread migration doesn't solve the OP's issue, because threads share > memory with other threads: passing a copy of something is not the same as > passing a pointer to something, unless you have a way for writes through a > pointer to act on the original memory. > Yes, you are right with that. I was dreaming a bit ... To extend the channel-based communication model in Go to a distributed setting you need "all or nothing" garanteed delivery of an item that is inserted into some distributed channel. Otherwise, in case of item to be placed in a distributed channel gets lost, the application may sit. What is useful here is supervision as in the actor model (see 1, 2). If two parties comminucate through a network and get communication problems, a third party resets >both< communication parties that thereafter start anew. This is the approach that made applications written in Erlang fault-tolerant and highly stable. However, if you want to apply supervision for distributed Go channels you have to change from channels to actors - at least behind the scenes of the distributed channels. AFAIK, no one has done something like that for anything writen in Go. Nats is very reliable, but does not provide guaranteed "all or nothing" delivery. [1] https://erlang.org/doc/design_principles/sup_princ.html [2] https://doc.akka.io/docs/akka/2.5/general/supervision.html -- 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/194f0772-0940-4515-850d-da0b410bb7f8%40googlegroups.com.
[go-nuts] Re: distributed runtime
Have you heard of the Amoeba distributed OS? See https://en.wikipedia.org/wiki/Amoeba_(operating_system). Well, in Amoeba a thread can be suspended, thereafter be sent to some other machine where it is resumed. That you can't do with goroutines of course (and goroutines pursue a different approach anway). But I think you could take some ideas from Amoeba. There is also Plan9 to look at, see https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs or Sprite (https://en.wikipedia.org/wiki/Sprite_(operating_system). All those things are bloody awful interesting things. Unhappily, to get anything accomplished that comes only near any of those things would be hell of a lot of work ... -- 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/fd966422-3b2f-41ff-b6e2-9eb913ef5b21%40googlegroups.com.
[go-nuts] Re: the Dominance of English in Programming Languages
"They" were also developing languages of their own, also in countries not
of English language, such as Pascal, Modula, Scala (Switzerland), Kotlin
(Russia) and using English words as key words. It is understood by everyone
in the world who already knows some other language ;-).
Am Montag, 29. April 2019 15:37:45 UTC+2 schrieb fbaube:
>
> It's interesting to see this!
>
> Back in the early 1970s I wondered what the programming languages in other
> countries (not-USA) looked like - what were the keywords, etc.
>
> Well, it turns out that (AFAIK) they were using the same compilers and the
> same interpreters, and languages with the same English keywords, because
> (also AFAIK) nobody was writing non-English-keyword compilers in Europe and
> nobody was patching existing binaries (like BASIC.EXE) to change the
> keywords contained in executables.
>
> cheers - fred
>
> On Monday, April 29, 2019 at 11:58:50 AM UTC+3, yvan...@gmail.com wrote:
>>
>>
>> In France we have WINDEV
>>
> giving something like
>> '''
>> // Le document sera enregistré en noir et blanc
>> SI TwainVersJPEG("C:\Temp\MaPhoto.JPEG", 0, Faux, TwainNoirBlanc) = Vrai
>> ALORS
>> Info("Le document a été enregistré")
>> SINON
>> Erreur("Le document n'a pas été scanné")
>> FIN
>>
>
--
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: Go if else syntax .. suggested replacement
Here is the analoguous discussion concerning the ternary operator in Kotlin:
https://discuss.kotlinlang.org/t/ternary-operator/2116
After 168 posts to this thread where the thread creator did not want to
accept that the language needs no ternary operator, the thread was finally
closed by the admin.
Am Mittwoch, 24. April 2019 03:05:31 UTC+2 schrieb lgo...@gmail.com:
>
> It sure would be nice if Go syntax allowed programmers to replace
>
> if ( test) {
> ...do sonething
> } else {
> ..do something else
> }
>
> with
>
> ? (test) {
> //...do something
> }
> {
> //..do something else
> }
>
> The ? operator can be anything the Go language team considers appropriate
>
--
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: Generics
Here are some code generators that let you define template parameters: https://github.com/cheekybits/genny https://github.com/taylorchu/generic https://github.com/joeshaw/gengen https://github.com/clipperhouse/gen Making use of Go templates: https://github.com/ncw/gotemplate https://github.com/droundy/gotgo Am Dienstag, 11. Dezember 2018 04:00:57 UTC+1 schrieb Tharaneedharan Vilwanathan: > > Hi All, > > I have a quick question. > > What is the best choice for writing generic code till Go officially > supports generics? Just looking for some guidance. > > Regards > dharani > > -- 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: Go Performance
I recommend to change the Java version to make use of Netty (netty.io). Netty contains a lot of network knowledge to speed up things. -- 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: I am not in favor of generics.
Am Dienstag, 18. September 2018 13:29:37 UTC+2 schrieb Chris Hopkins: > > Pondering this, my concern is that it might become too powerful. I'm > scared this will make it harder to work out what someone has done if > there's too much indirection and magic added on top. It feels like it could > be a really *really* big hammer. > I'm not so much scared in this way. Every average Joe Java boilerplate coder gets along with generics. It only gets a little tricky with inheritance. But even there you can manage without thinking and just doing trial and error if you wanted to. Besides that, Go does not have inheritance. So, I think it will neither be tricky to make use of nor to read the code. -- 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: Go concurrency performance
It seems that in your Put function you are creating a new hashTable for every single put with the values from the existing hashTable being moved over to the new hashTable. Why are doing that? Just add the new value for the given key to the hashTable for the segment obtained by key.Hash() % 16 and you are done. Am Donnerstag, 6. September 2018 15:00:18 UTC+2 schrieb Robert Engels: > > Hi, > > I posted this to golang-dev, and the consensus seems to be this is a > better forum to address the issue? > > Anyway, you can review the project > https://github.com/robaho/go-concurrency-test > > The readme.md details the experiment. > > It does some analysis of the Go concurrency primitives, in the context of > writing a ‘shared cache’. The conclusion is that there is a lot of room for > improvement, at least when compared to Java. > > With a larger audience it might be possible for someone to actually run > the test (strange how people see the results and critique without ever even > attempting to run them…), hopefully on additional platforms like Linux, and > possibly a higher core machine (and then increase the number of threads). > > Anyway, let me know your thoughts. Thanks. > > > > > -- 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.
Re: [go-nuts] Why can't we use < > for the Go generic parameters ?
Am Donnerstag, 6. September 2018 13:43:32 UTC+2 schrieb Christophe Meessen: > > I understand your example, but it wouldn't be a problem anymore with a > special character like a $ sign. D use the !. > Scala uses [ and ] instead of < and > to avoid the problem that < and > mean something different depending on the context. -- 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: Ternary ... again
> var color
> if temperature > 100 {
> color = “red”
> } else {
> color = “blue”
> }
>
IMHO, it could be argued about whether adding something like this would be
useful:
color := if temperature > 100 {
return “red”
} else {
return “blue”
}
--
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: Would someone care to compare Firefox Quantum Rust concurrency features to Go....
Concurrency in Rust and Go are completely different things. In Rust a thread has its own memory space and hence a thread cannot reference data by reference of some other thread. The rational behind that is security. Also, a thread in Rust is not lightweight, but a full-blown OS thread. So there is no CSP in Rust as in Go and therefore there is little to compare between Rust and Go concerning concurrency. AFAIK, there is some crate in Rust that adds some minimal support for coroutines, but I don't think its used in Servo. Am Donnerstag, 23. November 2017 09:04:09 UTC+1 schrieb Anssi Porttikivi: > > How would this look, if implemented in Go? Is there anything to learn from > Rust "fearless concurrency"? What are the goals and complexity trade-offs > of the two languages? > https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-In-Firefox-Quantum.html > > When and why would there be a browser engine in Go? ;-) Some interesting > projects to compare to are > - Servo (rust) https://github.com/servo/servo/ > - 3S (haskell) https://hsbrowser.wordpress.com/3s-functional-web-browser/ > - LURE (lua) https://github.com/admin36/lua-LURE > - Weasy (python) https://github.com/Kozea/WeasyPrint > -- 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.
