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

351–360 of 363 posts

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

#351

Post by im_down_w_otp »

Veen wrote: post #333
im_down_w_otp wrote: post #250

Earlier quoted context omitted.

I experience this depression constantly. It's very rare to find people or places using Erlang, the community is extremely small and seemingly getting smaller all the time, and new things attempting to approximate its core strengths (often badly or incompletely) keep coming to the market and only further exacerbating the situation. So I end up stuck working with crappier tech, crappier tools, and dealing with the effe…

What are your thoughts on Elixir?

It's fine. Parts of it seem really weird to me.

Agents don't seem like they should be in the standard library. The pipe operator should probably have some sugar for representing the first implicit argument to the function because it's weird to have things like Enum.map/2 become written as Enum.map/1 in that context. Protocols are bizarrely complex (you can do the same thing in Erlang with about 10% of the ceremony) and made weirder by the fact that structs are represented as maps with a special key instead of as records, so field access and key walking has an unnecessary amount of overhead comparatively. It doesn't feel "complete", because there are pretty big chunks of the underlying system that still make you extremely aware you're really running atop Erlang (debugging, tracing, profiling, etc.), up to and including the docs themselves which often just point you straight to the relevant Erlang documentation.

I like that it has brought a lot of new energy to the BEAM ecosystem. I like the tooling and focus on docs and testing that have come with it. I like the macro system, even though I think it's overused by the community and often to ill effect, but the system itself is much cleaner than Erlang's.

tl;dr... Sure, why not. :-)

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

#352

Post by kuschku »

cube2222 wrote: post #349
kuschku wrote: post #342

Earlier quoted context omitted.

> (would probably do it in a few threads, sending messages between each other). The problem is that I try to abstract these things away – in Java, I have a general framework, and just do var c = new ObservableCollection (); var f = new AsyncObservableFilter (); f.setSource(c); f.addFilter(new DayChangeMessageFilter()); f.addFilter(new CollapseJoinLeaveMessageFilter()); f.addFilter(new RemoveIgnoredMessagesFilter());…

Of course I can't say for 100% as I don't know your codebase. But I think you could easily do this with Message being an interface defining the common functionality of your messages (like, probably, render(), timestamp(), id()). Then you could just have you DayChangeFilter use the timestamp, joinleave do a type assertion, removeignored check for the id. If the genericism for you is also abstracting away the source of…

See, the problem is that "message" is only used in this one place.

In another place, I use there a type such as network, and the filters are entirely different ones.

In yet another place, I use even other types.

The types used there have nothing in common, nor do the filters.

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

#353

Post by cube2222 »

kuschku wrote: post #352
cube2222 wrote: post #349

Earlier quoted context omitted.

Of course I can't say for 100% as I don't know your codebase. But I think you could easily do this with Message being an interface defining the common functionality of your messages (like, probably, render(), timestamp(), id()). Then you could just have you DayChangeFilter use the timestamp, joinleave do a type assertion, removeignored check for the id. If the genericism for you is also abstracting away the source of…

See, the problem is that "message" is only used in this one place. In another place, I use there a type such as network, and the filters are entirely different ones. In yet another place, I use even other types. The types used there have nothing in common, nor do the filters.

Ok sorry, I thought the unit of generic'ness you mean is the message. You're basically just talking about generic custom collections. Yeah, it is a thing you won't get in Go. And you'll have to write it every time again.

I'm usually just writing custom ones for each case, takes just a little bit more work. If I need more genericness, as I said, I use Java/Scala/F#

EDIT: In theory you can hack this all together using interface{}, but I wouldn't do that, it's a hack and ignores the type safety of the language.

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

#354

Post by crimsonalucard »

jaegerpicker wrote: post #346
crimsonalucard wrote: post #191

Earlier quoted context omitted.

Haskell is actually less expressive. It is a functional abstraction on top of what is essentially a procedural machine and with all abstractions placed on top of lower layers you can only lose functionality as you go up rather than gain. You could say assembly language is the most expressive language out there. The great thing about Haskell and other functional programming languages is that the functional style force…

