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

Everyday hassles in Go

crufter.com

Post reply on HN
Print view View original

101–110 of 297 posts

Re: Everyday hassles in Go

#101

Post by kasey_junk »

lmm wrote: post #80
kasey_junk wrote: post #35

Earlier quoted context omitted.

> use some kind of "magic" No it doesn't use magic, but it does take a language that is burdened with a complex type system and throws it out the window. You also are glossing over a huge host of complexity around build/deployment. What jvm are you targeting? Is it on the servers you are deploying to? Are you going to make a fat jar? If not, how are you doing dependency resolution? Is your build artifact something th…

> No it doesn't use magic, but it does take a language that is burdened with a complex type system and throws it out the window. What are you talking about? Spray works hand-in-glove with the Scala type system; would, in fact, be impossible in a language without it. > You also are glossing over a huge host of complexity around build/deployment. What jvm are you targeting? Is it on the servers you are deploying to? Ar…

> What are you talking about? Spray works hand-in-glove with the Scala type system; would, in fact, be impossible in a language without it.

In the example you linked to: https://github.com/spray/spray/blob/release/1.1/examples/spr...

The "main" function dispatch is not type safe (nor can it be given Spray's reliance on the current akka type model).

My experience is that anything that relies on akka ends up throwing out a huge majority of useful type safety because it is hard to minimize it. A bunch of the advantages you mention around AOP and not monkey patching are due to this.

Re: Everyday hassles in Go

#102

Post by tarikjn »

friendly_chap wrote: post #83
tarikjn wrote: post #61

I couldn't agree more with this article. I did some Go a year ago and liked it. Then coming back to it a year later after having done some functional programming in Clojure, it's not just the lack of generics that disrupt my flow but also having to think about all sorts of imperative programming details like naming and creating variables and scope placements in cases that would otherwise be unnecessary in a functiona…

This question is not easy. Most languages I consider well designed do not become mainstream - which comes with a host of problems. Nowadays I think if having no type system at all is better than having a broken type system, thus I am considering picking up a mainstream dynamic language (JS being an obvious candidate - but the runtime puts me off).

JS could fill the role but both the runtime and language are unideal, we end up dealing with a lot of browser baggage.

JS is still my tool of choice for building web apps. Just as for long running services, Clojure is a no brainer for me.

I am pretty open to ML or LISP based syntaxes, not necessarily looking for something Clojure-like.

Re: Everyday hassles in Go

#103

Post by vardump »

threeseed wrote: post #91
vardump wrote: post #51

Earlier quoted context omitted.

Not to mention deployment. No JVM to configure. Or application server... Minimally, just drop the binary and an init.d script. Feel free to use something fancier for manageability etc., the point was the simple option is available.

You don't need to configure the JVM as in many cases the defaults are fine. And most of the frameworks in use today do not require an application server. Go is definitely simple. But I wouldnt characterise modern day Java development as being that complicated.

Well, you don't need the JVM and any dependencies it pulls. That's also worth something in the era of "cloud" services. Less to install. Less to update. Ideally you only need to update the deployed application. Which in case of Go is that one binary.

Another big thing is that same app written in Go just takes (significantly) less RAM than when written in Java. Go has arrays (and slices) of structs, not just struct pointers (in Java-speak: object references). This also dramatically reduces short lived garbage. Additionally Golang strings consume less memory, as they are UTF-8 by default in memory. In Java, you can start JVM with -XX:+UseCompressedStrings option, but that adds branches and still falls back to UTF-16 when string contains non-ascii characters.

Re: Everyday hassles in Go

#104

Post by ominous_prime »

frou_dh wrote: post #47
NateDad wrote: post #37

Earlier quoted context omitted.

Which you can catch with a linter like https://github.com/kisielk/errcheck . Errors in Go are just values. There's nothing "more wrong" about ignoring a return value that is an error or one that is file handle, for example. And in cases where a function returns an error and a value (where the error generally indicates the validity of the value), you'll get a compile error if you don't check the error. That's pretty g…

> And in cases where a function returns an error and a value (where the error generally indicates the validity of the value), you'll get a compile error if you don't check the error. This compiles: package main import "errors" func main() { x, err := f() if err != nil { return } y, err := g() h(x, y) } func f() (x int, err error) { return 1000, nil } func g() (y int, err error) { err = errors.New("boo"); return } fun…

This looks more like a bug. The second err is a valid redeclaration, and so should be checked for usage on it's own. Though the redeclaration through multiple assignment is itself a bit of a wart that the programmer hast to be wary of, so it may not be a big deal.

In any case, the go compiler is very helpful in most cases, and better tooling can improve things further.

Re: Everyday hassles in Go

#105

Post by lmm »

kasey_junk wrote: post #101
lmm wrote: post #80

Earlier quoted context omitted.

> No it doesn't use magic, but it does take a language that is burdened with a complex type system and throws it out the window. What are you talking about? Spray works hand-in-glove with the Scala type system; would, in fact, be impossible in a language without it. > You also are glossing over a huge host of complexity around build/deployment. What jvm are you targeting? Is it on the servers you are deploying to? Ar…

> What are you talking about? Spray works hand-in-glove with the Scala type system; would, in fact, be impossible in a language without it. In the example you linked to: https://github.com/spray/spray/blob/release/1.1/examples/spr... The "main" function dispatch is not type safe (nor can it be given Spray's reliance on the current akka type model). My experience is that anything that relies on akka ends up throwing o…

Ah, my bad. https://github.com/spray/spray/tree/release/1.1/examples/spr... (or even https://github.com/spray/spray/blob/release/1.1/examples/spr... if you want the very simple case) are better examples, that use the lovely type-safe routing DSL.

Re: Everyday hassles in Go

#106

Post by brianolson »

The first point "no generics, no code reuse" is the best one. Go really needs generics/templates/macros or _something_. It doesn't even have subclassing, although you can kinda extend a type if you only use its public interface. I've been tempted to see if I could reasonably use the "text/template" package and feed that back into the Go compiler to achieve this.

The rest is mostly a Haskell fanboy whining that Go isn't Haskell.

Re: Everyday hassles in Go

#107

Post by NateDad »

brianolson wrote: post #106

The first point "no generics, no code reuse" is the best one. Go really needs generics/templates/macros or _something_. It doesn't even have subclassing, although you can kinda extend a type if you only use its public interface. I've been tempted to see if I could reasonably use the "text/template" package and feed that back into the Go compiler to achieve this. The rest is mostly a Haskell fanboy whining that Go isn…

Go has a very nice standard library. The whole thing is reusable code.

Re: Everyday hassles in Go

#108

Post by jasonkostempski »

nine_k wrote: post #53
NateDad wrote: post #32

Earlier quoted context omitted.

They're simple loops. You don't need to copy and paste, you just write them out because it's just ridiculously simple logic. Just like you don't copy and paste if statements.

Ridiculously simple and wordy . Exactly the stuff the computer should do for me.

I think editors solve that problem pretty well. I usually only have to type something like "fo" part of my collection name and another or 2 before I get down to business, no matter what language I'm using.

Re: Everyday hassles in Go

#109

Post by dalke »

stephencanon wrote: post #84
dalke wrote: post #57

Earlier quoted context omitted.

C11 added the _Generic keyword, so someone must have complained. A common complaint is the desire to have, say, cos(x) work on floats, doubles, and long doubles rather than calling respectively cosf(), cos(), cosl().

Huh? C has had the header for 15 years, which lets cos(x) do exactly that, and work on complex types besides.

_Generic makes it easy to implement things like tgmath yourself.

Re: Everyday hassles in Go

#110

Post by kasey_junk »

zzzcpan wrote: post #76

Well, I want Go to have refcounting instead of current GC, so my programs could guaranty latency. Single-threaded runtime, without all the locks, slow channels, races and so on, because there is no point in so much overhead and complexity for the majority of programs. More consistency couldn't hurt, so I wouldn't have to assign anonymous function to a variable just to return it. Fast regular expressions compiled by t…

I'm not sure if this is sarcasm or not, but I will assume not. If they made the changes you suggest golang would be come useless to me. That isn't to say what you want isn't valid, only that it gets to the heart of all these arguments. Every design decision comes with trade offs and you can't please everyone.
Post reply on HN