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

Seven years of Go

blog.golang.org

Post reply on HN
Print view View original

221–230 of 318 posts

Re: Seven years of Go

#221

Post by aikah »

mixedCase wrote: post #97
pvsukale3 wrote: post #85

Question : Is there a possibility that when Go package management is launched there will be a good opinionated framework like rails for GO . Because for new learners ORM , authentication etc things matter a lot. I know Go promotes use of native HTTP package instead of frameworks but it is a large barrier for newcomers and have risk of writing error-prone web applications.

Doing ORMs and auth without knowing what you're doing imply a huge risk out of itself, which Go tries to avoid. If you have relational data the solution is not to use an ORM to half-abstract it away, it's to learn SQL. ORMs can be useful tools to avoid boilerplate, but they will show their ugly internals when SHTF, and those are always harder to understand than plain SQL. As for auth, it's very easy to add to any web…

> Doing ORMs and auth without knowing what you're doing imply a huge risk out of itself, which Go tries to avoid.

And implementing it yourself the wrong way is also a huge risk.

Re: Seven years of Go

#222

Post by runT1ME »

stcredzero wrote: post #157
richard_todd wrote: post #70

Earlier quoted context omitted.

I miss generics, not because I would write new generic functions all the time, but because a few key generics provide infrastructure that increases the beauty of programs dramatically. The tupled (T, error) return types are a key area I think generics would help. The error-tuples themselves aren't the problem, but rather Go's inability to cleanly handle them. Threading error state around requires repetitive glue code…

I miss generics, not because I would write new generic functions all the time, but because a few key generics provide infrastructure that increases the beauty of programs dramatically. The problem is this: Have you ever worked in a mature codebase with generics, where they haven't somehow been overused? Please tell me where that is!

Yes, constantly. I've rarely seen generics overused.

Re: Seven years of Go

#223

Post by ansible »

dasil003 wrote: post #93
tedunangst wrote: post #83

Earlier quoted context omitted.

I'll argue this point. It takes me 30 seconds to write a SQL query. It's not hard. On the flip side, I don't end up running queries that haul megabytes of data in just to peek at one column. SQL is already much higher level than assembly. Piling on more abstraction just increases the likelihood that the code is doing extraneous work.

I agree SQL is not hard, but getting the data into objects is definitely repetitive work. ORMs are a double-edged sword where people who don't know SQL write bad ORM code because they can, but a good ORM gives various ORM level that allow one to do the right thing and still save a lot of repetitive boilerplate. If you avoid an ORM, the typical medium sized CRUD app usually ends up with some poorly conceived bespoke a…

If you are doing plain SQL in your golang app, I highly encourage you to check out sqlx:

https://github.com/jmoiron/sqlx

It has features like directly unpacking the results of a query into a structure. Very handy.

Re: Seven years of Go

#224

Post by stcredzero »

detaro wrote: post #178
stcredzero wrote: post #171

Earlier quoted context omitted.

4. Enums. My god, Enums. Such a simple feature, but so insanely welcome and useful in Rust. Enums are so underrated. So many architecture problems introduced by bad coders in Smalltalk would have been entirely avoided with Swift style enums.

Can you give examples, assuming you are referring to patterns that still are somewhat common? I've seen a bunch of somewhat-connected Singletons used as enums with extra functionality in Smalltalk, is that the kind of thing you were thinking of?

Most of the times we couldn't do the refactorings/changes we wanted to, it was because we could only be 99.9% sure and not 100% sure someone didn't stick some goofy value somewhere to denote something special.

Also, I'm not so sure that Smalltalk as a language community and as a programming environment did what it took to get everyone to do the right thing. In Swift, it seems like the programmer would quickly learn that an enum is the right thing to do, and management would be on board with using it, because it's obviously the way you're supposed to do the thing. I could just hear one of my bosses saying, "Do you really need that? I don't want to hear about you delving into some sort of 'science project' where you could just stick a String there."

The quick and dirty way of doing things with "somewhat-connected Singletons used as enums" would be just to use the class hierarchy, and subclasses of a particular class would constitute one particular enum. But even with that, someone would have some sort of objection to it.

Re: Seven years of Go

#225

Post by magnushiie »

weberc2 wrote: post #197
AsyncAwait wrote: post #103

Earlier quoted context omitted.

> it's usually for some tree-like structure, but the cases where I need a high-performance tree structure and can't take the performance hit of `interface{}` are few and far between. The problem with interface{} is that it makes it pretty much worthless to have a type system at all.

> The problem with interface{} is that it makes it pretty much worthless to have a type system at all. I don't understand this argument. You need `interface{}` about 1% of the time; somehow it's better to have no type checking than only 99% type checking? Even in the 1% of cases, I've literally never seen a production bug (or even a failed test case) caused by a type error. I'm sure they happen, but I doubt they happ…

Except the 99% (though in my experience more like 80% of the cases where generics would be considered in other languages) of the time you are refraining yourseld from using interface{} and perhaps choosing another bad solution (lesser of the evils)

Re: Seven years of Go

#226

Post by stcredzero »

pcwalton wrote: post #180
stcredzero wrote: post #157

Earlier quoted context omitted.

I miss generics, not because I would write new generic functions all the time, but because a few key generics provide infrastructure that increases the beauty of programs dramatically. The problem is this: Have you ever worked in a mature codebase with generics, where they haven't somehow been overused? Please tell me where that is!

I've also worked on codebases that have overused the && operator. Should we remove that in favor of nested if?

Only if the cost-benefit works out, and there isn't a better solution.

Re: Seven years of Go

#227

Post by krylon »

fizzbatter wrote: post #8

So, i was a Go developer for ~4 years, then for the last 4 months or so i've been learning and using Rust. The pure joy of some things with Rust was astounding. Now, i joined a new job and they're in need of a new language for some backend tasks - the choice was mine. Rust or Go? The backend tasks were heavy API servers - nothing amazing, we don't do groundbreaking work. Python was their existing language, but they w…

> Enums. My god, Enums.

Oh yes, please.

Re: Seven years of Go

#228

Post by jhomedall »

mappu wrote: post #195
AsyncAwait wrote: post #103

Earlier quoted context omitted.

> it's usually for some tree-like structure, but the cases where I need a high-performance tree structure and can't take the performance hit of `interface{}` are few and far between. The problem with interface{} is that it makes it pretty much worthless to have a type system at all.

Generics in java work via type erasure, so is the same as interface{} by the time the code is running.

That's not relevant to type safety, though. Haskell also has type erasure.

Re: Seven years of Go

#229

Post by magnushiie »

mappu wrote: post #195
AsyncAwait wrote: post #103

Earlier quoted context omitted.

> it's usually for some tree-like structure, but the cases where I need a high-performance tree structure and can't take the performance hit of `interface{}` are few and far between. The problem with interface{} is that it makes it pretty much worthless to have a type system at all.

Generics in java work via type erasure, so is the same as interface{} by the time the code is running.

Although I very much like C# where generics are not elided, I think most of the value comes from the productivity from static analysis, and therefore Java generics cature most of the value. Perf improvement opportunities are great though.

Re: Seven years of Go

#230

Post by pjmlp »

weberc2 wrote: post #190
pjmlp wrote: post #107

Earlier quoted context omitted.

C++17 gives you async/await, coroutines and parallel algorithms.

Right, but this is still a far cry from Go's runtime/scheduler. In particular, the Go runtime completely handles threading and async I/O for me. I'm not sure what C++17 coroutines look like, but I don't even have to explicitly yield (which is the case in other C++ coroutine libraries).

Just like any other async/await model.

Also you don't need explicit yield on task runtimes like HPX.

Post reply on HN