
Go Creeping In - mpweiher
https://www.tbray.org/ongoing/When/201x/2019/06/12/Go-Creeping-In
======
svat
I am not a Go programmer, but every time there is a discussion about Go I want
to link to the article on “Language Design in the Service of Software
Engineering”:
[https://talks.golang.org/2012/splash.article](https://talks.golang.org/2012/splash.article)

It explains so many of Go's design decisions and why it is the way it is (e.g.
why something like gofmt/gofix is among the best things about the language); I
wish there were similar articles on the design decisions behind more
languages.

The first point in this (OP) post is also explained by the same philosophy: as
far as Readability / “I can pop open almost any .go file and [can] understand
it pretty quick” goes, it is a powerful thing to be able to navigate to pretty
much any team's code and not only understand their code but also be able to
focus on what's specific to that code rather than on idiosyncratic stylistic
differences. In other languages this is done with a lot of adherence to the
style guide; if Go tries to make it even easier, this would make sense.

~~~
owaislone
At my current job, most of the backend code is divided in two separate groups.
One uses Java while another is built with Go. Both have teams have very good
reasons to choose what they did and both languages are serving their purpose
pretty well but one of the major issues with the Java team I've seen is how
discussion there is around styling the code. Most PRs have some comments about
some styling and it gets a bit worse every time a new engineer joins the team.
I think what you pointed about Go is one of it's best features if not the
best.

~~~
aphexairlines
The Java team could use EditorConfig, CheckStyle, FindBugs, ErrorProne, or
other tools to enforce team rules similar to how the Go team uses tools like
gofmt.

~~~
elithrar
I think the part here is that there aren’t tools “like” gofmt - there is only
gofmt. Other tools wrap it, but there’s no choice (and bikeshedding) to make.

