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

The March Towards Go

zef.me

Post reply on HN
Print view View original

111–120 of 217 posts

Re: The March Towards Go

#111

Post by binocarlos »

Udo wrote: post #61

This sums up the problem: > Not looking at Go yet? It may be a good time to do so now — everybody else is. That's going to be a large albatross around Go's neck, as it has been around node.js', and Rails before that. Large amounts of developers flocking to a new thing because "this is the thing to use now and if you don't you're dead meat". Personally, I thought Node.js was a terrible platform for serving dynamic web…

It's like everyone looking at everyone else's fashion sense and then quickly getting down the shops to buy up the same sort of stuff.

I suppose it depends on what you are trying to do - if it is looking good to those with fashion sense - better get down them shops. If it's to like, actually build stuff - the feeling of being uncool because of what language you use is a massive distraction to ignore.

I've been learning Go because its a great language for concurrent server systems (and better than node in some areas).

That I feel slightly cooler because of that choice feels a bit like having the right daps (sneakers) at school.

Re: The March Towards Go

#112

Post by Touche »

avz wrote: post #81
candl wrote: post #70

Earlier quoted context omitted.

I tried to like Go. I was allured by the native compilation and quite low memory footprint while still being quite high level, but I just can't. I can't stand it forces you to use K&R style. I can't stand the verbose error handling. I can't stand the inconsistency in the built-in types and libraries. I hate that unused variables and imports are a compile error which is just stupid and kills all the fun in programming…

I'd argue placing error handling in a spotlight is a feature, not a bug. Years of hiding error handling resulted in cultural biases that sanction focus on features without sufficient consideration for failure modes and unexpected conditions. Merely throwing an exception when something goes wrong may give you a peace of mind, but often leads to software which isn't robust against simple failures.

You can ignore errors in Go.

Re: The March Towards Go

#113

Post by DCKing »

otikik wrote: post #85
DCKing wrote: post #66

Earlier quoted context omitted.

Go's type system being weak is a factual statement. Haskell's type system being overcomplicated is an opinion. One might prefer a weak type system over a strong type system, but that's a different discussion. The parent clearly expressed that he wants a static strong type system.

> weak is a factual statement I disagree. "Weakly typed" does not even have a precise definition. Defining "strongly typed" as "the way Haskell does it" and anything less as "weakly typed" is an opinion. I agree that Haskell types are stronger than Go. That does not does not mean that Go is "weakly typed". It's "less strongly typed than Haskell". > The parent clearly expressed that he wants a static strong type syste…

I'm not saying Go is a weakly typed language. I'm just saying that the statement "Go is a weakly typed language" is a factual statement that may be true or false. You were wrong in positing the claims "weakly typed" and "overcomplicated" as if they are somehow equally valid, because one is a factual claim and the other is an opinion.

In the most conventional definitions, Go is a strongly typed language. So this factual statement appears to be false.

As always, there is some confusion in this topic about dynamic typing vs static typing. There seems to be plenty of dynamic typing in Go, which in itself does not make its type system weak.

Re: The March Towards Go

#114

Post by angularly »

I wonder why they didn't choose Go in the first place. Both languages were introduced in 2009, I remember evaluating both, and choosing Go because it was clearly superiour when the goal was serverside, speed, stability, maintenance and simplicity.

Re: The March Towards Go

#115

Post by pjmlp »

anko wrote: post #100
pjmlp wrote: post #93

Earlier quoted context omitted.

Because thanks to our experience with strong typed languages with native compilers and type inference, we know better. Many of us have had the fortune to work with C, C++, Ada, .NET, Java, Delphi, Modula and Oberon derived languages, ML language family. So we already know what modern strong typed languages, with native compiler toolchains, are capable of in terms of language features. And going Go feels a bit backwar…

.NET isn't a language. The languages you list really suck compared to Go. They are ridiculously verbose. Goroutines in particular are really quite nice.

> .NET isn't a language.

