[atx42]

I think Go and Angular should have died, and would already be footnotes in programming history if they had not been introduced by Google. Let's make procedural programming great again? I get it, you can compile it and it has concurrency, but there's better alternatives in my mind, unfortunately not as popular.

[bloblaw]

Go is successful because it has many appealing features:

  1. trivial cross-compilation
  2. native multi-threading (eg no GIL or multi-process hacks) that is easy to take advantage of
  3. fast. An order of magnitude faster than Python in many cases.
  4. easy to deploy. Most often just a single binary

I like Go because once I compile it, I can ship that binary anywhere and it will run. I like Python for a great number of tasks and for prototyping, but I prefer Go when I need to run my code on another machine (or it needs to be fast).

To put it simply, with Go I ship a binary. With Python I have to ship my entire development environment.

[didibus]

Ya, and if you look at the language space, there's nothing else that offers #1.

That set of features isn't related to the language itself (though the language was designed to allow those features).

This is where Go is appealing, it's not the language itself, it's the properties it brings with it. Cross-compilation, multi-spec, reasonable performance and low memory footprint. Single binaries. And I'd add fast compilation times.

Honestly it needs more competition that offers those same properties, because I'd love to have more choice of language (syntax + semantics), but get the same properties. But for now, you have to use Golang if you want something that gives you all those properties and that's just where Golang differentiates itself.

[bloblaw]

That's a great point, and one I hadn't considered. One language feature that Go brings is first-class multi-threading and communication amongst and with child threads.

The only languages I know that can compete with Go with similar properties are Nim, Zig, and Rust. I'd like to include Delphi / Free-Pascal, but cross-compilation can be a bit of headache at times.

[Tozen]

Well, when it comes to cross-platform desktop apps, Lazarus (Free Pascal) and Delphi (payware) do very well. There is nothing in Nim, Zig, Rust, or Go that I know of that can compare to the Lazarus or Delphi IDEs (for Object Pascal). As a matter of fact, there is an effort among Golang users to copy Lazarus. But, for Lazarus and Delphi, things get a bit shaky when we start talking about mobile or desktop and mobile development.

Delphi incorporates a mobile solution that was bought for the purpose, called FireMonkey, that doesn't completely integrate with their desktop solution (VCL). Each new version of Delphi is making progress with integrating the different solutions more tightly, but we are still talking about payware that is priced above what most individuals would want or feel comfortable paying for.

Lazarus, for various odd reasons (or even suspicious reasons), their developers appear to be dragging their feet with making a mobile solution. They should be able to incorporate technologies such as OpenGL ES with LCL and their custom drawn interface, but don't. A 3rd party developer came up with their own solution, that works for Android only (LAMW), but doesn't integrate with the desktop solution (LCL) nor is a part of Lazarus. So for Lazarus, outside of desktop development, things get a bit confusing. However, if team Lazarus ever got their act together and took mobile development more seriously, they probably would have among the best solutions out there.

[didibus]

I didn't know Mom and Zig had those properties, I'll have to check them out.

Rust I believe doesn't do true cross-compilation, isn't it just relying on you using virtualization like docker and other to do so?

[steveklabnik]

Rust does "true" cross-compilation, yes.

There is a tool, "cross," that uses Docker as part of its workflow, but it's not inherent in Rust's abilities to cross compile.

[xigoi]

Nim has all these properties. (I'm not sure about threading because I don't use it much.)

[snapetom]

The two things I always bring up in interviews on why I like Go:

1) Easy to use pointers. There's just pointers, not like C where you can have anywhere from 4 to 8 different types depending on your platform. And no, pass by reference vs. value are not the same as pointers.

2) Very simple to use concurrency.

[mb7733]

> 1) Easy to use pointers. There's just pointers, not like C where you can have anywhere from 4 to 8 different types depending on your platform. And no, pass by reference vs. value are not the same as pointers.

Do you mean C++? Or am I confused?

[snapetom]

Null, void, wild, dangling in core C. DOS also had far, near. I believe one of the Windows Visual something platforms had extensions that added another three or four.

[bornfreddy]

I'll bite. So null is just a special value one can assign to a pointer, marking it not used. In Go this is nil. Void means "absence of type" and is related to pointers only marginally - void* is a pointer to something we don't know a type of. In Go, I guess a pointer to interface{} would be the same? (Not quite, but close)