~~~
aphexairlines
If the team puts in place a code formatter/linter tool there won't be
bikeshedding for them either. If they're happy to let google format their Go
code they can let google format their Java code too:
[https://github.com/google/google-java-
format](https://github.com/google/google-java-format)

~~~
themoat
We had a "discussion" on which formatter/linter to use for a different
language. There were 2 choices and I bet we spend 300 man hours on nonsense.
Everyone had to have their say.

You can decide TO use a linter, but then you just get to argue about which
linter...

~~~
aphexairlines
The fact that there are multiple linter tools shouldn't paralyze a group of
people for 300 man hours. The Go ecosystem will eventually have choices too.
For instance, I think there are a couple of different protobuf implementations
for Go already.

~~~
malandrew
It shouldn't but it does. See Wadler's Law:

[https://wiki.haskell.org/Wadler's_Law](https://wiki.haskell.org/Wadler's_Law)

------
acln
The most important property of Go for me is that the language is not red/blue.
[1]

This enables I/O interfaces to be truly universal, covering just about
everything from files on disk, to pipes, to in-memory buffers, to sockets.
This feature facilitates a style of, for lack of a better word, _generic_
programming that is hard to come by in other systems.

I find basically any other language or platform except Go lacking and
unpleasant in this regard, due to the viral nature of asynchronous functions,
which never disappears entirely, no matter how much syntactic sugar is
sprinkled on top of it.

Things like mismatch between event reactors or asynchronous frameworks do not
exist in Go. Interfaces Just Work, and the entire ecosystem uses them.

[1] [http://journal.stuffwithstuff.com/2015/02/01/what-color-
is-y...](http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-
function/)

~~~
pacala
I wish I understood what problems people solve day in and day out such that
they need to call IO in the middle of Dijkstra’s algorithm. Most "business
logic" ought be pure functions over persistent data structures with no IO
other than the occasional logging. At the last possible moment, 5% of the code
wires in IO in some boilerplaty way. Is that sufficiently pervasive to worry
about it?

~~~
dxbydt
> what problems people solve that they need to call IO in the middle of
> Dijkstra’s algorithm.

I worked on several problems of this nature at Twitter in 2012. Hopefully
there’s a better way to solve them in 2019...prolly not, but maybe.

say you want to find the median of the number of followers a person on twitter
has. so that should be easy - make 1 dataframe with follower count of each
bloke and call median() - well, there’s some 300,000,000 blokes, so not that
easy :) You have to make a dataframe via ETL - reading & writing to disk 100s
of times, loading a few thousand users each time, distributed median
computation. so a silly sub-second median query took 2 months to code up &
debug & ran for a few hours due to so much IO.

another much harder problem - you want to find the median number of hops
between one user & another. so now you have 300m x 300m tuples as your result
- where & how to store them is in itself a monstrous challenge. but how the
heck do you even compute the result ? you read in one tweet from john to
steve, so that’s 1 hop from john to steve & viceversa. you then read a second
tweet from steve to mary, so that’s 1 hop from steve to mary & viceversa, 2
hops from john to mary & viceversa. in this manner you read 100s of billions
of tweets & keep updating hopcount. somewhere in there john sends mary a tweet
- oh fuck now the hopcount is 1, not 2. this will then change lots of other
hopcounts. in theory there are nice graph algos for this sort of thing. but in
reality, your data is billions of tweets constantly increasing, stored in
distributed compute clusters across the planet & just getting a handle on all
this can be a 6 month project for some lucky scientist who got to work on
this.

~~~
bsder
> I worked on several problems of this nature at Twitter in 2012. Hopefully
> there’s a better way to solve them in 2019...prolly not, but maybe.

Okay, so Twitter has scale. To a first, second and third order engineering
approximation-- _nobody else does_.

If you are a mere mortal writing practically anything, pull it all into
memory, operate on it to create another copy, destroy the original copy (or
let GC kill it).

Embedded programmers _might_ get a pass on this given limited memory (32K
RAM)--but that same kind of attitude is getting more and more essential as you
start getting Big/Little core mixes on the same chip.

Computers are mind-bogglingly powerful.

I have been completely stunned at how many transactions
Nginix+Django+PostgreSQL can actually handle before you need to start thinking
about "scaling".

------
lenkite
Programmers who write CLI apps/network-services tend to love Go. Programmers
who love mutable, imperative programming love Go. Programmers who find the CSP
model a natural fit for asynchronous programming love Go. Programmers who want
the stdlib to contain what they need for 80% of use-cases love Go. Programmers
who love checking `if err != nil` in every statement love Go.

Programmers who write re-usable libraries (eventually) come to hate Go.
Programmers who leverage Sequences/Streams, immutability and functional
programming tend to hate Go. Programmers who prefer exceptions or railway-
result types for error handling also tend to hate Go. Programmers who desire
tight control over performance and memory management will obviously hate Go.

In my _personal_ opinion, the Go language is handicapped to claim simplicity.
However, the Go standard library is amazing for productivity. If Go the
language, didn't come with its stdlib and wasn't pushed by Google, you
wouldn't have so many Go fans.

~~~
zeveb
> Programmers who leverage Sequences/Streams, immutability and functional
> programming tend to hate Go.

I dunno, applying the Reader/Writer pattern to other objects in order to get
sequences & streams works pretty well in Go.

> If Go the language, didn't come with its stdlib and wasn't pushed by Google,
> you wouldn't have so many Go fans.

I think the latter part is very true. Go had the very good fortune to be a
Pike tool put out by Google back when, ‘hey, Google are producing this!’ was a
_good_ thing.

I like Go, but I also like Plan 9 — and it never took off. Neither did
Newsqueak or Alef. But Go did, in large part, I think, due to Google’s
positive reputation a decade ago.

~~~
rakoo
The Reader/Writer interfaces are beautiful in their simplicity, but they're
only useful if you want to stream raw, non-Go data. If you want to iterate
over a slice or a channel, basically as soon as your data is fit into Go
datastructures you don't have a simple and beautiful pattern for working with
them as a flow of data.

~~~
zeveb
You can always implement a FooReader, which iterates over a flow of Foo
objects (which might, for example, be items in a slice or channel). We do this
all the time. It is, as you note, quite simple and I think elegant too.

~~~
lenkite
Yes, I have done this, but I was talking more about streams that I can splice,
filter, map, join, pair, slice, window, buffer, groupby, scan, skip, take,
switch, zip, reduce, etc.

Not really possible without generics, lambdas and a good core of functional
routines.

Once you get used to this and the speed, productivity and elegance with which
problems can be solved, using Golang feels a bit primitive and painful. The
same Go code is usually 5x-10x longer.

------
hu3
That's a trend I witnessed first hand while working as dev for a bank. Old
Java code slowly being phased out for Go. Which to me seemed like madness at
the time due to lack of generics but it turned out to be fine, just needed a
different mindset. This often resulted in a much shorter edit-compile-run loop
and halved the hardware requirements, specially memory.

These days I'm not even surprised when new clients demand Go in my current
consulting firm.

I think there are "better" languages than Go but they also come with their own
tradeoffs and from what I've seen, to many it seems Go is preffered after
weighting in.

~~~
wikibob
This is interesting. At the Banks was this driven by internal staff, or
contractors?

I’m considering contracting, any particular banks that you thought were more
competent?

~~~
hu3
In my case the Go adoption was spearheaded by a team lead from their staff.

As for what banks are more competent or dare I say modern, it can vary wildly
even in the same bank depending on what piece of software each team works on.
From my experience banks are (understandably) resistant to change so you might
have a hard time finding greenfield projects there. In general, I'd say go for
banks only if you're interested in quick money over career development. It can
be soul crushing at times.

~~~
kjs3
Disclaimer: At a very large US bank.

Seconding the assessment. We have pockets of everything from legacy mainframe
you've probably never heard of (no, not every mainframe is an IBM) to cutting
edge cloud/docker/devops/agile/etc. Just depends on where you can be plugged
in.

------
kitd
_It’s amazing — amazing I say — how little generics are missed._

Ooof. I've just spent about 3 days debugging Go code that was copypasted x N,
with minor (incorrect) modifications. Rewriting it with generics would have
been about 30-min job and made it much more maintainable in the future.

~~~
lostmyoldone
Yeah, I wish more people would accept that there are clear tradeoffs between
different type systems.

The tradeoff in Go seems to work reasonably well for services that doesn't
want, or need, to handle complex application domain as fluently as
concurrency. Essentially it works well for network/systems level code, and
anything that looks like that.

But for code that is more of an encoding on an application/service domain, the
lack if generics hinders reasoning more than it helps. There you have no use
for the fancy concurrency stuff, it has to be abstracted away for the domain
experts to be able to be productive. There are, usually, also enough code that
global readability become less helpful, and unambiguous contracts/types across
systems becomes moreso.

The latter case is massively helped by any way to enforce contracts over
methods and types, as long as refactoring tools can reason over it.
Nevertheless I do believe that locally (in methods/functions) a well behaved
type inference and IDE tooling is better than extremely verbose type
statements that I then make the IDE hide from me!

To me these are clearly different scenarios, but apparently not to most
people, or these discussions would rarely occur, but we would have discussions
about the characteristics of languages making them suitable for any specific
task.

After all, for every solution there exists a possible language where the
solution for a particular problem is part of the language, trivially making it
the best language for that problem.

Also trivially, there exists a best language for me, personally, to solve any
problem. This is the hypothetical language which encodes and compensates for
my individual perceptual and cognitive bias.

Now, in a large enough enterprise, the most important contracts, and hence
generics, might be expressed in the outward facing interfaces, and thus making
them mostly redundant in a single service. Sharing implementations becomes
less important at this scale, as it creates problems on it own. Hiring and
onboarding masses of juniors are commonly a problem here.

Hence, except for networking/systems styled solutions, Go might also be well
suited for very large organizations with endless hiring needs, and a desire to
look more modern.

~~~
treis
>Essentially it works well for network/systems level code, and anything that
looks like that.

You can also see this in the testing story. Go is very focused on unit testing
which makes sense when you are one cog in a giant machine. But if you're
writing something standalone the friction to write end to end integration
tests is what turned me off.

------
tmaly
I have had much success with Go for the past 5 years.

Simplicity is by far the most powerful feature. If I have to hire someone
right out of school, they can pickup the language very quickly.

If a team member leaves the company, I can still read and understand the code
they wrote.

Over a long term horizon, the features of Go make it easier to maintain the
software written with it.

~~~
endorphone
This is the killer feature of Go, and it's what so many who clamor for various
features-of-other-languages miss.

Go is designed for simplicity. It is easy to write, but more importantly is
easy to understand, even far in the future. For a given problem, _n_
programmers will generally coalesce on a small number of possible Go
implementations, whereas other languages will often yield _n_ divergent
solutions.

I've had Go solutions that I built years ago that I can get into and maintain
in seconds, even when I hadn't touched Go in months.

Go isn't my primary tooling (my life today is mostly Swift), but as a
comparison where a language has gone awry I'd point to C# -- as Microsoft has
tried to incorporate whatever cool thing every other language has added, C#
projects have often turned into write-only projects where the original author
barely can grok their code a month later, and everyone shrugs and says
"rewrite it" when confronted with another programmer's C# code. Rust is much
the same.

~~~
pcwalton
Can you give an example of Rust incorporating "whatever cool thing every other
language has added"?

I have never had the experience of Rust code becoming write-only after a
month, and I don't know anyone else who has either.

~~~
endorphone
That statement was clearly in reference to C#, which evolved from a
beautifully concise language to now being a mishmash of every other style of
programming (including the abomination that is LINQ).

Rust, though, suffers from being too clever, making it a language in which you
can make concise, powerful solutions, but it can making grokking the code
difficult, inefficient and error prone.

This is where our egos step forward and we announce that it's No Problem For
Me, but we've all experienced a situation where we've leveraged a powerful
language to do some amazing things, and then a month later it is a gruelling,
headache inducing experience trying to figure out what is doing what, where,
so we announce that we'll just rewrite the whole thing.

~~~
pcwalton
> Rust, though, suffers from being too clever, making it a language in which
> you can make concise, powerful solutions, but it can making grokking the
> code difficult, inefficient and error prone.

Can you explain _specifically_ how Rust is supposedly too clever?

~~~
endorphone
With all due respect, I don't think you're in a position to have a unbiased
perspective on this, and I am certain I'm never going to convince you.

But I'll leave it that there have been countless "Rust is too difficult" links
for you to find on Google, many of which have been posted on here. And
_invariably_ when we discuss Rust the conversation goes like this-

"why is it so complex to do [some simple thing]?"

"Oh well Rust is a _System Programming Language_ , and it's doing important
things in important ways"

"Okay, but I'm not building an OS, I'm just..."

[chest puffing, ego's appear, etc]

"Well _I_ certainly have no problem with it..."

~~~
pcwalton
I still can't figure out exactly what design decisions you disagree with, but
it sounds like you're objecting to the lack of GC or memory safety. There are
some applications for which GC is not appropriate. Maybe you don't work on any
of those applications. That's fine, but that's very different from saying Rust
is overly complicated.

~~~
helper
I think this is a great point that indirectly highlights how people are often
talking past each other when a go vs rust debate comes up. People work in
different problem domains with different constraints and therefore the a good
language choice in one domain might be wrong for the other.

I don't think anyone in the go community would suggest you write a browser in
go. Ignoring the GC performance issues, just the awkwardness of using cgo
would make most go developers shudder.

Likewise there are many problem domains where a GC'ed language works just
fine. In these cases it is appropriate to consider other factors when deciding
which language to use. Perhaps your team is made up of a bunch of experienced
scala developers, scala might be a good choice for you over go or rust. That
doesn't mean your good choice is universally applicable to all teams.

Some teams might care more about getting the most value per cpu cycle
possible. Other teams might care more about the time it takes to get a new
engineer up to speed in the language. Both of these can be valid reasons to
choose a specific language.

I guess what I'm trying to say is: "Try to choose the language (and other
tools) that best matches your organizations constraints. Don't assume that
other teams have the same constraints."

------
S_A_P
Its interesting to see what languages become the backbone of different
industries. Here in Houston, .NET rules, and I have seen a huge shift towards
.NET core and cross platform. Im in the middle of a big build out right now,
and we have begun building .NET core services that don't use IIS for our
service layer.

~~~
pjmlp
Here in Germany, at enterprise level it is pretty much .NET, Java, C++ and
Web, while most mobile apps tend to focus either on mobile Web or hybrid
solutions (Xamarin, Ionic, C++ with native views).

Everything else are just small campings.

------
DiabloD3
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.

~~~
the_duke
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.

~~~
enneff
> the ubiquitous `interface{}` pattern

I’m totally biased because I’ve worked on and with go for a decade, including
reviewing all sorts of Go we write at Google, but I just don’t get this
criticism. It’s just not something I see in the code bases I work on. I admit
that I may be working on different kinds of programs to what some others do,
and I don’t want to deny anyone their legitimate experiences, but my personal
experience has been that this is rarely a thing, if ever.

~~~
the_duke
It can be found in many libraries in the ecosystem, and is common enough in
the standard library.

The lack of generics just severely restricts the expressiveness of the type
system.

I think the best way to work around this is use of code generation, which is a
great tool for internal, controlled environments, but very cumbersome for open
source libraries.

~~~
enneff
I don’t see much, if any, generated Go code at Google. Not to say that it
doesn’t happen but it’s not on my radar.

~~~
dnautics
Aren't http or grpc apis autogenerated? You'd be crazy not to use a generator
for those.

------
peterwwillis
I'm still super annoyed that the solution to "dynamically resolving
dependencies is a PITA" became "just make a monolithic app and pray for no
external dependencies/conflicts".

Windows figured this out ages ago. You ship DLLs with your app, you keep them
in the same directory, and run your app wherever, but update it incrementally.
Now your user doesn't need to download a 120MB file every time there is a one-
line change.

Wrapping this pattern in a ZIP file that can be executed directly (another
Windows-ism) basically gives you everything you want from a static app, but
adds the ability to inspect and patch components. Why does nobody use this
method?

~~~
quickthrower2
You can send out binary patches / deltas though?

------
naikrovek
The number of Go-haters (for lack of a better term) in here is astounding, to
me.

If you don't want to see Go in new code, then _don 't use Go in new code._
There's nothing wrong with this point of view, by the way, (even though it
confuses me a bit.)