It is easier to name the eco-system than all the languages with available compilers targeting .NET.

> The languages you list really suck compared to Go. They are ridiculously verbose.

Except they embrace the last 30 years of language research.

> Goroutines in particular are really quite nice.

Goroutines are nothing new. Modula-2 already had them.

Re: The March Towards Go

#116

Post by rdtsc »

Udo wrote: post #61

This sums up the problem: > Not looking at Go yet? It may be a good time to do so now — everybody else is. That's going to be a large albatross around Go's neck, as it has been around node.js', and Rails before that. Large amounts of developers flocking to a new thing because "this is the thing to use now and if you don't you're dead meat". Personally, I thought Node.js was a terrible platform for serving dynamic web…

> Large amounts of developers flocking to a new thing because "this is the thing to use now and if you don't you're dead meat".

Well "why did you pick this technology?" question is a good way to find out who are you talking to. If they say "webscale" and "callbacks are this new concurrency paradigm" then well, I might not form the best opinion about them.

Re: The March Towards Go

#117

Post by sagichmal »

beck5 wrote: post #96
sagichmal wrote: post #41

Earlier quoted context omitted.

> Lack of decent IDE with intellisense/good refactoring > support. Sublime Text + GoSublime; vim + go-vim. > Libraries seem to be globally shared between projects > like rvm rather than in the project like nvm. There's no fixed rule. If you need dependable reproducible builds, current best-practice is to vendor your libraries in your repo.

Thanks, sublime tex and vim with plugins are still a long way off what you get from a good ide. Just glancing there is no real refactoring support, its more around auto complete.

Refactoring in Go is accomplished with `go fix`.

Re: The March Towards Go

#118

Post by lmm »

collyw wrote: post #98
dom96 wrote: post #29

Earlier quoted context omitted.

This blog post misses a very good Python replacement, namely Nimrod ( http://nimrod-lang.org ).

With the exception of speed, why does Python need a replacement? I am using Python daily, and pretty much all performance problems (with my work) can be solved at the database or caching level. I get the impression that Numpy can produce reasonable performance for numeric problems. In my experience developer productivity is of far more importance to business than language performance (obviously that depends on your d…

The blog post gives the rationale; it's a combination of performance, a hope that static typing would make it possible to avoid a class of errors 0install had been experiencing, and wanting to ship native binaries with no dependencies - a pretty specialized use case, but one that 0install happens to need. (I'm aware that things like freeze exist, but they're not really first-class citizens, and the startup time - very important for a command-line utility - is not great).

In general I agree with you, I was a big fan of Python until I discovered Scala. But it's not a great fit for the 0install use case, and as you'll see from subsequent posts, switching to OCaml turned out to increase reliability and performance without sacrificing concision or development productivity.

Re: The March Towards Go

#119

Post by mercurial »

collyw wrote: post #98
dom96 wrote: post #29

Earlier quoted context omitted.

This blog post misses a very good Python replacement, namely Nimrod ( http://nimrod-lang.org ).

With the exception of speed, why does Python need a replacement? I am using Python daily, and pretty much all performance problems (with my work) can be solved at the database or caching level. I get the impression that Numpy can produce reasonable performance for numeric problems. In my experience developer productivity is of far more importance to business than language performance (obviously that depends on your d…

> With the exception of speed, why does Python need a replacement?

Depends what you use it for. It's very good for a subcategory of problems, in particular prototypes or glue code. However, it leads to "use your test suite as a compiler" for large scale projects due its lack of static typing.

Re: The March Towards Go

#120

Post by jaxytee »

abritishguy wrote: post #68
jaxytee wrote: post #55

TL;DR It is very likely that TJH is a hive mind. FYI some question TJ Holowaychuk's 'person.' A glance at his github commits would lead you to believe he is some open source prodigy, but there is a curious case being built (share=1 trick, no Quora login needed): http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk-...

Lol, he works at segment.io and he is very much one person.

Have you met him?
Post reply on HN