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

591–600 of 614 posts

Re: Go 1.18

#591

Post by zinclozenge »

cardanome wrote: post #268
zinclozenge wrote: post #193

Earlier quoted context omitted.

None with the same performance characteristics, ease of use, and ecosystem size. I'm reasonably competent with Rust, but sometimes I don't want to bash my head against the borrow checker or litter my code with copy/clone. Go hits a nice sweet spot, my main quibbles are that there's no native iterators/comprehensions or sum types with compiler checked exhaustive matching. With generics we can get libraries that allow…

Ocaml. Insanely fast compiler. Great type system. Functional programming at its best but still relatively pragmatic and easy to mix in some imperative code if need be. It is a bit more complicated than Go and the ecosystem is maybe a bit more patchy but other than you will have a good time.

Believe me, i'd love to use ocaml but the ecosystem isn't just "a bit more patchy" compared to go, unfortunately.

Re: Go 1.18

#592

Post by ArchOversight »

int_19h wrote: post #360
ArchOversight wrote: post #246

Earlier quoted context omitted.

I wish I had your time and effort to be able to fix the issues of split DNS in macOS being broken unless using cgo. https://github.com/golang/go/issues/12524 This has been an open issue since 2015. It's a pain because every single last tool using go cross compilation fails to use the proper DNS resolver and thereby doesn't work when using work VPN's. This is tools like: kubectl, vault, concourse (fly), and many other…

A better question is, why is Go using its own DNS resolver instead of the OS-provided one in the first place?

> why is Go [doing something that doesn't seem to make much sense]

Because it's Go, and NIH is very strong and alive, and Go can do it better than anyone else.

Re: Go 1.18

#593

Post by preseinger »

lenkite wrote: post #471
preseinger wrote: post #287

Earlier quoted context omitted.

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.

I guess you used map[interface{}]interface{} everywhere you needed to use a Go map ? If not, then your statement is a logical contradiction.

Of course not. I use map[myKeyType]myValueType, depending on the problem I'm solving.

Re: Go 1.18

#594

Post by azth »

oxplot wrote: post #138

When you hear most critics of Go (or any language for that matter), they talk as if Go is merely an alternative syntax for their favorite language. Of course they're bothered by lack of a missing features and unfamiliar ways. As tired of an analogy as it may be, programming languages are like natural languages. Trying to learn Japanese by translating sentences, idioms and proverbs from English word for word will only…

> in service of large distributed teams and long term maintainability.

Except those didn't really manifest. The opposite was actually true, golang is worse for large teams and maintainability compared to languages like Java and C#.

> Go authors avoided complicating the language, runtime, and compiler

Which ended up complicating end users' code. There is no way around it, complexity has to exist in one space or the other. They just made writing the compiler easier, which made writing and reading golang code much harder, and ended up with a weak language.

Re: Go 1.18

#595

Post by jshen »

pie_flavor wrote: post #590
jshen wrote: post #563

Earlier quoted context omitted.

You’ve missed the point. There are trade-offs that you are ignoring. There is no hard science that proves either of our opinions are right. I believe diversity is the better path in the face of such uncertainty, I don’t understand why you are against diversity here, and you continue to not directly answer that question. “ If your code did not use generics, it can continue to not use generics. If you did not interact…

Of course I'm not directly answering a polemic gotcha. If I work in Go, and I have a pain point in Go, and I want that pain point to be addressed, that's not being 'against diversity' or being 'for diversity'. It is being against wasting lots of time for nothing. Why are you against productivity? You continue to not directly answer that question.

Unlike you, I’ve answered your question many times. You are only looking at the benefit for a narrow use case without accounting for its holistic costs. We have a difference of opinion about those costs, and there is no hard science that can prove either of us right. I have acknowledged your point of view, and the possibility that it could be right. You have not reciprocated in any way, or even acknowledge that you understand the point I’m making.

Re: Go 1.18

#596

Post by zinclozenge »

zozbot234 wrote: post #331
zinclozenge wrote: post #193

Earlier quoted context omitted.

None with the same performance characteristics, ease of use, and ecosystem size. I'm reasonably competent with Rust, but sometimes I don't want to bash my head against the borrow checker or litter my code with copy/clone. Go hits a nice sweet spot, my main quibbles are that there's no native iterators/comprehensions or sum types with compiler checked exhaustive matching. With generics we can get libraries that allow…

A bit offtopic here, but it's a bit weird to see this argument that using .clone() in Rust is "littering" the code. The feature is there for a reason, and using it will still give you vastly more efficient code than in most other languages; quite possibly including Go.

Sure it very possibly might outperform Go, and almost undoubtedly outperform python and ruby, but it might also make refactoring for further performance down the road very difficult. When I reach for Rust, it's because I want maximum performance right off the bat. Otherwise I'd just use go, or even java/c#.

Re: Go 1.18

#597

Post by int_19h »

ArchOversight wrote: post #592
int_19h wrote: post #360

Earlier quoted context omitted.

A better question is, why is Go using its own DNS resolver instead of the OS-provided one in the first place?

> why is Go [doing something that doesn't seem to make much sense] Because it's Go, and NIH is very strong and alive, and Go can do it better than anyone else.

Sure, but there's usually some purported rationale. E.g. with direct syscalls it was to avoid FFI overhead. I'm curious as to what it was here; presumably trying to keep everything async?

Re: Go 1.18

#598

Post by azth »

IshKebab wrote: post #521
mrtranscendence wrote: post #514

Earlier quoted context omitted.

Sure, it’s much faster than Python, agreed. But is it fast enough to implement highly optimized numerical algorithms in a way that can compete with Fortran or C? That I’m not so sure of, and if not you’re stuck with the crappy FFI.

Unless you need the last 10% of performance, yes it is. You can also use assembly directly from Go if you need bleeding edge speed.

It's too verbose to do data science stuff.

Re: Go 1.18

#599

Post by pie_flavor »

jshen wrote: post #595
pie_flavor wrote: post #590

Earlier quoted context omitted.

Of course I'm not directly answering a polemic gotcha. If I work in Go, and I have a pain point in Go, and I want that pain point to be addressed, that's not being 'against diversity' or being 'for diversity'. It is being against wasting lots of time for nothing. Why are you against productivity? You continue to not directly answer that question.

Unlike you, I’ve answered your question many times. You are only looking at the benefit for a narrow use case without accounting for its holistic costs. We have a difference of opinion about those costs, and there is no hard science that can prove either of us right. I have acknowledged your point of view, and the possibility that it could be right. You have not reciprocated in any way, or even acknowledge that you u…

Diversity doesn't have anything to do with holistic costs. You shift between whether you're talking about holistic costs and whether you're talking about diversity depending on which part of the point you're making.

https://en.wikipedia.org/wiki/Motte-and-bailey_fallacy

Re: Go 1.18

#600

Post by diehunde »

john567 wrote: post #454
diehunde wrote: post #387

Earlier quoted context omitted.

Go is used a lot for systems programming where you do see those problems.

No you don't. If you do, you haven't understood the problem that you need to solve and you are reaching for things you don't need to use.

Seems like you are not aware of the kind of problems they solve. Systems engineers have been writing generic programming code for years to build databases, message queues, file systems, etc where you do need data structures that support arbitrary types/functions.
Post reply on HN