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

Three Months of Go, from a Haskeller’s perspective (2016)

barrucadu.co.uk

Post reply on HN
Print view View original

181–190 of 363 posts

Re: Three Months of Go, from a Haskeller’s perspective (2016)

#181

Post by ruslan_talpa »

noir_lord wrote: post #104
jwdunne wrote: post #8

It is, I think, going to be very difficult to enjoy writing code in a less powerful language when you are exposed to languages that hold awesome power. In fact, this has been the basis for much writing on Lisp too. Paul Graham has written entire essays along the same lines. If you work in a job that forces the use of a less powerful language than what you've been exposed to, you can, I think, go through a sort of dep…

I prefer less powerful languages (that have sufficient power to clearly express the domain). I've found that "powerful" languages allow me to do clever things(TM) and I hate clever things(TM) retroactively when I come back to them. This gets even worse when you have multiple people on the team doing clever things(TM).

If by clever things you mean "pointfree" all over the place then i agree but if you mean "abstractions" in general then that's a different thing and this says it best.

“The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.”

~ Edsger Dijkstra

I think i can honestly say i did not fully get that quote until i learned Haskell

Re: Three Months of Go, from a Haskeller’s perspective (2016)

#182

Post by dualogy »

steveklabnik wrote: post #125
dualogy wrote: post #17

Earlier quoted context omitted.

How robust/mature is it as of yet? More importantly, how are compile speeds and how much of a priority are they to the compiler maintainers? I too find it quite promising in terms of "a language aiming for the benefits of Go with the expressiveness and added easier correctness of FP". But "promising" doesn't mean I'd replace the few use-cases where Go currently shines for me (wouldn't recommend it for any-and-all dev…

> robust/mature Needs more context. It's more mature for some things than others, like many young languages. > how are compile times Not Go, for sure, but not the worst either. > how much of a priority are they Getting them down is a high priority, but has taken some time to make a dent in. The last few releases have all posted speed ups, and "cargo check" in the last release helps. Incremental recompilation is comin…

> Incremental recompilation is coming

Good to hear, when that is in place compile times matter a whole lot less

Re: Three Months of Go, from a Haskeller’s perspective (2016)

#183

Post by ruslan_talpa »

TheCondor wrote: post #134
jwdunne wrote: post #8

It is, I think, going to be very difficult to enjoy writing code in a less powerful language when you are exposed to languages that hold awesome power. In fact, this has been the basis for much writing on Lisp too. Paul Graham has written entire essays along the same lines. If you work in a job that forces the use of a less powerful language than what you've been exposed to, you can, I think, go through a sort of dep…

I don't know how to ask this without it sounding offensive, and I don't intend it that way. But do these "hardcore" haskellers enjoy writing programs at all? Like are there any well known open source apps that people actually use written in Haskell? There are tons of hobbiests and it has a following but what are the examples of its greatness? I ask as an old SML guy, I like the math theory, I like the promise of bett…

Haskell community does tend to produce extremely powerfull libraries but not so may user facing tools (maybe it's just an impression). However, compilers for Elm and PureScript are written in Haskell :) and you probably know the FB spam filter core is also in Haskell

Re: Three Months of Go, from a Haskeller’s perspective (2016)

#184

Post by edmccard »

j2kun wrote: post #174

> But Go does have generics, for the built-in types. Arrays, channels, maps, and slices all have generic type parameters. Doesn't this mean you could implement a generic tree type if you fix the underlying data structure to be an array/map? (Not a go programmer yet, but honestly curious)

>Doesn't this mean you could implement a generic tree type if you fix the underlying data structure to be an array/map?

Nope. There are only a few functions that accept type parameters, and they must be called with concrete types, and they only work with certain aggregate types. For example, "make" can only be used to create slices, maps or channels, so you could create a slice of 10 bytes with "make([]bytes, 10)" but you cannot write "make(T)" or even "make([]T, 10)" where T is a type variable, and you also can't do "make(Tree)" where Tree is, e.g, some struct type.

Re: Three Months of Go, from a Haskeller’s perspective (2016)

#185

Post by daxfohl »

unscaled wrote: post #148
canes123456 wrote: post #129

Earlier quoted context omitted.

No one is arguing to roll your own when there a generic sort in the standard library. The issue with clever things is that people try to make a all purpose solution for what could be a simple one off solution. The all purpose is only used for 2-3 uses and it never battle tested.

Clever things like a sort function that can sort both ints and floats and any new type that implements a comparison function?

Or a quicksort in constant memory.

Re: Three Months of Go, from a Haskeller’s perspective (2016)

#186

Post by bogomipz »

mrkgnao wrote: post #149
bogomipz wrote: post #135

The author states: >"Strict evaluation is typically better for performance than lazy evaluation (thunks cause allocation, so you’re gambling that the computation saved offsets the memory cost), but it does make things less composable. " Can anyone tell me what a "thunk" is in this context and also why it causes performance problems? The article linked to in the sentence results in a 404.

A thunk is an unevaluated value. Better, it's an unevaluated piece of code that returns a value when it's required. For instance, you can write x = [1..] which gives you a list of all the positive integers. Because of laziness (which thunking enables), this line runs just fine. The compiler allocates a thunk for x, saying "okay, I know what x is now". But x is never fully evaluated (because we don't really have enoug…

Thanks for the great explanations. Cheers.

Re: Three Months of Go, from a Haskeller’s perspective (2016)

#187

Post by sanderjd »

woah wrote: post #120
jwdunne wrote: post #82

Earlier quoted context omitted.

This is true, from my experience. When I'm screening candidates, I often ask them to solve a problem in their language of choice. They choose PHP, even though I know the same problem solution can be expressed far clearer and shorter in Ruby. Perhaps we are unearthing various kinds of choices i.e choices for best fit vs best convenience. Perhaps that's a case of engineering vs something other.

Despite its checkered past, isn't php these days a more powerful language than ruby?

I'm really curious about this! I don't know much about recent versions of PHP - what do you think makes it more powerful than Ruby?

Re: Three Months of Go, from a Haskeller’s perspective (2016)

#188

Post by kuschku »

cube2222 wrote: post #179
kuschku wrote: post #139

Earlier quoted context omitted.

> However, in practice, you just get used to it. I haven't had a situation in the past half year where I'd forget to handle the error / check it. But with the same argument, you could as well use PHP7. And this still doesn’t allow you to replace all stdlib datatypes with your own implementations without using custom precompilers.

Excuse me, what do you mean by 'replace all stdlib datatypes with your own implementations'. Why would I do that?

To interface via an FFI with a game engine, which uses a custom allocator, and you need to pass datatypes between it and your own code?

(As I’ve done in Java!)

To replace existing implementations with your own, because you want a LinkedArrayList (a linked list of blocks)? Or because you want a TreeMap instead of a HashMap, or a Set with different implementation?

Because you want to implement your own Either type to better handle return values (see https://github.com/spencerwi/Either.java )?

Re: Three Months of Go, from a Haskeller’s perspective (2016)

#189

Post by canes123456 »

unscaled wrote: post #148
canes123456 wrote: post #129

Earlier quoted context omitted.

No one is arguing to roll your own when there a generic sort in the standard library. The issue with clever things is that people try to make a all purpose solution for what could be a simple one off solution. The all purpose is only used for 2-3 uses and it never battle tested.

Clever things like a sort function that can sort both ints and floats and any new type that implements a comparison function?

I am not arguing for Go. I am arguing that there is an issue with some complex languages. Go is trying to avoid that issue. I agree that the issue is real but also think go takes it a little too far.
Post reply on HN