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

541–550 of 670 posts

Re: Toward Go 2

#541

Post by XorNot »

devit wrote: post #287
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…

Rust is probably what you are looking for. > a functional language Has closures. Has pattern matching. Has algebraic data types (however variants can't have generic parameters not present on the data type itself, but you can use trait objects to do that). Functions that don't take &mut parameters, & parameters with types with interior mutability and don't call functions that do I/O are pure (although they may not ter…

How do you get self-contained binaries with Rust? There's a lot of talk but I've not found a definitive "produces a static library" build guide.

Re: Toward Go 2

#542

Post by coldtea »

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).*

That sounds like unrelated to the semantics of the language.

Re: Toward Go 2

#543

Post by coldtea »

spyspy wrote: post #426
vec wrote: post #291

Earlier quoted context omitted.

I'm not even a Go developer, I just played with it a bit a couple of years ago and used it for a small one-off internal API thing, and I can think of a dozen real-world use cases for generics off the top of my head. * type-safe containers (linked lists, trees, etc.) * higher order functions (map, reduce, filter, etc.) * database adapters (i.e. something like `sql.NullColumn ` instead of half a dozen variations on `sq…

It's generally the opinion of the Go community that map, reduce and filter are bad ideas due to how easily they are abused. A for loop gets the job done easily enough. If you've ever worked with data scientists working with Python, you'll quite often see them all chained together, probably with some other list comprehensions thrown in until it becomes one incomprehensible line.

>It's generally the opinion of the Go community that map, reduce and filter are bad ideas due to how easily they are abused.

How easily are they abused?

Because it's the opinion of the programming community, including the brightest programmers out there, that FP, and map, reduce and filter are totally fine and dandy.

Re: Toward Go 2

#544

Post by johncolanduoni »

XorNot wrote: post #541
devit wrote: post #287

Earlier quoted context omitted.

