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

291–300 of 534 posts

Re: Go 2, here we come

#291

Post by mscasts »

treis wrote: post #48
asien wrote: post #26

I tried Go a while ago. I was hooked by the performance , the community around it and vendors support ( AWS , Heroku , GCloud etc...) but I got quickly fed up by the awkward package management system, the weird syntax and the horrible idea of $GOPATH, especially on Windows. Haven’t tried it since. Hope lots of this change to make the language more welcoming for Newcomers to the language.

>I tried Go a while ago. I was hooked by the performance , the community around it and vendors support ( AWS , Heroku , GCloud etc...) but I got quickly fed up by the awkward package management system, the weird syntax and the horrible idea of $GOPATH, especially on Windows. My experience was similar. In addition to those, I found I really missed a REPL console and moreso something like byebug that RoR has. For those…

> For those that aren't familiar, byebug lets you put the command "byebug" anywhere in your code that opens an in context REPL. It's enormously helpful for hard to figure out bugs.

Isn't that what a normal debugger does? Or am I simply just living in lala-land because of C#.NET/Visual Studios terrific debugging experience?

I remember php and the hell that was xdebug. It was much easier and more efficient to simply to a `var_dump` whenever you needed to debug.

Re: Go 2, here we come

#292

Post by ausjke »

ausjke wrote: post #262

I'm learning Go, just a naive question, why does Go put the variable type at the end of declaration, is this an absolute need? no other widely usage language does that, and it just feels odd to me.

My experience is limited to c, c++, java, all of them did 'type variable' instead of 'variable type', now I see there are many others that are doing things very differently. Thanks.

Love Go's one binary does http-server-login-everything-etc, can't be simpler for deployments.

Re: Go 2, here we come

#293

Post by bulldoa »

SwellJoe wrote: post #256
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…

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…

As a beginner, I really like rust.

It has excellent package management, robust compiler messages, pattern matching... etc. But once I start trying to build non trivial data structures it becomes a nightmare. For example, doubly linked list, any sort of graph is extremely hard for me to build in rust but extremely easy to build in golang.

I am still learning the full capability of rust, hopefully as I do more practice it gets easier. In the worst case I think I would still use it to build data pipelines since I really enjoyed the syntax and the safety check as long as I don't get into smart pointers or raw pointers.

Also another annoying point is that some libraries use nightly.

Re: Go 2, here we come

#294

Post by amelius »

bulldoa wrote: post #293
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…

As a beginner, I really like rust. It has excellent package management, robust compiler messages, pattern matching... etc. But once I start trying to build non trivial data structures it becomes a nightmare. For example, doubly linked list, any sort of graph is extremely hard for me to build in rust but extremely easy to build in golang. I am still learning the full capability of rust, hopefully as I do more practice…

You're not the only one having trouble writing basic data structures in safe Rust: [1]

[1] https://rcoh.me/posts/rust-linked-list-basically-impossible/

Re: Go 2, here we come

#295

Post by _ph_ »

Cyph0n wrote: post #172
llimllib wrote: post #147

Earlier quoted context omitted.

I don't understand what you mean, sorry

Think of it this way: if you spend time learning and using a feature that is not guaranteed to be there, say, a year down the line, is that a good investment?

Learning Go modules is a minimal investment. It is rather hours than days.

Re: Go 2, here we come

#296

Post by bluejekyll »

joobus wrote: post #250
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 feel the same way. By the time Go2 releases, I hope Rust has solidified its async/await syntax, and Rocket can build on stable.

As I understand it, async/await is not going to be too far behind the initial 2018 Edition (which is coming to stable soon).

Re: Go 2, here we come

#297

Post by _ph_ »

thanatos_dem wrote: post #230
floatboth wrote: post #214

Earlier quoted context omitted.

hah. GOPATH is the only thing I like about Go. I have all (non-Go) repositories cloned as URL-style paths e.g. ~/src/github.com/user/repo. I strongly dislike the non-standard internals (horrendous custom assembler, direct usage of syscalls instead of libc) and the "developers are too stupid to use this" attitude towards modern language features.

> direct usage of syscalls instead of libc But go isn’t built on top of C? Why would they add more dependencies that complicate and slow down the compilation process and hurt portability?

No, by default Go programs and the whole Go toolchain has no C dependencies. The whole Go toolchain is implemented in Go and it doesn't like into any C libraries. Go links against libc only if you either use CGO or a package which has C dependencies, but I am not sure whether there is any package left in the standard distribution, that does.

Re: Go 2, here we come

#298

Post by AsyncAwait »

meddlepal wrote: post #286
AsyncAwait wrote: post #276

Earlier quoted context omitted.

> Java and Python. It's two closest peers. See, I don't particularly enjoy Go, but that's because of its weak type system, which Python is no better at. Still, I understand that a lot of people enjoy Python, so good that it exists. Java is too verbose. I'd had understood if you have said Kotlin, but Java is not that much better, (yes, it has generics, but I myself prefer the way they're implemented in Rust/Swift). I…

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 Go in terms of verbosity

Yeah, but on par is not good enough, it has to be significantly better for your argument to work. Yet I don't see you calling for the eradication of Java. Also, gofmt makes it significantly easier to get familiar with a foreign Go codebase. Not a thing in the Java world. And not having to suffer the JVM startup time + having static binaries is indeed a real win for some.

> Scala is a shit show to maintain with some teams.

Yeah, it's a kitchen sink. Kotlin I like a lot better in this regard. But then everything can be a shit show with some teams.

P.S. Rust is getting rather good for writing web servers and with things like rocket.rs & aync/await, I think it'll be a real contender.

Re: Go 2, here we come

#299

Post by 013a »

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…

go1.11 pretty much solved this, though there are still many dependency managers out there and projects which rely on them that should be upgraded to support the New Way.

"package" in Go has always referred to a folder. Or in other words, a shared namespace for every entity exported by every file in that folder. "module" refers to a package which has a go.mod file in it; that module package + all of its children become versioned via that go.mod file and are distributed as one unit.

It operates identically to npm; npm packages are folders, and there's a special package with a package.json which versions that folder and all of its children. Then, that "package.json package" is what is distributed.

Re: Go 2, here we come

#300

Post by geezerjay »

sieabahlpark wrote: post #242
geezerjay wrote: post #80

Earlier quoted context omitted.

> there's an experimental feature That's not a feature but a fix for a design problem, and currently the only fix is an experimental one. For those seeking to invest their time learning a professional tool, that's a whole pile of no-nos that naturally point to a very hard pass.

I don't understand the issue with language improvements, should we only use languages that were perfectly designed to start? Like JavaScript?

> should we only use languages that were perfectly designed to start?

If there are a myriad of languages and we do have limited time to invest mastering a language, we better use our time wisely and not waste it with those with severe design problems and designers who have refused to face those issues for years.

Post reply on HN