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

111–120 of 297 posts

Re: Everyday hassles in Go

#111

Post by waps »

lmm wrote: post #8
bsaul wrote: post #2

Although i'm still very unsure about rob pike's argument that go don't need generics since it has interface, a recent experience : After having implemented a mini web services in go and being fed up with its limited type system, i decided to stop coding in go and start recoding my project in java using what is often advertized here as the most minimal framework : dropwizard. Well, i downloaded the framework, configur…

I don't think Java will get many defenders here. But try that in Scala, with Spray. There're a couple of lines of boilerplate to create the actor system, but that's about all. And you get a system that's flexible enough to let you write route definitions that look like a config file, but everything's typesafe. Your routes are just functions, you can refactor them like ordinary code. So too are the kind of "cross-cutt…

Java's problem is a problem that Go won't escape from. Java is a language with baggage tacked on. It's standard library is bytecode-compatible with java1 classes. With a small wrapper class the applet that I wrote in my introduction to Java class 14 years ago works perfectly fine.

The configuration problems you mention are the result of these libraries' need to be compatible with older versions of Java.

If you write your own data structures in Java, there is nothing preventing you from fully utilizing Java 8 features. It makes everything unusable in Java 7 of course, which is not considered an acceptable sacrifice by Oracle and it won't be for decades.