Rust is probably what you are looking for. > a functional language Has closures. Has pattern matching. Has algebraic data types (however variants can't have generic parameters not present on the data type itself, but you can use trait objects to do that). Functions that don't take &mut parameters, & parameters with types with interior mutability and don't call functions that do I/O are pure (although they may not ter…

How do you get self-contained binaries with Rust? There's a lot of talk but I've not found a definitive "produces a static library" build guide.

They're the default, even when you include 100+ packages via Cargo. The only issue I've faced is standard Linux cross-distro issues due to libc versions. Even most of the crates that handle bindings to C libraries link them statically by default.

Re: Toward Go 2

#545

Post by coldtea »

jpttsn wrote: post #527
runeks wrote: post #520

Earlier quoted context omitted.

> If you've ever worked with data scientists working with Python, you'll quite often see them all chained together, probably with some other list comprehensions thrown in until it becomes one incomprehensible line. It's not incomprehensible, it's just phrased a different way from what you're used to. A lot of programming boils down to mutating local or global state, by executing lines of code -- each of which mutatin…

> It's not incomprehensible, it's just phrased a different way from what you're used to. What would be incomprehensible?

Code that's badly written.

As opposed to code that just uses chained map, reduce etc as opposed to nested or sequential for loops.

One is a difference is skill, clarity etc, the other is a difference in style (imperative vs fp).

Re: Toward Go 2

#546

Post by johncolanduoni »

akavel wrote: post #534
zackmorris wrote: post #214

Go doesn't have const structs, maps or other objects: https://stackoverflow.com/questions/43368604/constant-struct... https://stackoverflow.com/questions/18342195/how-to-declare-... This is a remarkable oversight which makes it impossible to write purely-functional code with Go. We also see this same problem in most other imperative languages, with organizations going to great lengths to emulate const data: https://f…

I believe part of the reason was also some experience with C++, in which you sometimes have to "unconst" some fields of your const classes (the mutable keyword). This is a really ugly and nonintuitive design, so I assume they'd rather take extra care to make sure they don't have to repeat it. Even if it means no const at all.

I don't think this kind of thing is all that non-intuitive if you reframe const as shared vs. unique references. Rust is a good example of this, although with Go you would want to sidestep all the Cell stuff since it's unnecessary.

Re: Toward Go 2

#547

Post by Matthias247 »

ziotom78 wrote: post #212
nightski wrote: post #203

Earlier quoted context omitted.

Nearly every item on your list is available with OCaml.

Apart from "great concurrency story", because of the well known problems with the GC. This might be a huge shortcoming for a number of people.

F# is pretty good there, especially if one uses a library like Hopac. However I think it's still not on the level of Go, since concurrent operations are represented through monadic types (like Job), and so everything has one level of indirection. F# workflow builders ("do notation") makes that somewhat more bearable, but I still think it's harder to work with than just using normal function calls on normal lightweight threads, like available in Go.

Re: Toward Go 2

#548

Post by pjmlp »

vram22 wrote: post #348
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…

>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. I seem to remember that there was some intermediate form of language translation too - something called melting or freezing or some such (might have been two different things). This was for EiffelStudio, probably, not generic E…

Units in Turbo Pascal come from UCSD Pascal.

The OOP features in Turbo Pascal are based on Object Pascal, which was designed at Apple for their Lisa and Mac OS systems programing language, with input from Niklaus Wirth.

Turbo Pascal was the reason why most PC developers never had too much love for Modula-2, because by Turbo Pascal 4.0 we had all the goodies from Modula-2 with case insensitive keywords.

Also, the compilers were more expensive than Turbo Pascal ones.

Incidentally Martin Odersky was the author of Turbo Modula-2, the short lived Modula-2 compiler sold by Borland.

I usually thank my technical school for having us go through Turbo Basic and Turbo Pascal before getting into Turbo C.

We were using Turbo Pascal 5.5 (I already knew 3.0 and 4.0) and 6.0 was still hot out of Borland's factory, which is why I've always been a fan of strong typed systems programming.

Re: Toward Go 2

#549

Post by shaan7 »

brandonbloom wrote: post #265
littlestymaar wrote: post #160

Earlier quoted context omitted.

Not the GP, but you can think about generics as a better kind of interfaces : - performance wise: no dynamic dispatch, means no virtual function call, means faster code. - type safety: let say I want a data structure that can store anything but everything in it must be the same type. You just can't do that with Go's current type system without introspection (which is cumbersome and really slow). Generics already exis…

> you can think about generics as a better kind of interfaces No, you can't, because generics don't provide the key feature of interfaces: run-time dynamism. You could make a case that static polymorphism and dynamic polymorphism could be accomplished by a single mechanism, as traits do in Rust, but you can't say generics are "better" than interfaces, since they solve a different set of problems, with different imple…

> Yes, this is less convenient than proper generics, but this doesn't mean you can't do these things.

Yep, assembly is less convenient than Go, but it doesn't mean you can't write programs using assembly.

Re: Toward Go 2

#550

Post by randomdata »

lomnakkus wrote: post #490
randomdata wrote: post #459

Earlier quoted context omitted.

There are many different ways to provide generics (templates, typeclasses, etc.), each with their own pros and cons. It's not simply a matter of "add generics". And what solution they do come up with is going to bring the given cons those who would be better served by a different generics solution. The Go team have been long criticized for choosing the option that fits Google, but not the rest of the world. This seem…

Then they should ask for that instead. It's not unreasonable to ask "how do we implement this in the best way?", but I'll note a) that's not what was asked, and b) I have a hard time believing that code at Google is so incredibly "special" that they need a special kind of generics. Also, if Google is such a unique snowflake why not ask the Google people directly rather than the "Go community"?

> "how do we implement this in the best way?"

They asked for use cases from a wide range of people to ensure they implement it in the best way. Subtly different, but essentially the same request.

> I have a hard time believing that code at Google is so incredibly "special" that they need a special kind of generics.

I didn't say they need special generics. I said the approach that works best at Google may not be the best approach for the population at large. If Google is best served by C++-style generics, while the community as a whole would be better served by Haskell-style generics, why just jump in and do it the C++ way before seeing how others might want to use it?

> Also, if Google is such a unique snowflake why not ask the Google people directly rather than the "Go community"?

Because they are trying to avoid the mistake of using one datapoint like Go has struggled with in the past? They know what works in Google, but that doesn't necessarily work for everyone else. See: Package dependencies, among many.

Post reply on HN