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

301–310 of 614 posts

Re: Go 1.18

#301

Post by zozbot234 »

AnimalMuppet wrote: post #141
andrewf wrote: post #14

Earlier quoted context omitted.

I work at a Go shop that was a Python + RoR shop when I joined. I don't dispute Go's benefits at our scale. As a matter of personal preference, I don't enjoy Go. Go is Blub ( http://www.paulgraham.com/avg.html ). I think the industry is in a place where Blub makes sense! Lots of VC money is floating around, and schools are training a lot of people to hire with that money. Commercially relevant ideas most often succee…

In fact, Go was designed to enable average programmers to be productive on large systems. You might call that "Blub"; I don't. In fact, I claim that Paul Graham is completely wrong in that essay. To see why, think about Lisp and Haskell. When Lisp users look at Haskell, they know they're looking down, and they know why. "How can you get anything done in Haskell? It doesn't even have macros." But when Haskell users lo…

> In fact, Go was designed to enable average programmers to be productive on large systems.

The fallacy in that argument is that effective programming "in the large" requires more features, not less. Sure, there are highly dynamic programming languages that cannot meaningfully support programming beyond the scale of a "personal side project". Ironically for Paul Graham's "Blub" argument, LISP is quite clearly one such language. The same applies to languages such as Python, Ruby or ECMAscript, which would have been among the main alternatives to Go when it was first released.

And one can also fairly argue that Go has in fact made it simpler and easier to "program in the large" compared to C++, Java or C#, which were the other major alternatives to Go around that same time. So Pike's argument is not wrong as far as it goes. It is merely of limited applicability, because the jury is very much still out wrt. more recent and arguably higher-level languages like ReasonML, Kotlin, Dart, Erlang and yes, Rust. It's silly to conflate these languages with the likes of Python or C++, that is indeed the kind of argument that "Blub" was written for!

Re: Go 1.18

#302

Post by edenlinger »

honkycat wrote: post #215
edenlinger wrote: post #80

Earlier quoted context omitted.

I don't mean to disparage the wonderful work of the lo developers but, this is in many ways what I feared generics would bring. If you aren't going to lean into the simplicity and single way of doing something, you are likely better served in another language. I am probably an old man yelling at clouds and I hope those who like this style get tons of value from it. I just don't see the benefit of trying to retrofit s…

> If you aren't going to lean into the simplicity and single way of doing something, you are likely better served in another language. Generics were widely asked for by the community for many reasons, one of the main things being reducing boilerplate and having basic polymorphic functionality that other languages provide. I'm not trying to disparage you but: You don't know who I am, or my capabilities. Please don't b…

Man, I totally missed the mark if this is how you interpretted my comment. I never meant to imply any competence level. Certainly didn't meant to direct any judgment at you. Simply trying express the issue I had with the lo package.

I'm really happy we have gotten generics. I think some of our lower level tooling will be much easier to build. I know lots of the community will likely be happy to have non reflect based ORMs come out of that work. I have a coworker who has expressed interest in building a new json:api parsing library with generics. Happy we have it.

The map/reduce/filter and some of the other _ style helper functions from lo was what I was trying to speak to. Those idioms just don't seem to fit well in the language. The clarity of the single way to do something in Go has been immensely refreshing. I appreciate that so often Go code looks like Go code. I also don't find myself pondering which iterator to use or chain together to accomplish something. I just quickly go to a for loop and move on. In Ruby/Java/JS/Python I often find myself deciding which chainable to use instead of just solving the problem and moving on. The language is certainly not without its warts or shortcomings. To me it feels like if those kinds of options are things you really enjoy using in a language, it would feel more natural to use a different tool. Sacrificing that clarity seems to remove some of the biggest reasons to use the language as opposed to something with fewer limitations.

Sorry if I came across as condescending. Not a stereotype of the community I intended on perpetuating.

Re: Go 1.18

#303

Post by movedx »

2OEH8eoCRo0 wrote: post #254
justinsaccount wrote: post #48

Generics is the big news, but the fuzzing support is amazing too. I added a fuzz test to an app I have in about 5 minutes. It was no harder than adding a normal test. I expect to see a huge boon in users of fuzzing techniques which will benefit projects across the board.

Nobody at my work has even heard of fuzzing and thought I was making it up. I'm glad senior SWEs are paid so much to keep up with the industry. /s

