12 ms·

I just don't think Go has a place in new code. I know Googlers (who shall remain unnamed to protect the innocent, and politics at that company can kill your car

I just don't think Go has a place in new code. I know Googlers (who shall remain unnamed to protect the innocent, and politics at that company can kill your career) who joined the Go fandom because its their company's language, their department was C++ or Google-flavored Java heavy (arguably, a Java style worse than 'normal' Java or Android's dialect), and it was their only way out... However, when they were exposed to Rust, a lot of them converted to Rust, and now write Rust for Google on internal apps that need performance but safety, especially during concurrency. Others were exposed to Kotlin (especially due to the Android guys), and are championing that as a replacement for Google-flavored Java inside the company, since the JVM is also very sane when it comes to large scale safety during concurrency. So yeah, if I was writing brand new highly concurrent coroutines-like code, I'd skip Go and Goroutines, and go straight to Kotlin and Akka (not written in Kotlin, but very natural to use with Kotlin), since I end up with the power of the JVM, the elegance of Kotlin's syntax, and the Erlang Actors brought by Akka. And for those who have never used Erlang, learn it once, write something highly concurrent in it, and you'll learn to distaste almost every other language's faulty concurrency idioms almost immediately. Without the Erlang actors model, you're not going to be writing fault tolerant concurrent systems; just like "all languages converge until they become LISP", all concurrency systems converge until they become an Erlang actor model.

agumonkey 7y ago
So LFE will reign http://lfe.io/ http://lfe.io/ LFeO even ;)
- brobdingnagians 7y ago
  I was curious about learning LFE, but didn't see if it was able to interface with Phoenix (Elixir's web server). Is there any way to use Phoenix from LFE?
fetbaffe 7y ago
Why shouldn’t Go have a place i new code? You talk about Rust, but why does that make Go a bad choice? Is it technical reasons or politics?
- neel_k 7y ago
  It's taking on a fair amount of risk to use a language that (a) encourages the use of concurrency but (b) is not memory-safe when you do so, especially when writing network-facing code. Go uses multi-word primitive values, which means assignments are not atomic. Consequently, racing assignment statements can leave objects in weird states that violate type and gc invariants. For example, racing assignments to a value of interface type can give you an object with the wrong dictionary for its data. The argument for not worrying about this is that this is an unlikely scenario. It's reasonable to think in probabilistic terms when clients are not trying to break the software (eg, in games or office software). However, attackers are not probabilistic: they actively search out vulnerabilities and push on them, so potential vulnerabilities turn into actual vulnerabilities in predictable fashion.
  - sagichmal 7y ago
    “Memory safe” has a specific technical definition, and “atomic assignment” isn’t it.
    - burntsushi 7y ago
      No, the GP is correct. Data races are undefined behavior, and break memory safety: https://research.swtch.com/gorace https://research.swtch.com/gorace
      - pwodhouse 7y ago
        Is there a sense in which Russ's claim that "data races are not security problems" is true? It seems to be assuming that data races are impossible to exploit by users (data input), only by programmers.
        kibwen 7y ago
        Presumably because data races are so inconsistently triggered that creating a reliable exploit would be generally infeasible, even with control over user input. However, this unpredictability is also why data races (among other concurrency issues) are some of the most maddening types of bugs to observe, hunt down, and diagnose, which is why eliminating data races is actually a big deal for anyone who's ever wrestled with threads before.
neilalexander 7y ago
I would argue that Go's opinionated style is what makes it elegant. It's a programming language for people who are sick of programming languages. It makes clear promises and delivers on exactly those - it belongs in new code for that reason.
- Milner08 7y ago
  "a programming language for people who are sick of programming languages" is nonsense.
  - neilalexander 7y ago
    Why?
    - gonzo41 7y ago
      Look at Java. Look at Spring and look at all the other junk out there. Every corner you go around you see smart people trying to outsmart each other rather than solve problems. Go makes that harder.
      - vips7L 7y ago
        Spring boot is fantastic if you havent checked it out.
        sagichmal 7y ago
        Spring Boot is precisely the magical nonsense the GP was complaining about.
        gerbilly 7y ago
        I like Java and Spring, but I don't use Spring boot. Note that just because the recent tutorials out there mention Spring Boot, doesn't mean you can't wire together a Spring app either through config files or programatically.
