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

Go 2, here we come

blog.golang.org

Post reply on HN
Print view View original

411–420 of 534 posts

Re: Go 2, here we come

#411

Post by nordsieck »

a1369209993 wrote: post #398
nordsieck wrote: post #340

Earlier quoted context omitted.

> I'm curious what the motivation was to use int instead of uint considering indexes cannot be negative in Go. I want to emphasize that I do not know the true answer to this question. I think that indexes are int to play nicely with a decrementing loop counter. Doing: for i := len(n) - 1; i >= 0; i-- { fmt.Println(n[i]) } requires i to be signed due to the last iteration.

I'm not sure about go, but in C this could be: for(size_t i = zn; i-- > 0 ;) printf("%s\n",n[i]); (This is a large part of why unsigned over/underflow is well-defined behavior in C.)

In Go, i++/i-- is a statement, not an expression, so that doesn't work.

More generally, assignment is always a statement, and never an expression (e.g. you can't say a = b = c)

Re: Go 2, here we come

#412

Post by [deleted] »

Thaxll wrote: post #305
SwellJoe wrote: post #256

Earlier quoted context omitted.

I just started learning Rust for a small project, and I found its "one clear path" model very appealing (I don't know if it is a formal goal, or if it's just a happy accident based on a smaller, more focused, community). It doesn't just apply to the package manager, but that's one of the first bits a beginner sees. Rust has a single, easy-to-find, "pretty good" answer for nearly every question a beginner asks, at lea…

Rust easier to learn than JS lol... In Rust you have issues that will or will not overcome easily, nothing like that happen in Go. And seriously getting starting in Go takes less than an hour: - Install Go - Install VSCode + Go plugin - Start working

[deleted]

Re: Go 2, here we come

#413

Post by martinlev »

Waterluvian wrote: post #141

As a newcomer to Go, by an immensely wide margin, the hardest, most frustrating thing, which soured the language for me, is whatever the heck package management is in Go. There's like three or four different angles, all of which overlap. Some are official. Some aren't. The unofficial ones seem more popular. They're all kind of incomplete in different ways. And it was all such a frustrating migraine to try and figure…

The fact that it didn't have an official package manager from day 1 is a big issue to me. All other new languages have an officiel package manager - elixir, rust, ... https://github.com/golang/go/wiki/PackageManagementTools

Re: Go 2, here we come

#414

Post by gBecks »

SwellJoe wrote: post #320
Thaxll wrote: post #305

Earlier quoted context omitted.

Rust easier to learn than JS lol... In Rust you have issues that will or will not overcome easily, nothing like that happen in Go. And seriously getting starting in Go takes less than an hour: - Install Go - Install VSCode + Go plugin - Start working

I explicitly said above that Go is an easy language to learn. But, I found Rust easier. And, yes, I'm finding Rust easier to learn than JavaScript. Without question. It is a much, much, smaller and more cohesive language. It has some new concepts (features or techniques that I have never used in any other language), but so does modern JavaScript, and with JavaScript there's usually five ways to do it, and half of the…

I for one totally agree on rust being easier to learn than Javascript. I suspect it is because of the explicitness of rust vs the flexibility of javascript where you can do literally anything you wish without any sort of guard rails, then there's the ecosytem with like a gazillion tools in your build pipeline. I really admire front end devs because they do what I cannot, I guess i'm not as clever a programmer, I need the compiler to hold my hand , lead the way, and yell at me when I am going astray, rust does that for me , and when I'm done obiding by the rules, cargo is there to take over the rest of the process.

Re: Go 2, here we come

#415

Post by delhanty »

cdoxsey wrote: post #394
ryeguy wrote: post #347

Earlier quoted context omitted.

I really don't get the people opposed to generics. Is there actually a cross between experienced developers who have come from languages that have generics and understand them, yet don't want them in go? If so, why, and what do they use instead? Because go has no compromise-free answer for generics. You either lose type safety, maintainability, or performance. I suspect a lot of the generics hate is due to a large ch…

Although ultimately I do want generics in Go I am afraid they will make the language more difficult to use and understand. Generics in c++, c#, scala, java, etc all tend toward being very complex and change the way programs are written. The focus moves towards a taxonomy of types and developers (myself included) sometimes get stuck on difficult type problems. There's something about trying to preserve type safety whi…

>Generics in c++, c#, scala, java

They're not all the same though are they.

C++/CLI had both compile-time generics (templates) from C++, and run-time generics from the CLR. And they could be complementary at times.

For compile-time generics, Dlang are a lot more sane that C++, having had the benefit of coming later, and dumping C compatability.

Similarly, CLR (C#, ...) generics had the benefit of being designed having seen Java first, so IIRC they're baked into the CLR. CKR generics were derived from work done at MS Research Cambridge, and I seem to remember Don Syme (F# creator) being rather proud of them. Disclosure: I was contracting at MSR Cambridge back in 2007.

Anyway, the golang designers will be aware of these implementations, so hopefully they'll come up with a nice design.

Re: Go 2, here we come

#416

Post by johncolanduoni »

IshKebab wrote: post #357
ryeguy wrote: post #347

Earlier quoted context omitted.

I really don't get the people opposed to generics. Is there actually a cross between experienced developers who have come from languages that have generics and understand them, yet don't want them in go? If so, why, and what do they use instead? Because go has no compromise-free answer for generics. You either lose type safety, maintainability, or performance. I suspect a lot of the generics hate is due to a large ch…

It's people that have seen the abuses of C++ templates. They're very powerful and therefore people tend to want to use them for really complicated things. Look up things like SFINAE and compile time metaprogramming. Templates were not intended for those things. When they work they're ok, but if they go wrong good luck following the 10 line error message. Here's an example from Rust: https://www.reddit.com/r/rust/comm…

That's not compile time metaprogramming at all, it's just series of wrapped closures. It's basically the sequence of function call names preceding that call backwards, with different capitalization.

Re: Go 2, here we come

#417

Post by shakna »

mrfusion wrote: post #408
shakna wrote: post #403

Earlier quoted context omitted.

In a ahead-of-time compiled language probably not. The generic function is just a code generator for several functions that will get called in the right places, generated and put in the right places by the compiler, and then get optimised as per normal. And no, being a dynamic language is not what makes Python slow. Lua, Nim and Scheme are all examples of dynamic languages with fast implementations.

Now I have to ask, what would you say does make python slow?

Design choices, to be blunt.

Some of it is simple stuff, like CPython being interpreted, so PyPy get's a huge boost by JITting.

Some of it is much harder stuff, like the way Python is designed to store objects in memory (a list is a pointer to a contiguous space of pointers to things that might be pointers...), and everything that hangs off each object (everything has a dict), and the awful GIL ([0]). Awful for performance, great for thread-safety.

Every single part of a language design has trade-offs. It depends on what you're trying to do whether or not they help you, or hinder you.

Sometimes you change how you're doing things because priorities change, and get a radical improvement, like Python's 3.6 Dict. Most of the time, you don't. One step at a time. Not being able to break backwards compatibility hinders the designer, if they realise a trade-off they've made was a mistake. So you get stuck with some features you'd rather not have.

[0] https://wiki.python.org/moin/GlobalInterpreterLock

Re: Go 2, here we come

#418

Post by meddlepal »

AsyncAwait wrote: post #298
meddlepal wrote: post #286

Earlier quoted context omitted.

I like Kotlin and I write a lot of Kotlin for personal stuff, but I think it is a niche language in the backend/server space and hardly qualifies as mainstream outside Android. Python with PEP484 is pleasant. The concurrency story in Java is great already and it is going to improve once Project Loom is integrated. I fail to see how Java is significantly more verbose than Go. At least not the core libraries. The ecosy…

> Python with PEP484 is pleasant. Not yet, I use types as an important form of documentation, so the vast majority of the library ecosystem would need to adopt optional types before I'd consider it so. > Java 11 Not may people actually write Java 11 at work, most are stuck with 8, or even 6. Java 11 is basically even less mainstream than Kotlin right now, as not even Android supports it. > is pretty much on par with…

> significantly better for your argument to work.

No you misinterpreted my point. It has to be significantly better than what already exists at the time of creation. Java was this to C++ in the 90s and early 2000s. Go is not that language.

Re: Go 2, here we come

#419

Post by virmundi »

bsaul wrote: post #93
ilovecaching wrote: post #9

Well I must say the Go team is certainly putting in the work to avoid a catastrophic major version bump (e.g. Python). That said, any major additive change to Go, especially generics and/or try/catch will push me away from the language. If I need a well designed language, I have Rust. Go's sell for me is it's so naively simplistic it's actually useful when your team members are idiots. If they bolt on type variables,…

I really don't know why you got downvoted. The fact that go was meant to force "average" programmers produce maintainable code is an extremely important push for the language. I do think that generics are needed if go wants to become more useful in contexts others than network middleware or data plumbing, but i'm also pretty sure that adding them will help cripple a lot of codebase in a very short term.

I don't think Go pushes maintainable code. It's simple. That's it. Most of the code bases I see have no layers. As long as you write once and forget, you're fine. After that Go's lack of structure with functions for structs just floating freely in the source file makes things hard to manage. The community's extension of the language to prefer 1 or 2 large files per package makes things worse. The lack of an explicit interface implementation makes it hard to jump to the interface definition of a function on a concretion.

Re: Go 2, here we come

#420

Post by johncolanduoni »

djur wrote: post #364
paulddraper wrote: post #279

Earlier quoted context omitted.

> direct usage of syscalls instead of libc Why do you want to use libc for Go? You wouldn't use the Rust standard library for Go, why the C standard library?

It is very common for language runtimes to link and depend on libc on Unix, even if the libc API is not directly exposed in those languages. Go is somewhat unusual in this regard. MacOS doesn't guarantee backward compatibility for direct syscalls. This has caused bugs like this with compiled Go binaries: https://github.com/golang/go/issues/16570 Go has very recently started using libSystem (which is analogous to Linu…

On glibc-based Linux you generally need to compile on a system running the oldest (or close to) version of glibc you want to support. I suspect this was the singlehanded reason for Go being built that way.

That said, on macOS it makes a lot less sense because libSystem's compatibility guarantees work a lot like those of Win32, where you can safely compile on newer versions of the OS as long as you don't actually use features that are newer than your deployment target.

Post reply on HN