Hacker News Reader

Comment by joaodlf | Hacker News Reader

I don't share some of the opinions I see in the comments here.

I've recently started programming in Go and I am having a blast. Plus, I am making my systems faster and simpler with Go. I love concurrency in Go. I love the concept of Goroutines, the simple and intuitive use of Select. Channels still present a few mysteries here and there... But I'll get it at some point.

But the n#1 thing for me in Go is: It's written in Go. It's refreshing to drill into the language details, I feel like I have learned so much from seeing the Go source code (and having it readily available with a Ctrl+click in VS Code).

Maybe it's because I don't have the "depth" of some of the HN users, but Go feels great to me.

View on HN

I agree with you, I didn't know how to build a webapp, two years ago, I learned the basics and implemented a fully working webapp in Go along with the REST client, all without having to buy a single book, the docs are amazing, the community is amazing and the language made me build things fast, I love GOPATH, I love gofmt. Apart from the tooling, I felt as if I have been writing Go since a long time, even though I was just a newbie, my app: http://github.com/thewhitetulip/Tasks/

I also wrote a tutorial for newcomers like me: http://github.com/thewhitetulip/web-dev-golang-anti-textbook...

I am really glad for that guide. I came across it last week and really appreciate the methodology (i.e. an anti-textbook) thank you for that.

Thank you for your kind words! I am happy that you like it, I am writing a series of guides on vi, python, git and probably bash along with their YouTube series, you can find them here http://github.com/thewhitetulip/multiversity

  Maybe it's because I don't have the "depth"
  of some of the HN users, but Go feels great to me.

I doubt I have any more depth than you as a programmer, but I've gone one step farther than you down the language safety progression, so maybe my thoughts from here will be interesting.

When I moved from Python to Go not only did my code become more safe, I actually became a better programmer. There are a lot of silly things that you can do in Python that you can justify saying "just this once!" or "it's only temporary!" that are much harder to do with Go. I started writing a lot less complicated functions that did different things with different types, and moved to writing simpler, single purpose functions whenever possible. This was great and I learned a lot.

Then I moved from Go to Haskell, and the same thing happened again.

Haskell makes you specify whether a type can be null or not. It has referential transparency, so you can't mutate variables as a side effect of a function. It has sum types, eg:

  data User = Unauthenticated | Normal UserId | Admin UserId

.. that make it really easy to enforce invariants and are also super convenient to use because of pattern matching. I write a lot less "stringly typed" code now than I did when using Python or Go.

Now there are downsides -- Go has a great standard library, and it's tooling is fantastic (even down to little things like gofmt). I'm not saying you'd have a better experience with Haskell, just that there are real reasons why someone wouldn't want to go back after trying a more featureful language than Go.

> When I moved from Python to Go not only did my code become more safe, I actually became a better programmer.

This is probably more due to the fact that you moved from a dynamically typed language to a statically typed one rather than this new language itself.

Not sure why this is being downvoted without comment, considering that it is what accounts for the example that the parent comment chose.

But Go really does encourage good practices. I came to Go after programming in C, C++, Java and a bunch of dynamically typed languages. After a couple of years with Go I returned to C (and a bit to Java). And I'm writing better code in those languages now.

Now, part of it is natural progress probably. But especially when I'm writing C, I can tell that I'm writing it much better than before because I'm adopting back some idioms that Go encouraged me to adopt in the first place.

Also, because Go's standard library is so well written, you can learn from the best very easily, and understand what's going on. It's certainly not the case with other languages I write in.

I suspect every time you move to a different language family you learn new things. I did C/C++ and Java then worked with an old Pascal codebase of all things that IMO taught me more than most other languages. Even XSLT taught me quite a bit.

I can't say that Java has improved me in any language, but Go and Python have improved my Java. But any time you learn new idioms in a new language, your understanding of programming gets better I suppose.

Is there a good resource where those good transferable go idioms are written? I dont think I will have time to learn go anytime soon, but would definitely spent time with an article or something like that.