the_duke 7y ago
I'm personally not a big fan of Go due to the weak type system, with lack of generics as the main offender. And as a result, the ubiquitous `interface{}` pattern, stringly typed annotations, ... BUT Go offers simplicity, incredibly easy concurrency, decent performance, a good standard library for networking/http services, very quick compile times and a stricter type system than many other languages like Python/PHP. For many teams, especially coming from more dynamic languages, Go fills a sweet spot of performance, concurrency, type safety and ease of use. I love Rust, but it is much more complex, boilerplate heavy, adds more friction, is harder to learn, and concurrency is much harder to get right, even with the upcoming async/await feature. Not to mention the immature ecosystem, that will still need years of catching up to achieve parity with Go. Kotlin is also a great language, but has it's own downsides. You need to learn and understand Java (due to the many Java dependencies that you will pull in), there often will be a mismatch between Java libraries and idiomatic Kotlin code, concurrency is harder than in Go, and the JVM is a much more complex beast then the minimally tunable Go runtime. Go definitely has a place, even though it often wouldn't be my own first choice.
- kpcyrd 7y ago
  async/await is async io, this is something js is known for since it doesn't actually require parallelism. Getting concurrency _with_ parallelism right is a lot easier in rust than it is in go. You need to write thread safe code in both of them, but you get zero support from your compiler in go.
  - foldr 7y ago
    Go provides channels for safe communication between goroutines (which are distributed across multiple threads).
    - twic 7y ago
      You can use channels to pass mutable objects, which are then shared between threads. The passing itself may be safe, but the resulting situation isn't. The Rust compiler won't let you do that.
vmsp 7y ago
What's "Google-flavored Java"?
- wikibob 7y ago
  Check out the Google Java Style Guide: https://google.github.io/styleguide/javaguide.html https://google.github.io/styleguide/javaguide.html
- deleted 7y ago
  [deleted]
- saltyshake 7y ago
  Guice, Guice and more Guice. Some teams switch to Go because they are fed up of writing Google Java instead of real Java.
gypsyharlot 7y ago
What is your criticism of Go in all of this? That someone at Google prefers Rust? Or that you personally like Kotlin because of "the power of the JVM"? Getting away from the JVM is one of the reason FOR using Go rather than Kotlin/Scala/Java etc.
EdwardDiego 7y ago
I'm really curious now as to what Google flavoured Java looks like.
- chewxy 7y ago
  They taste like guava
naikrovek 7y ago
> I just don't think Go has a place in new code. This is a confusing statement, to me. This implies that go has a place in old code. Or are you saying that Go should not be used at all, because any future use is "new code"?
- adrianN 7y ago
  Rewriting existing, working programs in a different language very rarely makes sense. Avoiding a certain language for greenfield programs is much easier.
jacquesm 7y ago
> all concurrency systems converge until they become an Erlang actor model That's absolute gold, and I've seen a very accurate real life representation of that in recent times. Uncanny how many of those wheels we keep re-inventing.
- 0815test 7y ago
  Well, Erlang-like actor model is one basic pattern for achieving safe concurrency. A second one is keeping data read-only so that it can be freely accessed by multiple threads; and a further pattern is serializing access at run time (either using explicit locks, or in special cases with "non-blocking" algorithms and data structures). Rust is pretty unique in being able to comfortably encompass all of these patterns in its concurrency model, while ensuring safety.
  - masklinn 7y ago
    > A second one is keeping data read-only so that it can be freely accessed by multiple threads That's not really a "pattern for achieving safe concurrency". At one point, your concurrent processes need to communicate somehow or they're parallel more than concurrent.
