Hacker News Reader

Comment by throwaway894345 | Hacker News Reader

Moreover, not all domains require you to catch every error. In many applications, it's just fine to ship a few bugs and it's much better to ship a few bugs here and there rather than slow down dramatically to appease a pedantic type checker. This is especially true when bugs can be found and fixed in a matter of minutes or hours and when the bugs are superficial. And I also contend that the more pedantic the type checker, the more likely that the additional bugs that it finds are of diminishing importance--they are less and less likely to be a downtime issue, they are increasingly likely to be in very rarely hit paths.

I like Rust a lot and I hope to get to use it more, but "added type safety at the expense of iteration velocity" is not a good tradeoff for my domain and I suspect many others (although its iteration velocity is improving monotonically!).

View on HN

Strangely, I found Go to be one of the least productive languages I've ever used, 2nd only to Java. It just makes the programmer do so much of the work for common tasks, and it's incredibly repetitive and while it generally generates a fast program, the quality/fault rate isn't any better than any other iterative language.

curious what other languages and domains you are working in. In my experience, Go has been a boon to productivity. I do networked services mostly. Projects that are maintained for years with lots of tweaks. Rewrites, greenfield. Lots of focus on operability, maintainability, and high availability. My work started in php, became more serious under perl (anyevent), and python (twisted), and toss in a smattering of other things here and there (some C, C++, ruby, javascript, lua). The main work horses were perl and python though. I've been using Go now since 1.2 (around 2013/2014). Every time I go back to these other languages in the same domain it is like taking a giant leap backwards.

Go is most often preferable to any of the languages you mentioned, no doubt about it. It's just that Rust is generally held to an even higher standard.

I think that is your preference and not a generally accepted fact.

So you've only used untyped languages, C++? No wonder you think Go is productive...

Not that Java is even good, but that beats go. The history of Go is the history of Java, repeated as farce. It's even some of the same academic lineage come to bail things out with the type system for generics!

My only java experience was in college nearly two decades ago, so I def don’t have a valid opinion on Go vs Java. I’ve worked with dozens of former Java devs that were now working in Go. The majority felt it was a breath of fresh air and did not want to return to Java in the future. Granted that was not all of them. The plural of anecdote is not data, so I’d be interested in a larger poll to know how folks feel who have experienced both.

More anecdata for you. I'm a professional Java dev, and I spend my off-hours writing tools for work in Go. It feels so much nicer to use.

Go is quite a lot different than Java. Go has held to its promise of simplicity and consistency remarkably well. No need to learn groovy to configure Gradle to build your application; just use ‘go build’. No need to learn javadoc or configure your CI pipeline to build and deploy documentation packages. No need to figure out how to statically link your code, it’s the default. No need to figure out how to compile your code ahead of time, it’s the default. No need to figure out how to tune your GC for low latency and low memory usage, it’s the default. Plus Go has value types; Java is maybe going to get them, but they’ll never be idiomatic. On top of all of this are the misfeatures and antipatterns that are pervasive in Java but which don’t exist in ago—things like inheritance, objects, and the “you just want a banana, but the banana has a reference to the gorilla holding it and the whole damn jungle” design pattern. I know, I know “that’s just bad design and you can have that in any language!”—true in theory, but Go doesn’t have this in practice. Nor gratuitous inheritance hierarchies or anything else. And while Java folks don’t have to use those patterns/features if they don’t want to, the must still interface with them because their coworkers probably write code like that and if not your coworkers’ code, then the dependency library and even the standard library.

Go is a dramatically nicer programming experience than Java. There are some benefits in Java however: sometimes JIT is nice and Go has no analog to Spring. But these are very circumstantial benefits and not good tradeoffs in the general case.

Most of the things you listed are not a problem in C#. And you don't have to be tied deeply to Microsoft to use it these days — I develop stuff full-time on top of .NET Core under Linux (and host it on Linux).

