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

141–150 of 363 posts

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

#141

Post by kod »

gothrowaway wrote: post #81

When I look at a programming language, I look at the community and how it gets stuff done and projects that are noteworthy. Something about Haskell strikes me as different. Despite the buzz about it, I don't see many projects for it other than shellcheck, pandoc and xmonad, and for two of those, there's better solutions around (sphinx, awesome/i3). The other thing is the general flow I've see with Haskell programmers…

In over 10 years the most productive people I've worked with were able to learn Scala and ship code in Scala quickly, without worrying about whether they would rather be programming Haskell.

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

#142

Post by burntsushi »

coldtea wrote: post #121
manmal wrote: post #43

Earlier quoted context omitted.

It's stoicism for programming. Accept what you cannot change (tools, language), and focus on what you can change (attitude, striving for great solutions).

> Accept what you cannot change Only you can easily change languages... Stoicism was referring to actual things one cannot change. Like, say, death, or their status as a roman slave. So it's less stoicism and more "our way or the highway".

> Only you can easily change languages...

That's a ridiculous blanket statement to make. Changing languages can incur a very high cost. Making peace with this as an individual seems like a useful skill to acquire. If you want to insist then there's no connection to stoicism, then fine, but don't try to pass off language choice as something that's easy to change along the way.

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

#143

Post by paulddraper »

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 saved state whose evaluation has been postponed.

    a = 1 + 2
    if (condition) {
      print(a)
    }
In a lazy system, if `condition` is not true, then `a` is never evaluated.

This contrived example would be a poor place to have lazy evaluation though, as the overhead of deferring would exceed the cost of computing 1 + 2 up-front.

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

#144

Post by cube2222 »

kuschku wrote: post #133
cube2222 wrote: post #119

Earlier quoted context omitted.

Totally not, I'm working in Poland. And, I'm sorry to say, if you haven't heard about Consul, then you're really not in a position to judge if infrastructure tools are or aren't written in Go. Consul is the de'facto industry standard for service discovery for a few years already. EDIT: Cockroach is actually the most SV'ish of all those.

> Consul is the de'facto industry standard for service discovery for a few years already. So standard that it doesn’t even have a Wikipedia page? Nor is there even one for this specific type of datacenter-oriented service discovery? This is all pretty niche tech, used by a handful of startups that engineer technology for billions of users, but not used anywhere else. I’ve never seen any companies on national scale op…

The thing is, I know a lot of companies using it at nationwide scale (non-startups). I think there's a reason you are getting downvoted.

Anyways, Service Discovery like this is less niche than containers are. If containers are still niche for you, then there you go.

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

#145

Post by unscaled »

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…

I think Pandoc can count as an example here - it may be a niche product, but it's well known in its niche, and it's arguably the most powerful document markup format converter out there. And it's all Haskell.

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

#146

Post by evilduck »

coldtea wrote: post #121
manmal wrote: post #43

Earlier quoted context omitted.

It's stoicism for programming. Accept what you cannot change (tools, language), and focus on what you can change (attitude, striving for great solutions).

> Accept what you cannot change Only you can easily change languages... Stoicism was referring to actual things one cannot change. Like, say, death, or their status as a roman slave. So it's less stoicism and more "our way or the highway".

An individual can easily change languages.

It's significantly harder for an organization of 10+ developers to change from a single language to another single language without a technically savvy and respected manager just mandating what it will be.

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

#147

Post by shmageggy »

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…

Off the top of my head, Pandoc, a tool for converting between different markup/down flavors, and xmonad, a tiling window manager for linux. Both are well known and popular.

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

#148

Post by unscaled »

canes123456 wrote: post #129
coldtea wrote: post #118

Earlier quoted context omitted.

> 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. They also allow you to do sensible things(TM) like use the one and single, battle tested, standard library's generic sort, btree, etc implementation, instead of having to roll (and then read) 1000s of your own over the span of a year... And it's a false dichotomy that you can't…

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?

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

#149

Post by mrkgnao »

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 enough memory!): it's only evaluated as far as needed. Indeed, typing

    head x -- this is 1
makes the interpreter print the first element of the list. The rest is still in a thunk. In memory, we have something like

     [1,]
Now you can try doing

    head (tail x) -- this is 2
which evaluates the list only as far as the second element. Right now, in memory, the list looks something like

     [1,2,]
You can do similar things with basically any other datatype, enabling cool stuff like [1].

However, having to evaluate (or "force") thunks repeatedly in tight loops can obviously degrade performance: printing a Haskell list like [1..10] requires you to evaluate the first element, print it, then force the next thunk to print the 2, and so on. Comparing this to the equivalent in basically any other (strict) language, we see that a lot of indirection is removed, because the endless wrapping/unwrapping is replaced with a simple linked list of 10 elements. (I'm sure GHC is smart enough to optimize the thunking away in this toy case sufficiently.)

One might also say that a thunk is a "promise" (I'm not familiar with the JS concept of the same name, which I think is related to async things instead) to give you a certain value by calculating it only when you need it (if you do at all: a thunk stays unevaluated when you're done running the program, it's GC'd away).

[1]: http://jelv.is/blog/Lazy-Dynamic-Programming/

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

#150

Post by AsyncAwait »

cube2222 wrote: post #54
merb wrote: post #41

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". I never get the compile time argument. Well I code a big Scala application and the most time it spents is integration testing. the 1…

Well, the thing is, with compile times of 2 seconds I can run my unit tests as fast as possible. At the same time, I'd just use a mock database for most of the tests. It's great to be able to compile applications like kubernetes in 2 minutes.

If compile time is an issue, the new 'cargo check' tool may take some of the pain away.[1]

1 - https://blog.rust-lang.org/2017/03/16/Rust-1.16.html

Post reply on HN