giaour 7y ago
I would agree that Go is rarely the best choice for particular problem, but I've found it to be a good choice for "enterprise development" for two reasons. It's easily reviewable by others with varying levels of skill and familiarity with the project, and it doesn't have a complicated deployment story. At work, I've seen Go used primarily in projects that would have previously been written in Python or Ruby.
- notafrog 7y ago
  My biggest issue with navigating Go codebases is that sometimes it's cumbersome to find where a specific type/function is defined, when there are multiple files under the same directory.
  - cmonfeat 7y ago
    I've had this issue as well and found that it makes using an IDE almost mandatory for large code bases.
  - NateDad 7y ago
    A simple text search will find it every time. Since Go code should always be formatted, it's pretty trivial to search for `type HTTPServer` or `func NewServer(` ... even over fairly large codebases this will give few enough hits that you can just search everything most of the time.
  - apta 7y ago
    Not to mention trying to figure out which types implement a given interface. You'll get completely unrelated types you don't care about a lot of the time.
  - Lio 7y ago
    Would this not be solvable with something like ctags or godef? (I'm a newbie with Go so I've probably missed something in the problem you're describing).
th124567543 7y ago
Citation needed. From what I understand there is no Rust being used internally at Google (apart from perhaps individual engineers tinkering with it just for fun). There is no support for it from the build tools, so anything more than just messing about on your own machine won't work at Google: no libraries, no way to compile it, no way to test it, no way to deploy it, and no way to monitor it.
- rapsey 7y ago
  I do not know about internally, fuschia apparently has major parts written in Rust.
  - lima 7y ago
    And Chromium's crosvm. Rust is a perfect fit for that particular task (writing a VMM). I would be surprised if there was widespread usage of it, though. Rust chose a whole different set of tradeoffs than Go.
tptacek 7y ago
This is an extraordinarily unproductive way to start a comment and root a thread.
- whataboutism42 7y ago
  You would never do that of course.
- twic 7y ago
  $ curl -s 'https://news.ycombinator.com/item?id=20211301' | egrep -o comhead | wc 99 99 792 Seems to have been pretty productive to me.
Thaxll 7y ago
I started working with Kotlin recently, it's bad compare to Go goroutine model, the biggest problem is actually knowing if a function is sync or async, especially when you use other Java lib. The fact that you need to create your own threads pool to run those koroutine, really it's inferior to the Go runtime that does everything for you ( multiplexing goroutines onto os threads, creating new thread if blocking ect .. ), in Go it just works and it makes sense, in Kotlin you need to do many many things manually and it's much more complex for no apparent reasons.
- eropple 7y ago
  It's more complex because you have more control. If the Go scheduler does something pathological, you're going to be digging a hell of a lot deeper than you need to in Kotlin. You can just use a shared executor with a growing pool if you don't care.
- apta 7y ago
  Java is getting a fiber (green thread) implementation by means of project Loom. I recommend you check it out. In the mean time, you have other solutions like Vertx, Akka, and Reactor/RxJava.
apta 7y ago
> I just don't think Go has a place in new code This makes a lot of sense. I've seen and worked on code at a large US tech company that is mainly reliant on golang for its services, and let me tell you, it's hideous. It's very verbose, and they end up reinventing everything you have in Java land anyway in a much more verbose and error prone way. You also end up losing on the tremendous monitoring and management capability of the JVM, as well as the extremely mature and diverse ecosystem, with integrations into basically anything you can think of. You want to integrate into an "enterprise" system or infrastructure? ew who'd want to do that? we use golang because it's hip, who cares about about all that money making business? The funny thing is, there's still no getting away from Java/JVM, and they have a good number of services running on the JVM (particularly security related, and data processing pipeline services). While the language is "simple" (i.e. underpowered) enough that you can read it, it immediately translates into verbosity and complexity in the code base, with things like helper functions that are basically "map/filter/etc" calls in any sane language taking up 8-10 lines of code scattered everywhere, as opposed to them taking a single line of code as they're supposed to. Not to mention things like JSON handling, validation (non-existent way to do them in a non-error-prone way, unlike annotations or attributes in JVM/.NET), no way of doing compile time DI (unlike e.g. Dagger or micronaut on the JVM), the list goes on. Java the language is improving with things like switch expressions, records, and value types being added. The JVM itself is getting fibers, and better native integration for high performance work. GraalVM enables compilation to native binaries if needed. You also have languages like Kotlin to use on the JVM if you don't fancy Java itself. The only reason golang is being pushed around is hype. It's so underpowered that using it for any moderately complex domain becomes a mess. Even generics if they decide to add them won't fix that.
- simiones 7y ago
  I agree with almost everything you said. However, there is one point where I think you're wrong: the only advantage Go still has over java (as it exists today) is the size of the runtime - you can get a Go container serving an HTTP server in ~10MBs of size and similar amounts of RAM - this is still a far cry from what I've seen Java achieve. This is not important in many use cases, but if you are planning to run a microservices architecture, this can help a lot with horizontal scaling costs.
Touche 7y ago
Rust is a programming language for people who like programming languages. Every feature under the sun. Seems like the new Scala in that regard. I'd definitely use it if I was building a web browser or something else where C++ was previously the only option, but I personally don't want Scala 2.0 to build web servers or cli apps. I would rather focus on what I'm building, which is where Go excels.
- pjmlp 7y ago
  I focus on what I am building with JVM and .NET stacks, while enjoying quite expressive languages.
- kibwen 7y ago
  > Every feature under the sun. Have you gotten this impression from actually using Rust, or merely from people who themselves have not used Rust? It deliberately omits a ton of ideas from other programming languages (exceptions, classes, data inheritance, monads, and more), and the features it does have are intended to compose well and without a huge amount of mental burden.
  - Touche 7y ago
    Yep, it leaves out ideas that are no longer en vogue but has every idea that is currently en vogue. So in 20 years when those ideas are themselves thrown out, it will feel like a language of the 2010s.
- kybernetikos 7y ago
  Rust and Scala are at nearly opposite ends of the spectrum. Rust forces you to be explicit about nearly everything, Scala is all about allowing you to hide the details in lots of different ways.
ajbeach22 7y ago
> I just don't think Go has a place in new code. This is a completely blanket statement. Not only are there very large open source projects written in go which your company more than likely already uses (kubernetes, docker, prometheus, influxdb to name a few) there are also case studies of very respectable performance in go: 1 million requests/min http://marcio.io/2015/07/handling-1-million-requests-per-minute-with-golang/ http://marcio.io/2015/07/handling-1-million-requests-per-min... 1 million websockets in go: https://www.freecodecamp.org/news/million-websockets-and-go-cc58418460bb/ https://www.freecodecamp.org/news/million-websockets-and-go-... event loops in go: (surpasses redis in their benchmarks) https://github.com/tidwall/evio https://github.com/tidwall/evio I see golang more as a progression for JS or Python developers than Java or JVM based languages, as the concurrency model in golang is closer to to pythons + javascript async. The argument that Java, Kotlin, Erlang developers are less likely to move to Go is probably a valid one, but it is completely baseless to say that "go has no place in new code". The concurrency model in golang with channels makes more sense to someone more familiar with python/javascript who hasn't been exposed to threading or other concurrency models. If you can understand basic coroutines/channels you get the benefits of golangs concurrency (and even parallelism) without much effort, or code complexity, with an order of magnitude more performance that python or javascript for the same feature set. The profiling tools in golang are also first class (pprof, trace, ect) With pprof, its easy to see even traces of different coroutines, heap allocations, cumulative allocations, these are even safe to sample on production running services and this is provided by the standard library. There are even built in tools to profile GC. The argument that tooling and monitoring doesn't exist in golang is simply not true.
arvinsim 7y ago
> And for those who have never used Erlang, learn it once, write something highly concurrent in it, and you'll learn to distaste almost every other language's faulty concurrency idioms almost immediately. Does learning Elixir do the same?

agumonkey 7y ago

So LFE will reign http://lfe.io/ http://lfe.io/ LFeO even ;)

brobdingnagians 7y ago
I was curious about learning LFE, but didn't see if it was able to interface with Phoenix (Elixir's web server). Is there any way to use Phoenix from LFE?