Not that I know of, but Go is super easy to learn. You will get a grip of the basics and be productive over a few hours or weekend at most, and one or two hobby projects later you'll learn to appreciate the stuff I'm talking about.

BTW I've only felt I really knew the language and its inner workings and idioms deeply - after much longer, maybe a year and 2-3 big projects. But you get very productive very fast.

Not only that, but rarely am I supporting a library that I'm the sole developer on. Go takes away so much "individuality" of code. On most teams I've been on with Python and Java I can open up a file and immediate tell who wrote the library based on various style and other such. It's a lot harder with Go and that's a very good thing.

Yeah, at times the obsession of gophers with "idiomatic code" is annoying. But when you read someone else's code and it's idiomatic, you almost immediately have an intuitive sense how it works and can understand and modify it easily. Compared to Java OO code where you have to start chasing inheritance layers to find out where the piece of logic you're actually interested in resides...

Well, "idiomatic code" can often mean "for what you're trying to do, there is a way that works with the language better than any other way; do that". That is, it often means "working with the tool rather than fighting it". So, yeah, do it the idiomatic way unless another way is clearly better. (Idiomatic ought to win if evaluating "better" gives you a tie, because idiomatic will be more readable.)

I never really stopped to think about it until I read your comment, but I just realized the same applies to old Go code. As some of mine is approaching probably close to 2-3 years (and few things I haven't touched or looked at since!), and while it certainly could be rewritten to be better, it's interesting that Go's partial enforcement of idiomatic authorship appears to reduce the number of WTFs generated as a consequence of atrophy over time, to say nothing about how much less time is spent understanding the code.

Perhaps it's psychosomatic, but it sure seems easier to pick up something written in Go--long since forgotten--than it is in other languages. Then again, maybe it's also that Go taught me to substitute cleverness with terseness. The advantage here is that I've never been especially clever.

Interesting!

i think a couple of years of experience and learning a new language .. was a far bigger factor than any intrinsict characteristics of go

Not sure. the diff between 12 to 14 years experience is not like 2 to 4 years.

The type system is an integral part of the language.

That was true until things like optional typing as seen in flowtype/typescript came along.

I'm with you. IMHO, Go's simplicity is its biggest virtue. It has fostered a community that values consistency and clarity over syntactic sugar. And, as a result, I find each new codebase extremely accessible.

Definitely. Simplicity, and fantastic standard library. Go is like a much faster and more reliable version of Python.

People comparing it to C++ and Rust miss the point.

Normally it's the other way around, Go gets compared to other "Systems Programming" languages because somehow services got lumped in with that name over the last few years.

To me they're very discrete things, if you can't manually manage memory(raw pointers and the like) then it's not a System Programming language.

Go gets compared to "systems programming" languages because its designers specifically intended it to be used as such [1][2], albeit the definition of 'systems' they are using is deliberately evolved from the original shade of meaning as suggested by low-level languages that are sometimes deemed to be for 'systems programming' to illustrate that the nature of environments has changed, and a new approach is advantageous.

[1] https://talks.golang.org/2012/splash.article [2] https://golang.org/doc/faq

If its a "new environment" doesn't imply that it can't be systems programming?

I totally agree that Go is fantastic for services and networked things.

i.e., distributed systems.

And further, in my view, if manual memory management is extraordinarily difficult a language is not necessarily a good candidate for systems programming.

You can relatively easily get to manual memory management using Go's runtime, i.e. access those runtime·sysAlloc(), runtime·sysFree() functions directly, the way Go accesses syscalls in the external sys package [1]. It's like ten lines of code, nothing extraordinarily difficult.

[1] https://github.com/golang/sys/blob/master/unix/asm_linux_amd...

The difficulty of manually managing memory isn't necessarily to do with how many lines of code it takes to allocate or deallocate. The difficulty is in managing the scope of the rest of the program that is now susceptible to memory errors, which extends far beyond those initial ten lines of code if encapsulation is done inexpertly.

I think you have this backwards. 'Systems programming' has never meant 'operating systems'. To believe that Go is misdescribed as a 'systems programming' language you have to believe Rob Pike doesn't know what 'systems programming' means.

Perhaps you could help clear up the misconception by fixing Wikipedia's 'System Programming' and 'System Programming Language' entries.

It might also be worth commenting on these[0] Stack Exchange answers, too.

[0] http://softwareengineering.stackexchange.com/q/151610/54726

Why would I? They support what I said directly - 'system programming' is not limited to operating systems. Here's a bit from one of the Wikipedia entries you mention.

"System software is computer software designed to operate and control the computer hardware, and to provide a platform for running application software. System software is computer software designed to operate and control the computer hardware, and to provide a platform for running application software. System software includes software categories such as operating systems, utility software, device drivers, compilers, and linkers."

"System software includes software categories such as operating systems, utility software, device drivers, compilers, and linkers"

Most of those things can be summed up as "operating systems" (operating system, device drivers, and utility software, e.g. basic backend services) plus some essential supporting stuff (compiler and linker).

So, yeah, it's pretty much constrained to "operating systems" and the few essential items. It's not about network servers the kind Go is used for.

So it's not constrained to operating systems but it's pretty much constrained to operating systems. You can see how I'm less than convinced.

It's just not a precisely defined technical term and in a computer language really has more to do with the intent and purpose of the designers and implementors and the operational context than things like 'has manual memory management' or 'must be used for writing an actual operating system'. By your strange definition, writing an NFS server would not be 'systems programming' because for some reason networking is excluded. I don't find this seemingly arbitrary distinction convincing either.

>So it's not constrained to operating systems but it's pretty much constrained to operating systems. You can see how I'm less than convinced.

It's just that operating systems is not just the kernel. The POSIX userland of tools (ls, cat, ps, etc) are also systems programming, and essential part of an OS. And of course device drivers (which they even get linked or loaded directly to the kernel).

Postgres, Varnish, redis, or Apache on the other hand, or some ad-hoc enterprise backend service, is not "systems programming".

>* By your strange definition, writing an NFS server would not be 'systems programming' because for some reason networking is excluded.*

Never said that "networking is exclude". The TCP/IP stack is very much systems programming, as an example. And NFS would be too, as it's still a kind of filesystem (and thus working with the kernel and OS at a low level), and an essential part of a POSIX system.

Some load balancer for MySQL, on the other hand (one of Go's touted examples), not that much.

The definition of 'systems programming' is certainly wooly (and predates all of your examples) but I don't think it's an iterative stochastic hairsplitting fractal, like you're proposing. You've basically argued your way to a corner in which varnish and apache are not 'systems programming'. That's not a sensible use of the term.

If Apache is "systems programming" then why not one of the various web servers written in Lua or Python or whatever?

Are those then "systems programming languages" too?

Nope.

But is the activity of writing a web server in Lua or Python system programming?

In my experience, pvg is correct. It's been ages since "systems programming" was limited to just "operating systems" from what I can see. I don't know anybody who wouldn't refer to writing middleware or network servers as "systems programming".

Systems are relationships between input from the environment, algorithms/functions to process it, and output to the environment. Basically programs at a high-level representation. Systems analysis, design, and implementation started with basic control systems far as I can tell. At some point, there was a distinction between "systems" and "application" programming made by whoever. Original meaning of the term covered all programming where you then picked tools (eg languages) best suited for particular task.

Go's predecessors... Oberon-2, C, and Limbo... were two languages for OS's plus a distributed, systems language. Go's core is the first two with last being mainly for concurrency IIRC. That with ability to do unsafe stuff makes me think of Go as a systems language used mainly for regular applications.

Wikipedia says:

The primary distinguishing characteristic of systems programming when compared to application programming is that application programming aims to produce software which provides services to the user directly (e.g. word processor), whereas systems programming aims to produce software and software platforms which provide services to other software, are performance constrained, or both https://en.wikipedia.org/wiki/System_programming

By that definition it seems pretty clear that systems programming covers a lot more than just operating systems. But calling a language a systems programming language if it is unsuitable for writing operating systems seems a bit unusual. At least it would have been unusual at the time these terms were originally coined.

Given Pike's extensive experience inside a world of his own making (Plan 9 and Go), it's entirely reasonable to attribute the misconception that Go is a system language to Pike's idiosyncratic use of the phrase.

If I understand things correctly, Go came about as fallout related to the non-scalability of Python and the massive technical debt associated with Python within Google. The projects to automagically port Python code to Go code are a clear indicator that Go was at least in part imagined as a replacement for Python.

I personally wouldn't describe Python as a systems language, but some might.

Pike's idiosyncratic use of the phrase.

There's nothing idiosyncratic about it. "Systems Programming" has meant a lot more than just "operating systems" for at least as long as I've been doing this stuff, which dates back into the 90's. Maybe in some earlier age it was the case that "Systems Programming" was limited to "operating systems" but if so, it was quite some time ago. Language evolves...

Actually, Go was born out of a desire to make something better than c++ for google scale and style use. https://commandcenter.blogspot.it/2012/06/less-is-exponentia...

It just happens that Go is a better replacement for python than c++ in the general case.

Yeah, one of the cool things about go is it's ability to get reasonable compile times without byzantine management of include files, as in c++. I still don't know of any major c++ code base being targeted by go, whereas python is certainly in the crosshairs.

> To me they're very discrete things, if you can't manually manage memory(raw pointers and the like) then it's not a System Programming language.

Having a GC doesn't forbid that, in very specific cases.

Mesa/Cedar, Modula-2+, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, System C#, Swift, D are all examples of such languages.

Rust, too, had an optional GC (where the choice is per-data, not global) for a long time and still intended to be a systems language (And was pretty successful at being systemsy IMO). I think there was a time when &-pointers didn't exist and all sharing was done through the GC too. At one point there was a realization that the new borrowing system could be used to write GC-less programs pretty easily, and that was a turning point after which the GC started being phased out in community usage and eventually removed from the language.

I never said anything about having a GC, just that if you can't poke directly at memory when you need to then you're going to have a heck of a time working on the Systems Programming space.

> if you can't poke directly at memory when you need to then you're going to have a heck of a time working on the Systems Programming space

That's possible in go with unsafe.Pointer. Go's runtime, GC and memory allocator are written in Go and make use of this.

As mseepgood already replied, you can do that in Go.

Also remember Go was inspired a lot by Oberon-2. The Oberon languages were used for writing operating systems despite a GC. They just used assembly or UNSAFE constructs for stuff the type-safe or GC parts couldn't handle.

It gets compared with them because that is what it is particularly good for. Arguably, it is much less suited to Type 1 representational systems (http://aryehoffman.com/entry/project-types), for the same reasons as for the C language. Like C, it is particularly suited to Type 2a projects - those in computing and its infrastructure.

Yeah i love go and i am a C++ and Fortran dev by day. For me go just gets out of the way, and its just so easy to build actual things quickly. AND you get a static binary out of it which gets rid of the deployment issues with python.

Go is a really good git-r-done tool. There's nothing wrong with that despite what some would have you believe.

Our internal dashboard is Elm but the back end is mostly Go. Both have their pros and cons but both work. That's more than I can say for many other dev tools.

> Maybe it's because I don't have the "depth" of some of the HN users, but Go feels great to me.

I've been writing Go full-time as my primary language for nearly five years. Before that, my languages of choice were Lisp[0] and Python, with R as a very distant third choice[1]. I have always been a polyglot and enjoyed experimenting with any new language I could try out - you'd be hard pressed to name a non-esoteric language that I haven't written more than a "Hello, World" in at some point.

I still write other languages and appreciate them for what they are, but Go is what I reach for when I need to crank something out. The language gets out of my way and doesn't distract me - and as an added bonus, I can be reasonably confident that I can quickly refactor the code 6 months later and still have it run[2]. Go is not a scripting languages, but I sometimes even write small applications in Go that I would have previously written as shell scripts, just because it's easier and less thorny than remembering to avoid all of the pitfalls of shell scripting.

You might say that this is because I've been writing the language for so long - and yes, I'm definitely more comfortable with it today than I was in 2012. But everything I just said was still true even when I was only a few weeks into learning the language. It was like putting on glasses for the first time in my life - yes, I could "see" before, but somehow everything was just a little bit crisper, and I felt incomprehensibly more powerful and capable when writing Go compared to Lisp, Python, Scala, Java, Perl... despite having far more years of experience in those other languages.

If some people don't want to use Go, that's fine with me. But I strongly reject the criticisms that Go is meant for "mediocre" programmers, for programmers without experience in functional languages, or somehow an inferior language because it lacks feature X or Y from language Z.

[0] Common Lisp (via SBCL) or Racket, depending on the project and collaborators

[1] It's a language with a lot of warts, but even Python couldn't touch R for completeness in statistical libraries.

[2] Seriously, I have never found a language that made refactoring as easy - or, dare I say fun? - as Go.

> Seriously, I have never found a language that made refactoring as easy - or, dare I say fun? - as Go.

Sounds like someone's ready for Haskell.

>If some people don't want to use Go, that's fine with me. But I strongly reject the criticisms that Go is meant for "mediocre" programmers, for programmers without experience in functional languages, or somehow an inferior language because it lacks feature X or Y from language Z.

I think such complaints are the predictable backlash that's correlated with the final stage of its hype-cycle. Tech hipsters always need a hot new thing to tout so that they can pretend to know what they're talking about.

Now that we have a new iteration of hyped languages in Swift, TypeScript, and Elixir, Scala, Go, and node.js are on the hipsterdom downtrend (which often also means they're on the mature user uptrend). That prior generation of languages are now at least semi-widely known, so they no longer serve the purposes of the talentless hipsters, who base their self-worth on the esoteric nature of their preferences and need something that most people don't yet know much about to hide their ineptitude.

I think Python is a great example of a community that built a real niche for itself and legitimately earned the respect of mature, senior engineers by repeatedly proving and improving its utility and stability for many years. Giving Go the opportunity to develop this same type of sustainable, consistent, healthily growing ecosystem without a flood of 0.1x programmers and other hipsters is really the best thing for it. I'm optimistic for Go in the long term.

At the beginning of the Java and the XML hype cycles few people called that out the new toys weren't as shiny as they looked on the box. It took 10, maybe 15, years for others to catch up.

Look behind hype cycles and often you'll find $company marketing department.

>I strongly reject the criticisms that Go is meant for "mediocre" programmers

I don't know how else to describe people who don't resent being second-class citizens under the library designers, who don't insist on being able to create their own abstractions and use them with the operators that slices or maps support. The language has extensible interfaces but doesn't use them for things like iteration and equality.

> I don't know how else to describe people who don't resent being second-class citizens under the library designers...

One suggestion: describe them as "people who have a different opinion than I do", rather than automatically concluding that anyone who doesn't feel the same way as you do about something must be "mediocre". There are popular languages that I can't stand writing, and languages that I think are badly designed, but I would never be tempted to say that those languages are "for mediocre programmers" just because they don't have the attributes that I look for.

As a polyglot, I can definitively say that every language in widespread use is "missing" something in its design that, at first glance, would be glaringly obvious to someone who's used to a different language. If anything, the sign of a good programmer (as opposed to a mediocre one) is the ability to conceptualize why a language might be successful despite (or even because of) this apparent "flaw".

>One suggestion: describe them as "people who have a different opinion than I do"

Some "different opinions" are just different opinions, other "different opinions" do indeed point to mediocre programmers.

I'm not saying that is the case with Go: just that what you wrote is orthogonal. One can have a different opinion that is NOT to be respected, but dismissed. Not everything is equally valid.

"How do I iterate over a slice?"

"for...range."

"How do I iterate over my own type?"

"The hard way."

"What interface can I implement to make for...range work?"

"You can't. Our types are important enough to support properly, yours aren't."

As a programmer I expect more than that, and I don't respect people who meekly agree that creating types is properly left to their betters.

> But I strongly reject the criticisms that Go is meant for "mediocre" programmers, for programmers without experience in functional languages, ...

It's not a criticism, it's literally how the Go language creators themselves describe it. See the Rob Pike quote at http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-in...

> It's not a criticism

I'm responding to criticisms in this and other HN threads about Go, so yes, I'm talking about a criticism.

> it's literally how the Go language creators themselves describe it. See the Rob Pike quote

Unless you think Rob Pike is saying that Google is hiring mediocre programmers (hint: he's not), that statement is intended as a criticism of academics ("researchers"). He's saying that the same things that excite researchers about programming languages don't lend themselves to good software engineering in industry. (And he's right).

But regardless of what the creators of the language may have intended, I'm saying that the criticism regarding experience with functional languages is flat-out wrong. I've written more code in various functional languages than the overwhelming majority of people who read this site - both on and off the clock - and I'm testifying that yes, even for someone who has deep experience with functional language of both the Lisp and the SML families, Go still has a lot to offer that very few others do.

> Unless you think Rob Pike is saying that Google is hiring mediocre programmers (hint: he's not), that statement is intended as a criticism of academics ("researchers"). He's saying that the same things that excite researchers about programming languages don't lend themselves to good software engineering in industry. (And he's right).

If that was the case, it was a very dubious thought. Before Go was launched, the languages used in Google were Java, Python and C++. None of them look academic, none of them seem to require another language that is specifically designed to "unexcite" newcomers. Neither is functional, really.

OK. I should have said, it's not inherently a criticism, it's just a fact. That others may choose to use it as a criticism--well, that's upto them.

Personally I don't think there's such a thing as a 'mediocre' programmer, I think there are programmers who have studied and trained in concepts, techniques and idioms and those who haven't.

It seems pretty clear from that quote that Google is hiring kids fresh out of college, and instead of training and educating them they're throwing them at an intentionally simplified language to get them to churn out code quickly.

Also I find it hard to believe that type-safety guarantees don't lead to good software engineering in industry, when the biggest industrial users of Python, PHP, JavaScript and Clojure--the dynamic language titans of the tech industry--have all recently developed and popularised type systems for them.

And in fact, I also don't see how you can derive a criticism of academia out of those quotes when they mention 'researchers' only in passing, as a point of comparison to talk about their coders' skill level. Too much mental gymnastics for me.

> I think there are programmers who have studied and trained in concepts, techniques and idioms and those who haven't

Which is really just talking in circles, because as I've now said in three consecutive comments, I have quite extensive experience with functional programming, and so I'm rejecting the argument that Go is simply for people who don't have that experience.

> And in fact, I also don't see how you can derive a criticism of academia out of those quotes when they mention 'researchers' only in passing, as a point of comparison to talk about their coders' skill level.

It's probably because, in five years of writing the language, I've had the opportunity to hear Pike (and others) talk about the topic. So when I'm responding, I'm drawing on that body of knowledge to inform what I'm saying, rather than limiting myself to a single quotation cited on a blog post written by someone who (by his own admission) is very new to the language.

> ... I'm rejecting the argument that Go is simply for people who don't have that experience.

You may reject it, but the fact remains that that was explicitly one of their design goals when creating Go.

> ... a single quotation cited on a blog post written by someone who (by his own admission) is very new to the language.

A quotation is a quotation; either Rob Pike said those words or he didn't. Who cited the quotation doesn't make a difference.

> Unless you think Rob Pike is saying that Google is hiring mediocre programmers (hint: he's not),

Actually that's exactly what he's saying - although "inexperienced" is probably a better word than mediocre.

Golang is the modern blub language. It's really great for large companies and big code bases used by many people who want to get quickly up to speed. A decent, even new, programmer can get up to speed and be very productive in Golang in a matter of weeks. I can go and read the Kubernetes code base, which is huge, and know exactly what's going on pretty quickly, despite the complexities in that codebase like code generation and massive concurrency.

A language like Rust on the other hand would take months before someone can be seriously productive in it. That has a very real cost. It's sacrificing short term productivity for the long term benefits.

I think for a big company like Google, with so much staff, many inexperienced, and relatively high turnover (lots of people leaving and going constantly), a language like Golang is perfect.

At a small hedge fund, where you have maybe a dozen or two lifers, investing in a more strategic language like Haskell, Rust, OCaml, etc. starts to become viable.

Bah, a language being 'easy to get up to speed with' and 'a perfect fit for large teams working on huge code bases' should be a clue to stay the hell away from it.

Because if Golang maintains its current momentum, someday soon the developing world will start pumping out legions of mediocre Golang coders, just as they did with Java.

Especially when compared to working with something like Spring Boot every day it's fantastic. Getting rid of all the bloat is a bigger win than any of its unique features in my opinion.

Comparing Go directly to Spring Boot? ;)

What are your problems with spring boot? What bloat are you referring to?

I suppose most of my negative experiences with it are specifically in the context of using it to build microservices. The memory usage alone created a bit of a problem, I ended up using nearly all of my 16GB of RAM when I had to run many services simultaneously. And because the functionality of any given service was fairly minimal, there really wasn't a need for a framework like that.

The autoconfiguratuon was also a bit dangerous. Since any dependency could cause any other dependency to reconfigure itself, it made it difficult to determine why things would break at times. At one point one of our libraries that used RabbitMQ behaved differently in some other services because another dependency saw RabbitMQ on the class path and started trying to use queues that didn't exist. Someone spent a day and a half figuring that out because the error was being swallowed by something else so the application was just failing to start with some crypic error. And when autoconfiguration wasn't enough, you'd sometimes find yourself needing to write dozens of lines of Java to do something as simple as connecting to a second database.

In general I found we tended to have less predictable or obvious behavior in our Spring apps, and they tended to be more likely to fail at runtime than I would've liked.

I usually get rid of @EnableAutoConfiguration and then selectively import the auto-configuration classes I actually want with @ImportAutoConfiguration.

A Spring developer once mentioned, on a mailing list post i have long since lost, that the autoconfiguration stuff is pretty much demo-ware. It's good for getting a simple app up and running fast, but for anything serious, you should import the configurations manually, exactly as you say. Fortunately, that's an easy enough transition to make at any point in a project's lifetime.

I don't think I'll be working with it again in the near future but I'll definitely have to keep that in mind in the future.

For me, I imagine the dropwizard guys sat round asking each other what the best servlet container is, web MVC tool, ORM, DI framework, etc, etc. and they choose the very best they can think of for a dev to work with.

Then a couple of years later that company comes along where they ask the same questions and but there's a guy with Tourette's in the corner and Every. Single. Time. the answer to the question is SPRING!! SPRING!! SPRING'S THE RIGHT ANSWER!! SPRING!

From the moment you boot spring boot and discover how much longer it takes to boot it's a struggle not to question the motivations of a place where the answer's the same no matter the question.

Sorry. I know some people love it!

Actually, in that company, the answer isn't always Spring Boot. Sometimes it's Cloud Foundry.

I love spring boot. And I like golang as well.

Spring might look bloat in the start, but it's powerful. At present there's no framework in golang which has so much power and freedom...

I completely agree. Go made me enjoy programming again.

I really enjoy programming in golang, having recently taught quite a few people the language I am forever thankful for its simplicity.

This paired with vscode + click to see other peoples code is a great platform to get started with systems programming and tools development.

Can't thank the go developers enough.

I also enjoy it, but just wanted to note that Go is not really a systems programming language, unless you mean "cloud/network systems".

Yeah, systems programming != distributed systems. I think Rust is a better example of a modern "systems" language.

I don't know. I feel like if I need something productive, I would go very high level like Python. In the VERY rare case Python is too slow, I would go really low level like rust.

I don't see the interest for something that not really low level, but not realy high level either like Go. If concurrency is the main issue and is the niche I'm targeting, I would go Erlang or Elixir.

I have a hard time finding any use case for Go.

For me Go is the goto language for usecases where Python and Java were used. Python is great for tooling, and Java was the primary language for the backend.

So now, whenever i think about tooling or backend, Go is the primary answer, because its good in both paradigms.

The other languages i use is C++, and Swift, each one with their own niches. C++ for complex machinery, that requires more control and integration with other libs, and Swift for general applications, specially the ones that are user focused.

In my case, i cant find a niche for Rust. And thats because C++ is already covering that ground for me. I can see why i would use Rust instead of C++, but in the majority of cases where i use C++, there are huge complementary source code already in C++, making the effort to code everything in Rust from scratch, a complete nonsense.

So for me the language in "limbo" right now is Rust. (and i dont think that people with big C++ codebases would rewrite in Rust, because there's little advantage, at least compared to modern C++)

One nice thing about the "rewrite C++ in Rust" is that oh can do it incrementally; we're taking the same approach for Firefox, for example.

Out of curiosity, what are the libraries in C++ that you miss in Rust, or would have to re-write?

For me C++ (or Rust) would be the languages to go for Browsers, VM's, Compilers, Game Engines, Glue Code for a OS(platform layer to prepare things for a app to run) etc..

The problem is, there's a lot of code in C++ already for all of this. V8, Dart, Java Vm's in C++, Webkit, Chrome, Firefox in C++, great game engines in C++.

Is not that i wouldnt use Rust.. on the contrary. But the problem is, for the usecase i think Rust would be very good, there are a lot of code in C++ already, that would require a effort of years to port in Rust.

For instance i work in Chrome C++ source a lot.. and the codebase is a beast.

Maybe if, in the future, things that are starting now in Rust, will be the the successful cases for this kind of machinery.

But given that, at least i, wouldnt use Rust to make a webserver backend (the same way i wouldnt use C++ for that), because i think its overkill. While i like Rust, i cant see a opportunity to use it, and the great impediment for that, is the C++ codebase legacy, and both languages basically competing for the same paradigm.

But theres a great thing in favor of Rust, because its the only modern real contender to C++. But i think it will be a slow and harsh competition (albeit a necessary one).

Cool, totally get this argument. I was mostly curious if you were thinking about something in Rust, but then found the libraries lacking, as we're trying to work on filling in gaps here.

Yes. And just to make it clear, when i say "in limbo" is actually a compliment, in a sense that i want to use it, but didnt found the right opportunity to do so.

I would be glad to be able to use Go, Swift and Rust, instead of Go, Swift and C++. Its just that i cant find a way to do so, and it has nothing to do with Rust the language, the ecosystem and the community. They are all awesome.

The target audience is people who don't know Elixir and Rust, have no time and not enough conceptual base to learn them in a reasonable time, and have to ship concurrent code, fast. Go is stupidly simple; this can also be an upside.

Python's concurrency story is much better in 3.5+ than in 2.x, but a lot of people use 2.x for various reasons.

Turns out also that, from an organizational perspective, it can take a lot to support n+1 programming languages. A codebase with 10 languages is more difficult to maintain than one with 2 or 3.

As a result I think there is large benefit to having a language like Go -- it satisfies many overlapping needs, and organizations can avoid adopting too many other languages that fulfill niche areas.

At Google there are only (5) core / officially supported languages: Python, Javascript, Java, C++, and Go.

Python is generally applied in a scripting context. Javascript in frontend context. Java / C++ where you'd expect. Go for writing servers, application infra, tools, scripts, etc.

You forgot Dart and Typescript, which power AdWords and Angular respectively.

Same here! I code Go for ~3 years in my spare time and PHP only for hard bucks

> and having it readily available with a Ctrl+click in VS Code

I haven't used VS Code since the beta, but it can do that now? Wow. I should give it a try.

Reply on news.ycombinator.com