Grokbase › Groups › Go › golang-nuts › February 2016
FAQ
Hello, all.

Long time listener, first time caller.

Here's the situation I'm in. I got bored and started writing a compiler
from Clojure to the Go runtime. At the moment, I'm struggling with how to
translate the JVM's concurrency idioms for Clojure `Vars` over to Go. In
particular, Clojure Vars rely on thread-local storage
(ref: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Var.java#L67).
The use case for this isn't immediately obvious, but in essence it enables
downstream local bindings within Clojure source code that don't clobber
global references.

From what I understand, `x/net/context` exists largely to address problems
very similar to this one, but going down that route feels like I could very
easily end up having to pass context as an additional function argument to
half the functions in the compiler. That feels ugly, though the functional
programmer in me is also pleased by it.

Has anyone else run into a similar translation issue to this? What's the
recommended path here?

Cheers,

  - V

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Ian Lance Taylor at Feb 4, 2016 at 10:19 pm ⇧

    On Thu, Feb 4, 2016 at 12:24 AM, W. David Jarvis wrote:
    Here's the situation I'm in. I got bored and started writing a compiler from
    Clojure to the Go runtime. At the moment, I'm struggling with how to
    translate the JVM's concurrency idioms for Clojure `Vars` over to Go. In
    particular, Clojure Vars rely on thread-local storage (ref:
    https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Var.java#L67).
    The use case for this isn't immediately obvious, but in essence it enables
    downstream local bindings within Clojure source code that don't clobber
    global references.

    From what I understand, `x/net/context` exists largely to address problems
    very similar to this one, but going down that route feels like I could very
    easily end up having to pass context as an additional function argument to
    half the functions in the compiler. That feels ugly, though the functional
    programmer in me is also pleased by it.

    Has anyone else run into a similar translation issue to this? What's the
    recommended path here?
    As you've discovered, Go has nothing comparable to thread-local
    storage. This is because in Go it's easy to start a new goroutine.
    Should that new goroutine share the thread-local storage or get new
    copies? Neither choice is always correct, depending on how the
    goroutine is being used. Instead, Go code uses function closures or
    explicit value passing, as appropriate.

    In order to translate code from a language that does use thread-local
    storage, you are going to have to use a context value, as you mention.
    That's the best and really the only approach. Yes, it will wind up
    everywhere.

    Ian

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Egon at Feb 5, 2016 at 8:41 am ⇧
    Just a nitpick: "Idiomatic Go design pattern" does not really make sense.
    You have idioms and you have design patterns, they are different things. I
    have a hard time imagining an idiomatic design pattern.

    If you are thinking of a common way of writing something (in some
    language/situation), then it's an idiom. Not a design pattern.

    + Egon
    On Thursday, 4 February 2016 18:11:36 UTC+2, W. David Jarvis wrote:

    Hello, all.

    Long time listener, first time caller.

    Here's the situation I'm in. I got bored and started writing a compiler
    from Clojure to the Go runtime. At the moment, I'm struggling with how to
    translate the JVM's concurrency idioms for Clojure `Vars` over to Go. In
    particular, Clojure Vars rely on thread-local storage (ref:
    https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Var.java#L67).
    The use case for this isn't immediately obvious, but in essence it enables
    downstream local bindings within Clojure source code that don't clobber
    global references.

    From what I understand, `x/net/context` exists largely to address problems
    very similar to this one, but going down that route feels like I could very
    easily end up having to pass context as an additional function argument to
    half the functions in the compiler. That feels ugly, though the functional
    programmer in me is also pleased by it.

    Has anyone else run into a similar translation issue to this? What's the
    recommended path here?

    Cheers,

    - V
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Forud A at Feb 5, 2016 at 9:23 pm ⇧
    There is another workaround here : https://github.com/jtolds/gls .
    On Thursday, February 4, 2016 at 7:41:36 PM UTC+3:30, W. David Jarvis wrote:

    Hello, all.

    Long time listener, first time caller.

    Here's the situation I'm in. I got bored and started writing a compiler
    from Clojure to the Go runtime. At the moment, I'm struggling with how to
    translate the JVM's concurrency idioms for Clojure `Vars` over to Go. In
    particular, Clojure Vars rely on thread-local storage (ref:
    https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Var.java#L67).
    The use case for this isn't immediately obvious, but in essence it enables
    downstream local bindings within Clojure source code that don't clobber
    global references.

    From what I understand, `x/net/context` exists largely to address problems
    very similar to this one, but going down that route feels like I could very
    easily end up having to pass context as an additional function argument to
    half the functions in the compiler. That feels ugly, though the functional
    programmer in me is also pleased by it.

    Has anyone else run into a similar translation issue to this? What's the
    recommended path here?

    Cheers,

    - V
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedFeb 4, '16 at 4:11p
activeFeb 5, '16 at 9:23p
posts4
users4
websitegolang.org

4 users in discussion

Egon: 1 post W. David Jarvis: 1 post Forud A: 1 post Ian Lance Taylor: 1 post

Content

People

Support

Translate

site design / logo © 2022 Grokbase