Hacker News Reader

Comment by kyllo | Hacker News Reader

Rust addresses all of these problems. It's memory safe through compile-time reference counting and borrow checking (not garbage collected), and it has exceptions and generics. It also has a more powerful type system with type inference.

Having tried out both Go and Rust I don't see any reason to prefer Go, at least once Rust has a 1.0 release, which is supposed to happen the next 2-3 months.

Both languages were designed to replace C++, but only Rust has the features to actually succeed at that, IMHO.

View on HN

> Both languages were designed to replace C++

AFAIU Go was designed to replace C++/Java/Python as _the_ language to use at Google, not as languages themselves. Which is why there is so much focus on simplicity, tooling, productivity (like compile speed and easy deployment).

Criticizing Go for not having enough features is missing the whole point: Go was created in part because C++ has too many features.

To my understanding, it was built for systems creators, not for programmers; it was built as a goto language who have to write program that is both efficient and simple to write and maintain. OTOH, I do see Rust as a C++ replacement, which makes it complementary to Go's focus (sadly it seems that D is lost in the middle, though...)

This is the feeling I get. I don't write much Go (I'm just now getting into it) but all of the major features I hear about seem to be directed at creating code and projects that are tractable at "Google Scale". Everything has been designed for massive teams, from fast compile times, or having a standard formatting scheme, to choosing syntactically insignificant whitespace (specifically the podcast mentioned finding instances where python snippets were embedded in another language somewhere which would shoot the whitespace to crap).

The language being dead simple also seems to be to that end, with things like removing ternary operators or not having the pre-increment being smaller sacrifices, and no generics being a larger one.