fetbaffe 7y ago

Why shouldn’t Go have a place i new code? You talk about Rust, but why does that make Go a bad choice? Is it technical reasons or politics?

neel_k 7y ago
It's taking on a fair amount of risk to use a language that (a) encourages the use of concurrency but (b) is not memory-safe when you do so, especially when writing network-facing code. Go uses multi-word primitive values, which means assignments are not atomic. Consequently, racing assignment statements can leave objects in weird states that violate type and gc invariants. For example, racing assignments to a value of interface type can give you an object with the wrong dictionary for its data. The argument for not worrying about this is that this is an unlikely scenario. It's reasonable to think in probabilistic terms when clients are not trying to break the software (eg, in games or office software). However, attackers are not probabilistic: they actively search out vulnerabilities and push on them, so potential vulnerabilities turn into actual vulnerabilities in predictable fashion.
- sagichmal 7y ago
  “Memory safe” has a specific technical definition, and “atomic assignment” isn’t it.
  - burntsushi 7y ago
    No, the GP is correct. Data races are undefined behavior, and break memory safety: https://research.swtch.com/gorace https://research.swtch.com/gorace
    - pwodhouse 7y ago
      Is there a sense in which Russ's claim that "data races are not security problems" is true? It seems to be assuming that data races are impossible to exploit by users (data input), only by programmers.
      - kibwen 7y ago
        Presumably because data races are so inconsistently triggered that creating a reliable exploit would be generally infeasible, even with control over user input. However, this unpredictability is also why data races (among other concurrency issues) are some of the most maddening types of bugs to observe, hunt down, and diagnose, which is why eliminating data races is actually a big deal for anyone who's ever wrestled with threads before.

