Live data from Hacker News

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

barrucadu.co.uk

251–260 of 363 posts

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

#251
post #207

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…

> In haskell the application has to be an elegant diamond or the thing won't even compile! Nonsense - You only have to make things as hard/elegant as you want them to be (and fore sure, some people do play that game for better/worse). But, Haskell will happily allow you throw everything in to IO; you can side-step creating a perfect model and just hack together a list of imperative IO statements. (unless you're refer…

If you are going to "throw everything in IO" then what advantage does Haskell have?

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

#252
post #32
post #30

Earlier quoted context omitted.

> is that it is disappointing what Google is capable of Man, how long will this meme survive? Go only initially originated with some Google developers, it's not in any way "Google's answer to Apple's and Microsoft's strategically-important and accordingly-subsidized-and-evangelized-and-invested-in languages". Just picture a handful of (previously "accomplished" in the field, as it turns out though) guys thinking "thi…

Those developers are being paid by Google and their actions within this context relate to the public image of their employer. If Google wouldn't agree with their actions, or did not pay to increase the team size, they would be developing the language outside Google walls.

You may disagree but Google relationship with Go looks lot more distant as compared to C#-MS, Java-Oracle, Swift-Apple. Here Dart-Google looks more appropriate. Those Dart people always keep telling us about Adword's usage of it. Google organizes Dart's conferences whereas for GopherCon doesn't even have Google as sponsor.

Go looks far more independent from Google in branding, sponsorship and references from official Google products.

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

#253
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…

Replying again since I can't edit my comment: Idris, Elm and PureScript.

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

#254
post #45

Earlier quoted context omitted.

I cannot speak for Elixir, but coming from the Erlang world, I'm sure it's a fine language that has sane defaults, much like Clojure. However I switched from Python to Scala and besides the performance issues and the poor handling of async I/O that I had with Python, by far the biggest problem with Python was all the insecurity while developing with it. It drove me insane, because we had a production system that alwa…

But writing Python is a pleasure :( And writing the same thing is Go feels like wasting my wrists for nothing, specially for throwaways and simple web code... Maybe one could write Python and turn a "strict" flag for the module (project?) where you'd have to fill in the types and it becomes Scala-like.

> But writing Python is a pleasure

This sentiment seems commonly shared, but by no means universally.

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

#255
post #248

Earlier quoted context omitted.

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…

Not OSS, but I know Galois use a lot of haskell in their work for largely government agencies (NASA, DoD, etc.) Perhaps the type of problems Haskell is apt to solve (those requiring strict correctness, etc.) are not typically open source software projects.

Maybe not Haskell, but a lot of ideas from Haskell and Haskell-like languages such as typeclasses, Option types, type inference, etc. have found their way to Rust, and it makes programming in Rust an absolute pleasure.

Rust, I'd argue, is the correct choice for many OSS projects. In fact, for security-focused projects, it should be the only choice. C-like performance without C-like vulnerabilities? It makes no sense to choose C or C++ any more.

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

#256
post #251
post #207

Earlier quoted context omitted.

> In haskell the application has to be an elegant diamond or the thing won't even compile! Nonsense - You only have to make things as hard/elegant as you want them to be (and fore sure, some people do play that game for better/worse). But, Haskell will happily allow you throw everything in to IO; you can side-step creating a perfect model and just hack together a list of imperative IO statements. (unless you're refer…

If you are going to "throw everything in IO" then what advantage does Haskell have?

yes, there is a difference between "'hack' together a program" and doing proper domain modeling.

However, neither should prevent the other. (i.e. "you can do X" should not be confused with "always do X"). Haskell allows you to choose.

Indeed, proper domain modeling is preferred.. but it's nice to have to ability to make that choice yourself based on your own constraints.

Additionally, Haskell makes it very easy/pleasant to refactor from the former to the latter. (On that note, imho the best models (in business) are arrived at iteratively rather than big-design-up-front)

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

#257
post #67

Earlier quoted context omitted.

"Dynamic languages make testing easier," paints a very broad brush. They have some very nice benefits, but also a lot of edgecases. * An argument might be an int when you expected a float. This can be addressed by casting things with `float()` in every entrypoint, but it's more defensive to require a float and error out otherwise. Either way, problems only appear at runtime. * An object might be null and this only ge…

> An object might be null and this only gets picked up at runtime - using Rust it's been very nice to have to explicitly say when things can be null. This point actually frustrates me greatly about C# 7. At some point, there was talk about non-nullable references being introduced into the language, which has been put on hold for at least another version. Personally, I think that feature should have been in the langua…

I have thought about creating a template struct with a single member that blows up if you try to insert null. Something like this:

  public struct NotNull
  {
    private readonly T val;
    public T Value { 
      get { return val; } 
    }
    public NotNull(T v)
    {
        if (v==null) 
          throw new Exception(); 
        val = v;
    }
  }
However you can still create a class FOO with a member NotNull xxx and xxx may be entirely uninitialized. It can be then passed from one method to another until you try to read it, so it basically does not give any guarantees.

I thinks this is why they pulled non-nullable types from C# - they couldn't figure out what to do in this case. If I were them I would force the constructor of FOO to blow up on exit if xxx is not populated. That would help a little bit. Although it still causes problems if a method is invoked from the constructor.

So yeah, it's a tough problem. Maybe they could add a check when a field of type NotNull is read to throw an exception? That way you're still possibly in trouble when reading a field, but at least you can be confident that if you receive a method parameter NotNull you know it's not null.

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

#258
post #249
post #2

I hate to sound like the rust evangelist strike force... I really do. But your complaints are exactly what it would solve... Sigh I hate to say this I really do. But here goes... So have you checked out rust?

Most haskellers are fond of Rust. However, it is certainly not a Haskell replacement; it has substantially less expressive power. This is, arguably, necessary for its impressive memory model (no GC and memory safe allocation), but it does hurt programmer productivity in many cases. I always feel constrained when I use Rust, although I can't fault the language for being that way. Rust is well-designed , but even good…

Luckily, LLVM 4.0 added support for AVR, and hopefully Rust can take advantage of this soon

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

#259

Earlier quoted context omitted.

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

More to the point, Rust is trying pretty hard on the compile time front. They've almost got incremental compilation out the door, on top of this.

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

#260

Earlier quoted context omitted.

This is an interesting point actually. Because it gets raised every time and I actually thought the same before starting with Go. Thing is, in practice you usually don't need special generic containers. And when I actually need it, I'll just code up a non-generic implementation. When I need a complex type system I'll use Scala.

Well, I use them a lot – I’ve written lots and lots of generic code in my projects, and reuse it across many dozens of projects. This allows me to have fully reactive collections in Java, lazy reactive collections, and more. I can just connect to a socket transmitting updates with netty, write a transformer, apply those to a lazy reactive collection, and have the changes directly appear in the list in the UI, fully t…

I'd love to take a look at your codebase if it's hosted on github (or something comparable).
Post reply on HN