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

Toward Go 2

blog.golang.org

Post reply on HN
Print view View original

621–630 of 670 posts

Re: Toward Go 2

#621

Post by mmargerum »

jcadam wrote: post #81
bad_user wrote: post #48

Java`s generics have had issues due to use site variance, plus the language isn't expressive enough, leading its users into a corner where they start wishing for reified generics (although arguably it's a case of missing the forest from the trees). But even so, even with all the shortcomings, once Java 5 was released people migrated to usage of generics, even if generics in Java are totally optional by design. My gue…

After some initial enthusiasm due to its gentle learning curve (actually, the Golang learning curve is nearly non-existent for an experienced programmer), I got sick of Go programming pretty quickly. Writing anything non-trivial will have you fighting against the limitations of the language (e.g., lack of generics which is particularly aggravating when trying to write a library). I've mostly moved on to Clojure for p…

Similar background here, but I found Go refreshingly liberating because everything in the language makes sense and there isn't a lot of magic going on. I might write a bit more code but its crystal clear how it works and more importantly I can come back in 6 months and grok the code. In face, this is the first language i've used in 25 years of coding where I can read anyones code and grok it. go fmt might be the best part of go.

Re: Toward Go 2

#622

Post by ufo »

willtim wrote: post #605
ufo wrote: post #590

Earlier quoted context omitted.

> I do concede that there is probably a definition of the term "gradual typing" out there that I am not strictly adhering to. The basic goal of gradual typing is that you can have your program be fully untyped or fully typed or somewhere in between and it will behave in a sensibly in all cases. Adding types to a program does not change the result of the program, except that sometimes adding types may cause new type e…

Thanks for the references. It looks like "gradual typing" is about trying to retrofit types to dynamic languages. That is certainly harder than starting with a statically-typed system and adding dynamic types (my preference). The latter clearly works, as evidenced by e.g. C# and Dart 2. > With this restriction, you cannot assign an accurate static type to a function with a dynamically typed implementation, which mean…

Indeed, gradual typing and optional typing are more along the line of adding types to a dynamic language. The kind of dynamic typing you were talking about looks more similar to the Haskell's Data.Dynamic type or the "dynamic" type in C#. It works great to add some dynamicity to the language (for example, to interoperate with a dynamic API, or to code metaprogrammey stuff like reflection and serialization) but you can't use this to bridge the full continuum between static typing and dynamic typing, which is the design space that languages like Dart and Typescript are trying to tackle.

> It depends what you mean by an accurate type.

The gradual typing literature tends to prefer having partial functions (that might raise well-behaved type errors at runtime) because it eases the transition between typed and untyped programs. You can add or remove type annotations without having to simultaneously add and remove tons of explicit pattern matches against Maybe. But this isn't the part I was talking about.

The key issue is that when you cast a function from (Variant->Variant) to (Int->Maybe Int) you need to add a small wrapper around the dynamic function that converts the input from Int to Variant and converts the output from Variant to Maybe Int. In theory it is simple but in practice all those wrappers can add up really quickly...

Functions are the simplest case where these higher-order type-conversion issues pop up but in my experience things are actually the most thorny when it comes to mutable objects and arrays. The extra type checks and conversions around every property read and write can add a ton of overhead. And from a semantics point of view you need to be careful because if your implementation is based around wrappers it could end up messing with object identity (like Javascript's === operator or Python's "is")

Re: Toward Go 2

#623

Post by mmargerum »

rbehrends wrote: post #316
didibus wrote: post #177

I get that everyone would love to have a functional language that's eager by default with optional lazy constructs, great polymorphism, statically typed with inference, generics, great concurrency story, an efficient GC, that compiles quickly to self contained binaries with simple and effective tooling which takes only seconds to setup while giving you perfomance that equals java and can rival C, with a low memory fo…

Honestly, no. For starters, I don't want a functional language (at least not a purely functional one). Purely functional programming has some distinct downsides. My preferences are firmly on the multiparadigm side, and I'm perfectly happy with a reasonable imperative language (that still supports higher-order functions and closures). What I'm not happy with is language designers seemingly ignoring the state of the ar…

Sounds like Scala might be what you are looking for if multi paradigm is your thing.

Re: Toward Go 2

#624

Post by mmargerum »

jimjimjim wrote: post #246

Here be Opinions: I hate generics. also, I hate exceptions. Too many people are wanting "magic" in their software. All some people want is to write the "Happy Path" through their code to get some Glory. If it's your pet project to control your toilet with tweets then that's fine. But if it's for a program that will run 24/7 without human intervention then the code had better be plain, filled with the Unhappy Paths an…

So much this. Been doing this for 25 years and I loathe magic like Exceptions. I consider Go's explicit error handling a plus. Any editor would let you code ife to generate the error scaffold.

I don't hate generics, but I don't require them either. If the Go guys can make them work well and fit into the language i'd be fine with it, but I don't want them to feel pressured into throwing something out there for the language purists. I doubt they feel pressured. They've been around the block and have as good a sense as any group i've ever seen for what to include in the language.

Go is not the language to use if you want to write clever code, but it's great when you write code for businesses that must run 24x7.

Re: Toward Go 2

#625

Post by randomdata »

lomnakkus wrote: post #620
randomdata wrote: post #614

Earlier quoted context omitted.

> Phrasing is important, and obviously (from the reactions of me and others in the thread) the phrasing was way off and perceived as condescending and lazy. Maybe, but I don't know that we should be attacking someone's poor communication ability. I'm sure I've misunderstood at least one of your points too. Let's just focus on what was actually asked for: Use-case examples. > OK, so you said they don't need a special…

> There isn't an all encompassing 'generics'. Generics is a broad category of different ways to achieve reusable statements across varying types, in a type-safe manner. To try and draw an analogy, it is kind of like functional and imperative programming. Both achieve the function of providing a way to write programs, but the paradigms differ greatly. Each with their own pros and cons. Yes, thank you. Everybody in thi…

> Yes, thank you. Everybody in this thread already knows that. PICK ONE.

They are picking one, based on the use-cases that will be given to them in the near future. I don't understand what your point is here.

> Since Go is structually typed and has mutable variables, that should be a good indication of what to do and what not to do.

That may be true, but the worst case scenario is that they learn nothing from the examples they get. You don't have to provide any if you feel it is a useless endeavour. If it gives them comfort, so be it.

> And now you're trying to bring imperative vs. functional into this?

It wasn't clear if you understood what I meant by there being different ways to provide generics. I struggled to write it as eloquently as I had hoped and the analogy was meant to bridge what gaps may have existed.

It's almost like communication can be difficult. Where have I see that before? Hmm...

Re: Toward Go 2

#626

Post by mmargerum »

baq wrote: post #322
jimjimjim wrote: post #246

Here be Opinions: I hate generics. also, I hate exceptions. Too many people are wanting "magic" in their software. All some people want is to write the "Happy Path" through their code to get some Glory. If it's your pet project to control your toilet with tweets then that's fine. But if it's for a program that will run 24/7 without human intervention then the code had better be plain, filled with the Unhappy Paths an…

there's nothing magic about generics. every time you make a channel or a map in go, you're using a generic function even if go people don't want you to call it that. there's nothing magic about exceptions, too, it's that it's harder than necessary to use them correctly and that's why it's not as big of a deal to not have them in go - as evidenced by this thread.

I think that's the point really. I think the average programmer like using generics, but rarely builds their own code with them. I've used them from time to time to great effect, but the use cases were pretty isolated. Maybe that makes me average? /shrug

Re: Toward Go 2

#627

Post by mmargerum »

lemoncucumber wrote: post #158

As much as I want them to fix the big things like lack of generics, I hope they fix some of the little things that the compiler doesn't catch but could/should. One that comes to mind is how easy it is to accidentally write: for foo := range(bar) Instead of: for _, foo := range(bar) When you just want to iterate over the contents of a slice and don't care about the indices. Failing to unpack both the index and the val…

I've got caught by this more than once. Again, implicit behavior sucks so I suggest they get rid of the first form.

Re: Toward Go 2

#628

Post by mmargerum »

the_duke wrote: post #166
tschellenbach wrote: post #112

The beauty of Go is that you get developer productivity pretty close to Ruby/Python levels with performance that is similar to Java/C++ Improvements to package management is probably the highest item on my wishlist for Go 2.

There is so much boilerplate you have to write that productivity drops considerably, both because you have to re-re-re-re-implement things (or use code generation) and because you need to scan lot's of redundant code before making sense of it. The alternative is often to just use interface{}, which hurts performance and type safety.

This is countered by having a much smaller footprint for the language / SDK in your brain. I easily write code twice as fast in Go as I do in Swift.

Re: Toward Go 2

#629

Post by vram22 »

fanf2 wrote: post #610
vram22 wrote: post #290

Earlier quoted context omitted.

>The article mentions that Go 1 code needs to be able to coexist with Go 2 in the same codebase. Interesting. Are there any other languages where that is allowed? I'm assuming that by "codebase" you mean all the code that gets compiled into one program or library (for compiled languages), or is part of one program or library (for interpreted languages). And I don't mean the case where only a common subset of Lang X v…

>>>>The article mentions that Go 1 code needs to be able to coexist with Go 2 in the same codebase. >>Interesting. Are there any other languages where that is allowed? C / C++ Perl 5/6 The various language feature pragmas in Haskell.

Interesting, didn't know this about C/C++, though I may have guessed it about Perl.

Re: Toward Go 2

#630

Post by idobai »

mmargerum wrote: post #624
jimjimjim wrote: post #246

Here be Opinions: I hate generics. also, I hate exceptions. Too many people are wanting "magic" in their software. All some people want is to write the "Happy Path" through their code to get some Glory. If it's your pet project to control your toilet with tweets then that's fine. But if it's for a program that will run 24/7 without human intervention then the code had better be plain, filled with the Unhappy Paths an…

So much this. Been doing this for 25 years and I loathe magic like Exceptions. I consider Go's explicit error handling a plus. Any editor would let you code ife to generate the error scaffold. I don't hate generics, but I don't require them either. If the Go guys can make them work well and fit into the language i'd be fine with it, but I don't want them to feel pressured into throwing something out there for the lan…

> If the Go guys can make them work well and fit into the language i'd be fine with it, but I don't want them to feel pressured into throwing something out there for the language purists.

"Purism" in this situation is to deny every useful feature because your compiler developers aren't capable of implementing them.

Post reply on HN