On Sun, Oct 28, 2018 at 2:16 AM T L wrote:
> For example, for a constant string with name Version, you can assure it
is not blank by using
>
> var _ = map[bool]int{false: 0, Version != "": 1}
Too complicated.
const (
Version = "v1.11"
_ = 1 / len(Version)
OK, that's a fair point.
So how about this then. The default (no tag) would be determined by the
compiler depending on what major version was being used to build the
application. If you were using Go 2.0, 2.1 etc, then the absence of the tag
would mean that new keywords would be treated as such
On Sunday, 28 October 2018 05:13:15 UTC+1, Lucio wrote:
>
> On Sunday, 28 October 2018 01:58:56 UTC+2, Scott Cotton wrote:
>>
>>
>> [ ... ]
>> Then a cross platform App would just implement for each platform. That
>> would be more work for app writers but provide more support for optimal
>> UI
First, I know this will not happen. It is just a dream.
Second, I'm not original: https://github.com/golang/go/issues/377
, https://groups.google.com/forum/#!topic/golang-dev/wg5K15tEJRQ
And this topic is just a forum for ideas.
I'm not really against := operator, but I'm against inconsistency bo
There are fallacies in your arguments.
First, you argue that Java is successful because it is backward compatible
all the way back to version 1.0, both in source and binary compatibility.
Therefore, if Go is to be just as successful, Go must do the same.
Second, you assume that people who disa
I never made any claims about anyone else. I only presented my opinion that
backwards compatibility is a requirement for success.
WORA was not a huge factor in Java’s initial success IMO. There was only a
single dominant OS and all others combined made up a tiny fraction of the
market. Linux w
On Thursday, 18 October 2018 08:00:56 UTC+2, Beoran wrote:
>
> After reading his proposal, I think you should help Burak Sedar work out
> his proposal in the other thread.
>
Where is Burak Sedar's proposal?
> It is conceptually a lot easier than the idea of contracts, but likely to
> be
On Sunday, 28 October 2018 11:11:49 UTC+2, Jan Mercl wrote:
>
> On Sun, Oct 28, 2018 at 2:16 AM T L >
> wrote:
>
> > For example, for a constant string with name Version, you can assure it
> is not blank by using
> >
> > var _ = map[bool]int{false: 0, Version != "": 1}
>
> Too complicated.
>
>
Hi Marvin,
I think a lot of us like the fact that when we see "a == b" in Go we know
what it is without looking up a redefinition somewhere.
To me, "a (==) b" is better if there is operator overloading, but I don't
like it in any case.
One problem with operator overloading is that, to use opera
On Sat, 27 Oct 2018 14:33:32 -0500, you wrote:
>What exactly are you referring to? I wasn’t aware of Android no longer being
>Java.
At Google I/O 2017 the Android team announced that Kotlin would be
supported as a first class language along with Java, including full
support in Android Studio.
W
Cool. Not sure why the JVM is not applicable to the discussion as it normally
ensures binary compatibility as languages evolve.
Sent from my iPhone
> On Oct 28, 2018, at 9:16 AM, Gerald Henriksen wrote:
>
>> On Sat, 27 Oct 2018 14:33:32 -0500, you wrote:
>>
>> What exactly are you referring
To clarify, think of the performance improvements in the GC in Go from 1.1 to
1.11. Amazing. But you only get these via recompiling which is a barrier. Many
java installations frequently get performance improvements with no code changes
or recompilation. This is why I’ve been investigating packa
On Sunday, October 28, 2018 at 5:11:49 AM UTC-4, Jan Mercl wrote:
>
> On Sun, Oct 28, 2018 at 2:16 AM T L >
> wrote:
>
> > For example, for a constant string with name Version, you can assure it
> is not blank by using
> >
> > var _ = map[bool]int{false: 0, Version != "": 1}
>
> Too complicate
To ground this last comment, every Java execution is a recompile in the
sense that the JVM holds all the magic and applys it to a Java “binary”
before and/or during execution.
The “write once run anywhere slogan” is at best a statement of “you code
once and we’ll localize and concreteize for you a
I prefer Go's compiled version over JIT of Java/.Net. I've faced the same
problem with Microsoft's 'dot net.' I asked this with Java and .Net but
they didn't listen then, and now Microsoft is adopting same with '.Net
Core' after Go.
Anyhow when Go came, finally there was another language that
On Sun, Oct 28, 2018 at 7:00 AM Scott Cotton wrote:
>
>
>
> On Thursday, 18 October 2018 08:00:56 UTC+2, Beoran wrote:
>>
>> After reading his proposal, I think you should help Burak Sedar work out his
>> proposal in the other thread.
>
>
> Where is Burak Sedar's proposal?
https://gist.github.co
On Sunday, 28 October 2018 15:31:54 UTC+1, Robert Engels wrote:
>
> To clarify, think of the performance improvements in the GC in Go from 1.1
> to 1.11. Amazing. But you only get these via recompiling which is a
> barrier. Many java installations frequently get performance improvements
> with
Since most variable re-declaration is to support error variables, one
likely outcome of the new error handling scheme is to end the need for it.
v1, err := f1() // this
v2, err := f2()
v1 := check f1() // becomes this (proposed by Go team)
v2 := check f2()
v1, ?err := f1() // or this (invokes a
Code in question:
// Flush writes any buffered data to the underlying io.Writer.
func (b *Writer) Flush() error {
if b.err != nil {
return b.err
}
if b.n == 0 {
return nil
}
n, err := b.wr.Write(b.buf[0:b.n])
if n < b.
On Sat, Oct 27, 2018 at 9:29 PM, wrote:
> Code in question:
>
> // Flush writes any buffered data to the underlying io.Writer.
> func (b *Writer) Flush() error {
> if b.err != nil {
> return b.err
> }
> if b.n == 0 {
> return nil
> }
There is an initiative to remove the requirement of having a C compiler for
certain CGO packages and this seems like a somewhat common thing to do,
even the Go race condition detector ships as a pre-built C blob in the Go
source tree. Yet I can't find any documentation on how to actually do this
It’s in its early stages but if I understand my conversations with Ian
correctly, he says this is already available for the stdlib. I agree that
dynamically linking to the runtime is more difficult but given some
restrictions it might work.
Sent from my iPhone
> On Oct 28, 2018, at 1:01 PM, S
Prior to about a couple of months ago, it was very rare to see anything
here about exciting additions to the language from aging gophers. I
think it's probably fair to say that many of us were quite happy with
that situation.
On Sun, 2018-10-28 at 07:31 -0500, Robert Engels wrote:
> Next thing Gop
On Sun, 28 Oct 2018 09:31:30 -0500, you wrote:
>To clarify, think of the performance improvements in the GC in Go from 1.1 to
>1.11. Amazing. But you only get these via recompiling which is a barrier. Many
>java installations frequently get performance improvements with no code
>changes or reco
On Monday, 29 October 2018 00:25:04 UTC+1, kortschak wrote:
>
> Prior to about a couple of months ago, it was very rare to see anything
> here about exciting additions to the language from aging gophers. I
> think it's probably fair to say that many of us were quite happy with
> that situation
Everybody is always aging, nothing to read into.
Sent from my iPhone
> On Oct 28, 2018, at 8:51 PM, Scott Cotton wrote:
>
>
>
>> On Monday, 29 October 2018 00:25:04 UTC+1, kortschak wrote:
>> Prior to about a couple of months ago, it was very rare to see anything
>> here about exciting addi
Another two things ways:
var _ = Version[:1]
var _ = Version[0]
On Sunday, October 28, 2018 at 11:12:51 AM UTC-4, T L wrote:
>
>
>
> On Sunday, October 28, 2018 at 5:11:49 AM UTC-4, Jan Mercl wrote:
>>
>> On Sun, Oct 28, 2018 at 2:16 AM T L wrote:
>>
>> > For example, for a constant string with
27 matches
Mail list logo