If you won't use Go because of its current lack of generics, that's a
perfectly valid point! Don't use Go. I don't mind AT ALL.

If you don't like Go for whatever reason, then _don 't use it._ Nothing at all
wrong with that position.

What I am astounded by is the apparent notion in here that "others need to be
made aware my position and brought into agreement with me" \- not quoting
anyone, just trying to cite a feeling MANY of the comments here are giving me.

Maybe it's the HN culture to do this, or the culture of comment sections in
general, I don't know.

~~~
the_mitsuhiko
I’m pretty sure the people that say they won’t use go for new code won’t use
go for new code. Not sure what your point is.

Go (like Rust) is not particularly popular ourside the wider HN/SV community.

~~~
vvpan
What's SV?

~~~
erk__
I guess it is Silicon Valley.

------
bovermyer
I use Go to solve problems. I don't solve _all_ problems with Go.

It works well enough, and the people I work with can collaborate in it easily
enough.

I think that sometimes the (younger?) HN/SV crowd forgets that there are a lot
of coders out there doing good work that don't need The Penultimate Best Tool.
We just need a tool that works.

------
chuhnk
It's amazing to see more and more finding Go. For a lot of us it's been almost
a decade since we started using it. Back then for me it was the perfect blend
between C and ruby. Today I believe it's the language of distributed systems
and the cloud. I personally think Go ends up with majority marketshare for all
cloud native systems and its already going in that direction with the core
tools like docker, kubernetes, etcd, grpc all using it. By extension of that I
believe a signifcant number of backend systems and services in the cloud will
also predominantly be Go based.

