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

131–140 of 297 posts

Re: Everyday hassles in Go

#131

Post by kasey_junk »

wtf_is_up wrote: post #114
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.

Unused import cleanup has been a standard part of all the major Java IDEs for quite some time. Further, checkstyle and other static analysis tools can easily replicate the check.

Re: Everyday hassles in Go

#133

Post by zzzcpan »

vardump wrote: post #122
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…

You don't like locks, but you want refcounting that requires a large number of atomic ops for acquire/release semantics and thus scales like crap? Ah, you really mean, single threaded as in no other threads? Well... ok. But that'd make Golang a lot less useful. For compiled regular expressions: just use PCRE library for compiled regular expressions. I bet there's already some library that does it for you. Maybe you s…

Refcounting and a single threaded runtime, instead of GC and a multithreaded one.

By compiled regexpes, I meant replacing things like bytes.Equal(foo, "qwe") with things like foo.m(`^qwe$`) or even foo.m/^qwe$/ that have the same performance. All the loops that scan through slices could benefit from it, golang has a lot of them. Plus more overall matching/scanning consistency, that should lead to fewer mistakes.

Re: Everyday hassles in Go

#134

Post by waps »

ufo wrote: post #19
lmm wrote: post #4

Agree with a lot of this, but I find the lack of any punctuation one of the most confusing things about Haskell code. Map String Any Is that a function call? A type declaration? What's a parameter to what? The go style map[string]interface{} is, much as I love to hate on all things go, much clearer.

> 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 programming theory and find Go woefully insufficient for anybody calling himself a programmer. And the ones that just fiddle around with things and make barely working programs without really knowing what they're doing are very happy that they don't have to know this in Go.

What's really going on is that people with real programming background find that Go forces them to think at the lowest possible level of abstraction, with no way up. And people without any programming background say "that's GREAT !".

Re: Everyday hassles in Go

#135

Post by falcolas »

NateDad wrote: post #107
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.

Not every problem can be solved with the standard library. At some point you need a 3rd party library, which may require your modification to work with your data types.

Re: Everyday hassles in Go

#136

Post by xasos »

tarikjn wrote: post #116
wtf_is_up wrote: post #98

Earlier quoted context omitted.

> 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?

> 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

I think for the most part, you won't be missing a lot in Haskell. If you are looking for what you say above, Go should satisfy your needs greatly. Haskell is amazing for functional programming needs - fast prototyping and great at doing mathematical calculations. It helps you think in another way, but I certainly wouldn't use it for building something like an API or networking.

Re: Everyday hassles in Go

#137

Post by kasey_junk »

NateDad wrote: post #121
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…

Go 1.5 is going to have real-time guarantees on GC.

"real-time guarantees" is not a particularly useful requirement as you can just set the minimum time very high to accomplish it. Real-time and low latency on the other hand would be a game changer, and I have pretty serious doubts about their ability to accomplish this.

Re: Everyday hassles in Go

#138

Post by colin_jack »

im_dario wrote: post #93
colin_jack wrote: post #72

Earlier quoted context omitted.

"I realized that if you miss generics in Go, your code is trying to cope with too much." Was wondering what you mean by that (not disagreeing just interested)?

I meant that if you miss generics, your code is probably too complex.

Sorry yeah I get that, but in what way?

Re: Everyday hassles in Go

#139

Post by falcolas »

vardump wrote: post #130
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…

Best joke in the industry: "Code reuse!" Cracks me up every time. ;-) We fall for those words over and over again. But in reality, sadly, reuse almost never happens. Maybe one day, maybe even in the next project...

Like c's 'libc', or C++ boost, or pythons 'requests', or...

Lots of code reuse there that depends on generics.

Re: Everyday hassles in Go

#140

Post by jramnani »

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…

You may want to take a look at Pixie.

"Pixie is a lightweight lisp suitable for both general use as well as shell scripting."

https://github.com/pixie-lang/pixie

Post reply on HN