I don't believe this is true for Haskell but I'm not a great Haskell dev. I do know Ocaml (mostly F# actually but it's super close) and this isn't at all true for OCaml which has a ton in common with Haskell. In OCaml I make lists of functions as pipe based expressions, where each step in the pipeline is a function. It's incredibly easy to reason about and matches the lists of functions view of development extraordin…

function composition sort of emulates a list of procedures but it's not really the same thing. There's restrictions on function composition that aren't intuitive.

A typical task list has tons of side effects, which is not the case with your "pipe lines."

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

#355

Post by camus2 »

_0w8t wrote: post #336
camus2 wrote: post #36

Earlier quoted context omitted.

> With code generation I can program my types using the same language I use for code with less things to learn. With code generation you are introducing your own compiler, DSL and all that bullshit that becomes yet another dependency you have to manage. That's busy work, that's bureaucracy, that's brittle. Now your codebase depends on pragma statements, manifests and obviously a specific syntax that aren't even manag…

In Go one can use template library to add custom generics using already known syntax. Essentially it will be Go source with familiar template annotations. Surely it is still a non-standard language, but the setup is trivial and extra flexibility of custom DSL may suits some projects better than hypothetical Go-with-generics.

> In Go one can use template library to add custom generics using already known syntax. Essentially it will be Go source with familiar template annotations. Surely it is still a non-standard language, but the setup is trivial and extra flexibility of custom DSL may suits some projects better than hypothetical Go-with-generics.

You answer addresses none of the points I was making. Your custom DSL is something you have to maintain on your own, and it obviously yet another thing that fragments the go community. Imagine if C had no macros and everybody would use its own pre-processor that you need to download before compiling a C lib. Go is exactly in the same situation. It's obviously "not a feature", nor simple, nor readable, nor smart, nor practical.

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

#356

Post by thesz »

amelius wrote: post #103
thesz wrote: post #97

Earlier quoted context omitted.

If you have not too much data in the heap, you are safe. Even if you have a lot of data there, you most probably fine too. As an example, see here: https://bazqux.com/ and the discussion is here: https://news.ycombinator.com/item?id=5961570 He was able to survive unexpected slashdot effect from being on the front page of Hacker news without even noticing it. He told me he went up one evening and found that there were…

Okay, but surviving a Slashdot effect is different from having a low-latency server of course :)

He didn't tell me that anyone complained about delays, etc.

I think delays weren't that noticeable then.

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

#358

Post by psiclops »

notjack wrote: post #324
psiclops wrote: post #311

Earlier quoted context omitted.

Javascript

Not a server language (no NodeJS at google). The other is C.

AFAIK (although I could be wrong about this) the typical 'five' languages used at Google are not specifically for servers. I have heard they are Javascript, Java, Python, Go, and C++

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

#359

Post by nv-vn »

gothrowaway wrote: post #289
nv-vn wrote: post #285

Earlier quoted context omitted.

>You're proving my point. If it were node.js, I highly doubt I'd have a person coming out of the woodwork with cleverly placed quotes as if it's a legal threat. The irony is that you came out to defend Go from any sort of criticism without any direct argument as to why Haskell is bad. Your post talks about the people who use it and criticizes them for criticizing other programmers, yet that reflects perfectly on what…

It's my experience and opinion. Also, I looked through your history, you're a Haskell programmer. Due to the context of my thread, I'd appreciate it if you disclosed your relation so others know. > AwesomeWM lists Lua as a feature It's a scripting language on top of that's used for configuration. > It's pretty similar to saying "code has been tested extensively by our quality assurance team" or something "code has be…

I am not a Haskell programmer, in fact I am not very fond of the language and have only ever used it for a single project. I find the language interesting, but I disagree with many of the fundamental design decisions and it is never my first choice for a project.

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

#360

Post by crimsonalucard »

prance wrote: post #332
crimsonalucard wrote: post #191

Earlier quoted context omitted.

Haskell is actually less expressive. It is a functional abstraction on top of what is essentially a procedural machine and with all abstractions placed on top of lower layers you can only lose functionality as you go up rather than gain. You could say assembly language is the most expressive language out there. The great thing about Haskell and other functional programming languages is that the functional style force…

> Haskell is actually less expressive. It is a functional abstraction on top of what is essentially a procedural machine and with all abstractions placed on top of lower layers you can only lose functionality as you go up rather than gain. You could say assembly language is the most expressive language out there. That is not what is usually meant by "expressiveness" of a language. You seem to be talking about types o…

The set of all possible assembly instructions is bigger than the set of all possible assembly instructions that haskell can compile to. Therefore haskell is less expressive than assembly language. That is what I mean by expressive.
Post reply on HN