211–220 of 241 posts
Earlier quoted context omitted.
How are the database libraries (postgres/mysql) these days? Last time I poked around (been a while) it seemed like most of them were pretty beta yet.
There's the new database/sql library ( http://weekly.golang.org/database/sql ), which is a general SQL interface backed by various driver implementations ( http://code.google.com/p/go-wiki/wiki/SQLDrivers ).
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 is that language, among so many others, sizeof(int) is implementation specific, and indeed it does vary, though (S)?ILP64 is rare. On the other hand sizeof(long) varies all the time. You seem very ignorant, please learn and stop the FUD.
Yeah, that must be it.
Earlier quoted context omitted.
> This is what e.g. Haskell does, and Go as well, I think. This is what Erlang does by default, GHC >= 6.12 will do it when using `+RTS -N -RTS` and Go requires explicitly setting GOMAXPROCS, the runtime defaults to single-threaded (as far as I know, GOMAXPROCS still hasn't been retired) and there is no way to have it auto-detect the core count.
The current weekly release has (and Go v1 will have) runtime.NumCPU() so you can do runtime.GOMAXPROCS(runtime.NumCPU())
A lot of great and capable languages are overlooked. The question is how do they overcome the opinion, hearsay and preferences that are louder than the truth? Too few devs: - truly give something 5 minutes before jumping to their foregone conclusion. - admit that most languages with a decent capable and decent programmer are all, pretty equally equipped. - every language + framework has it's pros and cons.
Earlier quoted context omitted.
Given all the languages you already programmed with, and given that the Go specification is relatively short (approximately the same as Scheme), maybe you overestimate the efforts it would require to learn it. But you don't need to, that's all fine.
Heh I think you inadvertently proved my point. I spent 6 months with Scheme, working through half of the SICP for personal growth. Just because the specification is simple it doesn't mean the patterns and lessons are straightforward, and I'm a pretty slow learner. If you read the Go FAQ you will note that about 1/3 of it is along the lines of "Why doesn't Go...". When I see that sort of language it's clear that betwe…
That's one of the primary points of protocol buffers ;-)
Earlier quoted context omitted.
Thanks for answering! I have no idea why someone downvoted your reply. People: downvoting is for mean and/or stupid comments, not things you disagree with. Anyway, in that case I imagine we'll see a Go preprocessor that takes all the line-initial braces and moves them up a break before sending code to the compiler. People get pretty worked up about this stuff.
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 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 Python without spaces. Are we talking no spaces in arguments, like
def func(arg1,arg2):
print "Indented"
return
def func(arg1,arg2):
print "Not indented"
return
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.
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.
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-magnitude integers (complement 1) in addition to complement 2 (C99 spec, section 6.2.6.2)
It also doesn't define the number of bits in a byte (C99 spec, section 3.6 p2)
Earlier quoted context omitted.
It is a bit annoying having to press 3 keys using two hands instead of just one. With '=' I can "hyperthread" my typing. While I'm finishing the LHS and pressing space I can move my right hand to press '=', while keeping my left hand thumb in place to press the space bar for the right side. With ':=' I have to stop everything to press shift with my left hand, then press ':', then release shift and press '='. It's ver…
Just think about how much more you'd have to type if you were programming C, and you'll be ok :) My main gripe with := vs = is that as I change my code, an existing := may suddenly become invalid, meaning I have to go back and change it when compilation fails, or vice versa.
As someone who has been stuck writing JavaScript for Yahoo Widgets (Vizio Connected TV) over the past month, my appreciation for the compiler errors you get in static languages has grown tremendously. Previously I had taken them too much for granted.
As someone who is 38, and has programmed in everything from 6510/68k/MIPS/ARM assembler to C/C++ to ActionScript/haxe/JavaScript to D to Python, et al, I also think Go is pretty great. In addition to the cool things in the language, I really love what they are doing with the build system. The Go programming I've been doing has been on Windows but targeting an ARM CPU (the PXA168 in the Chumby 8 device) and cross-comp…
Nice. How is the arm compiler holding up? I wrote the original 5g and ken did a large bug fix and optimizer sweep at some point so I'm interested in hearing how it has been going?
Having previously worked for chumby industries (makers of those bean bag alarm clock internet device thigies) I've got a nice collection of ARMv5 class devices laying around waiting to become useful and it is nice to have a modern language that is relatively low level support development on them. Quite a few other projects out there with arm support only care about v7+.
Earlier quoted context omitted.
Did you try Haskell? Knowing Haskell makes reading about Go a very underwhelming experience.
On the bright side, waiting for the Haskell compiler to grind away means you have plenty of time to read up on Go.
Compilation times are not bad enough to be a problem.