7 ms·
There is no real substance in this blog post. At the end: I chose Go because it is being developed to solve the same problems I have to solve. All by a group o
by danieldk 13y ago
There is no real substance in this blog post. At the end:
I chose Go because it is being developed to solve the same problems I have to solve. All by a group of scientists an programmers that are each twice as smart as I have ever been (on my best day).
So, what are the problems you are trying to solve? And why can Go solve them better than, Java, Erlang, C++, Scala, or any other language?
If you could answer that question, you'd have an interesting blog post. And if the answer is 'concurrency via Goroutines and channels' (it always is), explain why they are better than Erlang or Akka's actors, STM in Clojure or Haskell, or other proposals, and you'd have a stellar blog post.
But really, this at the top of Hacker News?
- pjmlp 13y agoGo effect. Do you remember when Rails and Node were every day on HN? Now it is time for Go.
- orangethirty 13y agoI actually thought about using those. Rails is a memory hog, and Node is Javascript ( a language I am not fond of).
- nazka 13y agoNow it is time to Go.
- gabipurcaru 13y agoMaybe; but that's the way towards progress
- pjmlp 13y agoWe have a different opinion what progress means, it seems.
- reinhardt 13y agoEvery language has its 15 weeks of fame.
- orangethirty 13y agoThis is not the answer you are looking for. But I'm still figuring out that part. One of my problems have been performance/memory usage.Like many of you out there, I don't have endless funds to cover the infrastructure costs. So I have to make with run of the mill VPSs and web hosts. Go's speed and lower memory consumption (compared to my implementation in Python/Django), allows for my financials to stay in check. This project is privately funded, and I'm not SV rich. I will continue talking about the problems as they keep appearing. That is the purpose of the blog. I appreciate the bluntness.
- danieldk 13y agoPlease do not take my comment as a personal attack. Blogging is useful and practice makes perfection :). I was more surprised that it is at the top of Hacker News and as such it's more a critique on voting behaviour ;). I am looking forward to see your search innovations...
- orangethirty 13y agoOh, I know its not personal. I know that the HN crowd seeks more technical content. Which I will be providing. Its just that, as of right now, this is pretty much what I got. But keep posted. I am building and releasing often.
- gnuvince 13y ago> So, what are the problems you are trying to solve? And why can Go solve them better than, Java, Erlang, C++, Scala, or any other language? There should be a lot more text in that post to answer these important questions.
- jerf 13y ago"explain why they are better than Erlang or Akka's actors, STM in Clojure or Haskell," They aren't. I analyzed Go for my personal use, and I have a high degree of familiarity with Erlang and Haskell. The conclusion I came to was that it is a step back from Erlang and Haskell's concurrency support, and that I didn't care to step back into those problems. It's easier to do concurrency correctly in Go than it is in Python or C, but it's still pretty easy to make it blow up in your face and take down your whole program. You to both learn Go, and then learn all the implicit (and to some extent still forming) rules about exactly how you can safely handle channels, which the compiler can't help with. (I tried to keep an open mind, but I'm still of the opinion Erlang's processes with asynchronous mailboxes is better than Go's synchronous channels. Note that's two differences, not one; sync vs. async, and mailboxes vs. channels. And they are effectively synchronous, even when you set a buffer size, because there's still a hard cap on when the channel is full; semantically the difference between a 1-element sync channel and a 10-element sync channel is pretty minimal, you get the same crashes and failures either way if you misuse them, it just takes a bit longer in the 10-element case. Oh, and since "synchronous" seems to have had its meaning mangled here in the past few years, in this case it means that the writing and reading of a channel must coordinate.) But if you're coming from a traditional Algol language, it's a big step forward. I'm sure coming to Go from Python or Lisp feels like a blast of fresh air, because it really is an improvement. And it gives you this without having to abandon your Algol roots, which most of the rest of your alternatives do (except Akka, though I don't how hard those are to use correctly since they're in a mutable language), and that is saying something.
- voidlogic 13y agoDoesn't some of this depend on the performance needs of your application. Go appears to be faster and use less memory the Erlang in this popular microbenchmark: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=erlang&data=u64q http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t... Go vs Haskell/Erlang has a similar showing in TechEmpower's Web Framework Benchmarks: http://www.techempower.com/benchmarks/ http://www.techempower.com/benchmarks/
- jerf 13y ago
- voidlogic 13y ago>>So, what are the problems you are trying to solve? And why can Go solve them better than, Java, Erlang, C++, Scala, or any other language? Compared to X, Go has Y: Java: Less verbose, faster builds, native code (no JVM needed), cleaner OO, structural typing, better memory usage, structural typing, more convenient concurrency Erlang: Better performance, better memory use, cleaner syntax, easier to train people on/hire for, statically typed C++: Type and memory safety, much simpler syntax, better build times, large standard library, structural typing, garbage collection, easy and safe concurrency etc, etc
- voidlogic 13y agoDownvote? If you think this is inaccurate, respond, don't downvote.