>No need to learn groovy to configure Gradle to build your application

I rarely have to configure msbuild, mostly to do some relatively advanced stuff like auto-installing npm dependencies for an SPA.

>No need to learn javadoc

Just use

    /** */

>No need to figure out how to statically link your code

You can build pseudo-statically linked executables by adding one line to .csproj (which builds a single executable file, but it's really a self-extracting archive), and real static linking is in the works. I have no need for it personally though.

>how to compile your code ahead of time

Same thing — AOT compilation is one configuration line away. You don't need it very much though, as the CLR is very performant these days and beats Go in most benchmarks:

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

>No need to figure out how to tune your GC for low latency and low memory usage

I would argue CLR's GC is ahead of Go's GC at least for latency. Memory usage, not so much, but damn, look at the execution times above. It depends on your priorities I guess.

>Plus Go has value types

C# has had them since before Go was a thing. Unlike Java, it also has real structs, which you can configure the alignment of, and map a raw chunk of memory to them (which you received from a COM port, for example). This came in handy more often than I care to remember.

As for your forest/banana analogy, I'd argue it's never been as bad in .NET world as it's been in Java world. I have personally never found anything similar to the insane class hierarchies they have in Spring.

> I have personally never found anything similar to the insane class hierarchies they have in Spring.

Try to do something with stuff like XAML Workflows, Bizztalk, WCF, SharePoint, or MVVM. :)

I think people get causation and correlation a bit confused here ... Java code is like it is not just because of it's nature as a language but because a gigantic number of huge corporations use it. And they have bajillions of dollars to pay developers to figure out a gradle build, or navigate a typ e hierachy etc. That's why equivalents of Spring etc., have appeared for .Net etc.

Btw, did you know the default Gradle configuration for compiling a Java app is literally 1 line?

    apply plugin: 'java'

I'm not that much a fan of Gradle (too much magic), but it's one of the least verbose and easiest to figure out parts of working with java.

Having spent way too much years in java I’d have to say that the build systems are really the weakest part of java. We have „maven“ (wtf) and „gradle“ (powerful but yikes) oh and “ant” (dead now)

Wrt gradle: While it’s super easy to get started, any slight modification is a major pain.

Note to other tooling guys for other languages:

- I don’t want to write in a new language just for my build system

- I don’t want freaking xml hell like maven

And don’t get me even started with Maven as a package manager. But to be honest... it’s at least better than NPM :-)

So I assume you don't like many of the popular build tools at all - Make, bazel, etc all define a custom DSL effectively. At least Groovy or Kotlin are actual languages you can learn and use for other things, not something that has no alternative purpose so is completely wasted. And their syntax is very close to Java so you have a head start on learning it.

In general the concept of a "cross platform" build tool and "not having to learn another language" are at odds with each other, for anybody who isn't lucky enough to already work in the language the build tool is written in.

Interesting, I'd say the ones to challenge in the backend space are Java, C#, Scala, F#, OCaml, Erlang, Kotlin, Clojure, Elixir and Haskell.

Those are the stapled languages in the backend space which Go competes in. You could give some of them a try.

I’ve used Python and Go (and JS to a lesser extent) extensively and Go has been consistently faster to iterate with, much better performance, much less headache with build/deploy/dependency issues, much better for teamwork (less pedantry in code review, docs don’t get out of date as easily, types keep people from doing as much pointless magic, etc). Note that the performance point is hard to overstate since with Python it means you run into performance issues far sooner and your options for optimizing are in a much different complexity ballpark which completely eats any iteration velocity gains that you might have had from Python in the first place (in case it was ever a question).

I mean if you're comparing it against a language with an even weaker type system...

Python is not a great productivity language. I find Python less productive than enterprise Java. The tooling in Python is still in the dark ages.

