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

Seven years of Go

blog.golang.org

Post reply on HN
Print view View original

281–290 of 318 posts

Re: Seven years of Go

#281

Post by dilap »

Matthias247 wrote: post #231
dilap wrote: post #192

Earlier quoted context omitted.

objc is a huge one! most iphone apps. increasingly, swift too. there's some python stuff. the original bittorrent client. i did a couple apps using PyQt and python -- not an experience i would want to repeat, though.

Yeah, objc is. However mentally I counted that towards the OS languages and C family languages. Swift also belongs to the OS (first class langauge) category, although it's certainly not in the C family. For others maybe Delphi was succesful in the GUI domain. But in the last years it was certainly not often mentioned. For GTK there's also Vala, which was probably even designed to be used for GUIs.

Oh yes, it's very much a an "os language". But an important one to include in your list, I felt!

Objc is certainly C-derived, but it's also just as much smalltalk-derived. Definitely a very different beast than plain C (more so even than C++, I would say).

Re: Seven years of Go

#282

Post by cyphar »

chmike wrote: post #139
AsyncAwait wrote: post #106

Earlier quoted context omitted.

> strikes the right balance for me between productivity and safety. Would be curious to hear what "safety" you're referring to, is it just that it has a basic static type system, (which is constantly being undermined by interface{} and reflection), or is there more to it? Genuinely curious.

Compared to C it is safer. I never saw a segmentation fault, only some panic errors with bound checking. I prefer go to python or javascipt. It's far too easy to make errors in them. Minimal static code checking.

I have seen segfaults in Go. But that's what I get for using gcc-go.

Re: Seven years of Go

#283

Post by coldtea »

defgeneric wrote: post #133
aikah wrote: post #50

Earlier quoted context omitted.

> Many of the "old" ways of thinking do not apply to Go Whatever. Just because the language is effectively broken doesn't make practices in other languages irrelevant. And it's funny when you talk about the "old" ways of thinking in language that basically promotes C styles errors and bad macros through go gen. When I say the language is broken, look at Go type system, then look at how Go reflection makes the languag…

While I'd like to have generics in go, one of the upsides of the lack of generics is that your code becomes less idiosyncratic and more idiomatic. Too often in C++ for example, I find myself frustrated reading code where templates are unintentionally over-used because the programmer needlessly introduced an abstraction where the concrete would have sufficed. There is a certain pleasure in moving from the concrete to…

>While I'd like to have generics in go, one of the upsides of the lack of generics is that your code becomes less idiosyncratic and more idiomatic.

Idiomatic is only good if the idioms are good. Historically for lots of languages, and I would include Go there, the prevalent idioms were crap.

E.g. Java circa 2000-2007 and the J2EE factory-singleton-factory-proxy-singleton-XML crapfest.

Or PHP and the "devil may care" attitude of pre-Composer PHP codebases (including big ones like Wordpress).

Or the tons of broken ways of working with Javascript until the community regained some sanity in the last 5-6 years.

Re: Seven years of Go

#284

Post by coldtea »

stcredzero wrote: post #138
aikah wrote: post #50

Earlier quoted context omitted.

> Many of the "old" ways of thinking do not apply to Go Whatever. Just because the language is effectively broken doesn't make practices in other languages irrelevant. And it's funny when you talk about the "old" ways of thinking in language that basically promotes C styles errors and bad macros through go gen. When I say the language is broken, look at Go type system, then look at how Go reflection makes the languag…

Whatever. Just because the language is effectively broken doesn't make practices in other languages irrelevant. Classic. All languages stink, somewhere. The classic programmer Dunning-Kruger mistake: evaluating one language without self-awareness of all of the (probably unconscious) cost/benefit optimizations that mostly apply to the other language. This is like Smalltalkers and C++ programmers in the 90's arguing ab…

>Classic. All languages stink, somewhere.

Which, as information is content-less.

All languages might stink "somewhere", but there are absolutely better and worse languages, and it's not just a matter of different tradeoffs.

You can give 10 language writers a set of the same tradeoffs to strive for, even hand them in order: it doesn't mean that the 10 resulting languages will be of the same quality.

Re: Seven years of Go

#285

Post by pjmlp »

weberc2 wrote: post #263
pjmlp wrote: post #261

Earlier quoted context omitted.

Async/await model is nothing more than a state machine over coroutine. Goroutines are coroutines. On the async/await model there are two approaches. 1 - The compiler takes care of the scheduling of the coroutines among the threads on the task pool, like C# 5.0 introduced. 2 - The compiler maps async/await into intrisics that know magic functions on the handles that represent tasks managed by the thread pool. This is…

> Goroutines are coroutines. Traditionally, "coroutine" has been used to refer to a userspace concurrency unit that is not multiplexed and which requires explicit yielding. Mostly I'm grumpy about broadening a previously precise definition. > So while one must restrict ourselves with the co-routine scheduler provided by the Go runtime and to the yield points managed by it, with generalized async/await it is possible…

So what would you call coroutines that multiplex at API calls like NT fibers, or many green threads libraries.

Or for that matter, coroutines on Active Oberon, which are just multiplexed as in Go.

