31–40 of 257 posts
You still need a Makefile if you use things like godep, or their new `go generate` stuff. They have a long way to go on tooling; however, getting to say that is a luxury, due to just how "right" golang has been for systems work. Golang has been amazing to work with, and has just been stupidly productive. I miss debugging (gdb) and generic compile tools like tup, but that's about it!
Earlier quoted context omitted.
Some people look at a new language and don't see anything that proves it was made after the 1970s.
And I hope it stays that way. We don't need more features, we need to address psychological issue of mistake-making.
You may be a victim of the Blub paradox. There are many useful and powerful features missing from languages like Go, and many of them (like powerful type systems) exactly address human mistake-making.
You still need a Makefile if you use things like godep, or their new `go generate` stuff. They have a long way to go on tooling; however, getting to say that is a luxury, due to just how "right" golang has been for systems work. Golang has been amazing to work with, and has just been stupidly productive. I miss debugging (gdb) and generic compile tools like tup, but that's about it!
You don't need a Makefile for either of those.
A convenient way to do that is ask people to type 'make'.
Earlier quoted context omitted.
Erlang has the first two concepts nailed down. I don't know what "data sharing ... with promiscuous threading" is, but Erlang is functional and immutable, so data sharing only exists in the sense of passing immutable data structures around. Synchronization issues associatied with mutations don't exist for in-memory structures since it's all read-only access. I don't know Haskell's concurrency tools very well, but I b…
Neat. You can start an Erlang process (or whatever they're called) with an anonymous function, and pass it another anonymous function that closes over another lexical environment?
For me, Go's big win is that I can finally bring this, the right way to do it, to work, because it's the first time this paradigm is present in a conventional imperative language, not that it is the first in general. Many other languages got it right in theory before Go, but there was always some practical stopper, involving some obscure programming paradigm that I stood no chance of getting buy-in on (from engineering or management) or an ecosystem that simply couldn't be reasonably be called production-ready across the set of tasks I needed to accomplish. Go finally gave me almost everything I wanted for work. If it isn't everything, well, that's life sometimes, you know?
Earlier quoted context omitted.
Erlang has the first two concepts nailed down. I don't know what "data sharing ... with promiscuous threading" is, but Erlang is functional and immutable, so data sharing only exists in the sense of passing immutable data structures around. Synchronization issues associatied with mutations don't exist for in-memory structures since it's all read-only access. I don't know Haskell's concurrency tools very well, but I b…
Neat. You can start an Erlang process (or whatever they're called) with an anonymous function, and pass it another anonymous function that closes over another lexical environment?
Earlier quoted context omitted.
Erlang has the first two concepts nailed down. I don't know what "data sharing ... with promiscuous threading" is, but Erlang is functional and immutable, so data sharing only exists in the sense of passing immutable data structures around. Synchronization issues associatied with mutations don't exist for in-memory structures since it's all read-only access. I don't know Haskell's concurrency tools very well, but I b…
Neat. You can start an Erlang process (or whatever they're called) with an anonymous function, and pass it another anonymous function that closes over another lexical environment?
do_stuff() ->
GetAnswer = fun() -> 42 end,
spawn(fun() -> io:format("The answer is ~p\n", [GetAnswer()]) end).
And I pretty much hate the language. I feel like I'm writing in something that combines the worst weaknesses of Pascal and Java. In fact, Mark Dominus' comments about Java (http://blog.plover.com/prog/Java.html ) approximate my experience Go far better than I would have guessed when I started the project I'm on.
People who seem to be smart nevertheless keep talking it up... some not even as just a good tool but as their favorite language.
So I'll ask: What is it I need to read/work through in order to at least "get" Go and really understand its strengths (whether or not I end up liking it)?
Earlier quoted context omitted.
What do you think is worthwhile about Go? I agree that the tooling is nice, but beyond that, there is nothing interesting to me. Goroutines aren't interesting; languages like Erlang and Haskell got green threads right many years before Go was on the scene.
That's a reductive summary of goroutines. I don't doubt other languages have competitive features, but let's be clear about what the feature is: * Lightweight threads with a scheduling and state overhead low enough to run hundreds of thousands of threads at a time. * Seamless integration with the language, without any rituals or incantations needed to invoke them; you can, for instance, trivially pass closures from g…
But in the end it doesn't really matter that much. Go and Haskell are completely different languages for different purposes (getting stuff done in regular companies vs. doing interesting PL research or more advanced development in companies with little turnover.)