As for wild and dangling pointers (I would argue the are the same - pointers that show somewhere they shouldn't), fair point. Of course one would expect this from a language so many decades younger.

But none of these are pointer "types" (far and near arguably are - iirc they determine the size of a pointer - but these four are not). I hope the question on the interviews are posed differently, I for one wouldn't know what you mean.

[kaba0]

> As for wild and dangling pointers (I would argue the are the same - pointers that show somewhere they shouldn't), fair point. Of course one would expect this from a language so many decades younger.

It’s not due to age, but due to having a GC and being a managed language. I really don’t get all the comparisons of Go to C, the former seems to want to sell itself as a modern C replacement but they are nowhere in the same niche (and that’s ok, there are very few places where a GC can’t work). They just operate by completely different semantics when it comes to pointers.

[lenkite]

I love Golang but its pointers are awful. "Nil is not really Nil" has tripped >1M Go programmers. It's the "trillion dollar" mistake.

People make fun out of C++ all the time. Yet, Go has some extraordinary Gotchas of its own. You need to read "The Go Bestiary" to make sure you don't blow your head off.

[kaba0]

1. VM-targeting languages have even more trivial cross-compilation, like you even get a single .jar file 2. There are hundreds of languages like that 3. It’s not too hard to be faster than python - Java, C#, JS are all in the same ballpark as Go (and for more complex programs some can often surpass it due to the much better GC-implementations) 4. Very very slightly easier than the above mentioned bunch. But with Java’s stellar backwards compatibility record you pretty much just has to have a big enough JVM version and that’s it.

[wiz21c]

How fast is it compared to rust ? Do you know.

I ask because I've started a side project in rust because all of its guarantees were appealing to me (I don't want to spend too much time on bugs, and my code uses some threads). I also need maximum performances. So I've chosen it. But now I have my compilation times that reach 45 seconds, so I'm slowly wondering if the go balance (towards fast compilation) would not be more advantageous; unless of course, performances are real bad...

[cogman10]

There are a bunch of different metrics for performance that it is a little hard to compare.

Rust will have faster CPU and memory performance. It has no GC (well, other than RC). If you are IO bound, there won't be much of an appreciable difference, assuming you are using Rust's async/await for stuff. If you are using threads directly, then it will be a lot easier to make goroutines faster for IO stuff.

The long compile time of rust has a lot to do with it's LLVM backend, which is ultimately generating pretty fast code. You don't get that with go (well, unless gollvm lands). Go traded execution speed for compile speed by doing their own compiler/optimizer. Generally speaking, that doesn't really matter (hence the reason python is popular).

[throwaway894345]

It's about on par with Java and C#, which is roughly in the ballpark of "half as fast as Rust/C/C++". If your goal is to spend less time programming overall, Go is great for most applications. If your goal is to spend 10% less time fixing bugs and 100% more time writing code, Rust is great for most applications. :) Of course those figures are made up, but in my experience they're in the right ballpark (I like both languages, but if I actually want to get something done in a reasonable timeframe I always end up using Go).

[snapetom]

As someone who has started side projects with very technical and opinionated friends, just stick with Rust.

Make a decision, stick with it, ship it. If there's a real problem, change it after you have it up and running. There's no point in optimizing for millions of users if you have 0 users now.

[wiz21c]

yeah sure, I have zero user and well, it may be like that until my death :-)

that project was an excuse for learning rust. But now I understant rust a bit more, well, I'm a bit scare to wait 45 sec on each build for a side project (ie a project I do on my very limited spare time) :-)

but anyway, rust is really cool to work with (I have a python/C++/assembler/R background). The level of checking it does is really mindblowing (and frustrating at times :-))

[estebank]

Try to debug where your compile times are going[1][2], but if you want a good rule of thumb: separate your crate into multiple if you can (that way incremental compilation will yield better results), switch to an alternative linker, like mold or lld, and use trait objects instead of generics (monomorphization can be expensive during compilation, while trait objects can be slower at runtime, but not enough to be worth it worrying about it).

[1]: https://fasterthanli.me/articles/why-is-my-rust-build-so-slo...

[2]: https://matklad.github.io/2021/09/04/fast-rust-builds.html

[wiz21c]

