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

391–400 of 670 posts

Re: Toward Go 2

#391

Post by dtech »

elliotmr wrote: post #273
scribu wrote: post #248

Earlier quoted context omitted.

I think the negative attitude comes more from frustration than from anything else. > I am a professional programmer working at a large company and I am pretty sure that 95% of my colleagues (myself included, as difficult as it is for me to admit) have no idea what a reified generic is. I didn't know what it was called either until I saw them mentioned here, but now that I know about it, I get why it would be useful.…

> I don't mean any disrespect, but this is a very good example of the Blub Paradox: http://wiki.c2.com/?BlubParadox Interesting read, and I admit there is some of that. But my point isn't to say that those features aren't useful or powerful, but rather that with the constraint of working with a large group of programmers of varying skills, simplicity has more value than power (as long as we can deliver software that…

One of the problems is who decides what is too simple. E.g. why are for loops, function calls and lamdbas considered simple enough to be in go, but generics aren't? When I TA'ed CS introductory courses, student usually had a lot less trouble with understanding generics than lambdas.

Not including feature X in programming language Y will also ensure that no-one who primarily uses Y will ever come to understand or appreciate X.

The blub paradox basically represents the opinion that it is always better for languages to include more powerful features.

I think that goes too far, working primarily in Scala I am seeing firsthand how much diminishing returns extra complexity in the language can have, but I'm certainly of the opinion that Go leans too heavily toward handicapping the language in pursuit of simplicity.

Re: Toward Go 2

#392

Post by Animats »

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.

Yes, go has generics, or at least parameterized types, used for channels and maps. What it doesn't have are user-defined parameterized types.

Re: Toward Go 2

#393

Post by Sir_Substance »

43224gg252 wrote: post #382
kasey_junk wrote: post #369

Earlier quoted context omitted.

Calling those languages screw ups is one of the funnier things I've seen in awhile.

I know that both Java and C++ have a lot more issues than Golang ever will. I've used all three languages. Java has mile long class hierarchies, massive try-catch blocks, indentation as thick as my neck, and runs in a JVM. It's so bad there are already other implementations that people would much rather use. I also really don't like the file/project naming conventions. C++ is a whole other animal. The whole system of…

>Compared to them Go is a very well thought out and elegant language.

But interestingly, not one I would choose with which to embark on a project that I expected to require more than 2000 lines of code (as a ballpark scale measurement).

Go seems to be an excellent glue language. It's very suitable for making a tool that does /this/ and only /this/, putting it in a docker container and running 500 of it at once, linking other parts of my stack together.

I would never use it to write a RDMS, because (as someone who has admittedly been following the situation only loosely) the language maintainers don't seem interested in solving other-people problems. They seem to be making a language for them, and I can respect and understand that, but it certainly gives me pause to think about using it for anything big. If I run into a problem that Go can't solve, will it be possible to persuade the language developers to give a shit? Situation unclear.

Re: Toward Go 2

#394

Post by ufo »

willtim wrote: post #181
munificent wrote: post #147

Earlier quoted context omitted.

