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

81–90 of 220 posts

Re: Leaving Go

#81

Post by tptacek »

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.

Nice to meet you.

Re: Leaving Go

#82

Post by coldcode »

All languages suck, at some level. Whether this matters to you is a matter of need, willingness to compromise, and benefits to you, for some definition of you. This often leads to people writing their own language if they can which generally only pleases themselves.

Re: Leaving Go

#83

Post by jamra »

I have a problem with his extensibility critique. I don't agree that having generic types are good for the language. The problem in using polymorphism is that your users are going to abuse polymorphism. There will be class hierarchies that will confuse and abstract from the algorithm at hand. You will be mutating and mangling objects rather than dealing with the issues at hand.

Reading a go source file is like following a for loop. It's quite technical. Reading a Java source file can be a case of trying to figure out the high level abstractions of the program.

Re: Leaving Go

#84

Post by DAddYE »

_ak wrote: post #39
DAddYE wrote: post #3

> I’ve been using Go since November and I’ve decided that it’s time to give it up for my hobby projects. I’d still be happy to use it professionally, but I find that programming in Go isn’t “fun” in the same way that Python, Haskell, or Lisp is. I can't leave go, but indeed I think absolutely the same. The thing is that GO was designed to replace c++ thing that absolutely failed. So we have a python/ruby replacement…

Go wasn't designed to replace C++, Go was designed to replace C++ at Google. And it totally succeeded at that, given the list of critical infrastructure at Google where Go is used, and in some cases has replaced existing C++ implementations.

Not sure if this was the same feel of Rob.

> I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++.

http://commandcenter.blogspot.com/2012/06/less-is-exponentia...

Re: Leaving Go

#85

Post by Jtsummers »

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.

Beat by a few minutes again, as piokuc says, it's in the standard. But even so, it may still be implemented as "just a library" in some CL implementations. That's the beauty of the language, it's so versatile you can extend it within itself, and it really feels like a language extension and not like you're accessing yet another API. If someone wanted a different object system, they could produce it within CL giving totally different OO semantics.

Re: Leaving Go

#86

Post by jerf »

bunkat wrote: post #56
Donch wrote: post #31

The example could have been simplified: func abs(x Top) Top { switch v := x.(type) { case int32: if v

This code doesn't actually compile. You can't assign v to x.(type) like that.

Are you sure? http://play.golang.org/p/dJC328-rh8

I did have to put "return x" as the last statement, though, not return v. And I'm not sure I'm happy about an "abs" that happily returns a string if fed a string, but, well, that's Go.

Relevant bit of the spec: http://golang.org/ref/spec#Type_switches

Re: Leaving Go

#87

Post by DocSavage »

Jabbles wrote: post #57

As much as I want to emphasize that this is not the right way to think about programming in Go, I do want to point out that the example has a lot of extra code that isn't needed. Indeed, it's not really possible to have a bug of the kind the author wrote if written properly: http://play.golang.org/p/puZBEmOVaI

The explicit type switch also lets you streamline handling of uint8, uint16, etc (just return value) and panic or error if given a type you don't expect.

But I find it unfortunate that type switches must have single type cases. For example, it's too bad this doesn't work:

http://play.golang.org/p/a4j1I6Oug-

The OP's complaint would be minor if the compiler would auto-unroll the multi-type case clause.

Re: Leaving Go

#88

Post by pron »

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.

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

Here's my hypothesis: programming language are made for people to use, and people spending time thinking about designing Watson, don't want to spend it thinking about expressing their program using lambda calculus. The only group for whom the stuff they develop coincides with language concepts are those writing compilers. So they get confused because their domain is the programming language, so they don't feel like they're spending their mind power on two different things. They can't imagine that someone trying to solve a tricky scheduling problem wouldn't want to spend time thinking about types.

The other group that can adopt languages like Haskell are those whose domain doesn't require too much thought: namely CRUD applications. These guys want to spend time thinking about type-driven-design. It might actually make their code quality better. They, too, can't understand why people solving a hard concurrent-data-structure problem wouldn't want to spend time thinking about expressing their ideas elegantly through types.

Both of these groups have one thing in common: expendable energy to spend thinking about programming language concepts. So to them, it seems easy; and it probably is, if you're willing to put some effort into it, which is precisely what many developers don't want to do.

Re: Leaving Go

#89

Post by tptacek »

m0th87 wrote: post #52
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…

You're right, Golang is all about pragmatism, and a very pragmatic thing for language designers to do is to listen to the marketplace on how the language should evolve. Lack of polymorphism must be the most common critique of Golang. It seems pretty practical to add it, as it would greatly reduce the amount of boilerplate. And it's not as if polymorphism is stuck in the ivory tower - languages used in industry have h…

When I wrote that paragraph, I definitely did not think of "pragmatism" as "doing whatever people wanted them to do". Golang is also not Perl. If you're looking for Perl, Golang will disappoint you.

Re: Leaving Go

#90

Post by one-more-minute »

xioxox wrote: post #35
herokusaki wrote: post #20

Earlier quoted context omitted.

Can you elaborate why?

I was interested until I discovered Julia doesn't have a useful form of OOP inheritance. Ok, you don't always need it, but for some things it's indispensable (e.g. using widget/window systems).

That's a bit like saying, for example, Python isn't interesting because it doesn't have monads (and they're essential for managing state, or whatever). Different languages have different ways of doing things, and lacking feature X isn't necessarily a deficiency.

Julia generally favours composition over inheritance. You might be interested to look at GTK.jl, its widget/window system.

https://github.com/JuliaLang/Gtk.jl

Post reply on HN