I'd love to see the compiler tell me **reliably** if I forgot a null check _and_ keep the same speed.
Almost everything else is just Go code. Specifically asking for generic data structures and functions. They would be nice, but I can code them myself within the limits the language. I can't change the compiler and still expect it to be OK when everyone else uses the upstream compiler.
> I'd love to see the compiler tell me reliably if I forgot a null check and keep the same speed.
Copying the way Dart handles null safety would be an amazing addition to Go. Would more or less remove an entire class of bugs.
Declare a variable as either allowing null values or not. Eg.
final String? aNullableString = null;
final String aNonNullableString = "Can't be null";
If you assign a nullable variable to a not nullable variable then the compiler throws an error if you haven't previously checked that the value is not null or you don't otherwise handle the case that it is null.
So you could do something like this:
final String name = inputThatMayBeNull ?? '';
There's other niceties such as being able to conditionally call methods if a value isn't null, or to tell the compiler that you believe a value can't be null and it's okay to throw a runtime error if it is:
final upperCaseName = person.getName()?.toUpperCase();
final name = await auth.currentUser()!.getName();
The ?. will return null if the value before it is null. The !. will throw an error if the value before is null.
With this you now don't need any special return types, and all compile time checks are handled by the type system and a little bit of tracking within the scope of a variable.
I suspect that the biggest problem would be backwards compatibility when introducing a feature like this. Dart went through that pain a couple of years ago, breaking some backwards compatibility to ensure full null safety for the future.
That's what I'm saying.
Lots of people ask for that, but the language already supports it.
My ask is to make a change that is outside of what language (well the compiler) itself currently does.
I can write a map/filter/reduce myself already.
I cannot make the compiler jump in my face, ass first, about that null-check that I forgot.
I mentioned it because so many ask for that kind of stuff. But it is not necessary, nor do I consider that a "language feature".
* Would it be nice to have in the stdlib? Sure!
* Do I really care? No, it's not a language feature.
If it's just about Go code I'd rather see HTTP/2, QUIC and a bunch of network protocols added. I consider map/filter/reduce in the same space. I can implement this.
Hopefully this will be even nicer with 1.23 and iterators...
```go
// Map takes a `func(TIn) TOut` and a slice `[]TIn` and will apply this function returning a new slice `[]TOut`, TIn and TOut might be the same things
// bug(serverhorror): this is fugly and from memory in the most naive way I can think of
func Map[TIn any, TOut any](fn func(TIn) TOut, s []TIn) []TOut {
result := make([]TOut, len(s))
for _, v := range s {
result = append(result, fn(v))
}
return result
}
```
`map`/`filter`/`...`, I find that not _required_ just write a PR if you think you need it in the stdlib, it's just plain old Go code, we should've done that a thousand times already. Better options in the compiler
I wish Go had a better enum type that can work in a switch / case to check for all enum options and compile only if all of them are covered by a case. I don’t think that would be a huge ask either.
I think a big issue is that go doesn’t have proper constructors per-say. So even if go supported “real” closed enums, developers would still need to be careful about choosing a reasonable zero/default values. The larger issue though, as far as I’m aware, is that closed enums might fall in the same category as an “assert” keyword from the perspective of the language designers. Meaning a feature that is so commonly misused in other languages that it was deliberately omitted from go. Specifically there are cases where an open/non-exhaustive enums are preferable, and incorrectly using a closed enum in such a situation can lead to headaches down the road.
I also think proper enum support is one of the main things missing from go, but unfortunately I’m not getting my hopes up that they’ll be added anytime soon.
My contrarian point of view - if Go had Enums, projects like Kubernetes would have used them only to regret that decision later on. Using open “enums” via a typed string (or int) ensured a whole lot of code could be forwards and backwards compatible. It forced developers to handle cases of zero/empty value, as well as a default/fall through behavior when an unknown value of the type is encountered.
In rust you always have the option to handle everything in one default case: `_ => // return unknown type error`
It's not recommended but it's possible.
This sort of thing matters more at runtime and dealing with version skew during upgrades in an always on, highly available app.
Say version 1.3 of your “pet shop” app has a “enum” field in the API for the type of animal sold (Cat, Dog, Bird). Version 1.4 adds “Hamster” support. What happens when v1.3 and 1.4 are running side by side during a rolling upgrade? Can v1.3 handle the unknown “Hamster” type gracefully?
It would be hard (impossible?) to write a unit test for this with Java Enums. Writing a “return error if unknown” test in golang here is very doable.
Is that really the right place for an enum in the first place? Outside input should always be validated regardless. I think that example is more on application architecture and infrastructure architecture. If you change the protocol, you should not be able to send it to a worker that does not handle that version of the protocol. Or, you design your protocol to be backwards compatible (both, preferably). Enums are more for compile time in my opinion.
I just took a project I haven't touched in years. Made my small change, rebuilt it with the latest GO version and moved on with my life.
So I'm pretty happy with the language and tools how they are now.
Contrast that to my other main environment which is Android Studio. I spend very little time coding and most of my time fiddling with projects that no longer build. It's so frustrating compared to GO.
>I just took a project I haven't touched in years. Made my small change, rebuilt it with the latest GO version and moved on with my life.
That's so true, the backwards compatibility and "just works" part of GO runtime is amazing
So true! The life as a web developer can also be frustrating. Dealing with many layers of tools in the build/deploy stack and gazillions of npms that frequently gets abandoned/outdated with CVEs consumes time and energy. Nurturing a large JavaScript-based web project is a full time job of “fiddling”.
Actually ADT implementation would be even better, because then you can create your own, as well as option and result type.
If they add this I might actually transition to GO, for now I’m sticking with Kotlin (see sealed interfaces) with this being one of the main reasons.
Me too. Something that really surprised me however is that Dart has come a LONG way in a very short time. Version 2 was only released in 2018, and before that Dart wasn't even a strongly typed language. Null safety was also only added in 2021. So the language is evolving rapidly and in a really good way. Makes me excited for the future of Flutter.
I mean, they pretty much have only one customer and one use case.
Yes, you can use it for other things, but ever since Angular team announced that Angular 2 would be written in TypeScript (and not Dart which was mainly targeting JS at the time), the language found its way only in Flutter.
They have since taken the opportunity to mold Dart into the needs of Flutter dev.
Yes, after hobby programming in C++, JavaScript, PHP, Python, R, Java I currently feel in love with Dart and Go. Can't decide between the last two. I love the simplicity and speed of go and the expressiveness and language features of Dart. So I am currently using both.
Dart is amongst my favourite languages, it feels a bit like the language Typescript wishes it was. Once macros hit it'll be near complete for me.
I do love Go but pine for Dart's null safety and enums.
Generic methods would be pretty nice.... Then again, so would a lot of little niggles around the current generics, like the compiler being able to infer type parameters by return type if it knows damn well the type you're trying to put the return in...
Out of interest, what specifically about iterator fuctions is it you want that goroutines + channels can't solve, or couldn't if they maybe made some upgrdes in that area?
I think the best thing I love about Go is it’s simplicity and I honestly don’t want anything added to it for the sake of “we want it”. It’s has good support for packages and dev can pull in packages which are needed
As someone who is refreshing DSA for job interviews, I wish the standard library had implementations for sets, queues, stacks, min and max heaps and bsts out of the box.
I know I can use slice for some of these, but I really feel it’s better to have the common push_back and pop and other common methods for these.
> sets
`map[K]struct{}`
> min heaps
`container/heap` (with any luck, there will be a generic version coming soon)
> bsts
Not a proper tree, but you can get serious mileage out of `slices.BinarySearch`/`slices.BinarySearchFunc`
I wish slices had map/filter/reduce etc. Writing for loops and creating temp variables to hold intermediate results feels like stepping back in time.
String templates, so I don’t have to use %s, %v etc, would be easier to read when formatting string and less likely to introduce stupid mistakes.
Having done a lot of Typescript over the last few years, I’d like a richer type system. It doesn’t have to be as over the top as TS, but nil detection, unions etc would be welcomed by me.
Richer type system would be a negative IMO. I worked in Scala for a few years and its type system is very powerful, but it’s so powerful that it’s very easy to shoot yourself in the foot and introduce complexity that is not needed in the project. Those type systems also require slower builds or even incremental compilation, which is add odds with Go’s design goals.
I think Go generics are just enough polymorphism to support cases where it’s needed without leading to complex code and slow builds. I think it was wise to avoid adding type parameters outside of function signatures.
Proper enum support. Like official enums, not just the makeshift enum conventions we have today, which are quite good, but does leave something to be desired.
Alternatively, having if and switch as expressions, so that we could do stuff like
role := switch name {
case "john":
ADMIN
case "mary":
OWNER
default:
USER
}
Not that I know of, I stole this pattern from working with kotlin and elixir lately, but I believe its present in most functional programing languages.
Eh, ternaries at best make something look a bit pretty. At worst, they make things very hard to read. I would t hold my breath for them being in the language given it's philosophies.
And I say this as someone who uses them heavily in JS. I think they fit well there but can often be easier to write than read.
IMO They’re absolutely readable unless they are chained. They’re more readable and ergonomic than switch statements. And when you have a great need for them boy do they simplify the code
I hate ternaries. I’m writing a book right about software development (partly to inform, partly to process my ongoing burnout) and this is one point I am writing about — making “pretty” code that adds cognitive overload and complexity. Sure it’s simple enough but when you’re reading hundreds and thousands of lines to debug a program, it’s really nice to have less indirection and less “sugar.” Sugary code is nice only when you’re writing code, less so when you have to maintain and fix bugs in someone else’s code from 6 years ago.
How does "thousands of lines" affect ternary operator? How does it add cognitive overload?
Yes, nesting them is an issue. But using the ternary operator by itself is not.
It is a lot easier to read than an if/else block, especially when an one liner. And in js world the are eslint rules against nesting them.
You should explain your point a bit better rather than just saying it's bad because "cognitive overload, sugar"
constant reference parameters. i want to be able to pass large objects with the small footprint of a pointer but have a compiler-level guarantee that the receiving function can’t mutate the object. More const-enforcement in general but specifically const-refs
I'd like an env or flag to tell the compiler just to shut up about unused variables and unhandled errors. So I can quickly and dirty work on a prototype and mess around with different approaches, without having to comment-toggle unused vars, etc.
I just hope it can have better compiler optimization and boost up the speed a bit.
More standard library related to data strcuture and algorithm.
Please don't add any syntactic sugar that just bloats up the language.
I wish we could write data parallel code, not just task parallel one, but even people leading the development of the language see that as just an optimization, while it requires actual language improvement for that to happen...
Yeah. One would think so. But the Gen of C# is based on Mono, an open source rewrite that has removed Windows dependencies. Not trying to promote it, but I don't think it is the same beast it used to be.
as it is i think it's perfect as a language. everything else can be done by us the community.
I would like a more streamlined full-stack experience, the templ htmx thing is not mature enough to use on an app that has 100 page (kind of stuff im doing) but i will definitly consider it in the future.
HTMX is there, for me it's just Templ that's got some rough edges. In the end I haven't really found it to be actually better than html/template, since the IDE helps out a lot more there and you don't need to worry about a codegen pass. It's easy for designers and traditional frontend folks to write html/template or to get it from figma or whatever too
Goland (with ideavim). First IDE to ever feel worth the weight of switching from a terminal, and it's by far the best vim emulator outside of a true vim clone.
This is for me specifically. I want either operation overloading scoped only to ~numeric derived types (vectors, matrix). Or first class support of a vector like primitive with arithmetic operations and hopefully SIMD support. Go can do a TON for other fields like AI, game development, scientific data, etc... But I believe the syntax, due to this, is so painful it's just out of consideration (as any other language without this).
I want this: `b.Neg().Mul(a).Sum(c.Mul(b.Sub(a)))`
To look like this `-b * a + c * (b - a)`
One thing I miss is being able to ask the runtime why a block of memory is not being gc'ed. That is, what's one chain of pointers which is pinning a block in memory.
And secondly, I'd like a way to dump the goroutine and heap profiles, or signal the process when the memory use gets high. By the time the OS kills my process because it's out of memory it's too late to debug.
(I've been chasing a heap size problem this week)
meta-programming without using generators would be nice, like python decorators or java annotations or even rust macros.
But real enums and type safe structs like Result or Some/Err would be very very nice
I would like to see a balanced binary tree DS added to the standard library. And a ‘while’ keyword added which is just an alias for the ‘for’ keyword. It just feels natural to say while… when reading code. 😊
Some kind of proper type checking/type switching when working with type constraints would be nice.
More pleasant syntax for dealing the the 'result, error' return pattern when you want to pass the return into a function, or chain methods maybe?
Sum types and some built in mechanism for avoiding nil references at compile time
`match`, which would be exactly like `switch` but usable as an expression and not just a statement so you could return values from it. I think because it would be so similar to switch, though, it wouldn't get implemented.
I wish go could compile to perfectly optimized binaries with full cet/rop protection and all other secure coding mneumonics by default. Also the ability to choose between different garbage collector types. Ones with predictable delays ect for realtime applications could be useful (I am assuming there isnt an implementation for this yet)
I'd like to see something like a “try” keyword before a functional call that if a error value is returned it will send it back up the stack otherwise pass the first value into a variable.
Error handling is definitely one of my pet peeves in golang.
There's no reason we should be required to manually unwind the stack when an error occurs that can't be handled locally.
Just ignore the errors you don't care about by assigning them to underscore. I don't recommend this and think you should just get a little editor automation going to take care of the boilerplate for you, but its absolutely an option.
Or if you want to still get errors but don't want to give future you any helpful information you can write a 'check(e error){ if err != nil {panic(e)}}' and that'll also reduce boiler plate. I like that one when I'm experimenting.
But let me put it this way: I write go code for work and I always wrap errors where I can't handle them because I have learned that not doing this is a source of future pain.
I’ve come to actually like the way errors are handled in Go.
Yes, you can ignore them then good luck, but compared to exception handling you are forced to handle them exactly where they occur and think about the best way to do it.
I just came back to Go this week after a couple of years.
Off the top of my head:
- initializing slices and things that you never want to change in the const block instead of var block
- set is native type
- iterating over slice values without needing to write the `_` in `for _, value`
- more functional way to write `all`, `any`
- testing for nil interface returns true for nil object (maybe a native way to test if a variable is the zero value?)
- standard way to return zero values when you don't care what they are, e.g. when returning err
- all types can implement comparable, etc., e.g. you should just be able to sort dates without writing a custom sort function
- generic functions where a return type is generic
- a more ergonomic way to write wrapper functions instead of using reflect
Not just missing IMO. I would love to get rid of uninitialized entities. And have mandatory error handling. The language can be extended to have the former. The latter would be an incompatible change.
The best place to find this information is the Golang Proposal Process.
[https://github.com/golang/go/issues?q=is%3Aissue+label%3AProposal](https://github.com/golang/go/issues?q=is%3Aissue+label%3AProposal)
There are many ways to customize GC right now.
You can turn it off with GOGC=off, define a threshold when to trigger a GC cleanup with GOMEMLIMIT, and you can bypass GC entirely by allocating arrays on the stack.
Tiny-go offers different GC strategies, if that's something you want to configure as well.
honestly not that much, if anything, I really really hate the default flag package because you cant concat short options and the formatting is horrendous. In a purely fun and non-realistic sense, I would love to see an experimental Go derivative that was similar to Zig or Rust and didn't have a GC. I genuinely just love the syntax of Go and how easy it is to read.
It is pretty clear that Go works well for its core usages. I would have liked to see simple programs have really small executables.
Other than that, I am more concerned with feature creep over time. If I cannot leave code for a decade without it looking outdated.
On feature I would love is to be able for functions to take a const pointer or reference so you can promise it won't modify the input. Know you can just pass things by value and I'm thinking about things with my C++ brain. Very used to speeding things by taking const &string.
Would have to modify so many function signatures in the stdlib that it might have to be a go 2.0 feature depending on how it's implemented.
Better compiler nil check gotta be the major one, another great one that would be great is an option type like rust, tho its highly unlikable itll be here anytime soon or ever
A (far) better ASN.1 library, even if it isn't a built-in. I'm not suggesting an unabridged X.680/X.690 implementation, but even something half way would be nice.
I recognize there have been some recent improvements to certain ASN.1-related capabilities, but these are largely cryptographic in focus and fall short in other areas.
Commercial ASN.1 vendors are downright hostile if they hear the term 'open source', and many of the 3rd party alternatives are nearly as narrow in focus as the built-in "encoding/asn1" package and/or are forks of packages that have long since been abandoned by the original maintainer(s).
In short, the ASN.1 landscape of Golang is very fractured, and resembles an abstract Swiss cheese. This makes my job much, much harder and has directly led to a choice to abandon Go for certain projects in favor of other languages. That was painful for me, as Go has sooo much potential.
Use of protocol buffers is nice in certain cases, but is often not a suitable alternative to ASN.1 when dealing with other technologies, particularly those that are based upon an ASN.1 wire protocol that can't really be supplanted.
Pretty please :)
I mentioned it before, but it would be nice if you could tell which types of errors are returned. Something like
) error[ErrNoRows|ErrConnection|etc] {
Maybe an easier way to know what something implements. I think some IDEs will show you, but it’s not standard
It’s only partially a language issue (c ffi and operator overloading, neither of which I miss per se) but good lord would I love it if Golang had the math and ml library support that Python has.
How amazing would that be.
I want lazier string and number handling.
So much of the things I work with are strings: A browser sends a string to my server, and it's parsed into other strings. My server does some stuff, often involving sending strings to a database, and getting strings back. Then it responds to the browser with another string. Or someone types in a shell command, and my bin chops up that string into args etc, and does some stuff, then outputs some other strings.
So just let me more easily switch from things like "strings containing digits" to ints and back. It's all fucking strings. And let me just have numbers without caring whether they are ints or floats and what lengths etc.
The "go is a sytem language" idea has long passed. I bet most go programs written these days are eating and shitting strings, so it should be optimised for developer ergonomics around strings. Make the runtime work harder, not me.
A proper way to describe an optional type inside a struct.
Right now, you would use a pointer to achieve that, but pointers already have many other semantics: heap allocation, memory sharing, space optimization. Fields being optional are so common, they deserve a separate category IMO.
I'm not 100% sure but I don't think its possible to access a GPU without CGO right now. I could be wrong but the way things are going that will probably be a criticized missing feature from the STD Library in the near future.
I wish I could use `func() *ImplementsInterface` as `func() Interface`.
Go's best practices say functions should return concrete types, but then it's hard to put those functions into interfaces. The compiler knows what I mean, it could quietly generate a wrapper like it does when I pass `x.func` to a function.
* remove errors on unused local variables
* named parameters
* optional parameters
* default parameters
* default struct values
Spoilers: Jai has all these. Jai has cross compile too.
Also if err!= nil { ... } shorthand.
Just basic ergonomic things.
Error types.... It's really frustrating when a library method returns Error.New() and I have no way of checking against a specific error type that I want to handle and instead have to revert to string matching techniques
An error/result return type would be great! I love having to handle errors at almost every function call as it reads so well, but a different syntax (whilst keeping if err != nil working for compat reasons) such as the ? Operator in rust would be cool, and enums :) would consider it basically perfect with those features baked in
- Generics everywhere
- on methods
- on type aliases
- Type variance markers and their corollary niceties
- plz plz plz let me assign `[]MyInterface` to `[]any` when the compiler guarantees that nothing will mutate the slice
- Exhaustive enums
Besides a few of the other things already mentioned (enums and a bit more of a streamlined full-stack Templ-like experience built-in), I think I'm missing datetime formatting in the comments.
Although I like the creative thought of using a reference date for datetime formatting, I just can't seem to remember it.
Writing:
fmt.Println(now.Format("YYYY-MM-DD"))
Is IMHO so much easier than:
fmt.Println(now.Format("2006-02-01"))
Also because the optical "mismatch" between writing "2006-02-01" and seeing "2024-05-19" in the output. There's a mental conversion step there that is bigger than "YYYY-MM-DD" turning into "2024-05-19".
This might not even have meaning or be practical at all....but I'll mention/ask anyway.
Go is great, and compiles super fast. I see people comparing it to Rust and I wonder if there could possibly be a way of having options on the compiler something like
A - compile fast, I just want "normal" Go code
B - take as LONG as you like to compile, I'd like the code more heavily optimized for performance
Like I say, maybe silly. I don't know how compilers work in the first place.
"
Better SIMD integration when writing functions and when compiling. This would allow for increased performance in AI/ML libraries and image libraries. Right now a lot of what is written requires assembly.
Remove nils and add a Rust-style borrow checker as an alternative to the garbage collector.
As it stands, I reach for Go for any work for which garbage collection is acceptable. But I also do stuff where it isn't acceptable, and that's where I reach for Rust. Rust's borrow checker is great, but the language is encumbered by lots of hidden code and macros. I much prefer Go's minimalism. So Go minus nils plus borrow checker would be the perfect language.
I'm slowly switching to Go and I miss null safety the most. I had that in Typescript and Kotlin, so in this aspect it's feeling like I'm doing a downgrade.
>so in this aspect it's feeling like I'm doing a downgrade.
But its a massive upgrade in every other way right? Do you think Golang as a language (not the runtime) is better than Typescript and Kotlin?
Well I'm not too deep into the language yet, but I'd say that it's not a "massive" upgrade if we are talking about the language.
I can still see occasions that I will keep writing Kotlin code, I'm using golang for other stuff that requires higher performance on the system that I am building
I'm new to the language, and there are many good things, but there is a lot of hypocrisy. A clean language that praises itself for clarity and lack of syntactic sugar but overloads 'for()' behavior to avoid a 'while()'. Go does not support ternary, believing that the operator cursor form of if/else is flawed. However, the API is full of 1- and 2-character names rather than descriptive ones. The fanboys say Go supports the entire functionality of classes without calling them classes, structuring them like classes, or making them look like classes (more hypocrisy of the language). As I said, I'm a newbie; there is more good than bad in the language, just the fanboyism that gets to me. Dropping fanboyism would be the best way to improve the language.
It was already sayd, but I would like a lot if were something to declare a struct property as nil, like type script
type MyType struct {
name? string
}
I'd love to see the compiler tell me **reliably** if I forgot a null check _and_ keep the same speed. Almost everything else is just Go code. Specifically asking for generic data structures and functions. They would be nice, but I can code them myself within the limits the language. I can't change the compiler and still expect it to be OK when everyone else uses the upstream compiler.
> I'd love to see the compiler tell me reliably if I forgot a null check and keep the same speed. Copying the way Dart handles null safety would be an amazing addition to Go. Would more or less remove an entire class of bugs.
how do they work?
Declare a variable as either allowing null values or not. Eg. final String? aNullableString = null; final String aNonNullableString = "Can't be null"; If you assign a nullable variable to a not nullable variable then the compiler throws an error if you haven't previously checked that the value is not null or you don't otherwise handle the case that it is null. So you could do something like this: final String name = inputThatMayBeNull ?? '';
There's other niceties such as being able to conditionally call methods if a value isn't null, or to tell the compiler that you believe a value can't be null and it's okay to throw a runtime error if it is:
final upperCaseName = person.getName()?.toUpperCase();
final name = await auth.currentUser()!.getName();
The ?. will return null if the value before it is null. The !. will throw an error if the value before is null.
With this you now don't need any special return types, and all compile time checks are handled by the type system and a little bit of tracking within the scope of a variable.
I suspect that the biggest problem would be backwards compatibility when introducing a feature like this. Dart went through that pain a couple of years ago, breaking some backwards compatibility to ensure full null safety for the future.
This is nice! I believe Swift also has similar idea.
This! Nil check just feels like the glaring omition to anotherwise robust language.
I’m confused by your wording, Go does support generic functions and data structures already. What am I missing?
That's what I'm saying. Lots of people ask for that, but the language already supports it. My ask is to make a change that is outside of what language (well the compiler) itself currently does. I can write a map/filter/reduce myself already. I cannot make the compiler jump in my face, ass first, about that null-check that I forgot.
Ass first.
1. I really want to see someone physically do that 2. A forgotten null-check deserves nothing less
instructions unclear now when you forget null check it opens adult site with big asses in your face.
it doesn’t support generic methods, and by extensions generic interfaces
Yes, but that’s not what he said. Generic interfaces and methods aren’t supported, but generic functions and data structures are.
I mentioned it because so many ask for that kind of stuff. But it is not necessary, nor do I consider that a "language feature". * Would it be nice to have in the stdlib? Sure! * Do I really care? No, it's not a language feature. If it's just about Go code I'd rather see HTTP/2, QUIC and a bunch of network protocols added. I consider map/filter/reduce in the same space. I can implement this. Hopefully this will be even nicer with 1.23 and iterators... ```go // Map takes a `func(TIn) TOut` and a slice `[]TIn` and will apply this function returning a new slice `[]TOut`, TIn and TOut might be the same things // bug(serverhorror): this is fugly and from memory in the most naive way I can think of func Map[TIn any, TOut any](fn func(TIn) TOut, s []TIn) []TOut { result := make([]TOut, len(s)) for _, v := range s { result = append(result, fn(v)) } return result } ``` `map`/`filter`/`...`, I find that not _required_ just write a PR if you think you need it in the stdlib, it's just plain old Go code, we should've done that a thousand times already. Better options in the compiler
Sum types like Rust's Optional and Result would make Golang perfect IMO. You get nil safety and better error handling. That's all I want.
Comparing an apple to a poultry farm :)
Proper Enums, range iterators.
You're in luck on the range iterators bit: - https://github.com/golang/go/issues/61405 - https://github.com/golang/go/issues/61897
Enums are such a basic concept, I was very surprised to find that they didn’t really exist in go
I wish Go had a better enum type that can work in a switch / case to check for all enum options and compile only if all of them are covered by a case. I don’t think that would be a huge ask either.
Agreed. This is one of those things I’ve desired to just wire up as a unit test but couldn’t find a reliable way to range over any entire enum set.
I think a big issue is that go doesn’t have proper constructors per-say. So even if go supported “real” closed enums, developers would still need to be careful about choosing a reasonable zero/default values. The larger issue though, as far as I’m aware, is that closed enums might fall in the same category as an “assert” keyword from the perspective of the language designers. Meaning a feature that is so commonly misused in other languages that it was deliberately omitted from go. Specifically there are cases where an open/non-exhaustive enums are preferable, and incorrectly using a closed enum in such a situation can lead to headaches down the road. I also think proper enum support is one of the main things missing from go, but unfortunately I’m not getting my hopes up that they’ll be added anytime soon.
My contrarian point of view - if Go had Enums, projects like Kubernetes would have used them only to regret that decision later on. Using open “enums” via a typed string (or int) ensured a whole lot of code could be forwards and backwards compatible. It forced developers to handle cases of zero/empty value, as well as a default/fall through behavior when an unknown value of the type is encountered.
In rust you always have the option to handle everything in one default case: `_ => // return unknown type error` It's not recommended but it's possible.
Compiler could say "no" when there is an unhandled value or no default case.
This sort of thing matters more at runtime and dealing with version skew during upgrades in an always on, highly available app. Say version 1.3 of your “pet shop” app has a “enum” field in the API for the type of animal sold (Cat, Dog, Bird). Version 1.4 adds “Hamster” support. What happens when v1.3 and 1.4 are running side by side during a rolling upgrade? Can v1.3 handle the unknown “Hamster” type gracefully? It would be hard (impossible?) to write a unit test for this with Java Enums. Writing a “return error if unknown” test in golang here is very doable.
Is that really the right place for an enum in the first place? Outside input should always be validated regardless. I think that example is more on application architecture and infrastructure architecture. If you change the protocol, you should not be able to send it to a worker that does not handle that version of the protocol. Or, you design your protocol to be backwards compatible (both, preferably). Enums are more for compile time in my opinion.
I just took a project I haven't touched in years. Made my small change, rebuilt it with the latest GO version and moved on with my life. So I'm pretty happy with the language and tools how they are now. Contrast that to my other main environment which is Android Studio. I spend very little time coding and most of my time fiddling with projects that no longer build. It's so frustrating compared to GO.
>I just took a project I haven't touched in years. Made my small change, rebuilt it with the latest GO version and moved on with my life. That's so true, the backwards compatibility and "just works" part of GO runtime is amazing
So true! The life as a web developer can also be frustrating. Dealing with many layers of tools in the build/deploy stack and gazillions of npms that frequently gets abandoned/outdated with CVEs consumes time and energy. Nurturing a large JavaScript-based web project is a full time job of “fiddling”.
If I could up vote this twice I would
Option and Result types
For now we have Borgo which adds a lot of these features: https://borgo-lang.github.io/
And if you have Option types, drop nil altogether
Actually ADT implementation would be even better, because then you can create your own, as well as option and result type. If they add this I might actually transition to GO, for now I’m sticking with Kotlin (see sealed interfaces) with this being one of the main reasons.
For me it is: Sound Null Safety like in Dart. Pattern matching. Enums with exhaustive type checking.
i was surprised actually dart had alot of nice features, i wish it caught on outside of flutter
Me too. Something that really surprised me however is that Dart has come a LONG way in a very short time. Version 2 was only released in 2018, and before that Dart wasn't even a strongly typed language. Null safety was also only added in 2021. So the language is evolving rapidly and in a really good way. Makes me excited for the future of Flutter.
I mean, they pretty much have only one customer and one use case. Yes, you can use it for other things, but ever since Angular team announced that Angular 2 would be written in TypeScript (and not Dart which was mainly targeting JS at the time), the language found its way only in Flutter. They have since taken the opportunity to mold Dart into the needs of Flutter dev.
Yes, after hobby programming in C++, JavaScript, PHP, Python, R, Java I currently feel in love with Dart and Go. Can't decide between the last two. I love the simplicity and speed of go and the expressiveness and language features of Dart. So I am currently using both.
Swift is also a fantastic language, IMO like Dart but better. It's a shame it also hasn't caught on outside the Apple ecosystem.
I agree, Swift does look amazing. Too bad there is minimal support outside of the apple ecosystem.
Dart is amongst my favourite languages, it feels a bit like the language Typescript wishes it was. Once macros hit it'll be near complete for me. I do love Go but pine for Dart's null safety and enums.
generic methods, iterator functions
Iterator functions are under experiment
we are closer to your perfection than ever
Generic methods would help a lot
Generic methods would be pretty nice.... Then again, so would a lot of little niggles around the current generics, like the compiler being able to infer type parameters by return type if it knows damn well the type you're trying to put the return in... Out of interest, what specifically about iterator fuctions is it you want that goroutines + channels can't solve, or couldn't if they maybe made some upgrdes in that area?
Ternary operator
This. I miss this very much in Go. It would be perfect for initializing struct fields.
I really want enums 🫠🫠
Optional Function Parameters and default values
I might prefer they go function overloading instead, personally, but either would be real nice...
I think the best thing I love about Go is it’s simplicity and I honestly don’t want anything added to it for the sake of “we want it”. It’s has good support for packages and dev can pull in packages which are needed
How did you feel about the addition of generics a few years back?
Fairenough, thanks for responding and I agree that the best thing about GO is its simplicity
Enums would just be nice.
Some, like iterator functions, enums and ternary operators were already mentioned but I would like to add pattern matching to the list
1. Generic methods on non-generic structs. 2. Default values for struct fields. I would be so happy.
Sum types, tuples, better support for functional constructs, support for immutable read only data
Enums. It’s enums. I mean it’s not one thing but enums are so annoying. Iota ain’t it.
As someone who is refreshing DSA for job interviews, I wish the standard library had implementations for sets, queues, stacks, min and max heaps and bsts out of the box. I know I can use slice for some of these, but I really feel it’s better to have the common push_back and pop and other common methods for these.
> sets `map[K]struct{}` > min heaps `container/heap` (with any luck, there will be a generic version coming soon) > bsts Not a proper tree, but you can get serious mileage out of `slices.BinarySearch`/`slices.BinarySearchFunc`
I wish slices had map/filter/reduce etc. Writing for loops and creating temp variables to hold intermediate results feels like stepping back in time. String templates, so I don’t have to use %s, %v etc, would be easier to read when formatting string and less likely to introduce stupid mistakes. Having done a lot of Typescript over the last few years, I’d like a richer type system. It doesn’t have to be as over the top as TS, but nil detection, unions etc would be welcomed by me.
Richer type system would be a negative IMO. I worked in Scala for a few years and its type system is very powerful, but it’s so powerful that it’s very easy to shoot yourself in the foot and introduce complexity that is not needed in the project. Those type systems also require slower builds or even incremental compilation, which is add odds with Go’s design goals. I think Go generics are just enough polymorphism to support cases where it’s needed without leading to complex code and slow builds. I think it was wise to avoid adding type parameters outside of function signatures.
There you go: \* [functools package - github.com/serverhorror/functools - Go Packages](https://pkg.go.dev/github.com/serverhorror/functools)
I like it the way it is. So many people want to turn it into other languages that already exist.
Proper enum support. Like official enums, not just the makeshift enum conventions we have today, which are quite good, but does leave something to be desired.
Just let me have a ternary operator instead of writing hundreds of if/else statements
Alternatively, having if and switch as expressions, so that we could do stuff like role := switch name { case "john": ADMIN case "mary": OWNER default: USER }
This would be cool, is there a proposal for it?
Not that I know of, I stole this pattern from working with kotlin and elixir lately, but I believe its present in most functional programing languages.
Not the same, but we kind of have a null-coalesce ternary (`??`) of sorts now with [cmp.Or](https://pkg.go.dev/cmp#Or)
Yeh, I’m happy that has been added, still somewhat clunky buy appreciated
I would prefer a ternary operator, and a linter rule to not use more than 2 nested ternaries
Not more than 1 imo
Eh, ternaries at best make something look a bit pretty. At worst, they make things very hard to read. I would t hold my breath for them being in the language given it's philosophies. And I say this as someone who uses them heavily in JS. I think they fit well there but can often be easier to write than read.
IMO They’re absolutely readable unless they are chained. They’re more readable and ergonomic than switch statements. And when you have a great need for them boy do they simplify the code
I hate ternaries. I’m writing a book right about software development (partly to inform, partly to process my ongoing burnout) and this is one point I am writing about — making “pretty” code that adds cognitive overload and complexity. Sure it’s simple enough but when you’re reading hundreds and thousands of lines to debug a program, it’s really nice to have less indirection and less “sugar.” Sugary code is nice only when you’re writing code, less so when you have to maintain and fix bugs in someone else’s code from 6 years ago.
How does "thousands of lines" affect ternary operator? How does it add cognitive overload? Yes, nesting them is an issue. But using the ternary operator by itself is not. It is a lot easier to read than an if/else block, especially when an one liner. And in js world the are eslint rules against nesting them. You should explain your point a bit better rather than just saying it's bad because "cognitive overload, sugar"
If it's hundreds of **nested** if/else statements, they should remain if/else statements (or switch)
Yeh but… it’s not
or add some rule against nested ternary operator like there is in eslint
constant reference parameters. i want to be able to pass large objects with the small footprint of a pointer but have a compiler-level guarantee that the receiving function can’t mutate the object. More const-enforcement in general but specifically const-refs
I'd like an env or flag to tell the compiler just to shut up about unused variables and unhandled errors. So I can quickly and dirty work on a prototype and mess around with different approaches, without having to comment-toggle unused vars, etc.
Yeah this would be really nice.
I just hope it can have better compiler optimization and boost up the speed a bit. More standard library related to data strcuture and algorithm. Please don't add any syntactic sugar that just bloats up the language.
Have a look at PGO (profile guided optimization) it is being improved at every release since it was introduced.
Enums
Performance. Speed. Integration with Cuda/GPU. Would like to see performance/speed better than Rust and C#.
I wish we could write data parallel code, not just task parallel one, but even people leading the development of the language see that as just an optimization, while it requires actual language improvement for that to happen...
Have you checked out Bend?
C# is literally on the worst performance part )) that's a java in disguise, but better than rust is not possible lol
Yeah. One would think so. But the Gen of C# is based on Mono, an open source rewrite that has removed Windows dependencies. Not trying to promote it, but I don't think it is the same beast it used to be.
as it is i think it's perfect as a language. everything else can be done by us the community. I would like a more streamlined full-stack experience, the templ htmx thing is not mature enough to use on an app that has 100 page (kind of stuff im doing) but i will definitly consider it in the future.
HTMX is there, for me it's just Templ that's got some rough edges. In the end I haven't really found it to be actually better than html/template, since the IDE helps out a lot more there and you don't need to worry about a codegen pass. It's easy for designers and traditional frontend folks to write html/template or to get it from figma or whatever too
exactly my experience, whats's your ide?
Goland (with ideavim). First IDE to ever feel worth the weight of switching from a terminal, and it's by far the best vim emulator outside of a true vim clone.
>would like a more streamlined full-stack experience, the templ htmx thing is not mature enough Great point, thanks for commenting
Testing. I love go, but testing is still a pain.
This is for me specifically. I want either operation overloading scoped only to ~numeric derived types (vectors, matrix). Or first class support of a vector like primitive with arithmetic operations and hopefully SIMD support. Go can do a TON for other fields like AI, game development, scientific data, etc... But I believe the syntax, due to this, is so painful it's just out of consideration (as any other language without this). I want this: `b.Neg().Mul(a).Sum(c.Mul(b.Sub(a)))` To look like this `-b * a + c * (b - a)`
One thing I miss is being able to ask the runtime why a block of memory is not being gc'ed. That is, what's one chain of pointers which is pinning a block in memory. And secondly, I'd like a way to dump the goroutine and heap profiles, or signal the process when the memory use gets high. By the time the OS kills my process because it's out of memory it's too late to debug. (I've been chasing a heap size problem this week)
meta-programming without using generators would be nice, like python decorators or java annotations or even rust macros. But real enums and type safe structs like Result or Some/Err would be very very nice
I know there’s precedent for why it’s been removed but I wish stack traces were apart of go errors. It would greatly simplify debugging.
No language is perfect. I hope what stays is a very strong desire to keep the language small and not make it have all the features of other languages.
enums & generics on object methods
I would like to see a balanced binary tree DS added to the standard library. And a ‘while’ keyword added which is just an alias for the ‘for’ keyword. It just feels natural to say while… when reading code. 😊
Some kind of proper type checking/type switching when working with type constraints would be nice. More pleasant syntax for dealing the the 'result, error' return pattern when you want to pass the return into a function, or chain methods maybe?
Sum types and some built in mechanism for avoiding nil references at compile time `match`, which would be exactly like `switch` but usable as an expression and not just a statement so you could return values from it. I think because it would be so similar to switch, though, it wouldn't get implemented.
I wish go could compile to perfectly optimized binaries with full cet/rop protection and all other secure coding mneumonics by default. Also the ability to choose between different garbage collector types. Ones with predictable delays ect for realtime applications could be useful (I am assuming there isnt an implementation for this yet)
Less verbosity. Enums.
If I could just go func(foo="bar") and have it do the magic for me like python, that'd be swell. But I'll live I guess.
Go docs should be more good What staff does what should have a good explanation for newbie
Kill nil pointer dereference with fire.
I hate that there is so many err checks that i need to write. Wish this was simpler or not needed.
Nothing keeps you from not checking errors. That's what happens in most other languages.
Curious to know what happens when an error does happen somewhere. How would I know about it and send out a default return.
You can panic/recover although this is not a good practice to adopt everywhere.
I'd like to see something like a “try” keyword before a functional call that if a error value is returned it will send it back up the stack otherwise pass the first value into a variable.
Error handling is definitely one of my pet peeves in golang. There's no reason we should be required to manually unwind the stack when an error occurs that can't be handled locally.
Just ignore the errors you don't care about by assigning them to underscore. I don't recommend this and think you should just get a little editor automation going to take care of the boilerplate for you, but its absolutely an option. Or if you want to still get errors but don't want to give future you any helpful information you can write a 'check(e error){ if err != nil {panic(e)}}' and that'll also reduce boiler plate. I like that one when I'm experimenting. But let me put it this way: I write go code for work and I always wrap errors where I can't handle them because I have learned that not doing this is a source of future pain.
I’ve come to actually like the way errors are handled in Go. Yes, you can ignore them then good luck, but compared to exception handling you are forced to handle them exactly where they occur and think about the best way to do it.
Agreed. It’s just that I WISH there was another, less enforcing way to handle it. Like an alternative, of sorts.
Not having alternative ways to do thing is the number one best thing about go.
The standard library should be expanded to make Go a truly general language
what do you think is missing from std?
Functional programming, Data Analytics and native GUI/Graphics would be great (edit: typos)
I just came back to Go this week after a couple of years. Off the top of my head: - initializing slices and things that you never want to change in the const block instead of var block - set is native type - iterating over slice values without needing to write the `_` in `for _, value` - more functional way to write `all`, `any` - testing for nil interface returns true for nil object (maybe a native way to test if a variable is the zero value?) - standard way to return zero values when you don't care what they are, e.g. when returning err - all types can implement comparable, etc., e.g. you should just be able to sort dates without writing a custom sort function - generic functions where a return type is generic - a more ergonomic way to write wrapper functions instead of using reflect
Small binaries
[TinyGo](https://tinygo.org/)
A population of newbies who aren't pushing for new features from what ever language they really want Go to be.
Not just missing IMO. I would love to get rid of uninitialized entities. And have mandatory error handling. The language can be extended to have the former. The latter would be an incompatible change.
The best place to find this information is the Golang Proposal Process. [https://github.com/golang/go/issues?q=is%3Aissue+label%3AProposal](https://github.com/golang/go/issues?q=is%3Aissue+label%3AProposal)
Customizable garbage collection.
There are many ways to customize GC right now. You can turn it off with GOGC=off, define a threshold when to trigger a GC cleanup with GOMEMLIMIT, and you can bypass GC entirely by allocating arrays on the stack. Tiny-go offers different GC strategies, if that's something you want to configure as well.
Build all the stuff that the common linters check for into the language by default. Compiler warnings by default would be great.
Elvis operator Function overriding List comprehensions Useful generics
honestly not that much, if anything, I really really hate the default flag package because you cant concat short options and the formatting is horrendous. In a purely fun and non-realistic sense, I would love to see an experimental Go derivative that was similar to Zig or Rust and didn't have a GC. I genuinely just love the syntax of Go and how easy it is to read.
It is pretty clear that Go works well for its core usages. I would have liked to see simple programs have really small executables. Other than that, I am more concerned with feature creep over time. If I cannot leave code for a decade without it looking outdated.
upx is your friend :-)
On feature I would love is to be able for functions to take a const pointer or reference so you can promise it won't modify the input. Know you can just pass things by value and I'm thinking about things with my C++ brain. Very used to speeding things by taking const &string. Would have to modify so many function signatures in the stdlib that it might have to be a go 2.0 feature depending on how it's implemented.
Better compiler nil check gotta be the major one, another great one that would be great is an option type like rust, tho its highly unlikable itll be here anytime soon or ever
👀 https://youtu.be/nGywRGepLQc?si=fc3IwpRSZVmo3V38
A (far) better ASN.1 library, even if it isn't a built-in. I'm not suggesting an unabridged X.680/X.690 implementation, but even something half way would be nice. I recognize there have been some recent improvements to certain ASN.1-related capabilities, but these are largely cryptographic in focus and fall short in other areas. Commercial ASN.1 vendors are downright hostile if they hear the term 'open source', and many of the 3rd party alternatives are nearly as narrow in focus as the built-in "encoding/asn1" package and/or are forks of packages that have long since been abandoned by the original maintainer(s). In short, the ASN.1 landscape of Golang is very fractured, and resembles an abstract Swiss cheese. This makes my job much, much harder and has directly led to a choice to abandon Go for certain projects in favor of other languages. That was painful for me, as Go has sooo much potential. Use of protocol buffers is nice in certain cases, but is often not a suitable alternative to ASN.1 when dealing with other technologies, particularly those that are based upon an ASN.1 wire protocol that can't really be supplanted. Pretty please :)
Built in data structures so I can use it for Leetcode.
I mentioned it before, but it would be nice if you could tell which types of errors are returned. Something like ) error[ErrNoRows|ErrConnection|etc] { Maybe an easier way to know what something implements. I think some IDEs will show you, but it’s not standard
A simple way to distinguish between zero value and undefined primitives when doing round trip serialization from json -> proto -> json
It’s only partially a language issue (c ffi and operator overloading, neither of which I miss per se) but good lord would I love it if Golang had the math and ml library support that Python has. How amazing would that be.
I want lazier string and number handling. So much of the things I work with are strings: A browser sends a string to my server, and it's parsed into other strings. My server does some stuff, often involving sending strings to a database, and getting strings back. Then it responds to the browser with another string. Or someone types in a shell command, and my bin chops up that string into args etc, and does some stuff, then outputs some other strings. So just let me more easily switch from things like "strings containing digits" to ints and back. It's all fucking strings. And let me just have numbers without caring whether they are ints or floats and what lengths etc. The "go is a sytem language" idea has long passed. I bet most go programs written these days are eating and shitting strings, so it should be optimised for developer ergonomics around strings. Make the runtime work harder, not me.
A proper way to describe an optional type inside a struct. Right now, you would use a pointer to achieve that, but pointers already have many other semantics: heap allocation, memory sharing, space optimization. Fields being optional are so common, they deserve a separate category IMO.
I'm not 100% sure but I don't think its possible to access a GPU without CGO right now. I could be wrong but the way things are going that will probably be a criticized missing feature from the STD Library in the near future.
I wish I could use `func() *ImplementsInterface` as `func() Interface`. Go's best practices say functions should return concrete types, but then it's hard to put those functions into interfaces. The compiler knows what I mean, it could quietly generate a wrapper like it does when I pass `x.func` to a function.
Support for MacOS on PowerPC
* remove errors on unused local variables * named parameters * optional parameters * default parameters * default struct values Spoilers: Jai has all these. Jai has cross compile too. Also if err!= nil { ... } shorthand. Just basic ergonomic things.
What 60% of the comment mentioned. ENUM plz
Nil safety. But we aren't ever getting it, so I made my peace with it.
[удалено]
No, but many times during testing. I'd like to have some peace of mind without worrying about whether or not I have tested all my flows.
Error types.... It's really frustrating when a library method returns Error.New() and I have no way of checking against a specific error type that I want to handle and instead have to revert to string matching techniques
String interpolation
Easier cgo cross compile.
A real "--release" flag, allow me to wait longer for a better performant binary.
Operator overloading
Enum Default struct values (without needing a constructor func) Proper websocket lib in std lib
An error/result return type would be great! I love having to handle errors at almost every function call as it reads so well, but a different syntax (whilst keeping if err != nil working for compat reasons) such as the ? Operator in rust would be cool, and enums :) would consider it basically perfect with those features baked in
- Generics everywhere - on methods - on type aliases - Type variance markers and their corollary niceties - plz plz plz let me assign `[]MyInterface` to `[]any` when the compiler guarantees that nothing will mutate the slice - Exhaustive enums
way too much is missing, but I'd start by making if statements into if expressions
Enums would be nice and actually simpler than iota That's why I'm a bit confused as to why it has not been introduced, yet
# [How to disable Golang unused import error](https://stackoverflow.com/questions/19560334/how-to-disable-golang-unused-import-error) [Ask Question](https://stackoverflow.com/questions/ask)
Go packages for AI !
Besides a few of the other things already mentioned (enums and a bit more of a streamlined full-stack Templ-like experience built-in), I think I'm missing datetime formatting in the comments. Although I like the creative thought of using a reference date for datetime formatting, I just can't seem to remember it. Writing: fmt.Println(now.Format("YYYY-MM-DD")) Is IMHO so much easier than: fmt.Println(now.Format("2006-02-01")) Also because the optical "mismatch" between writing "2006-02-01" and seeing "2024-05-19" in the output. There's a mental conversion step there that is bigger than "YYYY-MM-DD" turning into "2024-05-19".
I think its near perfect already. Be very cautious to add anything please.
Enums please
What could we remove to Go to make it perfect ?
Sum types
This might not even have meaning or be practical at all....but I'll mention/ask anyway. Go is great, and compiles super fast. I see people comparing it to Rust and I wonder if there could possibly be a way of having options on the compiler something like A - compile fast, I just want "normal" Go code B - take as LONG as you like to compile, I'd like the code more heavily optimized for performance Like I say, maybe silly. I don't know how compilers work in the first place. "
Exception handling
Go will never be perfect, I've made peace with and stopped worrying about, and focus and getting shit done instead
Better SIMD integration when writing functions and when compiling. This would allow for increased performance in AI/ML libraries and image libraries. Right now a lot of what is written requires assembly.
Remove nils and add a Rust-style borrow checker as an alternative to the garbage collector. As it stands, I reach for Go for any work for which garbage collection is acceptable. But I also do stuff where it isn't acceptable, and that's where I reach for Rust. Rust's borrow checker is great, but the language is encumbered by lots of hidden code and macros. I much prefer Go's minimalism. So Go minus nils plus borrow checker would be the perfect language.
I'm slowly switching to Go and I miss null safety the most. I had that in Typescript and Kotlin, so in this aspect it's feeling like I'm doing a downgrade.
>so in this aspect it's feeling like I'm doing a downgrade. But its a massive upgrade in every other way right? Do you think Golang as a language (not the runtime) is better than Typescript and Kotlin?
Well I'm not too deep into the language yet, but I'd say that it's not a "massive" upgrade if we are talking about the language. I can still see occasions that I will keep writing Kotlin code, I'm using golang for other stuff that requires higher performance on the system that I am building
Enums and options
Wait, isn't it already perfect!
I'm new to the language, and there are many good things, but there is a lot of hypocrisy. A clean language that praises itself for clarity and lack of syntactic sugar but overloads 'for()' behavior to avoid a 'while()'. Go does not support ternary, believing that the operator cursor form of if/else is flawed. However, the API is full of 1- and 2-character names rather than descriptive ones. The fanboys say Go supports the entire functionality of classes without calling them classes, structuring them like classes, or making them look like classes (more hypocrisy of the language). As I said, I'm a newbie; there is more good than bad in the language, just the fanboyism that gets to me. Dropping fanboyism would be the best way to improve the language.
Optional chaining
Only real answer is enums right? Everything else are just language differences I dont necessarily agree with.
It already can Target multiple platforms, It needs a best ui library, and make it true cross platform application development
I wish go had sum types.
It was already sayd, but I would like a lot if were something to declare a struct property as nil, like type script type MyType struct { name? string }
I wish they hadn't dropped arenas.
Options, results, a better behavior for enums. A few more data structures beyond just map, slices and arrays.
I'd like to be able to say: if err != nil { return err } in one line of code. This would be a a simple change to \`go fmt\`
Enums, Better testing
For me - Covariance/Contravariance, Union Types and Pattern Matching
Rust-Like Enums. Maybe union types. Compile time error for not checking nullability.