27 ms·

I really like the engineering principles in general that the Go team uses, however, I just don't like Go. That isn't meant as a slight or anything other than si

I really like the engineering principles in general that the Go team uses, however, I just don't like Go. That isn't meant as a slight or anything other than simply my opinion. That said, I really like the idea of a simple language based on the sort of principles demonstrated here. The runtime seems really nice, I just wish I liked the language better (IMO: not expressive enough, needs better error handling, needs much better enums, needs pattern matching, has error prone C-style 'for', almost everything is statements not expressions, special comments are error prone, has nil pointers, etc.). In the end I think if someone were to write a slightly simpler version of Rust with the Go runtime it might be pretty neat. That said, I don't know what I'd want to drop from Rust so maybe I'm just fantasizing.

Zababa 4y ago
> In the end I think if someone were to write a slightly simpler version of Rust with the Go runtime it might be pretty neat. OCaml kind of gives you that, but the dev experience isn't as good as Rust or Go in my opinion. Still, I enjoy it a lot, more than Go or Rust.
- nu11ptr 4y ago
  Agreed - I really like OCaml. Unfortunately it isn't popular enough to get tons of ecosystem love, so I could never find the libraries I need. I'd be pretty happy if it got more popular. Maybe the new multicore work will help.
  - galangalalgol 4y ago
    What about F#?
  - nextos 4y ago
    Yeah, came here to say the same thing. OCaml is pretty great, and the addition of multicore and algebraic effects will make it even better. It does have some unique ecosystem elements such as Coq, WhyML, Mirage, etc. But common components could be definitely improved.
- lairv 4y ago
  Does OCaml matches Go speed though ?
  - agent281 4y ago
    They actually sit right next to each other on programming language benchmarks game. Scroll down to CPU seconds, median and percentiles. https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- int_19h 4y ago
  Rust is basically what you get if you start with OCaml, remove the GC, and add enough features to the type system to compensate for that without giving up on safety.
akira2501 4y ago
I haven't found any issues with expression, so far. I wouldn't use it to write a UI, but for writing networking code or automated tasks I find it perfectly suited to the task. I appreciate it's error handling. It's burdensome, sure, but it presents almost no additional cognitive load when attempting to reason about control flow. It essentially has no enums. However, it has a comfortable type system that can wrap primitive types, and you can define methods on those wrapped types. It's serviceable, but not elegant. I have never been a fan of pattern matching outside of functional languages. The phenomenon I notice in languages that do have it, is the majority of uses cases seem to be a pattern match with two outcomes, one a Some() and the other a None(). It really seems like a more annoying way to write if {} else {}. It has for, but it also has 'range.' It makes up for a lot. It has nil pointers, which are just a "zero value." It's not uncommon to make it useful and safer in certain contexts. You can request a lookup in a map that is nil. You can ask for the length of a slice that is nil. You get sensible answers still. There are still footguns, but they're all single barrel.. which is _nicer_. I don't need a perfect language. Good enough with low cognitive load and amazing cross-compile facilities I'll take any day of the week.
- nu11ptr 4y ago
  I will agree Rust has a higher "cognitive load", but not if you write it every day. I think Rust might be tough to leave and come back say a year later, but Go admittedly would be easy. That said, having written 50K+ code in both languages, I never want to write Go again. Rust on the other hand is all I want to write now. I do wonder how many people who understand Go's limitations (and work around them as you point out above) have truly given Rust a try (takes a few months - can't be done faster). I can't imagine anyone would want to go back tbh, but maybe I'm wrong. EDIT: In fairness, there is one thing and exactly one thing I miss about Go: compile times. Rust is simply no competition here, but in trade, it is doing a ton of extra work. Trade offs.
  - ikiris 4y ago
    The problem with rust is explicitly that cognitive load in large codebases. It is much easier to read go code than rust when working on many things. Rust fits great if you don't scale though.
