Seven years of Go • Hacker News Board

Re: Seven years of Go

#231

Post by Matthias247 » Thu, Nov 10, 2016, 9:48 PM UTC

dilap wrote: post #192

Matthias247 wrote: post #110

Earlier quoted context omitted.

IMHO Go is a good choice for lots of system daemons and commandline tools. If networking is involved it shines even more. > 7 years without proper penetration into the GUI market seems odd, unless it is aimed elsewhere? You could apply this criticism to nearly all languags, as there are currently only very few that are used for native GUIs: C and C++, because the operating systems and native toolkits are written in t…

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.

Re: Seven years of Go

#232

Post by weberc2 » Thu, Nov 10, 2016, 9:50 PM UTC

pcwalton wrote: post #200

weberc2 wrote: post #184

Earlier quoted context omitted.

> Package management. Macros (Rust has a widely used ORM). Generics. Easier error handling. Pattern matching. Functional features, such as map(). A more flexible module system. Built-in FFI. Inline assembly. Etc, etc Package management and easier error handling are the only ones that doesn't roll up into safety or performance, and I dispute that Rust's error handling is easier than Go's. > I'm going to push back on t…

> Package management and easier error handling are the only ones that doesn't roll up into safety or performance, and I dispute that Rust's error handling is easier than Go's. Generics, pattern matching, functional features, modules, easy FFI, are productivity features! They have nothing to do with safety and performance (although they are incidentally used to implement some speed/safety features, because why not). I…

> Generics, pattern matching, functional features, modules, easy FFI, are productivity features! They have nothing to do with safety and performance

I dispute that these features improve productivity. With the exception of modules (whose purpose has always eluded me) all are available in Go (or could be trivially implemented) at the expense of safety and/or performance.