neilalexander 7y ago

I would argue that Go's opinionated style is what makes it elegant. It's a programming language for people who are sick of programming languages. It makes clear promises and delivers on exactly those - it belongs in new code for that reason.

Milner08 7y ago
"a programming language for people who are sick of programming languages" is nonsense.
- neilalexander 7y ago
  Why?
  - gonzo41 7y ago
    Look at Java. Look at Spring and look at all the other junk out there. Every corner you go around you see smart people trying to outsmart each other rather than solve problems. Go makes that harder.
    - vips7L 7y ago
      Spring boot is fantastic if you havent checked it out.
      - sagichmal 7y ago
        Spring Boot is precisely the magical nonsense the GP was complaining about.
        gerbilly 7y ago
        I like Java and Spring, but I don't use Spring boot. Note that just because the recent tutorials out there mention Spring Boot, doesn't mean you can't wire together a Spring app either through config files or programatically.

the_duke 7y ago

I'm personally not a big fan of Go due to the weak type system, with lack of generics as the main offender. And as a result, the ubiquitous `interface{}` pattern, stringly typed annotations, ... BUT Go offers simplicity, incredibly easy concurrency, decent performance, a good standard library for networking/http services, very quick compile times and a stricter type system than many other languages like Python/PHP. For many teams, especially coming from more dynamic languages, Go fills a sweet spot of performance, concurrency, type safety and ease of use. I love Rust, but it is much more complex, boilerplate heavy, adds more friction, is harder to learn, and concurrency is much harder to get right, even with the upcoming async/await feature. Not to mention the immature ecosystem, that will still need years of catching up to achieve parity with Go. Kotlin is also a great language, but has it's own downsides. You need to learn and understand Java (due to the many Java dependencies that you will pull in), there often will be a mismatch between Java libraries and idiomatic Kotlin code, concurrency is harder than in Go, and the JVM is a much more complex beast then the minimally tunable Go runtime. Go definitely has a place, even though it often wouldn't be my own first choice.

kpcyrd 7y ago
async/await is async io, this is something js is known for since it doesn't actually require parallelism. Getting concurrency _with_ parallelism right is a lot easier in rust than it is in go. You need to write thread safe code in both of them, but you get zero support from your compiler in go.
- foldr 7y ago
  Go provides channels for safe communication between goroutines (which are distributed across multiple threads).
  - twic 7y ago
    You can use channels to pass mutable objects, which are then shared between threads. The passing itself may be safe, but the resulting situation isn't. The Rust compiler won't let you do that.

vmsp 7y ago

What's "Google-flavored Java"?

wikibob 7y ago
Check out the Google Java Style Guide: https://google.github.io/styleguide/javaguide.html https://google.github.io/styleguide/javaguide.html
deleted 7y ago
[deleted]
saltyshake 7y ago
Guice, Guice and more Guice. Some teams switch to Go because they are fed up of writing Google Java instead of real Java.

gypsyharlot 7y ago

What is your criticism of Go in all of this? That someone at Google prefers Rust? Or that you personally like Kotlin because of "the power of the JVM"? Getting away from the JVM is one of the reason FOR using Go rather than Kotlin/Scala/Java etc.

EdwardDiego 7y ago

I'm really curious now as to what Google flavoured Java looks like.

chewxy 7y ago
They taste like guava

naikrovek 7y ago

> I just don't think Go has a place in new code. This is a confusing statement, to me. This implies that go has a place in old code. Or are you saying that Go should not be used at all, because any future use is "new code"?

adrianN 7y ago
Rewriting existing, working programs in a different language very rarely makes sense. Avoiding a certain language for greenfield programs is much easier.

jacquesm 7y ago