This doesn't rule out other languages, its merely an indicator of a trend
we've seen time and time again related to platforms. Windows, Linux, Android,
etc. Every platform has a dominant language. Other newer up and comers like
typescript, rust, swift, kotlin, etc have their place but for their respective
platforms.

Go's adoption will accelerate in the next decade but you'll also find it
disappear into the background as development as a whole levels up beyond the
languages of today.

Only us millenials and older generations will speak of it. The next generation
will be preoccupied with an entirely different model of programming.

~~~
dunk010
And what model of programming do you suggest it might be? ;-D

~~~
brodsky
Training AIs. I strongly believe this will be an occupation class in the
future.

------
mooreds
Ah, the sweet smell of language wars in the morning.

Seriously, though, I wonder how much of golang adoption is due to it being a
shiny new thing relative to Java and how much is due to it actually solving a
problem. Bray outlines several areas where golang functionally outperforms
Java (deadlocks, truly WORA).

I have used golang a bit and found it ok. Because of my background I'd prefer
to write code in a dynamic language but I get that there are times when you
need to have better performance, and you may want that without the baggage of
the JVM.

~~~
dunk010
I didn't find the article all that convincing. Just a general FOMO smell, and
not much substance to back it up. Nothing deep.

------
valyala
Go is awesome programming language, since it is simple, readable and provides
good tooling - code verification (vet), code formatting, testing,
benchmarking, tracing, race detector, profiling - out of the box.

