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

Leaving Go

jozefg.bitbucket.org

Post reply on HN
Print view View original

41–50 of 220 posts

Re: Leaving Go

#41

Post by Locke1689 »

pron wrote: post #18

It's ironic that the "better" the language (for some hazy definition of "better") the less actual work seems to get done with it. So Go can be pretty annoying at times, and so can Java (I've said before that I find the two almost identical, but that's beside the point now); and C is horrible and completely unsafe and downright dangerous. Yet more useful working code has probably been written in Java and C than all ot…

As someone who thinks that more advanced type systems and proof-carrying-code are some of the biggest advances in theoretical computer science and practical programming in the last few decades, but also is a C# compiler developer, I have also noticed this. Haskell is really interesting, but C# developers get shit done.

I'm not sure what the cause is, but it definitely gnaws at me.

Re: Leaving Go

#42

Post by pnathan »

pron wrote: post #18

It's ironic that the "better" the language (for some hazy definition of "better") the less actual work seems to get done with it. So Go can be pretty annoying at times, and so can Java (I've said before that I find the two almost identical, but that's beside the point now); and C is horrible and completely unsafe and downright dangerous. Yet more useful working code has probably been written in Java and C than all ot…

Haskell contributed materially in the seL4 effort for a verified microkernel: http://ssrg.nicta.com.au/projects/seL4/

Re: Leaving Go

#43

Post by baruch »

DAddYE wrote: post #29
tptacek wrote: post #24

If you're looking for a language that will enable "bottom-up development", where you gradually define, in Paul Graham On Lisp style, a language optimized for your problem domain, Golang is not the language for you. Similarly, if you're looking for a language that will read and write like a specification for your problem domain, so that writing your program has the side effect of doing half the work of proving your pr…

> Systems C programmers I don't know many (TBH none) c programmers that likes or actually uses go. The thing is that as for c++ if you are still writing in c is just for few reasons: portability (in terms of embedding your library) and speed. Especially the former seems very important. EDIT: I know => I know personally or I follow.

I prefer to work in C over C++ (did both at different jobs), mostly does C but where I don't care just that much about performance (specific allocations of memory and the like) than I'm likely to prefer Go over C++. It's far nicer and I really like the goroutines and channels concept. I like it that much that I copied it back to C in-fact.

Re: Leaving Go

#44

Post by jimktrains2 »

piokuc wrote: post #17
lmm wrote: post #7

Does anyone actually use CLOS? It's always held up as this great example of language extensibility, but my impression is that since it's not part of the core language Lisp folk tend to create their own abstractions instead.

Not sure what you mean by "not part of core language" - CLOS is part of ANSI Common Lisp standard.

It wasn't always that way. It use to be just a lib iirc.

Re: Leaving Go

#45

Post by tragic »

pron wrote: post #18

It's ironic that the "better" the language (for some hazy definition of "better") the less actual work seems to get done with it. So Go can be pretty annoying at times, and so can Java (I've said before that I find the two almost identical, but that's beside the point now); and C is horrible and completely unsafe and downright dangerous. Yet more useful working code has probably been written in Java and C than all ot…

I'm rather taken with Tidal: https://github.com/yaxu/Tidal/

It basically allows you to procedurally generate thumping dance music by live coding in a Haskell DSL in Emacs.

Which, given Haskell's rather academic reputation, is pretty damn cool.

Re: Leaving Go

#46

Post by pnathan »

Locke1689 wrote: post #41
pron wrote: post #18

It's ironic that the "better" the language (for some hazy definition of "better") the less actual work seems to get done with it. So Go can be pretty annoying at times, and so can Java (I've said before that I find the two almost identical, but that's beside the point now); and C is horrible and completely unsafe and downright dangerous. Yet more useful working code has probably been written in Java and C than all ot…

As someone who thinks that more advanced type systems and proof-carrying-code are some of the biggest advances in theoretical computer science and practical programming in the last few decades, but also is a C# compiler developer, I have also noticed this. Haskell is really interesting, but C# developers get shit done. I'm not sure what the cause is, but it definitely gnaws at me.

> C# developers get shit done.

Yes, and that says a lot about the final quality too, no? We could say the same about Perl/PHP/Java/C++ and then we're sitting in the same horrible morass we live in today, because people settle for minimally bad code produced as fast as possible.

Good, cheap, fast. Pick 2. Almost invariably: Cheap+fast are the picked results.

Re: Leaving Go

#47

Post by Dewie »

sandGorgon wrote: post #30

>Ok, it’s only a few characters, big deal. Now what does this do? >b.Mul(b).Sub(big.NewInt(4).Mul(a).Mul(c)) >Or in Haskell >b * b - 4 * a * c umm.. correct me if I'm wrong, since I'm not well versed in either Haskell or Go, but doesnt the Golang version read better in terms of scoping. I mean just by reading the Go version, I know what it will evaluate to, but in the Haskell version I dont know the precedence order…

I'm pretty sure that the precedence is the same as in the usual convention of arithmetics.

You can ask for it in GHCi (the REPL):

> :i (-)

> [...] infixl6

> :i ( * )

> [...] infixl7

So ( * ) has precedence over (-). The expression is then:

(b * b) - (4 * a * c)

Personally, I don't know if infix syntax is truly overall more readable than purely prefix/postfix syntax, or other such uniform representations. It might be for arithmetic, because it is so ingrained, but the precedence order was never hammered into me to such a degree that I learned it automatically by heart; I used to defensively make more parenthesise than I really needed to, just in case.

Re: Leaving Go

#48

Post by f2f »

DAddYE wrote: post #29
tptacek wrote: post #24

If you're looking for a language that will enable "bottom-up development", where you gradually define, in Paul Graham On Lisp style, a language optimized for your problem domain, Golang is not the language for you. Similarly, if you're looking for a language that will read and write like a specification for your problem domain, so that writing your program has the side effect of doing half the work of proving your pr…

> Systems C programmers I don't know many (TBH none) c programmers that likes or actually uses go. The thing is that as for c++ if you are still writing in c is just for few reasons: portability (in terms of embedding your library) and speed. Especially the former seems very important. EDIT: I know => I know personally or I follow.

pleased to make your acquaintance.

Re: Leaving Go

#49

Post by grayclhn »

sandGorgon wrote: post #30

>Ok, it’s only a few characters, big deal. Now what does this do? >b.Mul(b).Sub(big.NewInt(4).Mul(a).Mul(c)) >Or in Haskell >b * b - 4 * a * c umm.. correct me if I'm wrong, since I'm not well versed in either Haskell or Go, but doesnt the Golang version read better in terms of scoping. I mean just by reading the Go version, I know what it will evaluate to, but in the Haskell version I dont know the precedence order…

I do, and I don't even know Haskell: (b * b) - (4 * a * c)

edit: I don't know go, but I assume the go example is intentionally unreadable. But complaining about infix multiplication and subtraction is... curious.

Re: Leaving Go

#50

Post by piokuc »

jimktrains2 wrote: post #44
piokuc wrote: post #17

Earlier quoted context omitted.

Not sure what you mean by "not part of core language" - CLOS is part of ANSI Common Lisp standard.

It wasn't always that way. It use to be just a lib iirc.

Well, CLOS became part of ANSI Common Lisp standard 24 years ago...
Post reply on HN