Yeah, although Python was my first language and I used to love it, now I realize it's "the worst of all worlds". It's superficially easy, but it both runs slower than "real" languages and programmer productivity scales much, much worse than them. Of course "real" languages are also a scale and I think they too become worse further the scale. Go, C# and Java are probably around the sweet spot, although I myself prefer stricter languages like OCaml. Definitely something like Haskell is "too much" for my taste, probably will have to try Rust soon to figure out where it stands in my scale.

Were you using an IDE? For me, yeah go has a lot of boilerplate, but with autocomplete, because the type system is so simple, the autocomplete is super savvy and code just flies onto the screen. Still a fair amount of plumbing, but it's easy plumbing.

I can easily see it being tedious if you have to type every character.

The trouble with boilerplate is that we have tools that write it for you but almost nothing that reads it for you, much less reviews it for manual edits. Anything that can be generated from a high level description and then thrown away, should be.

The boilerplate still has to be read and so the boilerplate still gets in the way of understanding "What is this supposed to do"

The IDE side is in my experience the worse part for Go (unless you pay for JetBrains GoLand).

Code navigation is extremely basic (can only find references in the same package!), often breaks, and can't handle stuff like finding all interfaces that a type implements, or finding all implementations of an interface.

Which Go IDE's have you tried?

I tried GoLand, which was great.

Then, I tried VSCode with the Go plugin, both the default version and the go pls based one; and Emacs with the LSP package and go pls.

It used to be really good across the board, but I think modules broke a lot of things and they never fully repaired? I'm not sure, but I get the feeling that the quality of these editor integrations dropped a year or two ago.

As far as I can tell, they never had support for finding usages across packages, never had support for finding implementations of an interface, never had support for finding what interfaces a certain type matches/implements. These are basic features in any IDE for a language that has packages and interfaces.

Really good IDE support would include refactoring (more than renaming a local variable/struct field, e.g. Extract Function, extract parameter), advanced navigation/analysis (analyze data flow to/from variable, find call stack etc).

Go is somewhat decent in the tooling area, and you can get your job done with it, but it really doesn't have anything I would call good support in any area of tooling except the compiler (not code analysis, not debugging, not monitoring, not profiling, not package management).

> As far as I can tell, they never had support for finding usages across packages, never had support for finding implementations of an interface, never had support for finding what interfaces a certain type matches/implements. These are basic features in any IDE for a language that has packages and interfaces.

I suppose it depends on what you're used to. I've never found myself wanting to do these things, but I'm also strictly from a Python and C++ background so my standards are admittedly lower than Java and C# people. Hopefully gopls solves for these problems.

In C++, you have never tried to go to the definition vs declaration of a function? Or find calls to your class through a superclass?

I feel like Rust and Go are fundamentally different use cases and I wish people would stop the language debate.

Rust: For code that isn't meant to be iterated upon, that must be safe/correct while also being performant.

Go: For code that is meant to be iterated upon frequently, that must be performant and easy to maintain.

I would like my tools to be written in Rust, and I would like to interface with them in Go.

What's wrong with iterating on Rust? Comprehensive type checking makes refactorings a lot easier than something like Go. And you can iterate starting from a simple, working solution that relies on marginally more expensive features, such as .clone(), Rc<…>, Cell<…> or RefCell<…>, Any for dynamic data etc. etc.

Refactoring is safer with Rust, but in generaly Go is not so unsafe that refactoring costs more than it saves on the frontend. You can write a lot of Go (and contrary to the memes in this thread, you can still leverage the type system to great effect wrt safety) in the time it takes to get a little Rust to compile; however, Rust is getting better all the time.

I think you are missing the point of type systems. Our current economy doesn't value correctness at all. Code is rushed out, and usually live longer than it was designed too. This mimicks the the largest infrastructure debt of America (and to a lesser extent, the western world as a whole).

But the same shoddy system is also constantly changing the requirements, precisely because nothing is built for posterity and there's tons of make-work churn. Good type systems make code far easier to refactor, and refactoring (as opposed to slapped-on new code) is the only way to handle shifting requirements without being crushed under ones own weight.