Thanks to some hints in those articles (basically, enabling incremental builds on release mode), I've been able to remove about 70% (yes!) of the build time :-)

Thanks!

[didibus]

Go is slower than Rust. Rust allows you to go as fast as the metal can get you if you want.

But Go is still reasonably performant and has a reasonably low memory footprint. We're talking C#/Java level performance with C level memory footprint.

Rust is the next level up in performance.

[igouy]

How fast to do what?

fwiw https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

[lupire]

Why do you need maximum performance?

Logically, if you need maximum performance, you can't care about compile time.

[Gwypaas]

Consider turning your crate into a workspace instead. That usually helps to keep the compile times manageable.

[Xeoncross]

For a lot of people like me, Go was something of a better scripting language.

It wasn't as hard to grok as C or Rust, it wasn't as slow as Ruby, Python or PHP. most of all, it it was designed to make use of multiple cores. Surprisingly, having testing and formatting built into the tooling is also a huge win after spending years debating and changing choices in scripting land.

Go is the new PHP/Node.js and Rust is the replacement for everything else. I know this is technically wrong, but that's how it feels.

[tech_tuna]

Agreed 100%. I've used a bunch of languages over the years: C, C++, C#, VB, Perl, Java/Groovy/Kotlin, Javascript, Lua, Ruby, PHP, Python and Go. All fairly mainstream and I'm not going to start railing on the ones I don't like. . . so let's just say Python was the first language that I loved and Go is my current favorite.

For me, readability, simplicity and having compile time checks are wonderful. Go feels like a better Python. I still enjoy using Python but "runtime is funtime" even with type hinting and linting and everything else.

I am also a sucker for good tooling and a pleasant dev experience. Go has fantastic tooling. That being said, it has its warts and weak points. If I need to write something quick and dirty, I prefer Python. If I need to parse JSON and I don't have an easy way to generate client code, I prefer Python.

There are some quirky bits in Go I don't particularly like e.g. the reversal of parameter type and name in function signatures. . . that just confuses me because I typically am using 2-4 different languages in any given week and Go is the weirdo in this regard. :)

I would be thrilled to see Rust become the dominant systems programming language some day. I'm planning to learn it as soon as it looks like the right choice for me - for most of my work, Python + Go + bash (I love and hate bash) are more than sufficient.

[Sohcahtoa82]

> I still enjoy using Python but "runtime is funtime" even with type hinting and linting and everything else.

I'd love to see a s̶t̶r̶o̶n̶g̶ statically-typed Python that could throw type errors at compile time. I've only taken advantage of the duck typing once, and the way I did it was a massive code smell and I ended up refactoring it out anyways.

[kortex]

You mean statically typed? Python is already strongly typed.

Try running it through mypy with all the strict options. If you can get it to 100% pass and don't try to "cheat" the system too much with dynamic casts, I think you will find runtime type errors to be very rare.

[Sohcahtoa82]

> You mean statically typed? Python is already strongly typed.

Err...yes. I forget that "strong" and "static" are not the same and that "strong" and "duck" are not mutually exclusive.

[robertlagrant]

Mypy gets you a lot of the way there.

[crowdyriver]

My feelings exactly. I love go because of how productive and resilient can be. In months programming in it I've barely had any null pointer exceptions. If it compiles, and passes the linters, it mostly works aswell.

[Xeoncross]

Yeah, null pointers and the compiler writing more code for you (overlaps with generics) are pretty high on my wish list.

I'm bringing someone up in Go and they forget to initialize some map or struct: `&Foo{data:map[int]int{}}` and crash the app.

[hnov]

Go is incredibly productive. Its primitive type system keeps me from bikeshedding, the standard library mostly makes sense, builds are fast, and yes, the builtin asynchronous IO means that I can write a C10K server without even trying. No JVM, no choosing between libuv and libevent, literally just take the simplicity of the fork-per-request model and adapt it to modernity.

[umvi]

Procedural programming has always been great and continues to be great for most use cases. There's a time and a place for OOP, and there is a case to be made for functional programming, but it's hard to beat the simplicity of procedural programming. Go is an excellent procedural language that has lots of static guarantees and a super fast compile times (fast at least compared to C++).

[kaba0]

I really would not call it “lots of static guarantees”.. it has some static guarantees at most. It is pretty low in type safety, compared to even C++ and the like, let alone Rust, Haskell, etc.

