Choosing a virtual machine target was the wrong decision. All machines have
a machine in them, why add a virtual one? C already could be compiled on
every platform, all we got out of it was processing latency and a whole
extra layer of performance wrinkles that the CPU maker probably already
Hi everybody. I'm a beginner at Golang. Anyone who has the talent to Golang
please let me please
On Mon, Sep 24, 2018 at 1:05 AM Ian Denhardt wrote:
> Quoting Robert Engels (2018-09-23 13:38:04)
> > I wasn’t suggesting that Go should resemble Java. I was just trying to
> point out that many of
You did not offend me. This is a place for earnest ideas and all are
welcome.
Your comment is not yet persuasive, but it might become so. Still thinking.
I first heard from James Gosling about Java when Java was Oak. He seemed
proud to say, "C++ has objects. Well, I'll show them, I'll make
Quoting Robert Engels (2018-09-23 13:38:04)
> I wasn’t suggesting that Go should resemble Java. I was just trying to point
> out that many of the current issues under debate for Go2 have been resolved
> quite well in other languages, and looking to them for direction should not
> be out of
I wasn’t suggesting that Go should resemble Java. I was just trying to point
out that many of the current issues under debate for Go2 have been resolved
quite well in other languages, and looking to them for direction should not be
out of bounds just because they are not Go. That’s a little
On 9/23/18, Robert Engels wrote:
> I take offense to that. I apologized for my statement that was worded more
> harshly than intended. But if you think that Go is beyond criticism just
> because of ??? Anything??? Go is a GREAT tool for many classes of
> applications, but it is certainly not
I take offense to that. I apologized for my statement that was worded more
harshly than intended. But if you think that Go is beyond criticism just
because of ??? Anything??? Go is a GREAT tool for many classes of applications,
but it is certainly not appropriate for all use cases. Maybe with
I take exception to that statement, your notion of "understood
languages much better" doesn't parse in light of the fact that you are
here, debating the merits of Java in the primary Go forum instead of
writing wonderful code using the language you respect so much.
That's either hypocritical or
I’m sorry. I did not mean to offend anyone. It came out wrong and I apologize.
Sent from my iPhone
> On Sep 23, 2018, at 5:01 AM, Louki Sumirniy
> wrote:
>
> The thing that people are concerned about is creating a construct that
> enables you to write legal but confusing and unclear code.
The thing that people are concerned about is creating a construct that
enables you to write legal but confusing and unclear code. Let's say we
steal triple equals ===, and then use it to mean some kind of special
assignment operation. Or we make = become an addition operator infix for a
Issues like these highlight the deficiencies of Go compared to Java. The Java
designers understood languages far better, and from the start realized that
identity and reference equality were different concepts. Everyone in Go land
are debating these solved issues. Pick and chose what you want
On Saturday, 22 September 2018 16:47:00 UTC+2, Louki Sumirniy wrote:
>
>I think the thing everyone who likes operator overloading like mainly
>is being able to do infix and postfix syntax, instead of only prefix
>(function).
My own reason for wanting this is not really about syntax,
the reason i wrote something like "...operator overloading, but wait, don't
get excited..." was to bring awareness of a core problem without
(hopefully) having people bring the burden of experience. i say burden
because bad experiences can shadow the 'why' that was good with the 'how'
that was
On Saturday, 22 September 2018 16:47:00 UTC+2, Louki Sumirniy wrote:
>
> I think the thing everyone who likes operator overloading like mainly is
> being able to do infix and postfix syntax, instead of only prefix
> (function).
>
It's good that you brought that up, because another issue I
I think the thing everyone who likes operator overloading like mainly is
being able to do infix and postfix syntax, instead of only prefix
(function). But then also what do you do about interfaces that also
implement an operator interface? I'd guess biggest reason to not do it is
1) no human
Quoting Lucio (2018-09-21 16:15:19)
>The other thought I had, but is very poorly baked, is that the
>"essence" of polymorphism in Go operators is analogous to the informal
>definition of interfaces: it can be determined by the compiler, even
>though it is not expressed in a formal
In my opinion the interface represents the simplest way to allow operator
overloading. With an inbuilt interface that covers all the symbols and some
sort of category to break them down (boolean logic, binary logic,
arithmetic, misc unary, prefix infix and postfix). Then you can have the
built
"Google ate my homework, sir!"
Let me try again...
On 9/22/18, Ian Denhardt wrote:
>
> This is a very good insight. There's no technical reason why Go couldn't
> define a built-in interface, much like `error`, for various operators,
> e.g.
>
> type adder(type T) interface {
> Add(T)
On 9/22/18, Michael Jones wrote:
> these seem excellent points all around.
>
> one area of difficulty seems to me the lack of operator overloading. now,
> hold your breath, i'm not arguing for it here. but it highlights a kind of
> structural issue that is in the air around the discussion of
these seem excellent points all around.
one area of difficulty seems to me the lack of operator overloading. now,
hold your breath, i'm not arguing for it here. but it highlights a kind of
structural issue that is in the air around the discussion of generics.
consider:
i instantiate a tree type
On Friday, 21 September 2018 11:52:40 UTC+2, Louki Sumirniy wrote:
>
> This is something that I have seriously considered to be the right way for
> Go to express other generic types. I am in fact in the middle of a project
> at the moment where I have created a pair of generic byte buffer
This is something that I have seriously considered to be the right way for
Go to express other generic types. I am in fact in the middle of a project
at the moment where I have created a pair of generic byte buffer types, one
is the regular kind, the other uses memguard locked buffers, for
22 matches
Mail list logo
