111–120 of 209 posts
Earlier quoted context omitted.
Canadians now roll with the term Indigenous instead of Aboriginal
In 10 years a new word may become fashionable. Better to keep technical terms the same.
Just do a find and replace, refactoring is easy and trying to argue on the internet about it is tiring.
Thank god, this guy[0] can finally cut over to native generics in his code. [0]: https://www.reddit.com/r/rust/comments/5penft/parallelizing_...
It's funny how codegen has become widespread in Golang to work around its deficiency.
def traverseImpl[F[_], A, B](fa: Option[A])(f: A => F[B])(implicit F: Applicative[F]) =
fa map (a => F.map(f(a))(Some(_): Option[B])) getOrElse F.point(None)Earlier quoted context omitted.
Codegen is a super flexible and versatile tool, and simply having a strong generics feature does not mean you can avoid it: at $DAYJOB we use codegen even for C++ for e.g. grpc/openapi types, generating rapidjson streaming unmarshallers, etc not even counting Qt's moc/uic.
I understand and agree, I've run many a Java project that used codegen to emit Protobuf/Avro IDLs as types. But Go having actual generics, and accordingly removing some need for codegen, is not a bad thing at all.
I for one won't be using more advanced functional coding though, it's a lot more difficult to read / parse and the language is not designed with functional programming in mind. I'm sure people are already working on a functional programming library so you can do map / reduce / filter and the like, but readability and performance will be dreadful.
Thank god, this guy[0] can finally cut over to native generics in his code. [0]: https://www.reddit.com/r/rust/comments/5penft/parallelizing_...
S̷͕͂̒c̴͉͈̆ŕ̶̘͚̄e̸̘̽̌ͅa̵̼̳͌m̷̬̓̈́͜s̴͙͆ ̸̨͓̾̈́i̴͈̼͐ņ̶̟̊̍ ̵͍̐̊Ű̸̪̤n̴̪̝̅̍i̶̜͌c̷͎̩̑̀ỏ̶̜͊d̴̟̎͠e̴̘̿ Oh gosh oh gosh zaglo variables please no
> Because we will not know what the best practices are for using generics, Well, you could... take a look at languages created these past twenty years that support generics, learn lessons from that, and see how these lessons could apply to Go. But well, the Go team is not exactly known for paying much attention to the state of programming language theory, so I guess that's out.
Earlier quoted context omitted.
I would say, many people also look down on much more popular languages, such as PHP. Go is still an absolute niche language, even more niche than languages like Scala or R.
Niche in your niche perhaps, but there's a lot of code in the wild written in Go. Hell, all the modern devops tools are written in Go (Docker, k8s & co.) Meanwhile, as a non Java programmer, I've never seen a Scala app. I know about R, but nothing on my PC is written in it. Agreed that PHP is massive in comparison to all of them.
You could say the same thing about excel macros. They are both tools for wrangling data, tools that will typically not be distributed to end users.
Earlier quoted context omitted.
Hopefully not and never.
They already have it with panic and recover. They just don't recommend using it for error handling.
Explicit error handling can be tedious, but I’m never confused about what some code will do.
Compared to Java where an exception may bubble up 10 layers to a catchall try catch statement, I actually know where the error is coming from.
Would be nice to have this abstracted away with tooling though. I would imagine go generate could be used to great effect in this arena.
Earlier quoted context omitted.
I would say, many people also look down on much more popular languages, such as PHP. Go is still an absolute niche language, even more niche than languages like Scala or R.
Niche in your niche perhaps, but there's a lot of code in the wild written in Go. Hell, all the modern devops tools are written in Go (Docker, k8s & co.) Meanwhile, as a non Java programmer, I've never seen a Scala app. I know about R, but nothing on my PC is written in it. Agreed that PHP is massive in comparison to all of them.