[josephcsible]

Indeed. My overall complaint about Go is that despite being a very new programming language, it hasn't incorporated a lot of lessons learned long ago (e.g., the billion dollar mistake). One of my favorite articles about Go is http://cowlark.com/2009-11-15-go/

[hnov]

As a PL Golang is very unremarkable and it does have a lot of special casing and a general lack of "orthogonality," in fact it reminds me of PHP in some ways.

However, that's completely missing the point: Golang brought CSP into the mainstream when most were still using CPS to scale beyond OS threads. The kind of people who rewrite services to get performance improvements and then write blog posts about it aren't gonna learn your complicated language (just like they're not gonna spend their time messing with gevent and profiling to scale their python): they're makers not PL researchers. Google rightly noticed that there's a huge gap between existing mainstream offerings on the ease of use-performance spectrum and filled it with a DSL for programming network services. It doesn't need to be fancy, it needs to allow someone with CS201 knowledge to set-up the codebase so that people with CS101 knowledge can write sequential code that talks to the network without callbacks, yield/async/await or any of that incidental cruft.

[coin]

Could not agree more. Using Go is like stepping in a time machine and going back to 2005.

[KronisLV]

What's wrong with Angular? It being largely "batteries included" seemed pretty nice and I really liked the fact that TypeScript was a first class citizen - React and Vue both feel like it's been kind of tacked on, especially when a lot of additional libraries out there don't really have proper bindings.

That said, personally I also think that React kind of went downhill for a bit due to the hooks (after seeing a few projects become really nightmarish to debug due to render loops without clear causes for them, after people sprinkled one too many hooks in there).

Oh, and the Vue 2 to 3 migration is also a bit problematic because still many UI component libraries haven't been migrated over - currently actually using PrimeVue on a project because BootstrapVue still doesn't have proper support https://github.com/bootstrap-vue/bootstrap-vue/issues/5196

[gosukiwi]

No matter how hard I try, I just can't like React. I prefer Angular, Vue, even Ember. React feels like a downgrade to me.

[akira2501]

I have yet to find a language where cross compiling is as easy and simple as it is with Go. It's a first class feature of the language and for my use case, it makes it an obvious choice.

Programming is about managing tradeoffs to solve real problems, not building a perfect ideological environment to write code in.

[pkulak]

I can't think of anything off the top of my head that doesn't require a runtime, but does exclusively use green threads.

[BipolarCapybara]

What do you feel is a good alternative to Go?

[bloblaw]

Depends on your requirements. If you want statically compiled (AOT compiled), then I think Nim, Zig, or even Rust are good alternatives.

If you like the high-performance backend, then Java, Kotlin, Scala, or C# are great choices.

[sk1pper]

Do you mean for production? Zig isn't production-ready. Nim is extremely niche. I'm kind of puzzled why I see these thrown around so much on HN. Sure, they're fine for a side-project, but they're pretty out there for anything mission critical.

[uhtred]

Go should have died?! didn't Go come out like yesterday? This is why I am hesitant to invest time in new hot thing languages. I swear in 20 years everything important will still be written in C, PHP, Perl, C#, Java, Python (how could I forget JavaScript).

[bloblaw]

Go was released in 2009, which is 13 years ago. Many companies have built significant portions of their stacks on top of Go....Twitch, Google, Uber, Lyft, Amazon, etc.

It's widely used in industry and isn't going anywhere.

[oceanplexian]

I worked at one of those places and helped rewrite components into Go ;) Sure, there were performance benefits but in my experience there was never a real business problem that Go solved that Python couldn’t.

All the people freaking out about performance didn’t realize that even in the Python days, half of our datacenters pretty much sat idle or severely underutilized. Computing is dirt cheap as long as you’re not renting a 15-year-old CPU from a Cloud Provider for 100x markup. The other thing is that engineers would frequently build things that were just wasteful or unnecessary, and sure, Go sped things up, but you could have changed the design instead of the language.

[bloblaw]

So did I :) One of those places replaced an interpreted language used for a process intensive core function with Go and saw a massive performance increase...resulting in clear cost savings.

But Go isn't a silver bullet. It's another tool in the toolbox and sometimes it makes sense to reach for Python, or Kotlin, or Swift, etc. But choosing Python when you should've chosen Rust / Go / D is a tough design decision to quickly come back from.

