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

61–70 of 220 posts

Re: Leaving Go

#61

Post by coolsunglasses »

protomyth wrote: post #59
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…

"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." Sounds like he is looking for Forth or one of its decedents (e.g. Factor). That is pretty much the definition of how you do Forth development.

Bottom-up style works well for this ex-Lisper using Haskell.

Re: Leaving Go

#62

Post by pron »

pnathan wrote: post #46
Locke1689 wrote: post #41

Earlier quoted context omitted.

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.

> and then we're sitting in the same horrible morass we live in today

But you see, this is the claim that requires substantial evidence. Let's assume we're in a mess. If Haskell is one way out of it, as some people claim, why won't they show us the way? They've had more than 20 years to do it. There are enough Haskell developers out there to give us this pesky evidence we need. And yet we've seen absolutely none. There are way more impressive BASIC programs out there than Haskell programs. I think that there are two reasons for that: 1) People involved in PL research are less interested in programs that aren't compilers, and 2) languages like Haskell make certain tradeoffs that their designers fail to see, and as a result their advantages fall way short of the claims they make.

Re: Leaving Go

#64

Post by giovannibajo1 »

coherentpony wrote: post #11
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…

>The thing is that GO was designed to replace c++ thing that absolutely failed. I was so excited for GO to become a nice replacement to C++. GO has awesome build times. C++ has awful build times. This is partly due to all the extra work the C preprocessor has to do make sure all the headers are present. The big lose for me is the fact that GO has absolutely no operator overloading. This is one of the biggest wins in…

Go is also easy to parse, AFAICT, both syntactically and semantically, and they ship a parser in the standard library.

While absolutely not implying that it's a reasonable alternative, someone could try implementing infix operators as a syntactic layer on top of Go (kind of a preprocessor). It might work to fix the use case presented in the OP (math operators being far more readable in their infix form).

Infix operators might just be implemented as a syntactic sugar layer after all, at least as a first draft; if you're able to parse a Go source file and its types in a way that when you see a sum expression, you already know whether both arguments implement a Numeric interface and/or Add method, you might be halfway through.

To clarify: I love infix operators and I'd love if Go added them, and I consider the above just a hack.

Re: Leaving Go

#65

Post by camus2 »

taylorlapeyre wrote: post #8

I just wanted to point out that the author of this article is a high school student. http://jozefg.bitbucket.org/about.html

How does it make the OP less relevant? i know pretty smart programmers that are still in high school. And tt doesnt matter, the guy obviously knows Go.

Re: Leaving Go

#66

Post by astine »

Dewie wrote: post #22
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…

Maybe it turns out that the sociological side of programming trumps the technical side; that languages that forces or fosters a common vocabulary will always "win" over languages where you have so much power that you can easily diverge from the mainstream dialect, and there is not much culture of restraining this freedom. On the other hand, these dialects are embedded DSLs; specialized languages created and hosted by…

I think that part of the problem is that more 'powerful' languages often more concept heavy than more 'pragmatic' languages and that makes them harder to learn for a lot of programmers.

Take Clojure for example. A lot of people including myself like this language a lot, but to be productive in it, you have to get used to the JVM, Lisp s-expressions, a heavily functional programming style with few side effects, a significant break from a normal approach to OOP, and Clojure's distinctive concurrency constructs which are more complex than Go's. It's not that any one of these things is hard, but you have to know all of them. Unless you have Lisp, or Haskell (or similar) experience, the only one you're likely to know is the JVM, and even then, maybe not.

This isn't like C++ or Java which are huge languages with a lot to wrap your head around but at core simply reuse concepts that most programmers are familiar with, (OOP, basic types) It's the very things that make the language interesting to begin with that makes it trickier to pick up.

Most of this holds for Haskell, Erlang, etc.

Then again, real code is written in these languages, but they don't tend to dominate.

Re: Leaving Go

#68

Post by leccine »

It is so funny to see that somebody else got annoyed by Go the same way as I did. I could not get over the fact that I cant pass any type to a function other than interface{}. When you do that it just delays the problem and I have decided to not have a generic function but have multiple specific one. This violates the DRY principle but at least works. I am still looking for best practices with Go. I think the biggest advantage of that languages is the fact that Goole uses it in production and the libraries are well tested. The community is great too. Clojure has a way smaller community that limits the usage of that environment quite a bit. I agree with the author on Lisp is being more fun than Go, but that is a single dimension of the entire problem.

Re: Leaving Go

#69

Post by bsg75 »

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.

> Haskell is really interesting, but C# developers get shit done. > I'm not sure what the cause is, but it definitely gnaws at me.

Stuff that people are willing to pay for, which can be a very important concept for many (if not most) of us.

Re: Leaving Go

#70

Post by mseepgood »

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…

> languages used in industry have had them for decades

If languages used in industry have had something for decades it does not automatically mean that it's a good idea. Go reconsiders a couple of things that once were thought to be good ideas like class inheritance, exceptions, generics and questions their net benefits.

Post reply on HN