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

211–220 of 297 posts

Re: Everyday hassles in Go

#211

Post by vardump »

Xorlev wrote: post #193
vardump wrote: post #103

Earlier quoted context omitted.

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 p…

Java also has arrays. And on heap/off heap RAM allocation. We deploy all our services as uberjars, we have a single Amazon AMI with JDK 8 installed. It's pretty frictionless. It goes from a simple Gradle project, to a single jar on S3, and pulled from S3 by our AMI. Automatically launches via an upstart script. I'll give you less RAM usage for sure. But when I'm launching a whole VM for a service anyways, I don't car…

Java doesn't have Object or any Object derivative arrays. Only elementary types can be arrays. Of which reference type is one. So when you say:

  Integer[] boxedInts = new Integer[5];
You're allocating an array of references with length of 5, so usually 5 * 4 + 8 bytes. Additionally, each of the referenced Integer Object instance take up 16 bytes. Multiple arrays (or reference fields) can refer to same Object instance.

The example was about Integers, but it's basically the same story for FactoryWorkerPersons.

Java doesn't have arrays of objects. Only arrays of elementary types, up to 2^31-1 entries.

Re: Everyday hassles in Go

#212

Post by the_af »

waps wrote: post #134
ufo wrote: post #19

Earlier quoted context omitted.

> Is that a function call, A type declaration? If its following a "::" then its part of a type signature and its a type constructor application. Otherwise, its part of an expression and its a regular function call. BTW, Haskell capitalization is significant in Haskell. Identifiers starting with lower case are always regular functions. Types and type constructors always start with upper case. > What's a parameter to w…

Application in Haskell is left associative so its ((Map String) Any) You seem to have stumbled on the exact conflict. Anybody who's seen the theory of lambda calculus will recognize the significance of what you've written, and how it applies to partial binding of functions. Anybody who hasn't will either be thinking of lisp or just be totally confused. This is where the conflict is. Many developers actually know some…

I'd find it depressing if there was any programmer out there who had trouble understanding the concept of "left associativity". I think I learned it in high school.

Re: Everyday hassles in Go

#213

Post by callesgg »

How can sort be considered generic. Every type must be sorted by different stuff, the compiler can't possibly know what that stuff is.

I see what the author is coming from but generics would break what makes go great.

There has been times when I wanted generics, but it has generally meant that i was looking at the wrong side of the problem.

Re: Everyday hassles in Go

#214

Post by lmm »

gws wrote: post #58

Every time I read an article criticizing Go I end up appreciating it even more. Maybe it's because I've never felt the need to use generics and in all these articles the examples they give are functions of a few lines that would be quicker to write 2-3 times for different types than remembering generic syntax. Maybe it's because they exalt one line functional functions over a nice, simple, easy to read FOR loop when…

> 1) Pike, Thompson & co. made obvious errors in designing Go because of their ignorance of programming languages and/or ineptitude

Go was designed by a team at Google, where there is a policy that the only languages you're allowed to code in are C++, Java, and Python. I think the resulting language reflects that; it has many of the strengths of C++, Java and Python, and might even be a better language than all three. But it is also missing really obvious improvements that could be taken from e.g. the ML language family - which shouldn't be surprising, given that no-one at Google is allowed to use those languages!

Re: Everyday hassles in Go

#215

Post by codygman »

vardump wrote: post #146
falcolas wrote: post #139

Earlier quoted context omitted.

Like c's 'libc', or C++ boost, or pythons 'requests', or... Lots of code reuse there that depends on generics.

Yes, libraries get used. That's their point. My point was, that very little of application code ever gets reused, although we somehow always think it will.

That's why you write or update libraries before writing an application, so it can be reused and your application specific code is minimized as much as possible.

Re: Everyday hassles in Go

#216

Post by lmm »

callesgg wrote: post #213

How can sort be considered generic. Every type must be sorted by different stuff, the compiler can't possibly know what that stuff is. I see what the author is coming from but generics would break what makes go great. There has been times when I wanted generics, but it has generally meant that i was looking at the wrong side of the problem.

> How can sort be considered generic. Every type must be sorted by different stuff, the compiler can't possibly know what that stuff is.

What. Have you even used a language with generics? Yes it can, very easily; you can do it in a traditional-OO way by having a sortable interface, or if you want to be really cool you do it with a typeclass.

Re: Everyday hassles in Go

#217

Post by gnuvince »

NateDad wrote: post #40
rtpg wrote: post #31

Earlier quoted context omitted.

maps and filters are things that have existed for a long time, and are extremely commonplace. They are also very representative of common operations in programming. Not having generics means we can't properly build these ourselves, and Go doesn't offer list comprehensions, so instead we're forced to for loop.

Yes, loops, just like we learned in CS101.

Loops are basically just compares + labels + jumps, yet we abstracted away from those, because we saw that it was common to want to execute a block of code a given number of times (for loop) or as long as a condition held (while and do/while loops). In recent years, more languages (C++, Java) have added a construct for doing an operation on every element of a collection (for each). Why then can't we have more abstractions of patterns programmers write over and over again? It makes a lot of sense to have an operation to apply a function to every element of a collection (map) or to remove elements of a collection based on a predicate function (filter). Saying that we can write those with loops is the same as saying we can write loop with jumps: true, but have a specialized construct makes the intent of the programmer a lot more clear.

Re: Everyday hassles in Go

#218

Post by codygman »

dangerlibrary wrote: post #185
rjberry wrote: post #129

Earlier quoted context omitted.

Sure ... but if a loop is effectively doing a map, a filter, and a bunch of other operations all at once? It's a lot quicker to figure out what's going on if it's been written with combinators (once you're familiar with them) than if it's the vanilla loop.

It can be a lot less performant to chain several combinators.

Unless your compiler (ghc for example) uses fusion to turn it into a single loop anyway.

Re: Everyday hassles in Go

#219

Post by thrownaway2424 »

callesgg wrote: post #213

How can sort be considered generic. Every type must be sorted by different stuff, the compiler can't possibly know what that stuff is. I see what the author is coming from but generics would break what makes go great. There has been times when I wanted generics, but it has generally meant that i was looking at the wrong side of the problem.

Sort is generic when order is generic.

Re: Everyday hassles in Go

#220

Post by ufo »

stonemetal wrote: post #142
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…

If you don't need windows support, O'Caml with Jane Street's Core is pretty good. The Async module handles the concurrency bits, and the Pipe module handles the streaming parts.

Note that for now Ocaml is still single threaded so the concurrency is cooperative, similar to how it is in Python or Nodejs. BTW, I'd recommend Lwt instead of Async because its more popular (kind of sad that there are two competing concurrency libs though)
Post reply on HN