[feffe]

Go 1.0 was released in 2012, it spent 3 years in alpha/beta phase.

https://go.dev/blog/go1

[KronisLV]

> Go should have died?! didn't Go come out like yesterday? This is why I am hesitant to invest time in new hot thing languages.

Actually it came out about 10 years ago, in one way or another: https://go.dev/doc/devel/release So it largely depends on what timescales you're comfortable with - some people switch stacks or learn new tech every 3-5 years, for others this cycle is slower or faster, also depending on the stuff you're working with.

I'd say that web dev moves quickly, embedded moves more slowly, the rest is somewhere in the middle for the most part, maybe AI/ML and certain DevOps aspects rival web dev speeds of innovation/churn.

> I swear in 20 years everything important will still be written in C, PHP, Perl, C#, Java, Python (how could I forget JavaScript).

Perhaps, i think languages like Rust will be pretty widespread, both in the Linux kernel, as well as many tools and whatnot, albeit in a different and perhaps more conservative fashion than currently (the "rewrite everything in Rust" craze). In contrast, most of the modern web based SaaS solutions will be dead, most certainly the majority of Kubernetes tooling out there.

Go might just be boring and useful enough to stick around and join the dreadful bunch of languages used in maintaining legacy code. It's funny, though, because while the languages themselves are more usable than they were 10 years ago, people's sentiments (including mine) are largely influenced by how many bad codebases they have to maintain: https://earthly.dev/blog/brown-green-language/

On an unrelated note, it would be pretty cool to have extremely slowly moving and stable languages, projects and tooling out there. To see maybe 3 or 4 releases in my entire lifetime and to have the next generation take over the burden. Then again, seeing how COBOL and FORTRAN are now, perhaps that sense of grandeur isn't worth the effort and old projects should just die.

[uhtred]

> On an unrelated note, it would be pretty cool to have extremely slowly moving and stable languages, projects and tooling out there. To see maybe 3 or 4 releases in my entire lifetime and to have the next generation take over the burden. Then again, seeing how COBOL and FORTRAN are now, perhaps that sense of grandeur isn't worth the effort and old projects should just die.

Isn't that Perl?

[KronisLV]

Kind of, though the whole Raku thing made everything a tad wonky.

Some of the nicer Perl software that I use currently is BackupPPC, which has been pretty solid despite the slightly subpar UI: https://github.com/backuppc/backuppc

And another interesting piece that I can think of was RemoteBox, which was pretty niche but still worked nicely: https://remotebox.knobgoblin.org.uk/?page=about

From the more popular packages, one should also mention exiftool, which was written in Perl: https://github.com/exiftool/exiftool

Probably also a lot of other pieces of software, though it doesn't seem like there's much of a large/active community around Perl, for example, have a look at: https://github.com/trending/perl?since=monthly and then compare it to something like: https://github.com/trending/go?since=monthly

In regards to other contenders, I think FreePascal/Lazarus should also be mentioned, since they're pretty stable, capable and perhaps some of the better ways to write desktop software!

[uhtred]

I had no idea exiftool was writen in Perl!

[KronisLV]

Here's a few other tools that are written in Perl, sorted by GitHub popularity: https://github.com/EvanLi/Github-Ranking/blob/master/Top100/...

Actually, that repo has lists like this for most languages: https://github.com/EvanLi/Github-Ranking

[gnulinux]

> I swear in 20 years everything important will still be written in C, PHP, Perl, C#, Java, Python (how could I forget JavaScript).

Hmm all the languages you listed have certain niches that I think will likely remain alive in the next 20 years, except I don't think Perl deserves this spot. I think anything Perl is a great fit at, Python will also be a great fit and (subjectively) python code ends up being strictly more readable than perl.

I would guess PHP also has a similar relationship to Python but the effect, I believe, is a lot milder as PHP shops seem to be more decisive about sticking with PHP. All evidence anecdotal of course.

[dgb23]

There is plenty of important stuff written in this generation's languages like Go, Clojure, Rust, Typescript and so on. You might be relying on some of them.

[joebob42]

I think it should have died when it came out. Javas way older but I'd rather use that.

[geodel]

Well those alternatives can be popular if more people find them better. Isn't it?

[simonw]

What's better than procedural programming?

[tnzk]

I assume he implied functinal programming.