User23 4y ago
This is pretty much exactly how I feel. I have great respect for the Go team. I broadly agree with their design philosophy. I think CSP is a great theory for concurrency. And I just don’t really like writing Go. I don’t hate it, but I feel like I have to either fight the language or just repeat myself an awful lot. Honestly, I suspect the deficiency is on my end. Perhaps I’ve just spent too much time with Lisp and have experienced some professional deformation.
- KerrAvon 4y ago
  It's OK to have ergonomic opinions about languages! In scriptingland, I find Python abhorrent. Ruby fits my brain like a glove (the core language, not Rails). Doesn't indicate anything about the quality of the languages or their respective partisans.
  - dopidopHN 4y ago
    Look at you guys using nice looking languages! Haha, Java got better, but oh god it’s still verbose. We got rid of the getter setter silliness to be in “constructor land.” ( immutable records from Java 17 ) Function are still not first class citizens, but … they have a working visa now. You can shove lambda anywhere. It’s still awkward to write functional code Meh. Recently I’ve been really productive with it and I like the sheer boredom and lack of surprises.
    - RhodesianHunter 4y ago
      Most developers on the JVM with any freedom have switched to Kotlin.
      - fs111 4y ago
        citation needed
        RhodesianHunter 4y ago
        Any and all language trend survey results from the past couple of years.
