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

201–210 of 220 posts

Re: Leaving Go

#201

Post by cgh »

personZ wrote: post #194
cgh wrote: post #191

Earlier quoted context omitted.

Except the containers aren't typed. They are essentially containers of void*. If you believe that to be "generic", then you don't understand the topic.

This is simply wrong , and you clearly don't understand Go (which, as we've amply seen, doesn't stop people from pontificating about it).

You are right, I overlooked the magic of Go's build-in containers (I admit, I haven't touched the language after we looked at it around a year ago). I amend my comments to apply to user-defined containers and types, where generic == interface{}...at least, it did when we tried the language out.

This is an example of a simple "generic" in Go, as I recall it:

  type mytype struct {
    mydata interface{}
  }
The casting this requires felt like a step into the past when you're used to eg the STL.

Re: Leaving Go

#202

Post by dragonwriter »

chc wrote: post #200
krick wrote: post #193

Earlier quoted context omitted.

I don't really get what all you guys mean by "boring". I'd appreciate some clarification (especially about Go). What does it mean for language to be "fun"? I have some intuition of "fun", but it doesn't play well with what are you saying. I'd say being "fun" means ability to solve your problems easily, concentrating on problems themselves, not on language pitfalls. Isn't it? That's pretty much synonymous (maybe a lit…

> I don't really get what all you guys mean by "boring". I'd appreciate some clarification (especially about Go). Go offers very little that's interesting or innovative and doesn't go out of its way to empower you in any particular way. It's fairly straightforward and tries to avoid gotchas, which is both good and bad. This means writing code is easy and you're unlikely to make a mess, but there are relatively few op…

> Go offers very little that's interesting or innovative and doesn't go out of its way to empower you in any particular way.

That's true of the features looked at individually. I think its particular combination of design choices is interesting and novel ("innovative" requires a value judgement that I am not quite ready to make in Go's case; though I think the momentum its gained in certain areas is quite likely because it does offer something that is innovative in its utility even if its not immediately apparent why the particular combination of features it provides should be.)

Re: Leaving Go

#203

Post by chc »

dragonwriter wrote: post #202
chc wrote: post #200

Earlier quoted context omitted.

> I don't really get what all you guys mean by "boring". I'd appreciate some clarification (especially about Go). Go offers very little that's interesting or innovative and doesn't go out of its way to empower you in any particular way. It's fairly straightforward and tries to avoid gotchas, which is both good and bad. This means writing code is easy and you're unlikely to make a mess, but there are relatively few op…

> Go offers very little that's interesting or innovative and doesn't go out of its way to empower you in any particular way. That's true of the features looked at individually. I think its particular combination of design choices is interesting and novel ("innovative" requires a value judgement that I am not quite ready to make in Go's case; though I think the momentum its gained in certain areas is quite likely beca…

My feeling is that it's mainly the CSP features and the relatively good speed that make Go stand out despite being "boring." Having such strong concurrency primitives baked into a generally performant language is really cool and makes it the obvious choice for doing large tasks quickly.

Re: Leaving Go

#204

Post by coldtea »

grey-area wrote: post #97
m0th87 wrote: post #52

Earlier quoted context omitted.

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…

They probably will add generics at some point in the future. In the meantime, lots of people are using and enjoying the language as it is. If you want to write generic methods using your own types, you can define an interface to operate on, and then create types which conform (or wrap more basic types to conform) - as this article demonstrates after it sets up a straw man to criticise golang with. I quite like that a…

>In the meantime, lots of people are using and enjoying the language as it is.

I hear that a lot. That's not really an argument. People also enjoy stupid things, including things that hurt them, like drugs.

Re: Leaving Go

#205

Post by grey-area »

coldtea wrote: post #204
grey-area wrote: post #97

Earlier quoted context omitted.

They probably will add generics at some point in the future. In the meantime, lots of people are using and enjoying the language as it is. If you want to write generic methods using your own types, you can define an interface to operate on, and then create types which conform (or wrap more basic types to conform) - as this article demonstrates after it sets up a straw man to criticise golang with. I quite like that a…

> In the meantime, lots of people are using and enjoying the language as it is. I hear that a lot. That's not really an argument. People also enjoy stupid things, including things that hurt them, like drugs.

