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

Go 1.18

go.dev

Post reply on HN
Print view View original

501–510 of 614 posts

Re: Go 1.18

#501

Post by bashery »

cube2222 wrote: post #267
acchow wrote: post #252

Earlier quoted context omitted.

> That means ergonomic monads are not possible to implement This is a good thing?

Yes. I'm keeping up with the developments in functional languages, and many of them have lots of ways to do the same thing, with the "recommended" way changing once every 2 years. I intentionally choose Go where idiomatic code 5 years ago is mostly the same as idiomatic code now. Where no matter who writes the code, it ends up being fairly similar. Where I can easily dive into any open source library, understand the…

+1

Re: Go 1.18

#502

Post by t43562 »

thiht wrote: post #233
t43562 wrote: post #209

I think about Go with pleasure until I remember importing. The miseries I've experienced with modules - the way imports are satisfied......just so hard to understand. Built-in support for SCM sites like github (yuck!). Just struggling to put code in a place where some other bit of my code can use it. The C/C++ preprocessor is an abortion and go seems to have made something that solves all the problems I had with that…

Really? That’s honestly not an issue I have. My day to day dependency management story is just using go get and go mod tidy. It just works fine, and I work with a fair share of services and dependencies. Can you share some issues you have?

SCM support being baked in, I can't add support for our company git server since I'd need permissions to set it to return some kind of headers which I'm never going to get.

Now my code has references to github all over it and no chance to replace that dependency without a massive code change - something that may not be even practical.

The "replace" directive .... ha ha ha. Never got it to work for me - a total joke. Obviously it must work in some simple situation but apparently not mine.

The misery of trying to fork a library or just the subcomponent of that library that I need to change and use.

The strange special directories (internal, vendor, ....)

WTF is a "package" really and how does that relate to where you put code? It just seems to be a complete disconnect with where you put things or how you import them and is very confusing.

executables having to be alone in their own cmd directory.

Essentially that I hit mysterious import related problems that require continual careful reading of the docs to work out what I'm falling foul of.

Working out what is the real difference between GOPATH and GOROOT - you can read the docs many many times without understanding the straightjacket that the wise Go developers think should fit everyone and so you get problem after problem until you start to understand why "computer says no."

Creating read-only files in your home account so that you cannot "blow away" (without some trouble) the caching that is hiding or causing your latest module importing problem.

Sorry, the whole business is a great non-joy to have to deal with.

Re: Go 1.18

#503

Post by rr808 »

movedx wrote: post #381
rr808 wrote: post #364

Earlier quoted context omitted.

Engineers are people who can create a solution to a problem in an efficient and effective way. Specialists who know every detail are craftsmen who can create the best possible solution but they aren't necessarily good engineers.

> Engineers are people who can create a solution to a problem in an efficient and effective way. How do you create an "efficient" and "effective" solution if you're not aware of as many options as possible, i.e. fuzzing for security vulns? How is your solution "effective" if I can throw a bunch of Unicode at an input field and crash your application because the "engineer" didn't know what fuzzing is?

I've seen a common pattern of specialist devs who can write loads of code and complex tests, but never actually talk to a user or check if the software is doing what the users really want.

Re: Go 1.18

#504

Post by bashery »

lanstin wrote: post #410
avl999 wrote: post #213

Earlier quoted context omitted.

Avoid channels except for straight forward, producer-consumer workflows. Use mutexes and other traditional concurrency primitives for other stuff. Channels are a huge shotgun with caveats.

The thing about channels is, while they might be slow for tight inner loop type compute code, it lets you scale across all the cores very linearly. And, given a channel to flow the work thru, you can manage the number of workers at each stage however you like - growing with more load, dropping work with more load, back pressure with more load. All concisely and explicitly. And a lot of network server things are class…

+1

Re: Go 1.18

#505

Post by bashery »

mftb wrote: post #91
pkulak wrote: post #71

Earlier quoted context omitted.

I can never seem to understand why a GCed language has pointers, and makes you memorize when to use stack vs heap.

It's pretty straightforward, knowing when to use the stack vs heap can improve your performance. Having both paradigms available in the language means you can start out relying on the GC for everything. Later when you're ready, you can look to make more intelligent use of the stack.

+1

Re: Go 1.18

#506

Post by bashery »

candiddevmike wrote: post #32

Personally, I'm waiting until 1.19 to start seriously exploring generics. By then, the dust will have settled a bit, folks will have some good lessons learned to share, and there may be more packages in the stdlib for generics.

+1

Re: Go 1.18

#507

Post by viraptor »

preseinger wrote: post #287
pie_flavor wrote: post #277

I wish I understood how people can say 'this will result in so much more weird boilerplate garbage code' as it solves a problem that has resulted in an absolutely ludicrous amount of weird boilerplate garbage code. You're not trading off generic code vs non-generic code. Problems are generic. For solving generic problems , you're trading off the generic code that best expresses them, for codegen, dynamic downcasting,…

Problems are not generic. "I need a N-ary binary tree over arbitrary comparable types" is not a problem. Problems are expressed in terms of domain concepts that are unique to the problem space, the organization, the business need. Some _implementation details_ or maybe patterns that can be used to solve those problems may be generic. That's separate.

It depends on the level of abstraction you're addressing. One level may be "i need to store things with a quick search function", another may be "i need a storage of ordered names and expiry date for things", etc until you get to "I need a binary tree which orders by comparable types".

Where you split that process as a separate library you either decide to write or reuse - that becomes the problem to solve. A set implementation may be a problem to solve: https://github.com/deckarep/golang-set A btree may be a problem to solve: https://gitlab.com/cznic/b/-/tree/master/v2

Re: Go 1.18

#508

Post by thegeekpirate »

bashery wrote: post #506
candiddevmike wrote: post #32

Personally, I'm waiting until 1.19 to start seriously exploring generics. By then, the dust will have settled a bit, folks will have some good lessons learned to share, and there may be more packages in the stdlib for generics.

+1

Please stop posting this on every comment you agree with, as you're not adding anything useful to the discussion, while also sending alerts to people for no good reason.

Click on the upvote button instead.

Re: Go 1.18

#509

Post by geodel »

Thaxll wrote: post #292
kaba0 wrote: post #261

Earlier quoted context omitted.

Scala is pretty close to Go in terms of popularity and I would argue that it has a much bigger ecosystem due to the JVM. It is also pretty much a typed python in terms of ease of use, and the JVM has stellar performance — other than small running scripts, for many kind of workloads Java’s state of the art GC will have better throughput than Go’s.

Scala is on its way to die actually, I worked couple of years with lot of services in Scala, they were all replaced by regular Java or C# over the years, Scala missed the train and it's more and more difficult to find people that want to work with that language. It's a stagnant language that will not get more popular, it peaked.

You are right. Going by Google trends Scala is not only less popular then Go it is further going down when compared to Go [1]

1. https://trends.google.com/trends/explore?date=today%205-y&ge...

Re: Go 1.18

#510

Post by IshKebab »

mrtranscendence wrote: post #248
didip wrote: post #21

Generics!!! I can't wait for all the different data structure libraries to embrace it. It will make Go adoption in Data Science use-case easier.

I don’t see Go ever making headway in data science. For one, it’s not fast enough to implement algorithms directly but lacks a decent FFI; it would be burdensome to create the metric ton of new libraries that would have to be put into place. And there are Python libraries for basically everything already, from numeric computing to Bayesian time series to Spark to Torch and TensorFlow. Plus Go’s kind of weird, relativ…

Go is definitely fast enough to do data science.
Post reply on HN