All in all it seems like the underlying philosophy of Go is focused on Google specific context and engineering goals, and it's a happy accident when they work out well for programmers in the general case, whereas something like C++ or Rust isn't catering to those specific parameters (though they're obviously capable of working in that role, perhaps just not in the "ideal" way that the Go language maintainers would prefer).

> Everything has been designed for massive teams

Weird. Because I see the opposite.

Go would be fantastic for microservices or targeted applications. But features like exceptions are critical when you have 100+ developers spread across the world working on the one codebase and you want to ensure consistent error handling behaviour across the application.

Well, Google's C++ Style Guide[1] disallows exceptions, so it makes sense that they wouldn't put exceptions in Go either.

Come to think of it, Go does seem pretty similar to the subset of C++ that Google allows their developers to use. If you think of it that way, it starts to make sense to think of Go as an intended replacement for C++ at Google.

[1]http://google-styleguide.googlecode.com/svn/trunk/cppguide.h...

The Style Guide also says that the decision is mostly due to large amounts of existing Google code that is not exception-safe.

> Things would probably be different if we had to do it all over again from scratch.

I think at this point Go is more of a replacement for Java than C++.

Perhaps, but the problem is, with no generics or exceptions, it might just be too low-level and not expressive enough to really be a suitable Java replacement.

Yeah i just see Go as an alternative for web technologies, where Rust is much more system level focused. I could be wrong, but that seems to be the direction I see with Rust.

> Yeah i just see Go as an alternative for web technologies

I don't see any web technology Go could replace. Not even dynamically typed langauges.

I'm starting to use Go as an arguably better Node. Very fast, easy (pseudo)concurrency, relatively nice HTTP capabilities in the stdlib. It wouldn't be my first choice for building a full library, but it works well as an internal component in a service oriented architecture or a background worker for a queuing system.

Go is very uncontroversially a better Node. It also predates Node.

Depends on what you mean by "better".

Better language? Not really, if you want types TypeScript is a much better option. With node+typescript+react you can get end-to-end typechecked code with no FFI involved - thats really, really cool.

Better concurrency? Oh yeah, definitely. Better core libraries? Yes, by far.

Better package ecosystem and management? Definitely not.

    > Better language? Not really,

There is no conceivable universe in which the expression "JavaScript is a better language than Go" evaluates to true.

...except for in JavaScript itself:

    ~$ node
    > "JavaScript is a better language than Go" ? true : false
    true
    > "JavaScript" > "Go"
    true

Unless/until Go gets generics, I stand by my statement. A horrible type system that severely limits expressiveness is worse than no type system. Even TypeScript's type system is miles ahead compared to the one in Go.

I doubt it. The node ecosystem is second to none.

All the things node is designed to do and it does it at least as fast as Go.

We can argue that the Go concurrency model is better.I think nodejs's is good enough,easier to understand and to deploy. If your goal is to write lightweight webservers that do a specific task,nothing beats node in my opinion.

> easier to ... deploy

Ehm, really? Tree of javascript, possibly with some compiled libraries easier to deploy than a static binary?

I'm not saying node is hard to deploy, but I think maybe I'm misunderstanding what you mean here?

Prime candidate is any highly scalable TCP socket server. Currently, there's no better language for it

Erlang? That switch that is routing your phone calls?

Almost certainly not TCP socket based nor built on commodity hardware.

It hasn't rooted anybody's phone calls for a long time. Even Ericsson doesn't use Erlang based phone routing anymore...

Erlang is a better for it. WhatsApp runs their infrastructure on it. Can easily do millions of concurrent TCP connections on a single machine.

We could not have handled the load at Microcorruption, emulating CPU state for thousands of concurrent users, using Ruby --- which remains the front-end language for the site.

We could easily have done so in Java, but we'd be in Java's concurrency model, which is much more difficult to reason about.

So, you did it in Go instead of Java, right?

I think this is exactly what people mean when they say Go is more of a replacement for Java than it is a replacement for C++: In the sense that when Ruby and Python become too slow, people normally reach for Java, but now they have Go as an alternative option, with a better concurrency model than Java's.

We never even considered writing it in Java. We wanted something with the performance characteristics of C, which is what we would have used had we not had Golang.

Golang does not have the "performance xteristics of C"!

I must just be crazy.

There are alternatives to Java's concurrency model whilst still staying on the JVM:

http://docs.paralleluniverse.co/quasar/

Given how the JVM ecosystem looks like and what is planned for Java 9+ in terms of mechanical sympathy, I have my doubts.

People love to say this, but the observation falls apart quickly under scrutiny. People working in Java are doing so to retain access to the JVM and to the zillion libraries built on it. The JVM with its ecosystem is a colossal asset for Java; one of the greatest in all of commercial software development. (I say this as someone who does not enjoy Java).

Meanwhile: Golang neatly fills in a sweet spot just "below" Python and Ruby, where finer-grained control of memory and more predictable performance characteristics are required, but bare-metal performance isn't. That sweet spot actually describes a huge fraction of all the use cases for C/C++ in Internet software.

So this is a meme I'd like to see die. It somehow manages to simultaneously get Golang, Java, and C++ wrong all at the same time. The only way to make it worse would be to work in some kind of Lisp comparison, based on Golang's parsimony with parenthesis.

Couldn't agree more.

Anyone who thinks Go will ever be a replacement for Java is frankly clueless about enterprise software development. Go has almost non-existant integration with enterprise systems e.g. SAP, Hadoop. It lacks operational management capabilities e.g. JMX. And seriously the range of libraries on the JVM covers pretty much everything e.g. banking/finance use cases.

And concerningly there is not a single reasonably sized Go project to get an understanding of how it works with 20, 50, 100 or 500+ developers working on the same codebase.

> there is not a single reasonably sized Go project

I'm not sure if I misunderstood your statement, but Go has Docker, CoreOS and numerous other projects which have more than 20 developers working on the same codebase.

Docker and CoreOS are tiny compared to many enterprise Java apps. And they don't have 20 full time, active developers all contributing at the same time (at least not from the commit log).

Take for example eBay or Amazon and the huge array of different use cases they support. Those are the typical sized Java applications we are talking about. Insurance, Banking, Finance etc. Legacy integration, payments, reporting, various web front ends. One codebase.

You are mistaken if you think Amazon is backed by "enterprise" Java apps from a single codebase.

I was under the impression that Amazon was primarily a collection of services written mostly in Perl. Socket, do you know?

What I've heard from a friend who's a SDE there is that because they have a Service-Oriented Architecture the individual teams can use just about whatever language they feel is best for the particular job. The other teams don't care because they're just making service calls. I'm sure that was mostly Perl in the 90s, but today it is mostly Java, because their HR strategy is basically to hoover up all the fresh CS grads, whose strongest language is almost always Java. And also because when Amazon started building their SOA, Java/XML/SOAP was all the rage.

For what it's worth, a pristine checkout of Eucalyptus[1], that has parts written in Java, appears to be around 430k loc of java (comments and white space included).

Also, OT, didn't realize Eucalyptus had worked so much towards friendly development, and was moving towards including RiakCS as a S3 work-a-like backend[2].

[1] https://github.com/eucalyptus/eucalyptus [2] https://github.com/eucalyptus/eucalyptus/wiki/Scalable-Walru...

[edit: yes, I realize you were probably talking about Amazon the shopping cart, not Amazon the IT infrastructure provider]

Docker is fairly large, cloc output:

   ----------------------------------------------------------
   Language             files     blank    comment       code
   ----------------------------------------------------------
   Go                     750     14601       9901     115877
   CSS                      8       107        194      10010
   HTML                    11       362         21       3594
   Bourne Shell            28       391        323       2044
   Bourne Again Shell      25       249        185       1475
   Javascript              12       111         48        756
   Python                   1        23         24        192
   C                        1        20         19        179
   YAML                     4        25         13        162
   XML                      1         6          2         60
   make                     2        27          5         60
   Perl                     1        11         37         29
   vim script               2         8          3         13
   ----------------------------------------------------------
   SUM:                   846     15941      10775     134451
   ----------------------------------------------------------

And I believe there are a number of projects internally within Google but they tend not to talk about internal product technologies (at least at how large they are).

No Docker is not fairly large. It's tiny. 1M - 10M LOC is the size of most of the codebases I've worked on.

Most people simply don't have an understanding of enterprise applications. The majority of the apps are single codebase, Servlet/Spring type monstrosities. They are 10+ years old and have had hundreds of contract developers who come in, add a few new features and then go onto the next contract.

And my point is that I am yet to see what Go would be like in these situations.

It seems a little unfair to ding Golang for not providing evidence of something Golang was designed to avoid. "Where's all the boilerplate? Where are all the 10 layers of XML mapping? What would an AbstractStrategyFactory even look like?"

Rest assured, if Go manages to become a success in the enterprise you will get them.

It happened to every language without exception.

But will it happen to one without exceptions, as well?? :)

