On Thu, Apr 25, 2013 at 1:06 PM, Steven Degutis <sbde...@gmail.com> wrote:
> For example, will it have the ability to lookup functions by name at
> runtime?
This will most likely never come, because it's also an important
misfeature. If you can access functions by name at runtime, the
compiler can't trash unused code.
As a side note, in my experience an explicit registry has always been
a better interface in any case.
gustavo @ http://niemeyer.net
b is probably true but a is only true if you like lisp... ;-)
To make my point more explicit:(1) Clojure sits on top of Java(2) Clojure enhances Java(3) Go is better than Java(4) If Clojure sat on top of Go, it would (a) enhance Go, and (b) be better than Clojure-on-Java
On Thursday, April 25, 2013 11:18:46 AM UTC-5, Steven Degutis wrote:
That kind of attitude never leads to useful innovation.Imagine if Rob et al. had that kind of attitude! They'd never have written Go, they'd have said "look, if you want something low-level just use C or C++".
On Thu, Apr 25, 2013 at 11:13 AM, Gustavo Niemeyer wrote:
On Thu, Apr 25, 2013 at 1:10 PM, Steven Degutis wrote:There are several ways to make that kind of thing work, but to be
> Then this means we can't put Clojure (or anything like it) on top of Go.
honest I'm not personally concerned about that one limitation. If I
wanted Clojure, I'd just use it.
gustavo @ http://niemeyer.net
--
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...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
You need code to be super fast, I don't. You need it to be super efficient on memory, I don't.
And I just realized why. You have totally different requirements than us.You write low-level server code at Google. We wright high-level web apps.Our requirements are fundamentally different. Go will never be suitable for this task, only for what you're using it for.In fact, you even admitted you wrote it to replace C++, not Ruby.So your requirements are very different. You need code to be super fast, I don't. You need it to be super efficient on memory, I don't.For you, it's better to write a for-loop that looks for the index of a given element and breaks out of the loop when you've found it. But we prefer to have a single function like indexOf() which takes a collection and a function, because it's cleaner, easier to read, easier to write, and easier to maintain. But that's probably too inefficient for you, and it isn't type-safe enough for you either.
This is why it should come as no surprise to me that Go will never be suitable for what I do for a living, which is writing web apps.
-Steven
On Thursday, April 25, 2013 11:54:09 AM UTC-5, Rob Pike wrote:I'd prefer to have gophers all the way down.
-rob
--
Has these functional aspects been ruled out of future versions of Go? They are not related to dynamically looking up and invoking methods.
I wouldn't mind them really but I can do without. As for lisp on Go, cool but I would never use it.
To some extend, yes.But all features are trade-offs, so they come at a price.In giving high-level functions like map(), reduce(), indexOf(), etc, we would be losing type-safety and some efficiency/speed.I'm okay with this trade-off. In fact I prefer the code's clarity and maintainability over efficiency. Especially because in the apps I write, speed and memory are not the bottleneck.-Steven
--
And I just realized why. You have totally different requirements than us.You write low-level server code at Google. We wright high-level web apps.Our requirements are fundamentally different. Go will never be suitable for this task, only for what you're using it for.In fact, you even admitted you wrote it to replace C++, not Ruby.So your requirements are very different. You need code to be super fast, I don't. You need it to be super efficient on memory, I don't.For you, it's better to write a for-loop that looks for the index of a given element and breaks out of the loop when you've found it. But we prefer to have a single function like indexOf() which takes a collection and a function, because it's cleaner, easier to read, easier to write, and easier to maintain. But that's probably too inefficient for you, and it isn't type-safe enough for you either.
This is why it should come as no surprise to me that Go will never be suitable for what I do for a living, which is writing web apps.
-Steven
On Thursday, April 25, 2013 11:54:09 AM UTC-5, Rob Pike wrote:
I'd prefer to have gophers all the way down.
-rob
--
Then this means we can't put Clojure (or anything like it) on top of Go.
If you guys at Google are willing to put up with Go's set of trade-offs, then I'm glad for you. But Google is known for being.. unique. I don't know a single other person outside of this mailing list who is willing to put up with Go's trade-offs to write a web app.
-Steven
Has these functional aspects been ruled out of future versions of Go? They are not related to dynamically looking up and invoking methods.
My current plan is just to write a Go-code-emitter. It'll emit all the boxing and unboxing that lets us do all sorts of cool FP things but is tedious to write by hand.I think I already know how to solve most of the problems this will entail. The only problem left is type conversion.So if you pass a MyObject type into net.Dial, it'll have to know how to convert itself to a string. And I currently have no idea how to use /pkg/go/* to figure out that net.Dial takes ['string', 'string'] and returns ['Conn', 'error'].That's the only unsolved part I can think of.
My current plan is just to write a Go-code-emitter. It'll emit all the boxing and unboxing that lets us do all sorts of cool FP things but is tedious to write by hand.I think I already know how to solve most of the problems this will entail. The only problem left is type conversion.So if you pass a MyObject type into net.Dial, it'll have to know how to convert itself to a string. And I currently have no idea how to use /pkg/go/* to figure out that net.Dial takes ['string', 'string'] and returns ['Conn', 'error'].
That's the only unsolved part I can think of.
-Steven
Does that mean it's not possible using what's already in /pkg/go?
What you are asking to do is non trivial in the first place regardless of language. Please don't tell me you are suggesting that implementing clojure on top of the jvm was a trivial task. With that in mind, it is completely reasonable to consider rob's point without seeing feasibility. You are already proposing something outside the realm of "easy" feasibility in any language.
--dho
I agree that our profession requires high precision with words, names, semantics, meaning, etc.But in conversation we should only apply this to the proper degree. We should only offer correction when we discern that there's a misunderstanding. We should be unambiguous only when we perceive that our audience would otherwise lack sufficient context to understand our point.Otherwise we're just adding noise, not signal.-Steven
--
You said feasible in such a way that it implied it. Everything you are asking for is feasible but non trivial.
Yes Rob, it may be possible, but not necessarily practical. As it's a given that anything is possible in Turing-complete languages, the reader should mentally replace "is it possible" with "is it feasible without a disproportionate amount of work". This way we can all continue to use language of convenience without needing to be tiringly explicit all the time. I've found that in general this works quite well, except when the pedant or the bored are present.-Steven
Then this means we can't put Clojure (or anything like it) on top of Go.On Thu, Apr 25, 2013 at 11:08 AM, Gustavo Niemeyer <gus...@niemeyer.net> wrote:
On Thu, Apr 25, 2013 at 1:06 PM, Steven Degutis <sbde...@gmail.com> wrote:
> For example, will it have the ability to lookup functions by name at
> runtime?
--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/BmFX-PF9bSA/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
(3) Go is better than Java
In giving high-level functions like map(), reduce(), indexOf(), etc, we would be losing type-safety and some efficiency/speed.
The second is to "box" types into a type that these functions operate on. This would be quite ugly but work well. And if you strap a dynamic language on top, which translates into the pre-boxed code, it would actually work perfectly fine. That was my goal.