I'm not missing anything. I'm well aware of the value of type systems, as I am our current cultural decision to value speed over correctness.

I'm not confident that average level developers are able to ship features in Rust as quickly as they would in Go, which is the root of my point. Those building tools, which generally do not have the same success metrics with respect to speed and correctness, should use the language with a focus on safety and correctness. Those whose positions do not lend themselves to safety and correctness should not use that tool.

> I'm not confident that average level developers are able to ship features in Rust as quickly as they would in Go

Even if this was a genuine concern, they should still use Rust. Because it will be far easier to refactor the code that they ship into something that is safe and correct, compared to rewriting a Go codebase.

We can agree to disagree. The whole point of my post is that I do not agree with your statement.

Which code is not meant to be correct?

This is a silly strawman. All code is meant to be correct, but often times close enough to correct is good enough (as is literally the whole point of my post). Most businesses operate on code that is close enough to correct for their individual risk tolerance, and increasing that correctness would reduce speed/throughput and increase cost.

I think that's totally backwards. A good type system _improves_ iteration speed, it doesn't slow you down. When I refactor a Rust program, I have very high confidence that if it compiles, I haven't accidentally introduced a bug.

I don't write much Go code, but my company does. I have seen so many incidents and bugs whose root cause was: someone changed a library, that broke the semantics that users were relying on, but everything still compiled fine, so nobody noticed the subtly wrong behavior for a long time. An incredible amount of money has been lost like this.