JustSomeNobody 4y ago
> That isn't meant as a slight or anything other than simply my opinion. That's fine, we all have our preferences. I love Python, but I can't stand Ruby. I love Go, but hate C++. I make my living with C#, but won't touch Java. It's okay. We're not wrong. We're just different.
amedvednikov 4y ago
V fixes most of these, but it doesn't use Go's runtime: https://vlang.io/compare#go https://vlang.io/compare#go
- philosopher1234 4y ago
  It also doesn’t work :)
  - Tozen 4y ago
    You have never used it or are on an unnecessary disrespectful troll crusade. It works very well, for many of its fans, and keeps improving and getting better (at a high constant pace). Watch, learn, download, and enjoy this V program (https://youtu.be/6H7dprSwr74 https://youtu.be/6H7dprSwr74), among so many other examples (https://github.com/vlang/V/tree/master/examples https://github.com/vlang/V/tree/master/examples).
- todotask 4y ago
  I get you want to compare with Go, let have some benchmark. Despite V being new, the difference is quite insignificant for short-lived process in most case. You are more likely use Go for production at this time. https://programming-language-benchmarks.vercel.app/v-vs-go https://programming-language-benchmarks.vercel.app/v-vs-go
  - Tozen 4y ago
    Depends on the use case and persons involved. Nevertheless, V is on a constant march towards 1.0, and has been doing so at a higher pace than most other languages. And, its not necessarily an "either or" or "us versus them" situation, people can use both or whatever else "floats their boat". It's a bit disheartening to see programmers that fall into being so closed-minded or disparaging to other options or something new.
- cercatrova 4y ago
Thaxll 4y ago
Rust is adding new features at the speed of C++/C# which is quite bad imo, it's good a recipe to have different code base / way of doing things in just couple of years apart. Now for Rust there are many things that could be changed, async etc ...
- drogus 4y ago
  What exactly has Rust added in recent months or even years? The way I see it most changes in the language are making existing features work more consistently.
- nu11ptr 4y ago
  At first I thought this too, but if you look at the actual "features" they are adding they are all more less just smoothing out existing features. There aren't really any major new ones I can't think of that expand the "surface area" of the language. There is just a lot of polish still needed, esp. to things like async, const, etc. and most of the features appearing are about reducing the burden to use existing features.
  - pitaj 4y ago
    Exactly. All of the recent big features were added a few years ago, and now they're really just filling in the gaps.
Gigachad 4y ago
Rust has set the bar so high that it’s going to be hard for other languages to justify their use. If I had to make a bet, I’d say Typescript will take over for everything not performance critical and Rust will fit in every spot that either requires high quality assurance or high performance.
- brabel 4y ago
  Right, and no one will use Go, Java, Kotlin, Elixir, Ruby, Python, JavaScript, Haskell, OCaML, Ada, Lisp... anymore /s.
  - Tozen 4y ago
- Test0129 4y ago
  Rust users don't even register as a rounding error in the grand scheme of things. Don't get me wrong, I like Rust _the idea_. But to suggest Rust in it's current form, managed by it's current team, will be anything but a niche language for performance and safety critical corner cases is deluding yourself. The vast, vast, vast majority of programming to this day is still maintaining perfectly functional (but old) C++/Java/C/C# code bases. Anything overthrowing those thrones has to be both easy and better. Rust only fills one of these tasks. Go is far more popular because of the lower cognitive load, comparable speed, and relative ease at which you can become productive. Go won't replace Rust and comparing them is wrong. Go will, however, always be more popular than Rust. At least until Rust is adopted and supported by more major companies, used in major roles, and expands beyond it's niche.
apatheticonion 4y ago
I totally agree. After working with it for a while I feel like its best use is in writing CLI tools due to the compiler making it so damn easy to produce statically linked binaries for any platform, backed by an incredibly powerful standard library. My issue for application and web server development are in the language design as it restricts me in my personal quest to write loosely coupled code that is marinated in unit tests - at least when compared to other languages. That said I enjoy the language, have learned a lot from it, use Go often (previous day job) and have a gopher plushy - but I am just not a die hard loyalist. There are things about the language that blow others out of the water, but there are significant portions that leave a lot to be desired. What I have noticed is the language design has inconsistencies and there are lots of exceptions built into the language to get around missing features; features which are sometimes filled in later leaving ambiguity around approaches. For example, Go uses a nominal type system with the famous exception of interfaces with methods that are structurally evaluated. The issue is interfaces only feature structural type evaluation on the top level, anything nested beyond that is nominal. So an interface that has a method which returns an interface requires an implementing struct to return the _exact_ interface from that same method. You can accept a struct where an interface is a parameter but you cannot return a struct where an interface is the return type. This is useful when building type safe dependency containers, something that makes unit testing much easier. Instead people just overuse `Context`, prop drill it into everything and cast types at some point when trying to get things from it. Other examples are the return types from functions. Go didn't have generics initially so a Result[T] wasn't possible - but also exceptions were not possible. Tuples were not allowed by the type system but the language makes an exception for the function return types - fair enough. Without type parameters and a need for generic basic types like `map`, `slice` and `sync.Map`, the language made an exception for the the primitive types - giving them generics however this is now inconsistent with the current implementation of generics. Usage of `make()` and the confusion brought on by managing "references" also adds a bit of friction to the language. Generics are inconsistent as well - for instance you can have a struct with a type parameter but not methods - however you can have functions with type parameters that accept a struct as their first parameter. The tooling is a little underpowered, the test coverage analysis tool doesn't consider branch coverage, only statement coverage so you can have 100% test coverage reported with only 50% truly covered. Making mocks requires cumbersome type generation - this is something I am okay with but the types generated have terrible assertion capabilities. But there are phenomenal things from the language. Packages are a great design choice, module management from git is simple and effective, `range` is chefs kiss, the compiler is beautiful. I love the idea of goroutines but I'm not blown away by channels. They are fancy iterators with dedicated keywords which I find can clutter things up a little - but they were really cool when Go first came out and we were only just starting to think about how to manage asynchronous concurrency.
tgv 4y ago
Better enums and non-nil types, that would be my wish list for Go. And conditional expressions, if there's one more wish to be granted. There's no need to make it resemble Rust: Go's type system is expressive enough as it is. > has error prone C-style 'for' Not really true. It has `for index, elt := range v` to iterate over arrays and maps. It's a pity you can't define your own range, that's true.
- eliasdaler 4y ago
  Custom ranges will be possible at some point: https://github.com/golang/go/discussions/54245 https://github.com/golang/go/discussions/54245
ricardobeat 4y ago
I used to dislike it too, but after being “forced” to use it daily (chose a job thats 100% golang on the backend), you really grow into it. It would be really, really nice to have better error handling and a bit less verbosity all around, but in terms of cost/benefit it still beats any other language I’ve worked with by a fair margin. To get into it, it might help to start by modifying an existing project, a lot less painful than trying to write something from scratch without being familiar with the idioms.
randomdata 4y ago
> needs better error handling First it would need to add error handling before it could look to improve upon it. I'm not entirely convinced it should. I spend my days in a variety of other languages that have added error handling in various ways and, in my experience, it always ends up making errors unnecessarily difficult to do deal with. I regularly wish the idioms of those languages recognized errors as being core to your application as any other value, not something to treat differently. Go really got things right for the type of software I write. But not all software is solving the same problems. There are a lot of programs where you don't need to think about errors; where stopping the world is fine if you encounter one. Go is not at all a good fit for these situations. However, I think it is okay for Go to not try to be all things to all people. We already have plenty of other good languages that serve other niches. Right tool for the job and all that.
- jackosdev 4y ago
  Just make it so: varFoo, err := GetFoo() if err != nil { return err } Can be written as: varFoo := GetFoo()? Just like Rust, everyone would stop complaining about Go error handling. But they have this absolutist position on syntactic sugar, even for something like this that would make the language that much nicer to look at and work with.
  - EdwardDiego 4y ago
    So if GetFoo returned a non-nil error, would the function abort and immediately return the error? I'm used to a question mark being around null handling, but you know, JVM languages lol, null is thought about a lot.
    - jackosdev 4y ago
      Yeah exactly, it makes everything so much more ergonomic, especially with combinators, as in chaining method calls that might return an error
      - kubanczyk 4y ago
bayindirh 4y ago
We always make this discussion with friends. I don't think every language should tick the boxes the same way. I also personally like Go a lot. It's filling the gap between C++ and Python for me. If I need something compiled with proper threading support, but C++ would be an overkill, I reach for Go. Go is designed with a human centric view, IMHO: "Make writing great programs easier rather than design a language with novel/cutting edge features, but with a high cognitive load", and I find it as a noble aim as Rust's guarantees and aspirations. I understand why people love Rust, but I don't think it's the only one, or the proverbial silver bullet that we finally achieved. Yes, it's nice. Yes, it brings many things to the table, but it's not the final solution for once and for all. You like Rust? Great, Go for it (unintended pun alert), but I think we need all languages from all paradigms and perspectives. I find this talk [0] very informative and useful while interacting with other languages and communities. I'm not sharing this with any insinuations towards you, but just find it generally perspective broadening. [0]: https://www.youtube.com/watch?v=YX3iRjKj7C0 https://www.youtube.com/watch?v=YX3iRjKj7C0 - What Killed Smalltalk could Kill Ruby.
- xpressvideoz 4y ago
  > Go is designed with a human centric view, IMHO If it were Go's design philosophy, it would have allowed unused variables/imports. Those restrictions are there exactly because they help computers, reducing compilation time. The over-focus of compilation time also stems from monorepos being used by Google, whose purpose is also helping computers.
  - bayindirh 4y ago
    I think it goes both ways. Yes, eliminating unused variables and imports accelerates compilation. Also, compilation speed is a great deal for Go, but keeping the code devoid of unused variables also reduces the cognitive load of humans a lot. Keeping language simple is another feature which helps both ways.
  - randomdata 4y ago
    Fast compilation times are a human-centric goal. The machine couldn't care less if it takes a millennia to compile your program. Only humans care about fast compile times. But, I'm not sure that is even the primary benefit. The primary benefit is that you won't be incentivized to leave unused imports and variables to litter your code, as I see happen all the time in languages that aren't so strict. The Go team has even stated that they decided there would be no warnings because they've learned that warnings get ignored.
cies 4y ago
I agree. It feels a bit like where Java/JVM is at: popular, solid runtime, large community/ecosystem, but Java made some bad choices. In my opinion: Go needs a Kotlin. First and foremost to do away with implicit nulls (imho the biggest mistake), but here are other things that could be impoved you've already mentioned.
- seer-zig 4y ago
  The good thing is that Java is incorporating the proven features of other languages. It has gotten records, pattern matching (better than Kotlin's), and in the latest release, virtual threads with structured concurrency, better than async/await, and also better than golang as it lacks structured concurrency.
  - cies 4y ago
    But implicit nulls are a big pain point (in both Java and Go). And its very hard to fix for Java (and no plant thus far).
    - seer-zig 4y ago
      There are solutions like CheckerFramework or Nullaway or other compile time annotation processors.
      - cies 4y ago
        ...and Kotlin :)
bborud 4y ago
The error handling was a disappointment at first, but in practice it is a lot clearer and more usable than any other kinds of error handling I've tried. It could perhaps do with some syntactic sugar, but it isn't a big issue since IDEs can pick up that slack. After about half a decade of Go I'd say that the error handling is something I've come to like. "More expressive" in my opinion tends to mean "less readable", but there is some personal bias here. The people I've met during my career who like "more stuff" are usually the younger, less experienced programmers who aren't as concerned about long term viability. I'm in my fifth decade of programming and my approach is "do more with less". When people want more stuff, for me, it means that I'll be dealing with more cases of people not knowing how all the stuff works. Everyone likes to think they can deal with more cognitive overhead, but mostly people can't. I'm not sure if pattern matching belongs in a language like Go at all. Admittedly I haven't given it much thought, but it doesn't feel right for what Go aims to be. If you want to do Erlang, do Erlang, but I might be wrong about this. What's error prone about the for statement? I don't use the C-style for statement all that often as way more than 50% of my for loops are ranging or naked for loops with break/continue/return. Not having nil tends to lead to having to invent sentinel values all over the place, doesn't it? Is that really better? And since you often end up doing things by value in Go anyway, it isn't like you don't have any choice.
avgcorrection 4y ago
This truly is the final, futile iteration on the meme of: I want <current existing language> but with or without X: > That said, I don't know what I'd want to drop from Rust so maybe I'm just fantasizing. What is X? I don’t know.

Zababa 4y ago

> In the end I think if someone were to write a slightly simpler version of Rust with the Go runtime it might be pretty neat. OCaml kind of gives you that, but the dev experience isn't as good as Rust or Go in my opinion. Still, I enjoy it a lot, more than Go or Rust.

nu11ptr 4y ago
Agreed - I really like OCaml. Unfortunately it isn't popular enough to get tons of ecosystem love, so I could never find the libraries I need. I'd be pretty happy if it got more popular. Maybe the new multicore work will help.
- galangalalgol 4y ago
  What about F#?
- nextos 4y ago
  Yeah, came here to say the same thing. OCaml is pretty great, and the addition of multicore and algebraic effects will make it even better. It does have some unique ecosystem elements such as Coq, WhyML, Mirage, etc. But common components could be definitely improved.
lairv 4y ago
Does OCaml matches Go speed though ?
- agent281 4y ago
  They actually sit right next to each other on programming language benchmarks game. Scroll down to CPU seconds, median and percentiles. https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
int_19h 4y ago
Rust is basically what you get if you start with OCaml, remove the GC, and add enough features to the type system to compensate for that without giving up on safety.

akira2501 4y ago

I haven't found any issues with expression, so far. I wouldn't use it to write a UI, but for writing networking code or automated tasks I find it perfectly suited to the task. I appreciate it's error handling. It's burdensome, sure, but it presents almost no additional cognitive load when attempting to reason about control flow. It essentially has no enums. However, it has a comfortable type system that can wrap primitive types, and you can define methods on those wrapped types. It's serviceable, but not elegant. I have never been a fan of pattern matching outside of functional languages. The phenomenon I notice in languages that do have it, is the majority of uses cases seem to be a pattern match with two outcomes, one a Some() and the other a None(). It really seems like a more annoying way to write if {} else {}. It has for, but it also has 'range.' It makes up for a lot. It has nil pointers, which are just a "zero value." It's not uncommon to make it useful and safer in certain contexts. You can request a lookup in a map that is nil. You can ask for the length of a slice that is nil. You get sensible answers still. There are still footguns, but they're all single barrel.. which is _nicer_. I don't need a perfect language. Good enough with low cognitive load and amazing cross-compile facilities I'll take any day of the week.

nu11ptr 4y ago
I will agree Rust has a higher "cognitive load", but not if you write it every day. I think Rust might be tough to leave and come back say a year later, but Go admittedly would be easy. That said, having written 50K+ code in both languages, I never want to write Go again. Rust on the other hand is all I want to write now. I do wonder how many people who understand Go's limitations (and work around them as you point out above) have truly given Rust a try (takes a few months - can't be done faster). I can't imagine anyone would want to go back tbh, but maybe I'm wrong. EDIT: In fairness, there is one thing and exactly one thing I miss about Go: compile times. Rust is simply no competition here, but in trade, it is doing a ton of extra work. Trade offs.
- ikiris 4y ago
  The problem with rust is explicitly that cognitive load in large codebases. It is much easier to read go code than rust when working on many things. Rust fits great if you don't scale though.

