Live data from Hacker News

Go is amazing, period.

poincare101.blogspot.com

221–230 of 241 posts

Re: Go is amazing, period.

#221
post #66

Earlier quoted context omitted.

Maybe I'm mistaking terminology but that doesn't seem like a type issue you're describing.

There's no one definition of type safety. It ultimately depends on what your type system is trying to enforce. I strongly suspect, however, that most programmers expect "type-safe" languages to enforce memory safety, and that Go's lack of memory safety is surprising in this context.

I agree with everything you've said in this thread, except this: "type safety" should mean that the system has some belief about the type of values that cannot be compromised.

(sometimes type safety can be proven absolutely by static checking, but you have otherwise only run-time type checking, e.g. dynamic JVM languages, introspection).

Unlimited memory corruption does seem to imply that run-time type guarantees are gone, but it's still better to use the most appropriate terms.

Re: Go is amazing, period.

#222
post #217

Earlier quoted context omitted.

Fantastically dumb comment. FWIW int in C is also 32 bit on all mainstream 64 bit operating systems, and Go has int64. ROFL. I challenge you to find documentation for the C language or any other language commonly used in production where they speculate that they might wake up one day and change sizeof(int) on an existing platform. "Fantastically dumb," indeed.

C doesn't even define them, other setting a minimum. There have been C implementations where char was 64 bits. As far as the documentation for the C langauge where they speculate that it's not defined, just given a minimum bound: here you go: Their implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign (C99 spec, section 5.2.4.2.1) It also allows sign-m…

Holy @#$@, people. Did I wake up in a naïveté vortex?

No, C doesn't define sizeof(int). It is implementation defined. But you don't change it once you implement it in a given development environment... not if you want people to create and maintain production code with your tools. You don't speculate that one day you might want to change sizeof(int). It's just not something you do if you want to be taken seriously.

Is anyone in this thread over the age of 16?

Re: Go is amazing, period.

#224
post #146
post #142

Earlier quoted context omitted.

It seems you deleted your comment asking why you were downvoted. Here's why you were downvoted: > Way more than 5 minutes. Where are generics or do I have to learn some new construct? Wait a minute, is this thing object oriented or what? If not, why not? Do I have to learn some new philosophy? Already feeling a sense of dread having been through this game 10s of times before with other languages. If you didn't get pa…

It was no longer relevant and seemed to attract more downvotes. I have spent years with x86 + MIPS assembly language, C, C++, C#, Visual Basic and Q[uick]BASIC; months with Java, Scheme, Python, PHP; days/weeks with AS3, HaXE, Erlang, Scala, E, Objective-C, Ruby, Delphi, Pascal, Concurrent Clean, Prolog, ADA. I've probably missed a few. My point is (a) I'm not a lazy developer that doesn't enjoy learning new things o…

you have nailed wisdom to these younger 16 years old crowd. But nowadays younger crowd needs fashion,pizzaz,Prestige etc. in my experience learning about Message Brokers is very important than learning new language.

Re: Go is amazing, period.

#225

Is the Author is 13 years old. When did he really start programming.? just wondering After 16 years of programming experience still not able to decide which language is best. At last Settled for C and Common Lisp. But still have Doubts. As per Personal Experience Both Language is more than enough for me.

ok guys,, Let me print my wisdom, "Its not the programming language its You,its always you"

Re: Go is amazing, period.

#226

Earlier quoted context omitted.

I work in a place where people don't use spaces and don't use empty lines to separate logical groups of lines. It's a real pain for me who is a code format junkie as our code ends up being an ugly pack of unrelated crap that's really hard to read. It's Python code and I find it uglier than some fairly large C++ project I used to work on. Anyway, I wish there was a gofmt in Python because at least, I'd drop all hopes…

I completely support enforced style -- it's part of what I love about Python and F#'s light mode -- but it has to be the right style. I strongly believe that code should look like a screenplay, not a novel. More white space, in other words, is rarely a bad thing. Inline braces decrease white space and make unfamiliar code harder to scan, so to me they're Not Good. Also wow, I didn't know it was even possible to write…

Sorry, we are talking about that:

    def func(arg1,arg2):
        i=other_stuff(1,2,3,4,56,43,234+4*3)
        return i

Re: Go is amazing, period.

#227
post #217

Earlier quoted context omitted.

C doesn't even define them, other setting a minimum. There have been C implementations where char was 64 bits. As far as the documentation for the C langauge where they speculate that it's not defined, just given a minimum bound: here you go: Their implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign (C99 spec, section 5.2.4.2.1) It also allows sign-m…

Holy @#$@, people. Did I wake up in a naïveté vortex? No, C doesn't define sizeof(int). It is implementation defined. But you don't change it once you implement it in a given development environment... not if you want people to create and maintain production code with your tools. You don't speculate that one day you might want to change sizeof(int). It's just not something you do if you want to be taken seriously. Is…

GCC has options to change the size of int without even modifying the compiler. The size of integer types isn't even fixed within one implementation, in other words.

If you write production C code that depends on anything other than the minimum sizes defined in limits.h, your code is buggy.

Re: Go is amazing, period.

#228
post #217

Earlier quoted context omitted.

C doesn't even define them, other setting a minimum. There have been C implementations where char was 64 bits. As far as the documentation for the C langauge where they speculate that it's not defined, just given a minimum bound: here you go: Their implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign (C99 spec, section 5.2.4.2.1) It also allows sign-m…

Holy @#$@, people. Did I wake up in a naïveté vortex? No, C doesn't define sizeof(int). It is implementation defined. But you don't change it once you implement it in a given development environment... not if you want people to create and maintain production code with your tools. You don't speculate that one day you might want to change sizeof(int). It's just not something you do if you want to be taken seriously. Is…

[deleted]

Re: Go is amazing, period.

#229
post #147

Support for Unicode as a groundbreaking language feature? Closures (and first-class functions) as a major achievement? I don't want to sound smug, so I won't mention any languages I'm comparing to — but seriously, unless you've been living in Python-land, those things are nothing to write home about. I'm surprised this is getting so many upvotes. If I were to praise Go, I would concentrate on something innovative — c…

Yeah, my main complaint about Go is the way its adherents go on like its type inference is some incredible new invention. I guess in makes sense when you're selling it to Java people, but it rubs me the wrong way.

Re: Go is amazing, period.

#230
post #227

Earlier quoted context omitted.

Holy @#$@, people. Did I wake up in a naïveté vortex? No, C doesn't define sizeof(int). It is implementation defined. But you don't change it once you implement it in a given development environment... not if you want people to create and maintain production code with your tools. You don't speculate that one day you might want to change sizeof(int). It's just not something you do if you want to be taken seriously. Is…

GCC has options to change the size of int without even modifying the compiler. The size of integer types isn't even fixed within one implementation, in other words. If you write production C code that depends on anything other than the minimum sizes defined in limits.h, your code is buggy.

GCC has options to change the size of int without even modifying the compiler

Great, I'm very happy for them. If I ever wake up and decide to change sizeof(int), I can.

Now what do you suppose is going to happen if the GCC committers wake up one day and decide to change sizeof(int) for everyone?

I have a feeling we'd all see an awful lot of what you would apparently call "buggy code" if that ever happens. I also suspect there will be a pretty quick exodus of formerly loyal GCC users if that ever happens. No one will be able to trust the judgement of the compiler authors, at that point.

Seriously. I feel like the only sane guy in the asylum here.

Post reply on HN