I hear that a lot. That's not really an argument.

Well, it certainly isn't a convincing argument that it is the best of all possible languages, but it does lend weight to it being worth a look in its current form. Personally, compared to other languages I've been forced to think in (Java, C, C++, ObjC, Ruby), it comes out favourably, but I'm quite happy to accept that some people might think it is stupid, dangerously simple etc, etc. and listen to their reasons why - there's room for more than one language in the world.

Re: Leaving Go

#206

Post by bfrog »

Go's strengths are tooling and libraries. Especially when you see the well written libraries all revolving around internet protocols, encodings, and content generation. It makes it extremely easy to write performant web sites and http API endpoints which many people do daily.

All that said I hope Go adds D like compile time code generation and static typing or [D,Rust] gains better tooling and HTTP service oriented libraries and APIs that are as well written as the Go standard library packages are. Secondly I hope [D,Rust] sees how awesome having a common automatic format, build, and test tool is. In so few language is the testing package as simple as Go's. In so few languages is the build process as easy as Go's.

Re: Leaving Go

#207

Post by monkey26 »

stiff wrote: post #128
tptacek wrote: post #123

Earlier quoted context omitted.

I honestly am not sure I follow what your concern is with that line of code. list.New() looks extremely clean to me.

You frequently have packages that are named after generic nouns, like time, host, file etc. There are many contexts where this same generic name makes for the best variable name: clear, short, and easy to type: func ReadFile(filename String) { file := file.Open(filename) } In Go you have to invent a new name, so invariably you will see a lot of: theFile := file.Open(filename) aFile := file.Open(filename) readFile :=…

I've hit this a few times in Python and it bugged me like crazy. But then I grew up and dealt with it.

Re: Leaving Go

#208

Post by Locke1689 »

pnathan wrote: post #99
pron wrote: post #91

Earlier quoted context omitted.

> Sophisticated programs running sophisticated systems? They exist Not really. Well, far less than in all those horrible, unusable languages. All I'm saying is, if Haskell makes writing correct code so easy, where is it? There should be tons of it now. It should be practically everywhere. In fact, it should be financially stupid to do anything in any language other than Haskell. So where are all the companies making…

You're arguing from perfection. The reality is that most companies choose "fast+cheap" and usually incur significant technical debt which is paid off through throwing bodies at the problem. It is usually considered better to hire 3 people who are mediocre than 1 person who is very skilled. This is extremely well addressed in the software engineering literature going back to the late 60s. It's also the case that softw…

I don't buy this either. If this were true you'd still see, for lack of a better term, the "redis" of Haskell. You can't argue that antirez skimped on development or that he isn't talented enough.

Where is the redis of Haskell? The ffmpeg of ML? There's something else at play here.

Re: Leaving Go

#209

Post by mseepgood »

chc wrote: post #145
mseepgood wrote: post #137

Earlier quoted context omitted.

REPLs are for toying around and learning. The Go playground provides an alternative that seems to satisfy these needs for most people. If people really missed a Go REPL then the existing ones would not be "curiosities".

People use REPLs for more than "toying around and learning." They can be very useful both for exploratory programming (which is different from toying around in that you're actually trying to accomplish something) and debugging. It seems more likely to me that Go doesn't have a good REPL because Go just isn't very amenable to general-purpose REPLs, which is the same reason C REPLs tend to be more trouble than they're…

> People use REPLs for more than "toying around and learning."

In all those years of Scheme, Ruby, Python, Haskell, Scala I have never used REPLs for anything other than tutorials or trying out something quickly.

> that Go doesn't have a good REPL

What makes you think that the Go REPL is not a good REPL? Have you actually tried it? Probably not, because you do not care as much about REPLs as you think do.

Re: Leaving Go

#210

Post by lispm »

nostrademons wrote: post #102
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.

It's not a good thing - for production software - for a language to be too much fun to use. It means that developers spend all their time using the language and not enough time solving problems . The suckiness of Java/C# tends to encourage people to solve their problem and move on quickly to the next problem, because it's honestly not much fun trying to extend the language or build abstractions. Haskell & Lisp progra…

You get the hacky Lisp version in 15 minutes.
Post reply on HN