Panic/Recover will be used as expections.

If "enterprise applications" mean over-architectured monstrosities filled with boilerplate code, a hundred levels of indirection and horrible XML configuration files then thank god Go doesn't encourage that.

I think when people claim that Go is a replacement for Java, what they really mean is "Go has similar performance characteristics as the JVM and also doesn't require manual memory management".

Anyone who has ever worked in enterprise software can tell you, Go is (currently) exceptionally poorly suited for that style of development. I don't think that is an accident though. I think there is at least the implication that enterprise software development models and architectures are flawed at the core. Go seems to be designed from the start to prevent you from developing that way.

I may be reading more into the Go culture than I should, and I certainly don't think that there is proof that enterprise software can't be successful, but Go clearly steers you into building small, self contained servers that do one thing well and can go without change for a long time.

That observation is based on history. COBOL used to reign where Java sits now. The nature of corporations is changing, for the last nearly 20 years Java has enabled corporates to capitalise on investments in new hardware at a greater pace than COBOL did.

Golang is the new Java, you are watching it being born. Its not ready for the corporate world, its not on any large organisations radar (apart from its creator for course). The point is that Golang solves the problems of the future, it offer parallel execution to normal programmers.

In the future banks and large companies are going to stop having data centres of their own, CPU's are going to have 32+ cores. Java does not solve those problems natively.

Java is great, its got 40+ years of life left in it, but don't say that Java is strong because of its ecosystem. Ecosystems change from decade to decade.

Why do you say Rust has exceptions? We have fail!(), which does roughly the same thing as Go's panic(). So much so that we decided to rename it to panic!().

You're right. I must have misunderstood something I read.

Cool :)

Ahh, I remember what it was. I saw a code snippet like this:

    let input = reader.read_line().ok().expect("Failed to read line");

And I thought "Cool, Rust has exceptions!"

I'm probably too used to thinking in Python. Or maybe I'm just dyslexic and I read "expect()" as "except()".

Either way, your comment prompted me to dig into it further and find out how Rust actually handles errors. So, thanks!

Thanks for elaborating! I wrote that line in the docs, actually. I wonder if I should add an explicit note about exceptions not being a thing.

Reply on news.ycombinator.com