Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go as an alternative to Node.js for Very Fast Servers

techblog.safaribooksonline.com

Post reply on HN
Print view View original

81–90 of 147 posts

Re: Go as an alternative to Node.js for Very Fast Servers

#81

Post by zemo »

crypto5 wrote: post #71
4ad wrote: post #69

Earlier quoted context omitted.

Not really. Go comes with code rewriting tools, unsurprisingly since they were used to update the standard library and 3rd party code when the language changed before Go 1. I don't want to use a language that doesn't come with a parser in the standard library anymore.

So, is it possible to move/rename class/method/field smoothly using those tools? Extract code block to new method?

the gofmt tool has a replacement feature:

`gofmt -r 'InitialName -> FinalName'`

Re: Go as an alternative to Node.js for Very Fast Servers

#82

Post by driverdan »

mseepgood wrote: post #25
jacobmarble wrote: post #2

Node: Everyone knows JavaScript, there's a massive community, there are tons of libraries, and you get very good performance Go: No one knows this language, there's a small-but-growing community, there are enough libraries to get a lot done, and you get even better performance Java: They are paying me (money!) to write in this language

The Go community on Reddit is already bigger than the Node community: http://www.reddit.com/r/golang (3730) http://www.reddit.com/r/node (3581)

I wouldn't consider subreddits a good way to gauge a tech community's size. Try IRC rooms and mailing lists.

Re: Go as an alternative to Node.js for Very Fast Servers

#83

Post by steveklabnik »

tikhonj wrote: post #67
VeejayRampay wrote: post #50

Earlier quoted context omitted.

I've done Java, PHP, Objective Caml (in college for a few years), some basic C, Ruby and Javascript before and I concur. Go is a real breath of fresh air. I have the same feeling I have when I code with Ruby: that sense that the language works WITH me, that the whole experience is smooth and seamless. I wish Go stays on that path for a long time. And it never gets TOO big, which makes for awful communities.

Maybe you didn't do much OCaml? I've found it to be mostly significantly better than Go, especially with it's type system. Go's type system is relatively limited and ad-hoc where OCaml's is extremely elegant, simple and consistent. In particular, OCaml has an awesome module system and a great take on structural sub-typing combined with proper type inference and sane parametric polymorphism. Having actual algebraic da…

If you like OCaml but find Go lacking, you should check out Rust. I'm more of a Haskeller than a OCamlist, but the Rust compiler was originally written in OCaml, and it's influenced the language a lot.

Re: Go as an alternative to Node.js for Very Fast Servers

#85

Post by grey-area »

acc00 wrote: post #79
tikhonj wrote: post #67

Earlier quoted context omitted.

Maybe you didn't do much OCaml? I've found it to be mostly significantly better than Go, especially with it's type system. Go's type system is relatively limited and ad-hoc where OCaml's is extremely elegant, simple and consistent. In particular, OCaml has an awesome module system and a great take on structural sub-typing combined with proper type inference and sane parametric polymorphism. Having actual algebraic da…

I've written a moderate amount of OCaml and some Go. While I agree that the former is a nice language, it doesn't compare favorably to Go as a development suite: the standard library is terribly designed, and the package management is rather poor compared to Go's (which is about as great as it gets). Now there is "OCaml Batteries Included" which is supposed to mitigate that, but it appeared after I stopped actively u…

I love the package management in go and agree it is pretty good, but the lack of versions make me nervous. I do wish they reacted quicker to common criticisms like this and the missing generics, but I guess they want to take their time and do things right. What there is of go has been a pleasure to explore though.

Would you mind expanding on what is good about m expressions and how that could apply to go, I'm not familiar with them?

Re: Go as an alternative to Node.js for Very Fast Servers

#86

Post by icey »

tferris wrote: post #68

How long does take the compile time with a medium sized typical web project. Something which gets annoying or still bearable?

I am working on a project that has a few thousand lines of Go and compilation takes a second or so. Maybe less; it's fast enough that I don't really think about the fact that it's compiling unless I've done something that it complains about (which is awesome).

Re: Go as an alternative to Node.js for Very Fast Servers

#87

Post by gnuvince »

acc00 wrote: post #79
tikhonj wrote: post #67

Earlier quoted context omitted.

Maybe you didn't do much OCaml? I've found it to be mostly significantly better than Go, especially with it's type system. Go's type system is relatively limited and ad-hoc where OCaml's is extremely elegant, simple and consistent. In particular, OCaml has an awesome module system and a great take on structural sub-typing combined with proper type inference and sane parametric polymorphism. Having actual algebraic da…

I've written a moderate amount of OCaml and some Go. While I agree that the former is a nice language, it doesn't compare favorably to Go as a development suite: the standard library is terribly designed, and the package management is rather poor compared to Go's (which is about as great as it gets). Now there is "OCaml Batteries Included" which is supposed to mitigate that, but it appeared after I stopped actively u…

OCaml should definitely move toward adopting either Batteries or Jane Street Core as its standard library; they offer a lot more functionality.

For package management, I haven't had the chance to really try it yet, but I'm hearing good things about OPAM.

Finally, Rust just looks awesome, I'm hoping that the language stabilizes before the end of the year, as I'd love to do my master thesis with it.

Re: Go as an alternative to Node.js for Very Fast Servers

#89

Post by sigzero »

Flow wrote: post #44
mseepgood wrote: post #25

Earlier quoted context omitted.

The Go community on Reddit is already bigger than the Node community: http://www.reddit.com/r/golang (3730) http://www.reddit.com/r/node (3581)

And the Google+ Go community is growing fast and is already larger than the sub-reddit. https://plus.google.com/communities/114112804251407510571

You do see a correlation right?

Re: Go as an alternative to Node.js for Very Fast Servers

#90

Post by acc00 »

grey-area wrote: post #85
acc00 wrote: post #79

Earlier quoted context omitted.

I've written a moderate amount of OCaml and some Go. While I agree that the former is a nice language, it doesn't compare favorably to Go as a development suite: the standard library is terribly designed, and the package management is rather poor compared to Go's (which is about as great as it gets). Now there is "OCaml Batteries Included" which is supposed to mitigate that, but it appeared after I stopped actively u…

I love the package management in go and agree it is pretty good, but the lack of versions make me nervous. I do wish they reacted quicker to common criticisms like this and the missing generics, but I guess they want to take their time and do things right. What there is of go has been a pleasure to explore though. Would you mind expanding on what is good about m expressions and how that could apply to go, I'm not fam…

See [0] for an introduction to M-expressions, which was initially an alternative syntax for Lisp, but have found its way into APL and Mathematica.

Please note I'm suggesting using that syntax for OCaml, not Go.

In short, I want to write "f[x;y]" for "f x y". On the first sight it appears this adds a bunch of noise, but there are many advantages:

1. You now have much less parens resulting from nested function calls;

2. You get partial application by any argument, not just the last. map[;list] is a "functor" that applies its argument to "list";

3. Corollary to this, chaining functions together is now much easier even if you need to supply a parameter other than the last: f[;x]$g[y] (assuming $ stands for apply; it might be wortwhile to take empty space for application)

4. Further you are able to unify many aspects of the syntax (if[cond;true;false]), which makes parsing easier for both humans and computers.

[0] http://en.wikipedia.org/wiki/M-expression

Post reply on HN