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

651–660 of 670 posts

Re: Toward Go 2

#651

Post by fredmorcos »

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…

> 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 and boring.

You mean like memory and resource management code? Oh wait.. you use a garbage collected language. lol

Re: Toward Go 2

#652

Post by silverlake »

This is a frustratingly common way to design mainstream PLs: "show me the use case". I've seen it firsthand for a number of big PL projects. People are trapped in their little bubble. My approach is to be wildly polyglot, actively searching for good ideas in other languages. Also, I try to write complex code outside the intended domain space and understand why it's harder than it should be.

For example, in Go it's difficult to implement state machines in a clean way. Another is handling events and timeouts is easier with Reactive programming. Distributed programming is easier with Erlang or Akka. Don't wait for problem reports in the Go community. Look at the problems in other PLs and proactively improve Go.

Re: Toward Go 2

#653

Post by weberc2 »

kuschku wrote: post #594
weberc2 wrote: post #579

Earlier quoted context omitted.

This is all very neat, but I think Go could do all of this too, except that "query compile time" would happen on application init or on the first query or some such. Still, very cool and good work to the diesel team!

The whole point of an ideal type system is that if code compiles, it is provably correct and won’t have bugs. Few typesystems come close to that (Coq is one of the few languages where the system might be advanced enough), but generally you want to completely remove entire classes of errors.

I don't disagree, but I also don't see how our comments relate... Are you sure you meant to reply to me?

Re: Toward Go 2

#654

Post by weberc2 »

steveklabnik wrote: post #581
weberc2 wrote: post #579

Earlier quoted context omitted.

This is all very neat, but I think Go could do all of this too, except that "query compile time" would happen on application init or on the first query or some such. Still, very cool and good work to the diesel team!

Sure, and you get runtime errors instead of compile time errors. That's the point.

I understand; I wasn't comparing the languages, only making an observation.

Re: Toward Go 2

#655

Post by kuschku »

weberc2 wrote: post #653
kuschku wrote: post #594

Earlier quoted context omitted.

The whole point of an ideal type system is that if code compiles, it is provably correct and won’t have bugs. Few typesystems come close to that (Coq is one of the few languages where the system might be advanced enough), but generally you want to completely remove entire classes of errors.

I don't disagree, but I also don't see how our comments relate... Are you sure you meant to reply to me?

Yes, because Go couldn’t do all that on compile, which is the entire issue. It can’t prove the type safety of your SQL query at compile time, or the type safety of your generics usage.

Re: Toward Go 2

#656

Post by pjmlp »

e12e wrote: post #400
crawshaw wrote: post #5

Earlier quoted context omitted.

Several members of the Go team have invested significant effort in studying generics and designing proposals, since before Go 1.0. For example, Ian Lance Taylor published several of his previous efforts, which had shortcomings he was dissatisfied with. I believe your impression of the Go team's position has been corrupted (likely unintentionally) by intermediaries.

This made me wonder if there's been efforts to fork golang and add generics as a proof of concept? In theory it should be much easier than a few of the crazy things people have done with c over the years?

It would be an wasted effort given the community's high resistance to them, better spend those hours contributing to a project where users value the work given for free.

Re: Toward Go 2

#657

Post by vram22 »

rbehrends wrote: post #418
vram22 wrote: post #191

Earlier quoted context omitted.

Any thoughts on Eiffel's implementation of generics? https://en.wikipedia.org/wiki/Eiffel_(programming_language)#...

The key difference between Eiffel and Java generics is that Eiffel allows for covariance by design. Obviously, this is unsafe and runtime type checks had to catch these cases. The goal was originally to resolve this through additional static constraints [1], but in the end the downsides always outweighed the benefits. In the end, Eiffel stuck with covariance and a type system that is technically unsound, because the…

I'll check that out, thanks.

Re: Toward Go 2

#658

Post by erikpukinskis »

camus2 wrote: post #440
erikpukinskis wrote: post #323

Earlier quoted context omitted.

This suggests that both generics and inheritance are unnecessary.

And if you look at C you'll see that interfaces and struct methods are also unnecessary, GC is also unnecessary, bound-checked arrays are also unnecessary. The question is, do you want to write type safe code? which is memory safe? which has bound-checked array? or not? Assembly makes all that stuff unnecessary as well. This is not a good argument, especially when Go std lib is getting all these type unsafe API using…

What's unsafe about using one of the C libraries that do bounds checking, etc?

The argument about assembly is a red herring. Let's compare:

1) In addition to writing your business functions, learn these additional control structures to obtain safety

2) When writing your business functions, also use these well reviewed functions that enforce type and memory safety when moving code across interfaces.

3) Port all of your code to assembly, write you own memory safety control structures from scratch.

You see the difference? The choice in your mind between "add control structures to the language" and "do everything painstakingly by hand" but we are advocating a third option, which is: use well reviewed libraries written with only the basic control structures.

The reason I am advocating that is the more control structures you have the harder it is to analyze code. You end up slowly moving your codebase to a point where only people with deep deep knowledge of an advanced programming language can read it.

I think culturally, in 2017, programmers underestimamte how much can be done with just functions and literals and well written helpers.

The reason for that is we are rewarded (psychologically and professionally) for learning new control structures, but not as often for writing better code using the beginner structures.

Re: Toward Go 2

#659

Post by likeclockwork »

thibran wrote: post #139

I would love to see uniform-function-call-syntax. Turning: func (f Foo) name() string Into: func name(f Foo) string Callable like this: f.name() or name(f) Extending foreign structs from another package should be possible too, just without access to private fields. Other than that, if-as-expression would be nice to have, too.

One of my favorite features of D.

Re: Toward Go 2

#660

Post by grogenaut »

steveklabnik wrote: post #587
grogenaut wrote: post #424

Earlier quoted context omitted.

My point is... "Pattern matching correctly"... assumes no mistakes on the coder's part. Go back and re-read my comment. Or don't. Downvote me because I dare question your skill in the context of the mighty erlang.

You can't downvote people who reply to you on Hacker News, so that scenario isn't possible.

Sure you can. You only need two accounts. Which a lot of people have for work posting or other reasons. I don't but I know folks who do.
Post reply on HN