> all concurrency systems converge until they become an Erlang actor model That's absolute gold, and I've seen a very accurate real life representation of that in recent times. Uncanny how many of those wheels we keep re-inventing.

0815test 7y ago
Well, Erlang-like actor model is one basic pattern for achieving safe concurrency. A second one is keeping data read-only so that it can be freely accessed by multiple threads; and a further pattern is serializing access at run time (either using explicit locks, or in special cases with "non-blocking" algorithms and data structures). Rust is pretty unique in being able to comfortably encompass all of these patterns in its concurrency model, while ensuring safety.
- masklinn 7y ago
  > A second one is keeping data read-only so that it can be freely accessed by multiple threads That's not really a "pattern for achieving safe concurrency". At one point, your concurrent processes need to communicate somehow or they're parallel more than concurrent.

giaour 7y ago

I would agree that Go is rarely the best choice for particular problem, but I've found it to be a good choice for "enterprise development" for two reasons. It's easily reviewable by others with varying levels of skill and familiarity with the project, and it doesn't have a complicated deployment story. At work, I've seen Go used primarily in projects that would have previously been written in Python or Ruby.

notafrog 7y ago
My biggest issue with navigating Go codebases is that sometimes it's cumbersome to find where a specific type/function is defined, when there are multiple files under the same directory.
- cmonfeat 7y ago
  I've had this issue as well and found that it makes using an IDE almost mandatory for large code bases.
- NateDad 7y ago
  A simple text search will find it every time. Since Go code should always be formatted, it's pretty trivial to search for `type HTTPServer` or `func NewServer(` ... even over fairly large codebases this will give few enough hits that you can just search everything most of the time.
- apta 7y ago
  Not to mention trying to figure out which types implement a given interface. You'll get completely unrelated types you don't care about a lot of the time.