Go encourages writing simple straightforward code without complex
abstractions. This improves programmers' productivity, which allows writing
raw practical code instead of spending time on theoretical design patterns,
inheritance hierarchy, generics, fancy algorithms, monads, "zero-cost"
abstractions (with high mental cost), borrow checking, etc.

That's why we could write fast time series database in Go from scratch in less
than a year -
[https://github.com/VictoriaMetrics/VictoriaMetrics/](https://github.com/VictoriaMetrics/VictoriaMetrics/)
.

------
tracker1
I can't help but feel that JS, Go and Rust will really carve out a lot of
development that is currently in Java, and eventually a lot of C# as well.
Java is a lion's share in corporate dev, and C# is similar, stronger in some
regions/industries.

JS has already gained some traction via MEAN stack (though not a fan of
Angular, and can do without Mongo). Go has started gaining traction, and I
feel that once the Async/Await support cements in an LTS release of Rust, it's
use will grow substantially as well.

Frankly, it's an interesting time to be a developer, and largely the past
decade has been far more interesting than my first in software. I also think
there's still room for improvement.

------
ggcdn
I'm not experienced enough to give a proper critique of go, but I can say that
as a non-cs major learning to code, I found go wonderful to work with. Type
system is good enough to catch errors and understand code at a glance, yet not
overly cumbersome. The language syntax strikes the right balance of verbosity.
The only thing I don't like is the way errors are handled.

------
totalperspectiv
I'm curious as to the thoughts of people here on C#. It's in the same Java/Go
space, and .Net Core serms awesome on Linux.

~~~
WaltPurvis
Maybe you should turn this into an Ask post. I'm curious too.

~~~
totalperspectiv
Ask HN: What are your thoughts on C# on Linux? -
[https://news.ycombinator.com/item?id=20212649](https://news.ycombinator.com/item?id=20212649)

Done!

------
nl
I like Go a lot. I just wish there was as much support in Go for machine
learning as there is in Python.

At the moment, I feel like the whole "Python is the second best language for
every problem" makes it the default choice for a lot of people.

~~~
struct
I wrote a lot of (and still occasionally maintain) a library called golearn
[1] which tried to bring first-class support for the “traditional” ML
algorithms, but it seems that Go’s compiler and toolchain just don’t optimise
well enough for Go to be very competitive on performance for that application.
That’s not a criticism of Go, it’s just that C/C++/FORTRAN have decades of
optimising compiler support and most competing solutions are Python sugar over
a nest of such C/C++/FORTRAN libraries. Go’s also concurrent, which is nice,
but we found cases where being too concurrent also cost performance for most
people. I’m still optimistic that Go has a place in ML, but it’s probably not
right now.

[1]
[https://github.com/sjwitworth/golearn](https://github.com/sjwitworth/golearn)

~~~
nl
I do wonder if bridging to a good matrix/tensor library would be sufficient
(as it is in Python).

I'm aware of the interesting work happening in Swift/Tensorflow and was
wondering what the equivalent in Go would look like.

~~~
Intermernet
Have a look at gorgonia.

[https://github.com/gorgonia/gorgonia](https://github.com/gorgonia/gorgonia)

~~~
chewxy
To add to that, while Gorgonia's Tensor
([https://github.com/gorgonia/tensor](https://github.com/gorgonia/tensor))
library is fairly mature, plenty of work can still be done. Gorgonia proper
too has plenty of work to be done on improving the various VMs. Last, there is
greenfield work to be done in making Gorgonia user friendlier

------
MikeOfAu
The rise of Kubernetes will likely enhance go's presence in devops.

~~~
EdwardDiego
How much Go do you have to write to use K8s though? So far all I've seen is
YAML.

~~~
olalonde
You don't need to write any unless your fixing bugs or contributing to the
project (I'd say parent's comment still stands though).

~~~
EdwardDiego
> I'd say parent's comment still stands though

That people will appreciate Go because a tool is written in it? I'm dubious.

I use Kafka on a daily basis and read its source code with regularity to
better understand its behaviour. and while I love what Kafka can handle, and
how resilient it is, it doesn't enamour me more, or less, of Scala. What I
love about Kafka has little to do with the language and everything to do with
the architecture and design of the system.

Go is probably more readable than a lot of the legacy Scala in Kafka
admittedly (although their new Scala and Java code is far more readable) which
I guess could convince people to give it a try.

------
sandGorgon
what happens at companies where there a LOT of math. Like fintech, AI, etc
companies.

Are there equivalents of numpy,pandas, etc for go ?

what happens when you need to deploy models ?

~~~
kasey_junk
You use something else. Go does well at shuffling bytes. It does ok at
shuffling text. Once you leave those domains it starts to get abrasive pretty
quick.

It turns out lots and lots of systems shuffle bytes & text so golang has a lot
of room for adoption but for now modeling, business logic, math etc are all
better done in other languages.

~~~
walterbell
What are some language contenders for business logic?

~~~
pwm
At work for core domain modelling we use Haskell and for service layer code we
use Go and Node. They are imho good fits for their respective problem domains.

~~~
olalonde
How do "core domain modelling" and "service layer" communicate if you don't
mind sharing?

~~~
pwm
If you mean operationally then it's via simple http apis, although we are in
the process of moving to a fully serverless (ie. aws lambda) setup. If you
mean the data exchange format then it's JSON.

------
fc_barnes
Daily reminder that coroutines require a context switch.