Re: Seven years of Go

#286

Post by ithkuil »

candiodari wrote: post #268
_ph_ wrote: post #213

Earlier quoted context omitted.

Very few Go supporters would say that generics are unnecessary, especially not the development team. But they are not required at any price and so far no good solution for implementing them has been found. So they are delayed until that day. While I miss them certainly, I strongly prefer them being absent to a bad and complex/confusing implementation.

But the problems go further. The go type system is littered with exceptions. Why ? Because append, make, maps, channels in for loops, channels in while loops, ... all have their own specific entries in the type system. Go has generics ... but only for the core team. Go has polymorphism (there are polymorphic functions, all of which BEHAVE differently in the type system), there are return type polymorphic functions (f…

I found the https://github.com/juju/errors library to be a very practical way to include tracing info in the error values.

I wish the core error library behaved like that, and that the core language made it less verbose.

This is a typical thing in Go: the language is kept stable and backward compatibility is king. Solutions for some things are left to the community.

Other languages changed a lot over the years, getting better but frustrating people because of breaking changes. I believe this promise of stability paved the way for much of Go's success, despite many shortcomings

Re: Seven years of Go

#287

Post by agnivade »

fizzbatter wrote: post #8

So, i was a Go developer for ~4 years, then for the last 4 months or so i've been learning and using Rust. The pure joy of some things with Rust was astounding. Now, i joined a new job and they're in need of a new language for some backend tasks - the choice was mine. Rust or Go? The backend tasks were heavy API servers - nothing amazing, we don't do groundbreaking work. Python was their existing language, but they w…

> 3. Package management.

This is being taken care of. A package management committee has been formed and they will come up with a prototype tool in Go 1.8. https://docs.google.com/document/d/1qnmjwfMmvSCDaY4jxPmLAcca...

> 4. Enums.

Doesn't the iota identifier solve it for you ? It pretty much covers all my enum use cases.

Re: Seven years of Go

#288

Post by chmike »

AsyncAwait wrote: post #188
chmike wrote: post #139

Earlier quoted context omitted.

Compared to C it is safer. I never saw a segmentation fault, only some panic errors with bound checking. I prefer go to python or javascipt. It's far too easy to make errors in them. Minimal static code checking.

> compared to C it is safer. I never saw a segmentation fault Well, yeah, it has a GC so it kind of gets that "automatically", I was thinking more about the type system side of things. And compared to C almost anything is indeed safer. > I prefer go to python or javascipt. It's far too easy to make errors in them. That's fair, but these are both dynamic languages, so almost anything with any level of static typing be…

Not only static typing. I just found a bug in an open source python tool that crashed because of a missing member variable in a class. You have to assign a value in the attribute to create it. It requires careful programming to not get such errors. It is also easy to accidentaly create a member variable.

The time you gain by being able to hack some code together is lost by these types of error unless you are a very disciplined programmer.

Another kind of error with python is with blocks defined by vertical alignment. It is easy to make errors when you copy past code and the alignment is not corrected.

When you are under pressure or tired, your discipline may weaken. And this is difficult for inexperienced programmers.

You don't have these problems with go and the normalized formating helps a lot.

Re: Seven years of Go

#289

Post by chmike »

takeda wrote: post #189
chmike wrote: post #139

Earlier quoted context omitted.

Compared to C it is safer. I never saw a segmentation fault, only some panic errors with bound checking. I prefer go to python or javascipt. It's far too easy to make errors in them. Minimal static code checking.

Comparing Go to C is like comparing C to assembly. You get segfaults because C is lower level and allows you to do things that are nearly impossible to do in higher level languages. Better comparison is to compare Go to Java, also doesn't segfault, because it doesn't let you.

Since Go has pointers and Java doesn't. I thus expect Java to be safer than go. However, I don't know why but I don't like programming in Java. It's too verbose probably. I also prefer Go because it is closer to the metal and it's a very simple language.

Re: Seven years of Go

#290

Post by defgeneric »

lomnakkus wrote: post #235
defgeneric wrote: post #133

Earlier quoted context omitted.

While I'd like to have generics in go, one of the upsides of the lack of generics is that your code becomes less idiosyncratic and more idiomatic. Too often in C++ for example, I find myself frustrated reading code where templates are unintentionally over-used because the programmer needlessly introduced an abstraction where the concrete would have sufficed. There is a certain pleasure in moving from the concrete to…

> While I'd like to have generics in go, one of the upsides of the lack of generics is that your code becomes less idiosyncratic and more idiomatic. That sounds like a deepity[1] if ever I've heard one. Just to add something a little more substantive: It may not be obvious at first sight (esp. in e.g. C++ or Java), but 'generics'/'parametric polymorphism' can actually incredibly powerful at restricting what your prog…

> That sounds like a deepity[1] if ever I've heard one.

Your code becomes less peculiar to you and more in line with the peculiarities of the language as it's used by most people.

Shallow enough? Don't let an allergy to postmodernism become an allergy to a turned phrase.

Not sure what the rest of your comment has to do with my point, which was about, if you like, the pragmatics of programming.

Not concerned with the space of programs that type check. Insufferable haskellers...

Post reply on HN