- Lio 7y ago
  Would this not be solvable with something like ctags or godef? (I'm a newbie with Go so I've probably missed something in the problem you're describing).

th124567543 7y ago

Citation needed. From what I understand there is no Rust being used internally at Google (apart from perhaps individual engineers tinkering with it just for fun). There is no support for it from the build tools, so anything more than just messing about on your own machine won't work at Google: no libraries, no way to compile it, no way to test it, no way to deploy it, and no way to monitor it.

rapsey 7y ago
I do not know about internally, fuschia apparently has major parts written in Rust.
- lima 7y ago
  And Chromium's crosvm. Rust is a perfect fit for that particular task (writing a VMM). I would be surprised if there was widespread usage of it, though. Rust chose a whole different set of tradeoffs than Go.

tptacek 7y ago

This is an extraordinarily unproductive way to start a comment and root a thread.

whataboutism42 7y ago
You would never do that of course.
twic 7y ago
$ curl -s 'https://news.ycombinator.com/item?id=20211301' | egrep -o comhead | wc 99 99 792 Seems to have been pretty productive to me.

Thaxll 7y ago

I started working with Kotlin recently, it's bad compare to Go goroutine model, the biggest problem is actually knowing if a function is sync or async, especially when you use other Java lib. The fact that you need to create your own threads pool to run those koroutine, really it's inferior to the Go runtime that does everything for you ( multiplexing goroutines onto os threads, creating new thread if blocking ect .. ), in Go it just works and it makes sense, in Kotlin you need to do many many things manually and it's much more complex for no apparent reasons.

eropple 7y ago
It's more complex because you have more control. If the Go scheduler does something pathological, you're going to be digging a hell of a lot deeper than you need to in Kotlin. You can just use a shared executor with a growing pool if you don't care.
apta 7y ago
Java is getting a fiber (green thread) implementation by means of project Loom. I recommend you check it out. In the mean time, you have other solutions like Vertx, Akka, and Reactor/RxJava.

apta 7y ago

> I just don't think Go has a place in new code This makes a lot of sense. I've seen and worked on code at a large US tech company that is mainly reliant on golang for its services, and let me tell you, it's hideous. It's very verbose, and they end up reinventing everything you have in Java land anyway in a much more verbose and error prone way. You also end up losing on the tremendous monitoring and management capability of the JVM, as well as the extremely mature and diverse ecosystem, with integrations into basically anything you can think of. You want to integrate into an "enterprise" system or infrastructure? ew who'd want to do that? we use golang because it's hip, who cares about about all that money making business? The funny thing is, there's still no getting away from Java/JVM, and they have a good number of services running on the JVM (particularly security related, and data processing pipeline services). While the language is "simple" (i.e. underpowered) enough that you can read it, it immediately translates into verbosity and complexity in the code base, with things like helper functions that are basically "map/filter/etc" calls in any sane language taking up 8-10 lines of code scattered everywhere, as opposed to them taking a single line of code as they're supposed to. Not to mention things like JSON handling, validation (non-existent way to do them in a non-error-prone way, unlike annotations or attributes in JVM/.NET), no way of doing compile time DI (unlike e.g. Dagger or micronaut on the JVM), the list goes on. Java the language is improving with things like switch expressions, records, and value types being added. The JVM itself is getting fibers, and better native integration for high performance work. GraalVM enables compilation to native binaries if needed. You also have languages like Kotlin to use on the JVM if you don't fancy Java itself. The only reason golang is being pushed around is hype. It's so underpowered that using it for any moderately complex domain becomes a mess. Even generics if they decide to add them won't fix that.

simiones 7y ago
I agree with almost everything you said. However, there is one point where I think you're wrong: the only advantage Go still has over java (as it exists today) is the size of the runtime - you can get a Go container serving an HTTP server in ~10MBs of size and similar amounts of RAM - this is still a far cry from what I've seen Java achieve. This is not important in many use cases, but if you are planning to run a microservices architecture, this can help a lot with horizontal scaling costs.

Touche 7y ago

Rust is a programming language for people who like programming languages. Every feature under the sun. Seems like the new Scala in that regard. I'd definitely use it if I was building a web browser or something else where C++ was previously the only option, but I personally don't want Scala 2.0 to build web servers or cli apps. I would rather focus on what I'm building, which is where Go excels.

pjmlp 7y ago
I focus on what I am building with JVM and .NET stacks, while enjoying quite expressive languages.
kibwen 7y ago
> Every feature under the sun. Have you gotten this impression from actually using Rust, or merely from people who themselves have not used Rust? It deliberately omits a ton of ideas from other programming languages (exceptions, classes, data inheritance, monads, and more), and the features it does have are intended to compose well and without a huge amount of mental burden.
- Touche 7y ago
  Yep, it leaves out ideas that are no longer en vogue but has every idea that is currently en vogue. So in 20 years when those ideas are themselves thrown out, it will feel like a language of the 2010s.
kybernetikos 7y ago
Rust and Scala are at nearly opposite ends of the spectrum. Rust forces you to be explicit about nearly everything, Scala is all about allowing you to hide the details in lots of different ways.

ajbeach22 7y ago

> I just don't think Go has a place in new code. This is a completely blanket statement. Not only are there very large open source projects written in go which your company more than likely already uses (kubernetes, docker, prometheus, influxdb to name a few) there are also case studies of very respectable performance in go: 1 million requests/min http://marcio.io/2015/07/handling-1-million-requests-per-minute-with-golang/ http://marcio.io/2015/07/handling-1-million-requests-per-min... 1 million websockets in go: https://www.freecodecamp.org/news/million-websockets-and-go-cc58418460bb/ https://www.freecodecamp.org/news/million-websockets-and-go-... event loops in go: (surpasses redis in their benchmarks) https://github.com/tidwall/evio https://github.com/tidwall/evio I see golang more as a progression for JS or Python developers than Java or JVM based languages, as the concurrency model in golang is closer to to pythons + javascript async. The argument that Java, Kotlin, Erlang developers are less likely to move to Go is probably a valid one, but it is completely baseless to say that "go has no place in new code". The concurrency model in golang with channels makes more sense to someone more familiar with python/javascript who hasn't been exposed to threading or other concurrency models. If you can understand basic coroutines/channels you get the benefits of golangs concurrency (and even parallelism) without much effort, or code complexity, with an order of magnitude more performance that python or javascript for the same feature set. The profiling tools in golang are also first class (pprof, trace, ect) With pprof, its easy to see even traces of different coroutines, heap allocations, cumulative allocations, these are even safe to sample on production running services and this is provided by the standard library. There are even built in tools to profile GC. The argument that tooling and monitoring doesn't exist in golang is simply not true.

arvinsim 7y ago

> And for those who have never used Erlang, learn it once, write something highly concurrent in it, and you'll learn to distaste almost every other language's faulty concurrency idioms almost immediately. Does learning Elixir do the same?