User23 4y ago

This is pretty much exactly how I feel. I have great respect for the Go team. I broadly agree with their design philosophy. I think CSP is a great theory for concurrency. And I just don’t really like writing Go. I don’t hate it, but I feel like I have to either fight the language or just repeat myself an awful lot. Honestly, I suspect the deficiency is on my end. Perhaps I’ve just spent too much time with Lisp and have experienced some professional deformation.

KerrAvon 4y ago
It's OK to have ergonomic opinions about languages! In scriptingland, I find Python abhorrent. Ruby fits my brain like a glove (the core language, not Rails). Doesn't indicate anything about the quality of the languages or their respective partisans.
- dopidopHN 4y ago
  Look at you guys using nice looking languages! Haha, Java got better, but oh god it’s still verbose. We got rid of the getter setter silliness to be in “constructor land.” ( immutable records from Java 17 ) Function are still not first class citizens, but … they have a working visa now. You can shove lambda anywhere. It’s still awkward to write functional code Meh. Recently I’ve been really productive with it and I like the sheer boredom and lack of surprises.
  - RhodesianHunter 4y ago
    Most developers on the JVM with any freedom have switched to Kotlin.
    - fs111 4y ago
      citation needed
      - RhodesianHunter 4y ago
        Any and all language trend survey results from the past couple of years.

