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

441–450 of 614 posts

Re: Go 1.18

#441

Post by feffe »

int_19h wrote: post #355
cardanome wrote: post #268

Earlier quoted context omitted.

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.

Ocaml is not particularly fast, for a compiled language. Is Go really slower?

The compiler is fast in that is compiles code quickly, just as Go and the execution speed of produced programs are similar to Go (depending on what abstractions you use).

It seems there are a bunch of languages in the fast but not quite as fast as C/C++ category: Java, C#, Go, OCaml, SBCL (Lisp), Haskell

Re: Go 1.18

#442

Post by CraigJPerry »

stouset wrote: post #346
CraigJPerry wrote: post #341

Earlier quoted context omitted.

Generally direct refutation of a central point is a constructive argument. Here’s another example of direct refutation: You’ve given a strawman argument, specifically you’ve given one implementation which has abstracted the details (we don’t see the code for take, select and reduce). That’s just an arbitrary decision you’ve made, the equiv go example you could have posted might be: // idiomatic error handling elided…

> Generally direct refutation of a central point is a constructive argument. Selecting your own definition for a word and basing an argument around the definition you chose for it is not direct refutation of a central point. Again you appear to just want to play games where you get to declare yourself the Internet Argument Winner and pat yourself on the back instead of actually giving a shit about the perspectives of…

>> Selecting your own definition for a word

Is that accurate? I said:

>> To complicate something is to combine and intertwine it with other concerns. To fold them together is to complicate them.

The dictionary defines complicate as:

>> to make complex, intricate, involved, or difficult

With etymology:

>> complicat- folded together complicate combine, entangle. intertwine earlv 17th century

>> instead of actually giving a shit about the perspectives of those who disagree with you

Now i resent that because i took the time to try and steelman your bad argument.

>> they couldn't be without copy/pasting their implementation for every single array type you wanted to implement them for

Not true, as i said there’s always been options for this:

>> if we need them to be generic over argument types - in the absolute worst case (so not using go generate to help us here or an interface…

Behind the scenes in the compiler, the syntactic sugar of generics are ultimately performing what you would do with “go generate“.

>> in every project that wants to use them

I don’t follow, why aren’t we allowed to create a library for code reuse like https://github.com/logic-building/functional-go/blob/master/... has done for example?

Re: Go 1.18

#443

Post by kitd »

jshen wrote: post #327
munificent wrote: post #290

Earlier quoted context omitted.

There's a lot of developers that misuse/shouldn't use any powerful feature. If the solution is to give them a nerfed language, then you also nerf it for the users that would use the feature well in productive, useful ways.

Yes, it’s a trade-off. In an organization with thousands of developers the right trade-off is likely different than an org with 20. What I don’t understand is why people insist on making Go like every other language that already does what that are looking for. You want a language with generics, purely functional blah blah blah, great there are tons of choices, use one of them. Why insist on reducing the diversity in…

The syntax isn't the only driver of language popularity. Ecosystem/ tooling/ major sponsors/ large precedent projects etc all enhance a languages adoptability and big shops want to pick a language with a low risk and large supply of coders.

Re: Go 1.18

#444

Post by pjmlp »

pkulak wrote: post #71
_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…

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

Performance, Java made the mistake to not have good ways to deal with GC free allocations and now who knows when Valhala will ever happen.

Thankfully plenty of other GC based languages hadn't made the same mistake.

Re: Go 1.18

#445

Post by pjmlp »

gnoack wrote: post #189
HideousKojima wrote: post #181

Earlier quoted context omitted.

I see it the other way around, generics reduce complication and allow for code that's a lot more elegant and simple than without. It definitely adds complexity on the compiler side of things, but using them in C#, TypeScript, and Java has been only a plus. Unless you count that time I tried to do stuff with generic interfaces in Entity Framework Core, but that was EF Core's fault as opposed to generics's.

...and that time when people reinvented boolean expressions and their combinatorics under the disguise of Predicate and Matcher , making test errors hard to comprehend for very little additional benefit. etc etc There is also the problem that people don't generally have a good grasp on how to use type bounds[1] correctly... I believe Go avoids the worst of it through its simple type system, but still... this complica…

Still better than messing with code generators and template language workarounds.

Re: Go 1.18

#446

Post by kitd »

yashap wrote: post #420
mhio wrote: post #350

Earlier quoted context omitted.

What metric do you use for popularity? I'm more involved in the systems side so I'm definitely over exposed to Go projects. I would have considered Scala to be at least an order of magnitude less "popular" than Go. Kafka is the only open source project in Scala I can recall running into but there's probably a whole enterprise world I don't see.

For open source projects, it’s very popular in the “big data” world. Kafka, as you mentioned, but also Spark, Flink, Summingbird, Scalding, etc. And yeah, it’s a pretty popular backend language at some large companies. Twitter, LinkedIn, Netflix, the Guardian, Starbucks, AirBnB, Coursera, AT&T, etc. all make significant use of Scala. Go is certainly bigger, but Scala has plenty of adoption too.

Kafka is currently undergoing a rewrite into java.

Re: Go 1.18

#447

Post by pjmlp »

oxplot wrote: post #403
int_19h wrote: post #367

Earlier quoted context omitted.

Most critics of Go are well aware of its history and purported design goals. The problem is that the set of features that actually are in Go (like channels) versus those that weren't (like generics) or still aren't (like enums) doesn't really make sense when taking those design goals at face value. For example, generics. Like you say, the original claim was that they didn't want to do them because they thought that m…

> What, exactly, was gained here to justify the productivity lost while waiting? The goal isn't to wait long enough to come up with something novel. That's what research projects are for, and Go is on the exact opposite of the spectrum. If after deliberation, it turns out that a mostly similar solution is the way to go, then that's doing it "right". Also, the lost productivity that keeps getting mentioned is overblow…

Right, the design goals are it is a language for people not clever enough to deal with programming languages.

"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike 1"

"It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical. – Rob Pike 2"

Sources:

https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Pa...

https://talks.golang.org/2012/splash.article

Re: Go 1.18

#448

Post by pjmlp »

int_19h wrote: post #368
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…

It's worth remembering that Java and C# didn't have generics initially. And when they did get them, there was a lot of pushback along the same lines; sometimes almost word-to-word about lost simplicity etc. 18 years later, the C# and Java developers are doing fine.

It's worth remembering that C# did have them pre-release, Microsoft decided to release .NET 1.0 without them to avoid postponing the release date until they were fully done.

This is clearly described in the HOPL papers regarding generics in .NET.

Re: Go 1.18

#449

Post by dgb23 »

Thaxll wrote: post #291
SureshG wrote: post #281

Earlier quoted context omitted.

> 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. Not really no.

Sophisticated garbage collection and JIT have a very high ceiling. The CLR and the JVM are incredible technologies.

Re: Go 1.18

#450

Post by jatone »

stouset wrote: post #347
azornathogron wrote: post #345

Earlier quoted context omitted.

Two things... I think (?) - declaring `adminUsernames` and then using `userNames` (but I assume that's not what you're talking about because that won't even compile) - you're making an array with its length N instead of length 0 capacity N (I totally agree with your point, I just like looking for bugs)

Yep, the `userNames` thing was my own dumb mistake while editing in a comment box and was not intended as a reflection of the language. The capacity/length issue is the actual bug I was intending to include. But... also it's a mistake that's not even possible in the Ruby example due to not having to handle the "irrelevant" internal details of appending to the array, so maybe there's a point to it after all.

and its an optimization the ruby version doesn't necessarily have. you could have just as easily written:

    var names []string
    for i, user := range users {
        if user.isAdmin {
            names = append(names, user.Name)
       }
    }
and hilariously it likely still would be faster than ruby. I've managed large golang and ruby projects and the difference in maintenance work between the two is insane and its not a good look for ruby.
Post reply on HN