> I suspect the numbers are like: 95% of applications are best in scripting languages. 4% are best in managed languages (Java, C#, Go, etc.). 1% are best in low-level languages like Rust. If you want me to concede that point, fine.

I disagree. I think that Go beats scripting languages at their own game, in most cases. Of course this is all opinion and mine is no more valid than yours.

> But in terms of importance of projects, which correlates with the number of developers you need on the project, the numbers look very different.

Perhaps, but I'm not sure what your point is here, or how it relates to the broader topic. Are you arguing that more developers are needed on the project and thus more developers in total work on these core libraries than all other software projects?

Re: Seven years of Go

#233

Post by Manishearth » Thu, Nov 10, 2016, 9:53 PM UTC

weberc2 wrote: post #173

dbaupp wrote: post #155

Earlier quoted context omitted.

That approach has its own problems, such as wasting memory (need to store any data for each tag value separately, rather than benefiting from overlapping storage ala Rust enums or C tagged unions), as well as losing type safety: one has to manually remember which (groups of) fields correspond to which tag values (although the Go loss of type safety is far better/more controlled than the one for C tagged unions). Usin…

> such as wasting memory Granted, but I'll happily trade a few bytes of stack for zero allocs in many cases. > rather than benefiting from overlapping storage ala Rust enums or C tagged unions Of course, but we don't have those in Go, do we? > as well as losing type safety Tagged structs are not meaningfully less type safe than interfaces. > one has to manually remember which (groups of) fields correspond to which ta…

> Tagged structs are not meaningfully less type safe than interfaces.

Of course they are. What if you read from or write to the wrong field?

> Use an enum for the tag

Your example has one contained type per variant. In Rust it is common to have an enum like

    enum Foo {
      Variant1(String, u8, Vec),
      Variant2(u8),
      Variant3(String),
      Variant4(f32),
      Variant6(f32)
      Variant5(bool, bool, String)
   }

Naming tags for something like this would be hard. Some of the fields would be shared between variants. Some would not.

Re: Seven years of Go

#234

Post by randomdata » Thu, Nov 10, 2016, 9:53 PM UTC

keymone wrote: post #115

jamescun wrote: post #81

Earlier quoted context omitted.

This is a conscious decision. I believe the reasoning was readability. Ternary operators have a habit of being used in some really nasty nesting. https://golang.org/doc/faq#Does_Go_have_a_ternary_form

a = flag ? b : c is much more readable and concise than if flag { a = b } else { a = c } battling habits by making useful code inconvenient is just sad

But even the else keyword itself is reserved for special occasions in Go. The thing about the language is that if something seems awkward (which I agree your example is), you have to ask if you are expressing it that way only because that is what you would do in other languages, or if there is a Go way to express it? More often than not, there is a better way to express it.

The code you gave serves no purpose, so it is difficult to see how it fits into the larger context of a real application, but it may be possible that you don't need an if/else statement like this at all.

Re: Seven years of Go

#235

Post by lomnakkus » Thu, Nov 10, 2016, 9:53 PM UTC

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.

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 program can do and thus actually restrict the set of valid programs which will still satisfy the type checker. This is used to great effect in e.g. ML or Haskell and can be used somewhat effectively in Java/Scala code with subtype bounds. Of course in Haskell, being a language from the 1990s[2], you can use this to effectively restrict the types of effects used by any given function (database I/O, arbitrary I/O, networking, etc.).

[1] https://en.wiktionary.org/wiki/deepity#English

[2] Ok, this is slightly exaggerated since monads-for-IO were discovered quite a bit after 1990, but still... parametric polymorphism is crucial for this use case.

Re: Seven years of Go

#236

Post by stcredzero » Thu, Nov 10, 2016, 9:55 PM UTC

aikah wrote: post #168

stcredzero wrote: post #138

Earlier quoted context omitted.

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…

> If you're such a poor programmer, No need for personal attacks. > then just find a different language. What a warm an welcoming community the Go community is /s C++ doesn't have reflection, because it doesn't need it. But somehow Go needs it ? Reflection is a cop-out, especially in a language that has a simplistic type system. And don't get me started on struct tags. If you cant see the obvious issue with all these…

What a warm an welcoming community the Go community is /s

I have to say, I've had the "warm an welcoming /s" from the Go community myself. I'll give you a hint: You can also get the same from Smalltalk if you complain that a method can't have more than 256 temporary variables, and that this means Smalltalk isn't a real language. (How that demonstrates cluelessness is left as an exercise.) Annoying Dunning-Kruger crap that would only be clever and well informed if posted as a deliberate troll -- I leave that to you for what sort of welcome one should expect.

I'll also note that you are "copping out" by responding to exactly zero of my arguments and deflecting attention instead. Probably because you can't.

Reflection is a cop-out, especially in a language that has a simplistic type system.

Says who? This could just as well apply to Smalltalk. If you're pedantic about it, you could even say Smalltalk-80 is a strongly typed compiled language. Reflection is just another tool that has trade-offs and potential problems like any number of programming language tools. And if you said it was a language design "smell" you'd be right. But to a dedicated practitioner, no programming language is free of those.

Re: Seven years of Go

#237

Post by detaro » Thu, Nov 10, 2016, 9:55 PM UTC

stcredzero wrote: post #224

detaro wrote: post #178

Earlier quoted context omitted.

Can you give examples, assuming you are referring to patterns that still are somewhat common? I've seen a bunch of somewhat-connected Singletons used as enums with extra functionality in Smalltalk, is that the kind of thing you were thinking of?

Most of the times we couldn't do the refactorings/changes we wanted to, it was because we could only be 99.9% sure and not 100% sure someone didn't stick some goofy value somewhere to denote something special. Also, I'm not so sure that Smalltalk as a language community and as a programming environment did what it took to get everyone to do the right thing. In Swift, it seems like the programmer would quickly learn t…

Interesting point about refactoring and "doing the right thing", didn't think about that angle, thanks for the reply!

Re: Seven years of Go

#238

Post by pcwalton » Thu, Nov 10, 2016, 9:56 PM UTC

stcredzero wrote: post #226

pcwalton wrote: post #180

Earlier quoted context omitted.

I've also worked on codebases that have overused the && operator. Should we remove that in favor of nested if?

Only if the cost-benefit works out, and there isn't a better solution.

And that's clearly the case with generics.

Re: Seven years of Go

#239

Post by pcwalton » Thu, Nov 10, 2016, 9:57 PM UTC

weberc2 wrote: post #232

pcwalton wrote: post #200

Earlier quoted context omitted.

> Package management and easier error handling are the only ones that doesn't roll up into safety or performance, and I dispute that Rust's error handling is easier than Go's. Generics, pattern matching, functional features, modules, easy FFI, are productivity features! They have nothing to do with safety and performance (although they are incidentally used to implement some speed/safety features, because why not). I…

> Generics, pattern matching, functional features, modules, easy FFI, are productivity features! They have nothing to do with safety and performance I dispute that these features improve productivity. With the exception of modules (whose purpose has always eluded me) all are available in Go (or could be trivially implemented) at the expense of safety and/or performance. > I suspect the numbers are like: 95% of applic…

> I dispute that these features improve productivity. With the exception of modules (whose purpose has always eluded me) all are available in Go (or could be trivially implemented) at the expense of safety and/or performance.

OK. How do you implement array.map() in Golang?

Re: Seven years of Go

#240

Post by weberc2 » Thu, Nov 10, 2016, 9:57 PM UTC

pjmlp wrote: post #230

weberc2 wrote: post #190

Earlier quoted context omitted.

Right, but this is still a far cry from Go's runtime/scheduler. In particular, the Go runtime completely handles threading and async I/O for me. I'm not sure what C++17 coroutines look like, but I don't even have to explicitly yield (which is the case in other C++ coroutine libraries).

Just like any other async/await model. Also you don't need explicit yield on task runtimes like HPX.

> Just like any other async/await model.

I don't see how Go bears any resemblance to an async/await model. Did I misinterpret your statement?

> Also you don't need explicit yield on task runtimes like HPX.

I don't dispute that it's hypothetically possible to bolt enough things onto C++ to make it behave like Go, but I seriously doubt it's a viable solution. I would sincerely love to know if anyone has done all of this and is using it in production.