Go simply does not give you the tools to prevent these issues in the type system, you have to rely on really thorough unit tests (which inevitably don't get written in the spirit of "moving fast".)

And you're welcome to think that. YMMV.

Maybe you need to think why your company is not writing in Rust. Is there some quality of Rust that individual users prefer more than companies in general.

Whenever I hear about Rust in companies same dozen or so companies get mentioned every time.

The specifics of what languages my company writes are mostly historical, and I would say that Rust was not ideal for writing high-throughput network services until this year with the release of async/await.

But in general, companies adopt Go for the same reason they adopt MongoDB [0]: it's really easy to get started with, and get something that "works." The pain comes months or years down the road, and by then you're stuck with it.

[0] A company I previously worked for starting using MongoDB as a small startup, starting finding the limitations about 6 months later, but ending up spending an incredible amount of engineering time over 5 years getting rid of it.

You're a person that really does not like the Go programming language, and that's okay, but to try and paint a perfectly fine tool as bad because someone used it incorrectly, and then compare it to a pretty objectively bad product is silly.

We get it. You don't like Go. Don't use it. That's a perfectly fine option. Plenty of very successful companies, open source projects and services all work with Go (and literally every language) without issue. You not liking something does not make it bad.

I'm not sure I understand how this can happen in Go, it's a strongly type language, if for example you change a method / function signature, the code won't compile.

Go is strongly typed (you can't pass an int to a function expecting a string), but its type system is not very powerful, and it cannot express many of the types people need in practice. Back to the discussion at hand (generics), Go programmers usually work around this lack by using interface{} types, which can point to anything and are essentially dynamic typing.

As another example, Go makes it impossible to create a Maybe/Option type which leads to a bunch of issues around returning failing or empty values from functions. In one particularly costly example, there was a function in a library that was getting some price information from a file. Originally this returned nil when the price information could not be loaded, but a refactoring caused it instead to return 0 which the client happily used. This was not caught for _weeks_.

What you're describing comes down to "Bad programmers do bad things", which literally no language can or will solve. If your code has lots of interface{} in it, you're not really using the language as intended. Pretty much every Go styleguide/linter/whatever will throw up at interface{} usage.

You can write unsafe code in Rust. Does that mean that Rust is bad too?

100% agree. Same with :any in typescript. When it comes to bugs... I tend to think that a good configured linter is more important than the degree of the type system. It’s nice to have a strong type system but people forget that a lot of programmers are bad and a good type system won’t change that fact.

>Originally this returned nil when the price information could not be loaded, but a refactoring caused it instead to return 0 which the client happily used.

Hard to feel sympathetic, as this practice violates the Go convention of adding an additional return value to the function to indicate failure, either of type error or bool, as appropriate.

>Go makes it impossible to create a Maybe/Option type

It's very much possible: https://play.golang.org/p/MCxGcZ-rJRU.

Of course, it's not generic, but I have a feeling that might change soon :)

The Option type there isn't type safe. E.g. https://play.golang.org/p/CiQLf4yWhCO doesn't throw a type error for the Get function even though I've omitted the null check.

Sorry, but that's just ridiculous. Obviously the language can't prevent you from defining your Option type incorrectly. The point is that it's not possible to misuse it.

Okay let me rephrase. The type checker doesn't make sure you've checked the value of ok e.g. you can do this: https://play.golang.org/p/x18Rh2iwd2E

Go constantly requires boiler-plate checks for errors, null values etc. without the type checker helping ensure you've checked for an error or null value.

I've never seen those claims about heavy usage of empty interface in the real world, and in the few case we have it, there is type assertion that is safe and well known.

As for the second example I don't think it's a language issue but more a programmer one, how Rust would have saved you in that case, anyone could have returned 0 for the price instead of a proper type. Using Rust doesn't magically turn programmer into good ones. You still have to know how to properly design your code and best use the language and its features.

I'm often reading code in various language and I'm baffled at what a giant lib.rs looks like from someone that never really used Rust.

This is what strikes me: the situation is a programmer being lazy.

They wanted to do: something(getPrice()), but if getPrice can actually fail the then either something needs to accept an error, or they need to handle the error.

No type system imagined can save you from someone who's decided returning 0 is the correct way indicate an error in this scenario.

> how Rust would have saved you in that case, anyone could have returned 0 for the price instead of a proper type

You've missed the problem that was posed. It wasn't returning 0 to indicate an error, it was changing the error value from nil to 0. In rust that would've been a type change (from Option<int> to int). Because the context here was about how stronger type systems (like rust's) allow you to be more specific about your types, and thus many code changes that would not involve the type changing in other more weakly-type languages do cause a type change in rust.

Except that in Go, you always return the error alongside the value, like this:

    return 0, errors.New("unable to get price")

It's less elegant than Options but still, very common practice. GP's company clearly hasn't bought into Go if they're using a library that doesn't follow well-known conventions.

Sounds like your company is just using a unidiomatic library. It's poor practice to return a zero value as an error instead of, well, returning the error. As someone else said, it's standard practice in the vast majority of all go code to return a value, error tuple and check at each call site. In fact, it's so common that it's the number 2 complaint about go code after not having generics (error handling too verbose).

Go has its problems, and it isn't a perfect language, but I have never felt unproductive using it. In fact, my company uses it for all backend services. It has a great stdlib and first class tooling. Most of the discussion in this thread seems to be coming from people who barely use it or have only dabbled with go.

As a tangent, it's really tiring to see HN engage ad nauseum in these pointless language debates. Every language has its place; use it when it's appropriate.

Wait what?! Most of the major go libs (std and not) have been stable for years. Rust is merging random syntaxes and random packages get upgraded to std lib all the time.

The package ecosystem was so stable that go didn’t ship with a package manager (not saying it’s good but definitely a sign of relative stability).

Besides nil pointers (typesystem could do better here) and bad logic (can’t do better but language simplicity reduces this), what you’re saying is definitely not the experience of the majority. People constantly talk about being able to go to a golang program from 8 years ago and run it with no problems. Rust changes every few weeks.

Not to mention go compiles at the speed of light, so CI pipes are usually just rebuild and rerun the entire suite on every commit, so idk how such bugs would lurk unless the tests were lackluster. Which happens, I totally understand.

I don’t know what Rust you’ve been using, but they’ve been explicitly having all changes be backwards compatible since 2016 - when they hit 1.0 - with a few small changes in 2018.

> People constantly talk about being able to go to a golang program from 8 years ago and run it with no problems. Rust changes every few weeks.

You stated that "Rust is merging random syntaxes and random packages get upgraded to std lib all the time" as though it were incompatible with "being able to go to a program from 8 years ago and run it with no problems". But there's no incompatibility here. Rust adds new features at a faster rate than Go does, but it also maintains backwards compatibility ("stability without stagnation").

Sure, I conflated 'still compiles' with 'still the right pattern'. Its sorta like Javascript, ECMAscript has been backwards compatible but the ecosystem is a consistently moving target that users have to adopt their code to or feel left behind. E.g crossbeam and parkinglot. Also the bunch of nightly features that disappear but many use.

Sure the mainline stays clean but thats not what matters in practice.

> The package ecosystem was so stable that go didn’t ship with a package manager (not saying it’s good but definitely a sign of relative stability).

Which also explains why you can git clone a Go library/tool and have it not building because some dependencies introduced some breaking changes in the master branch. That happened the last 3 times I wanted to fix something in a Go project.

> Rust is merging random syntaxes and random packages get upgraded to std lib all the time.

I really don't know where this is coming from. The only package that was included into std like this is replacing the hashmap with hashbrown, and this didn't even change the public api of the standard library at all, besides improving performance of the hashmap.

> don't write much Go code, but my company does. I have seen so many incidents and bugs whose root cause was: someone changed a library, that broke the semantics that users were relying on, but everything still compiled fine, so nobody noticed the subtly wrong behavior for a long time. An incredible amount of money has been lost like this.

In all likelihood, that "incredible amount" is a small fraction of the money your company saved in iteration velocity by not using Rust in the first place. This might not be true depending on your domain--if you're writing space shuttle software, bugs can be really expensive. If you're writing ordinary web app backend code, you're probably much better off with Go than Rust.

I hope you are kidding mate. I've been solo maintaining 50k lines of Rust iterating over a few months and it's a breeze.

This. Let me give an example. When booting a system you can get errors as concurrently booted subsystems (we're talking tens of thousands of them potentially) don't necessarily finish in the order you want, inducing effectively dependency error race conditions. You can either write a totally checked system that is brittle to these race conditions, and many nightmares worth of debugging, testing, and giving up, or you can write floopy logic that accepts the problem, fails, and restarts, and moreover very likely gives you lowered downtime overall. What do you do?

(1) This is why you can even ship code written in JS or Python. (2) This is why Typescript and mypy exist.

I agree, although my experience with Mypy has been miserable. I’m not sure the costs are less than the gains. Also there are other tradeoffs, like performance and artifact size (numpy and pandas alone are 100mb).

Only because liability still isn't a sure thing with proper fines for those that ship faulty products.

Nonsense. No one is served by fining companies for superficial issues. Customers are nearly always better off getting features faster at the expense of superficial issues. Any other take ignores economic reality (I say this with much chagrin, as I would rather move slower and release finely crafted features).

1. There's lots of software that doesn't "ship" - it's used internally.

2. There's lots of software that "ships" as a web service, often used by people who are not paying for the web service.

If you're talking about defects for an actual product that render it unsafe or unsuitable for the intended purpose, then I can see your point (though even there I'm not sure that I completely agree). But there's much more software than that.

Note that the whole point of my post is that there are different risk profiles for different kinds of software (or even within one kind of software--e.g., the data security subsystems in saas apps have a different profile than the UI widget library). If the parent's point is "some bugs are serious!" then that's not a rebuttal to my post--don't use weak type systems for those projects or those parts of the project. You don't rebut "You don't have to write all software like it is space shuttle software" with "some software is space shuttle software!".

Reply on news.ycombinator.com