JustSomeNobody 4y ago

> That isn't meant as a slight or anything other than simply my opinion. That's fine, we all have our preferences. I love Python, but I can't stand Ruby. I love Go, but hate C++. I make my living with C#, but won't touch Java. It's okay. We're not wrong. We're just different.

amedvednikov 4y ago

V fixes most of these, but it doesn't use Go's runtime: https://vlang.io/compare#go https://vlang.io/compare#go

philosopher1234 4y ago
It also doesn’t work :)
- Tozen 4y ago
  You have never used it or are on an unnecessary disrespectful troll crusade. It works very well, for many of its fans, and keeps improving and getting better (at a high constant pace). Watch, learn, download, and enjoy this V program (https://youtu.be/6H7dprSwr74 https://youtu.be/6H7dprSwr74), among so many other examples (https://github.com/vlang/V/tree/master/examples https://github.com/vlang/V/tree/master/examples).
todotask 4y ago
I get you want to compare with Go, let have some benchmark. Despite V being new, the difference is quite insignificant for short-lived process in most case. You are more likely use Go for production at this time. https://programming-language-benchmarks.vercel.app/v-vs-go https://programming-language-benchmarks.vercel.app/v-vs-go
- Tozen 4y ago
  Depends on the use case and persons involved. Nevertheless, V is on a constant march towards 1.0, and has been doing so at a higher pace than most other languages. And, its not necessarily an "either or" or "us versus them" situation, people can use both or whatever else "floats their boat". It's a bit disheartening to see programmers that fall into being so closed-minded or disparaging to other options or something new.
cercatrova 4y ago

Thaxll 4y ago

Rust is adding new features at the speed of C++/C# which is quite bad imo, it's good a recipe to have different code base / way of doing things in just couple of years apart. Now for Rust there are many things that could be changed, async etc ...

drogus 4y ago
What exactly has Rust added in recent months or even years? The way I see it most changes in the language are making existing features work more consistently.
nu11ptr 4y ago
At first I thought this too, but if you look at the actual "features" they are adding they are all more less just smoothing out existing features. There aren't really any major new ones I can't think of that expand the "surface area" of the language. There is just a lot of polish still needed, esp. to things like async, const, etc. and most of the features appearing are about reducing the burden to use existing features.
- pitaj 4y ago
  Exactly. All of the recent big features were added a few years ago, and now they're really just filling in the gaps.

Gigachad 4y ago

Rust has set the bar so high that it’s going to be hard for other languages to justify their use. If I had to make a bet, I’d say Typescript will take over for everything not performance critical and Rust will fit in every spot that either requires high quality assurance or high performance.

brabel 4y ago
Right, and no one will use Go, Java, Kotlin, Elixir, Ruby, Python, JavaScript, Haskell, OCaML, Ada, Lisp... anymore /s.
- Tozen 4y ago
Test0129 4y ago
Rust users don't even register as a rounding error in the grand scheme of things. Don't get me wrong, I like Rust _the idea_. But to suggest Rust in it's current form, managed by it's current team, will be anything but a niche language for performance and safety critical corner cases is deluding yourself. The vast, vast, vast majority of programming to this day is still maintaining perfectly functional (but old) C++/Java/C/C# code bases. Anything overthrowing those thrones has to be both easy and better. Rust only fills one of these tasks. Go is far more popular because of the lower cognitive load, comparable speed, and relative ease at which you can become productive. Go won't replace Rust and comparing them is wrong. Go will, however, always be more popular than Rust. At least until Rust is adopted and supported by more major companies, used in major roles, and expands beyond it's niche.

apatheticonion 4y ago

I totally agree. After working with it for a while I feel like its best use is in writing CLI tools due to the compiler making it so damn easy to produce statically linked binaries for any platform, backed by an incredibly powerful standard library. My issue for application and web server development are in the language design as it restricts me in my personal quest to write loosely coupled code that is marinated in unit tests - at least when compared to other languages. That said I enjoy the language, have learned a lot from it, use Go often (previous day job) and have a gopher plushy - but I am just not a die hard loyalist. There are things about the language that blow others out of the water, but there are significant portions that leave a lot to be desired. What I have noticed is the language design has inconsistencies and there are lots of exceptions built into the language to get around missing features; features which are sometimes filled in later leaving ambiguity around approaches. For example, Go uses a nominal type system with the famous exception of interfaces with methods that are structurally evaluated. The issue is interfaces only feature structural type evaluation on the top level, anything nested beyond that is nominal. So an interface that has a method which returns an interface requires an implementing struct to return the _exact_ interface from that same method. You can accept a struct where an interface is a parameter but you cannot return a struct where an interface is the return type. This is useful when building type safe dependency containers, something that makes unit testing much easier. Instead people just overuse `Context`, prop drill it into everything and cast types at some point when trying to get things from it. Other examples are the return types from functions. Go didn't have generics initially so a Result[T] wasn't possible - but also exceptions were not possible. Tuples were not allowed by the type system but the language makes an exception for the function return types - fair enough. Without type parameters and a need for generic basic types like `map`, `slice` and `sync.Map`, the language made an exception for the the primitive types - giving them generics however this is now inconsistent with the current implementation of generics. Usage of `make()` and the confusion brought on by managing "references" also adds a bit of friction to the language. Generics are inconsistent as well - for instance you can have a struct with a type parameter but not methods - however you can have functions with type parameters that accept a struct as their first parameter. The tooling is a little underpowered, the test coverage analysis tool doesn't consider branch coverage, only statement coverage so you can have 100% test coverage reported with only 50% truly covered. Making mocks requires cumbersome type generation - this is something I am okay with but the types generated have terrible assertion capabilities. But there are phenomenal things from the language. Packages are a great design choice, module management from git is simple and effective, `range` is chefs kiss, the compiler is beautiful. I love the idea of goroutines but I'm not blown away by channels. They are fancy iterators with dedicated keywords which I find can clutter things up a little - but they were really cool when Go first came out and we were only just starting to think about how to manage asynchronous concurrency.

tgv 4y ago

Better enums and non-nil types, that would be my wish list for Go. And conditional expressions, if there's one more wish to be granted. There's no need to make it resemble Rust: Go's type system is expressive enough as it is. > has error prone C-style 'for' Not really true. It has `for index, elt := range v` to iterate over arrays and maps. It's a pity you can't define your own range, that's true.

eliasdaler 4y ago
Custom ranges will be possible at some point: https://github.com/golang/go/discussions/54245 https://github.com/golang/go/discussions/54245

ricardobeat 4y ago

I used to dislike it too, but after being “forced” to use it daily (chose a job thats 100% golang on the backend), you really grow into it. It would be really, really nice to have better error handling and a bit less verbosity all around, but in terms of cost/benefit it still beats any other language I’ve worked with by a fair margin. To get into it, it might help to start by modifying an existing project, a lot less painful than trying to write something from scratch without being familiar with the idioms.

randomdata 4y ago

> needs better error handling First it would need to add error handling before it could look to improve upon it. I'm not entirely convinced it should. I spend my days in a variety of other languages that have added error handling in various ways and, in my experience, it always ends up making errors unnecessarily difficult to do deal with. I regularly wish the idioms of those languages recognized errors as being core to your application as any other value, not something to treat differently. Go really got things right for the type of software I write. But not all software is solving the same problems. There are a lot of programs where you don't need to think about errors; where stopping the world is fine if you encounter one. Go is not at all a good fit for these situations. However, I think it is okay for Go to not try to be all things to all people. We already have plenty of other good languages that serve other niches. Right tool for the job and all that.

jackosdev 4y ago
Just make it so: varFoo, err := GetFoo() if err != nil { return err } Can be written as: varFoo := GetFoo()? Just like Rust, everyone would stop complaining about Go error handling. But they have this absolutist position on syntactic sugar, even for something like this that would make the language that much nicer to look at and work with.
- EdwardDiego 4y ago
  So if GetFoo returned a non-nil error, would the function abort and immediately return the error? I'm used to a question mark being around null handling, but you know, JVM languages lol, null is thought about a lot.
  - jackosdev 4y ago
    Yeah exactly, it makes everything so much more ergonomic, especially with combinators, as in chaining method calls that might return an error
    - kubanczyk 4y ago

bayindirh 4y ago

We always make this discussion with friends. I don't think every language should tick the boxes the same way. I also personally like Go a lot. It's filling the gap between C++ and Python for me. If I need something compiled with proper threading support, but C++ would be an overkill, I reach for Go. Go is designed with a human centric view, IMHO: "Make writing great programs easier rather than design a language with novel/cutting edge features, but with a high cognitive load", and I find it as a noble aim as Rust's guarantees and aspirations. I understand why people love Rust, but I don't think it's the only one, or the proverbial silver bullet that we finally achieved. Yes, it's nice. Yes, it brings many things to the table, but it's not the final solution for once and for all. You like Rust? Great, Go for it (unintended pun alert), but I think we need all languages from all paradigms and perspectives. I find this talk [0] very informative and useful while interacting with other languages and communities. I'm not sharing this with any insinuations towards you, but just find it generally perspective broadening. [0]: https://www.youtube.com/watch?v=YX3iRjKj7C0 https://www.youtube.com/watch?v=YX3iRjKj7C0 - What Killed Smalltalk could Kill Ruby.

xpressvideoz 4y ago
> Go is designed with a human centric view, IMHO If it were Go's design philosophy, it would have allowed unused variables/imports. Those restrictions are there exactly because they help computers, reducing compilation time. The over-focus of compilation time also stems from monorepos being used by Google, whose purpose is also helping computers.
- bayindirh 4y ago
  I think it goes both ways. Yes, eliminating unused variables and imports accelerates compilation. Also, compilation speed is a great deal for Go, but keeping the code devoid of unused variables also reduces the cognitive load of humans a lot. Keeping language simple is another feature which helps both ways.
- randomdata 4y ago
  Fast compilation times are a human-centric goal. The machine couldn't care less if it takes a millennia to compile your program. Only humans care about fast compile times. But, I'm not sure that is even the primary benefit. The primary benefit is that you won't be incentivized to leave unused imports and variables to litter your code, as I see happen all the time in languages that aren't so strict. The Go team has even stated that they decided there would be no warnings because they've learned that warnings get ignored.

cies 4y ago

I agree. It feels a bit like where Java/JVM is at: popular, solid runtime, large community/ecosystem, but Java made some bad choices. In my opinion: Go needs a Kotlin. First and foremost to do away with implicit nulls (imho the biggest mistake), but here are other things that could be impoved you've already mentioned.

seer-zig 4y ago
The good thing is that Java is incorporating the proven features of other languages. It has gotten records, pattern matching (better than Kotlin's), and in the latest release, virtual threads with structured concurrency, better than async/await, and also better than golang as it lacks structured concurrency.
- cies 4y ago
  But implicit nulls are a big pain point (in both Java and Go). And its very hard to fix for Java (and no plant thus far).
  - seer-zig 4y ago
    There are solutions like CheckerFramework or Nullaway or other compile time annotation processors.
    - cies 4y ago
      ...and Kotlin :)

bborud 4y ago

The error handling was a disappointment at first, but in practice it is a lot clearer and more usable than any other kinds of error handling I've tried. It could perhaps do with some syntactic sugar, but it isn't a big issue since IDEs can pick up that slack. After about half a decade of Go I'd say that the error handling is something I've come to like. "More expressive" in my opinion tends to mean "less readable", but there is some personal bias here. The people I've met during my career who like "more stuff" are usually the younger, less experienced programmers who aren't as concerned about long term viability. I'm in my fifth decade of programming and my approach is "do more with less". When people want more stuff, for me, it means that I'll be dealing with more cases of people not knowing how all the stuff works. Everyone likes to think they can deal with more cognitive overhead, but mostly people can't. I'm not sure if pattern matching belongs in a language like Go at all. Admittedly I haven't given it much thought, but it doesn't feel right for what Go aims to be. If you want to do Erlang, do Erlang, but I might be wrong about this. What's error prone about the for statement? I don't use the C-style for statement all that often as way more than 50% of my for loops are ranging or naked for loops with break/continue/return. Not having nil tends to lead to having to invent sentinel values all over the place, doesn't it? Is that really better? And since you often end up doing things by value in Go anyway, it isn't like you don't have any choice.

avgcorrection 4y ago

This truly is the final, futile iteration on the meme of: I want <current existing language> but with or without X: > That said, I don't know what I'd want to drop from Rust so maybe I'm just fantasizing. What is X? I don’t know.