> As a far as I can tell, an "optional type system" is > just an unsound type system with a marketing name. It is a term with a specific meaning. The key bit separating it from both gradual typing and a static type system with a dynamic type (like Scala or C#) is that in an optionally typed language, the type system has zero runtime effect. If you were to take a source file and mechanically strip out all of the type…

> To keep the guarantees you expect inside your typed code, you have to figure out how to handle untyped data that flows into it. This would be solved in a conventional static type system by forcing the user to eliminate the variant, and forcing the user to deal with the case that it has an unexpected value. So I cannot see why even C# dynamic is necessary, except to perhaps save some thinking, but this isn't a good…

The problem munificent was talking about is that for more complex types you cannot write that type checking predicate you want, which would check if a value belongs to the given type and return a variant-free version of the object. For example, if you have a reference to an array of integers in the typed part of the code you need to protect against untyped parts of the code inserting non-integers inside the array. The only solution is to insert typechecks in the reads and/or writes to the array (there is more than one way to do it, with different tradeoffs in expressivity and performance). A similar problem happens with functions: if you try to give a static type to a function with a dynamic implementation you can't just make the check at that point. You also need to insert type checks after every call, to see if the return value has the expected type (and again there is more than one way to do it...)

Re: Toward Go 2

#395

Post by hinkley »

steveklabnik wrote: post #227
weberc2 wrote: post #95

Earlier quoted context omitted.

Why does an ORM need generics? I ask because I've built something very like an ORM in Go and I didn't have any problem without generics. ADTs on the other hand...

The strongest typed ORM I've ever used is http://diesel.rs/ This code (okay I made the use line up because it's not on the website and I'm lazy, you do need one though): use some::stuff::for::the::dsl; let versions = Version::belonging_to(krate) .select(id) .order(num.desc()) .limit(5); let downloads = version_downloads .filter(date.gt(now - 90.days())) .filter(version_id.eq(any(versions))) .order(date) .load:: (&con…

I keep meaning to pick up Rust, still looking for some entry point that's interesting enough to get me off my butt.

How (well) does diesel deal with migrations? I've seen other ORMs fall down the stairs trying to deal with schema modification over time.

Re: Toward Go 2

#396

Post by davidp »

_old_dude_ wrote: post #342
masklinn wrote: post #85

Earlier quoted context omitted.

> Except they seem to focus only on Java, .NET and C++ C# isn't mentioned in any of the previous proposals, only Java, C++ and C.

C# does generics specialization at runtime, hard to do if you have no JIT :)

Thanks for the tip, you made me go google some things! [0]

Do you need a full-on JIT, or just a runtime? [1]

[0]: https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...

[1]: https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...

Re: Toward Go 2

#397

Post by rbehrends »

hota_mazi wrote: post #312
pjmlp wrote: post #282

Earlier quoted context omitted.

With Eiffel tools you got the IDE with interactive development, including a VM for rapid prototyping. Then you would use the AOT compiler (via compilation to C) to produce shippable binaries. So combining the easiness of interactive development with performance when it was time to ship the product. It was also available before Java was a thing. This is what I always kind of missed with Java and .NET, the previous gen…

You seem to imply that Eiffel's solution was superior to Java's but nothing could be further from the truth. The Eiffel compiler required four distinct sequential processes (note: not phases. I really mean that four programs needed to be run in sequence, and each of these four programs implemented who knows how many passes). Eiffel generated C++, huge executables, was incredibly slow (even with contract stuff turned…

> The Eiffel compiler required four distinct sequential processes (note: not phases. I really mean that four programs needed to be run in sequence, and each of these four programs implemented who knows how many passes). Eiffel generated C++, huge executables, was incredibly slow (even with contract stuff turned off).

This was not an inherent problem of the language, but one of the implementation.

I know this because I wrote a compiler for an Eiffel dialect for my Ph.D. thesis and there have been other Eiffel compilers without these shortcomings.

Also, EiffelStudio – which seems to be what you are talking about – generated C code, not C++ and had the option to generate an intermediate representation instead that could be mixed with compiled code.

> It was a very verbose language that implemented all known features under the sun, a bit like Ada and Scala.

It was actually pretty minimalist, not at all like Ada or Scala.

Code was verbose because (1) programmers were encouraged to annotate methods with contracts and (2) exactly because it was minimalist and didn't have a lot of alternative ways of expressing the same functionality.

Edit: There are two hard parts about writing an Eiffel compiler.

1. Getting the semantics of feature renaming during inheritance right. If you aren't careful, it's easy to introduce errors during this step.

2. Doing separate compilation for mutually dependent classes. This is where much of the complexity of the EiffelStudio compiler comes from. Java solved the problem by simply not allowing separate compilation in those cases. If class A has a member of type B and B has a member of type A, they need to be compiled together.

Everything else that's involved in writing an Eiffel compiler does not require more than than what you learn in your typical compiler course. (Though, obviously, experience will get you better results.)

Re: Toward Go 2

#398

Post by lemoncucumber »

mappu wrote: post #295
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…

If `bar` is a slice then the short syntax isn't that useful (although it's shorter than the three-clause for loop equivalent). But if `bar` is a map or a channel, then that short syntax is very handy. For comparison's sake, you don't see many PHP users complaining about the difference between `foreach($bar as $foo)` and `foreach($bar as $_ => $foo)`.

I'd also be fine with it if they switched the ordering of the tuple so that only unpacking one thing gave you the element instead of the index. My point is mainly that the behavior you get currently with a slice is not what you want 9 times out of 10.

Re: Toward Go 2

#399

Post by moogly »

abiox wrote: post #326
nightski wrote: post #203

Earlier quoted context omitted.

Nearly every item on your list is available with OCaml.

it's a bummer that the windows story for ocaml is so sketchy. i'd like to use it for work (various utilities and whatnot) but the ecosystem seems to make a lot of assumptions about the system it runs on. (for me there's still haskell and rust at least.)

How about F#?

Re: Toward Go 2

#400

Post by e12e »

crawshaw wrote: post #5
fusiongyro wrote: post #2

The paragraph I was looking for is this: > For example, I've been examining generics recently, but I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve. As a result, I can't answer a design question like whether to support generic methods, which is to say methods that are parameterized separately from the receiver. If we had a large set of real-world use case…

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?
Post reply on HN