I don't consider those kinds of people engineers at all. They're people who have learned a syntax, some patterns and, thanks to their human brain, can adopt it slightly to certain situations. But they're not engineers.

Engineers constantly ask why, explore the unknown and are aware of almost all possible solutions available to them. using this knowledge they select the correct tools and build the solution.

What you've described are skilled labourers.

I'm harsh with my judgement because I believe our industry has a lot of "statically minded" individuals who stay in their lane, never going outside their boxes, to explore what else is out there to help them solves the engineering problems they're faced with... and it's pissing me off :)

Re: Go 1.18

#304

Post by kaba0 »

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.

It just got a huge revamp with Scala 3, please do check it out if you hadn’t yet - it fixes some pain points while has many many exciting features, eg. can be null-safe with a single compiler flag (basically type T will not be able to represent a null, a java method that does return T will have a signature of T | Null). In great hands it can be insanely productive and well-maintainable, but of course I know that giving it to developers that look at the project more as a learning/experimenting thing can cause quite some damage due to the language’s strength.

Re: Go 1.18

#305

Post by yawaramin »

zinclozenge wrote: post #193
ed25519FUUU wrote: post #131

Earlier quoted context omitted.

Plenty of great functional alternatives to Go.

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…

Rust isn't a functional programming language. You could try OCaml, it's kind of a halfway point between Go and Haskell.

Re: Go 1.18

#306

Post by xiaq »

eatonphil wrote: post #273
slicedbrandy wrote: post #27

Now time to update interface{} usage and shift to any . $ gofmt -r 'interface{} -> any' -l **/*.go Replace -l with -w to write.

Is there an actual difference between these or is it just aesthetic? (and shorter)

any is an alias of interface{}, so purely aesthetic.

Re: Go 1.18

#307

Post by jjtheblunt »

SureshG wrote: post #281
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…

> None with the same performance characteristics, Most JVM languages (Kotlin/Scala/Clojure) including Java :) In fact kotlin/java has better peak performance than Go. Main advantage for go is the reduced memory footprint.

> In fact kotlin/java has better peak performance than Go.

Says what benchmark?

Re: Go 1.18

#308

Post by yawaramin »

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.

I understand not keeping up with it but 'it's on its way to die' is just spreading FUD. It's more popular than ever. Disney+, Lego, Canada Post, basically every large bank–plenty of people are using it and adoption is increasing.

Re: Go 1.18

#309

Post by the-smug-one »

Mawr wrote: post #176
frenchie4111 wrote: post #139

In celebration of generics release, I was playing around with supporting Optionals via generics. If anyone's interested I am happy to make this a real project https://github.com/frenchie4111/go-generic-optional

type Optional[T any] struct { value *T } Don't use a pointer - it's bad for performance. func MakeOptional[T any](value *T) Optional[T] { Use `New` instead - it's the idiomatic name for a constructor in Go. Drop the `Optional` part - the module name suffices - the caller will see: `opt.New`. Personally I just call the module `optional`, I think it's clearer: `optional.New`. func (o* Optional[T]) Unwrap() (T, error) {…

> Don't use a pointer - it's bad for performance.

That means you must have Optional[*sync.Mutex]. Then what's the point?

Re: Go 1.18

#310

Post by bsaul »

coder543 wrote: post #159
_0w8t wrote: post #67

For me the most puzzling aspect of Go is channels. Ada tried CSP (Concurrent Sequential Processes that Go channels are based on) in eighties and people quickly realized that it lead to bad performance and was unsuitable for a lot of useful cases. So Ada got standard mutexes and signals. So why CSP which does not allow to implement priority delivery or multicasting and makes cancelling much harder compared with normal…

> Still without proper sum types polymorphic and type-safe message queues are not possible. This isn't really true. You can define a channel where the message type is an interface, and then you can use a type switch on the receiving side to downcast that interface to various concrete message types. What you can't do without sum types is ensure that you don't need a "catch-all" branch for if/when a value is sent down…

That’s a weird definition of type safe… with very very low standards.

What OP probably means is that there’s no way to build a channel transmitting a list of various types while having the compiler warn you if you’ve forgotten a possible type, or if you’re trying to unwrap into an impossible one.

Post reply on HN