[flagged]
Major standard library changes in Go 1.20
91–100 of 265 posts
Re: Major standard library changes in Go 1.20
#92How substantial is Go's standard library compared to Python's? I know Go has support for what I would consider to be the bare minimum for what modern standard libraries must provide (http, crypto, time), but what about support of smtp, data serialization formats, etc? I want an alternative to Python that can provide the same awesome batteries-included experience. I am also considering Nim but I want a language with a…
You could consider Clojure. It is backed by the java ecosystem, which is substantial. Not quite the same as python's "batteries included" approach.
Groovy would be the most "batteries included" JVM language I think ... latest version even bundled YAML support in the standard library. Of course, it has all the downsides of a "kitchen sink" approach to language design.
Re: Major standard library changes in Go 1.20
#93How substantial is Go's standard library compared to Python's? I know Go has support for what I would consider to be the bare minimum for what modern standard libraries must provide (http, crypto, time), but what about support of smtp, data serialization formats, etc? I want an alternative to Python that can provide the same awesome batteries-included experience. I am also considering Nim but I want a language with a…
> know Go has support for what I would consider to be the bare minimum for what modern standard libraries must provide (http, crypto, time),
Compared to sat Rust Go has a very large and practical std lib ! You can actually do something with it I/O wise.
To save some of my karma points, Rust do have a big "community with crates"
Re: Major standard library changes in Go 1.20
#94[flagged]
Re: Major standard library changes in Go 1.20
#95Earlier quoted context omitted.
This is a strange take to me. The last thing in the world that I would accuse the Go developers of is being frantic. There have been discussions about generics for a decade. See this post, for example, that goes into a bit of the history: https://go.dev/blog/generics-proposal Keep in mind that the arena thing is not from the Go developers for general purpose usage, I suspect it’s an internal detail that might be usef…
Yes, generics (and many other proposals, like improved error handling) have been discussed for a long time. But for an almost equally long time, nothing happened. Go was stagnating for years until very recently, and the consensus seemed to be that the well-known deficiencies of the language were simply "what Go is", and anyone who doesn't like it just doesn't get it. Now suddenly we have generics, and a bunch of othe…
The near meaningless vision seems to be to see what sticks without using types in the lexer & parser https://groups.google.com/g/golang-nuts/c/7t-Q2vt60J8/m/0h-2.... Take array declaration being prefixed to the type name to prevent ambiguity with int []a, b; vs int a[], b; & then Ian & the rest doubling the work back & reusing postfix [] for generics resulted in making inferable type identifiers turn into required infix operators & that reversed the position of array declaration that es against the intuitive idea that what is independent comes first & to construct an array/pointer has a dependence on its elemental type that is a common pattern to programming languages with arrays. Along with the arbitrary predeclared identifier constraint requirement, using/burning one of the limited matching pairs was a complete waste as generics do not involve changing precedence - there is only a "(of) type (T)" operator - to accommodate nesting - D's "!" operator parses fine L to R w/o look ahead. The implementation taking years from some who have been programming for decades & resulting in a complete mess up is a grand ole time(r) fiasco.
Re: Major standard library changes in Go 1.20
#96Adding manual arena memory management seems like a weird choice for a supposedly memory-safe and GC'd language where this is supposed to be an implementation issue. I mean, you should hear the screams from Rust/Go people about how bad C is, and now you're just going to do it?
Garbage collector is too slow, so they're reintroducing malloc and free. Life writes the best scenarios.
Re: Major standard library changes in Go 1.20
#97Earlier quoted context omitted.
[flagged]
Every time this completely tired and worn out take is regurgitated on this website, it reminds me that people write big fat try/catch blocks because they never expect things like file reads to fail.
Please be respectful, nobody is regurgitating anything. People are frustrated because half of their programs are if err != nil { return nil, somestruct{}, false, "", err }
Re: Major standard library changes in Go 1.20
#98Earlier quoted context omitted.
The only constant is change. Especially with Go, apparently. It's hard to evaluate the comparison of Golang of today to the one I originally discovered 11 years ago in 2012. Then, it was a breath of fresh air. Nowadays.. I find myself sighing. It works but the joy has faded. Bit rot is life.
The joys and woes of reinventing computer programming right where it was left off in the early 70s.
I think I can sympathise, it's hard to keep up with all the development in PL, so it's easy to convince yourself that all those new inventions are stupid anyway and you don't need them, you'll do it your way.
And then, slowly over a couple of decades, other people will be making it their life's work to add in the things that you thought were stupid because inevitably the need for them surfaces.
Re: Major standard library changes in Go 1.20
#99[flagged]
I thought it was funny
Re: Major standard library changes in Go 1.20
#100How substantial is Go's standard library compared to Python's? I know Go has support for what I would consider to be the bare minimum for what modern standard libraries must provide (http, crypto, time), but what about support of smtp, data serialization formats, etc? I want an alternative to Python that can provide the same awesome batteries-included experience. I am also considering Nim but I want a language with a…
Go has probably the most extensive stdlib of major languages outside of Python (happy to be corrected on that). You can get a sense for what is available by looking here: https://pkg.go.dev/std . There is also the "pseudo stdlib" that is maintained by the Go project but for one reason or another is not available in the stdlib currently: https://pkg.go.dev/golang.org/x
Java seems to have just as much if not more available in its standard lib.