The same is true for C++. When it was designed it was a magnificent advance (and it hasn't fallen for the particular "enterprisy" traps java has fallen for). But then the language was redesigned, and redesigned. RTTI being the first major clusterfuck that they decided to make partially binary compatible. Exceptions being the second, and now lambdas being the third. You may disagree on what exactly is a clusterfuck and what isn't, but I hope you can agree on the deeper problem : baggage. Various things matter more to other developers (like pthreads, winsock, ...)

Writing a program from scratch in C++11, not using any of the old libraries ... is almost as pleasant as using rust. But most libraries can't update, because they'd lose too much doing so.

Go is on it's first design of it's standard library, and everything works reasonably well with today's standards ... this is of course not so much a feature of the language as it is the result of when it was constructed.

When the winds turn again, and they will, Go will look as antiquated as Java and C++. Actually, given how well C++ has handled this in the past, it will probably look more antiquated than C++.

Re: Everyday hassles in Go

#112

Post by erglkjahlkh »

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…

The majority of the programs do not really need to guarantee latency.

That being said, it is well known that Golang's present GC performs poorly. It presently fails to free memory in certain cases, and has pretty high overhead. There is work done on improving the GC to be fully concurrent, but that is still probably still 2-3 major versions away.

Re: Everyday hassles in Go

#113

Post by sentiental »

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…

I am starting to think they'll be recommending we use `go generate` to do handwritten templates before too long. It saves them the hassle of building generics into the type system and they clearly want it to be part of the build cycle.

http://blog.golang.org/generate

Re: Everyday hassles in Go

#114

Post by wtf_is_up »

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've come to really enjoy the error on unused variable/import.

It's so easy to add/delete imports with GoSublime plugin.

Everytime I write Java now, I seem to end up with loads of unused imports as I prototype and it just feels messy.

Once you get used to it, it's kind of nice.

Re: Everyday hassles in Go

#115

Post by jbooth »

lmm wrote: post #86
NateDad wrote: post #46

Earlier quoted context omitted.

It seems like Rust is what Go would become of you added all the Haskell-ness to it. Which is fine, but we already have Rust. So... Maybe we should be asking what Rust is missing from Go? Or if Rust is good enough, just use that.

Rust is missing garbage collection (which is by design, but IMO manual memory management is the wrong hair shirt to wear), and maturity. What I want is OCaml without people complaining about concurrency (which I suspect is mostly FUD - how many people who choose go "for performance" actually profile their programs? I get the sense there is this group of people who think any high-level language is inherently as slow a…

So, uh, what are you actually after? Just use Scala if that's what you want. If you can't be bothered to manage memory in rust, then it seems hard to believe that native compilation makes a difference for you.

Is it all just about the hype? Write code, ship products.

Re: Everyday hassles in Go

#116

Post by tarikjn »

wtf_is_up wrote: post #98
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…

> I am looking for a replacement programming language to solve small problems for which Python/Ruby would have traditionally been used, good file system, stream and networking APIs, but concurrency as a first class citizen, garbage collected, fast startup time. You just described Go, mostly. I can't think of a more fitting language given your stated requirements. To your first point: I don't know what Go has to do wi…

Yes, I did describe what Go is good at, that's because I am trying to find something to put it against for what I use it for currently.

Let's say I prefer Haskell's syntax/approach. Coming from Go, what could I be missing in Haskell?

Re: Everyday hassles in Go

#117

Post by rjberry »

jbooth wrote: post #94
rjberry wrote: post #77

Earlier quoted context omitted.

I dislike it when people say languages are either 'practical' or 'well designed'. As if a language is only useful if it's not built on sound mathematical ideas ... Generics are not a particularly new idea and nobody who uses language that implement them yearn for the days when they weren't around. See Paul's post on the idea that 'worse is better': http://pchiusano.github.io/2014-10-13/worseisworse.html

The point is that you reach an area where the mathematical ideas don't map perfectly to the underlying functionality you're providing. You can make your language "unsound" by violating those mathematical principles, or you can make something like the I/O monad. It is indeed "soundness" vs "practicality". EDIT: Oh, and that link seems to have misunderstood the 'worse is better' philosophy -- C++ isn't the champion of…

Paul explains fairly well why he thinks C++ is a good example of "worse is better", including quotes from the language designer to that effect.

I think when you get to more complicated (or at least alien) abstractions like the I/O Monad, it's not about whether it's practical to build software with it. It's perfectly practical - I know people working at big investment banks writing large scale software in Haskell, and they don't have any issue with it. What it comes down to is whether the people you work with will understand or want to invest the amount of time required to learn those abstractions. If you're working with very talented programmers, that might be yes. With the majority of programmers it is probably no.

But we're not talking about the I/O Monad. We're talking about generics, which are not difficult to understand, and that Go lacks them is a shame, as it means that whole layers of abstraction are not available to the programmer, so they end up having to spend more time writing boilerplate.

Re: Everyday hassles in Go

#118

Post by ominous_prime »

rjberry wrote: post #92
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.

All loops encode simple logic? I don't think that's true. Either way, a very good reason for not using loops is to make code more readable. If I see a loop I have to run it inside my head to figure out what the intent is, and if there's multiple things going on, that can take time. If I see a 'map' I think "right, this is tranforming every element in this list in this way"; if I see a filter, I think "right, this is…

Expanding a map to a for loop is very simple. Yes it removes a shortcut available when writing code, but when reading code I can consume that simple chunk of logic in one mental bite just as easily as I can a call to map.

Re: Everyday hassles in Go

#119

Post by NateDad »

threeseed wrote: post #96
bojo wrote: post #18

Earlier quoted context omitted.

Go is the most boring language I have ever coded in, and that is why I love it. Sure, it doesn't have some fancy bells and whistles people seem to want, but when you can sit down and write something functional, portable, and readable fairly quickly, I'd say that is a huge win.

You know you could replace "Go" with "Java 1.0" and your comment would still be accurate. Funny that.

This is old and tired. Go has a ton of features java 1.0 didn't. Hell, go has features java 1.7 doesn't (possibly 1.8, but I'm not as familiar with it).

Re: Everyday hassles in Go

#120

Post by lmm »

jbooth wrote: post #115
lmm wrote: post #86

Earlier quoted context omitted.

Rust is missing garbage collection (which is by design, but IMO manual memory management is the wrong hair shirt to wear), and maturity. What I want is OCaml without people complaining about concurrency (which I suspect is mostly FUD - how many people who choose go "for performance" actually profile their programs? I get the sense there is this group of people who think any high-level language is inherently as slow a…

So, uh, what are you actually after? Just use Scala if that's what you want. If you can't be bothered to manage memory in rust, then it seems hard to believe that native compilation makes a difference for you. Is it all just about the hype? Write code, ship products.

As I said, the JVM startup latency is a real issue. I'd like to be able to write little command-line utilities in Scala (or a Scala-like language) and not have to wait a second when I run them.

But yeah, I'm writing and shipping in Scala, and life is good, I shouldn't care about people hyping what I don't like.

Post reply on HN