Hacker News Reader

You took this thread on an offtopic tangent. When people do that by baiting the discussion into being about some hot generic controversy (Rust vs. Go! type system wars!), thread quality suffers. The generic baity discussions are all the same, and usually become flamey too.

Other users have started to complain about you doing this repeatedly, so we need to ask you to stop. No more of this, please, regardless of how much you like Rust.

So I am a C++ dev by day and I write some go and rust for side projects or smaller projects at work. Go is SOOOOOO much simpler to write (unless you get into crazy threading data race stuff) than rust. I like rust (a lot), but the mental load is a lot more to take on than go.

An interesting comparison between experiences is that people describe Rust as having a lot of mental load at first, but eventually as having way less, since the compiler does so much for you.

On the topic of the original thread, I wonder why Rust wasn’t included; maybe it’s because our first release that’s achieving similar goals is happening six weeks from now, and they wanted to see how things played out in practice, not in theory.

Yeah I agree that as I learned rust I got used to it and became slowly more productive. But I am still nowhere near as fast to accomplish things with it as I am with modern C++ or go or swift.

people describe Rust as having a lot of mental load at first, but eventually as having way less.

Well that's true for most not-so-semi-trivial stuff one has to learn, it doesn't mean is always a good idea though.

Just giving a different perspective to beginners.

Sure! You should use whatever tools you prefer. Rust isn’t the best programming language of all times, it has pros and cons like everything else.

> maybe it’s because our first release that’s achieving similar goals is happening six weeks from now

What's happening in the next release? Any backward compatible breaking changes?

https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html

Yes, but it's also much more likely to result in a run-time failure. I'm not talking about memory safety here -- just the fact that Rust has (Algebraic Data)/Sum Types[1]. Of course these kind of "want" pattern matching, but it's not an absolute requirement.

Having ADTs/Sum types will improve the reliability of your software immensely just by being available. It's truly absurd just how much work they can do: They can replace "null", they can ensure that there are no surprises in a state machine where some state carries over unexpectedly, etc. etc.

[1] Not higher-kinded, but that's probably a distraction for the point I'm making.

Yes I know. I love Sum types, and I love Trait oriented programming. And I definitely miss sum types in Go and C++. If C++ had sum types and no header files that would probably hit my (very subjective) sweetspot.

Tangent: I wish Rust had optional chaining like swift, which I know is a limitation due to Option just being a normal sum type. Having to pattern match every optional is burdensome

Heh, I was actually alluding to C++ with the pattern matching thing. Std::variant<> is actually a bona fide sum type, but using it is horrendous because of the lack of pattern matching. You can use the the "cppreference overloaded"[1] trick to sort-of do basic pattern matching of the outer constructor, but it's still not particularly well supported by compilers.

[1] I'm using this as a proxy name for a trick I saw on cppreference where you can (via template tricks, why not?) write code very similar to pattern matching, but it's ultimately quite simplistic and brittle.

Ahhh ok I gotcha now. To be honest I have not used std::variant yet as I am stuck on C++11 at work. I agree though at some point there is a limitation with no pattern matching like you have in rust

Agreed. You could encode valid state transitions phantom types, for example. Go's weaker type system means it has less power to encode was is and is not correct program behavior.

I've found that Go works well for small code bases where duplication isn't too much of a worry. It makes sense. The authors of Go are the same people who advocate for small, focused tools: the unix philosophy.

When you grow to a certain size though, it becomes very messy. Go has very little facility for abstraction despite being a higher level language with a GC and a substantial runtime. I also personally find the error handling frustrating. Most of the time all you want to do with an error is send it to the caller, who has more context on how to handle it.

I still write Go alongside Rust, but I use it as a scripting language, for all the things I used to use Python for. Rust just has the tools I need to build abstractions, and lets me avoid continually rewriting data structures.

Yes there is much more mental load you pay upfront during development but once you get code working and satisfy the borrow checker you now have significantly stronger runtime guarantees about your application in terms of safe and proper concurrency.

This is the trade off.

I understand that, I posted my response becasue the OC was presenting Rust as a replacement for Go but they are very different languages with different tradeoffs

Actually, the Go team even bills Go as a systems language. I think if you're going to consider Go, you should also consider what you could get with Rust.

Sure the upfront investment in Rust higher, Go is almost too small, but the upfront cost of Rust is amortized via the hours you save with all the abstractions and performance you get right out of the box.

They’ve moved away from “systems” as a moniker, and Rust slowly is too.

It’s just too confusing of a term these days, and nobody knows what it actually means, so it’s not useful.

I would say if one can write OSes, device drivers, debuggers, compilers, target bare metal deployments on language X, then it is a systems language, regardless of what label people put on it.

The problem with that is it's a narrowing of the 'historical' use of the term and just confuses things further. The Go (and now Rust, it seems) people are right to move away from it.

Even when Go started and used the term I don't think this is what they meant by it.

Well given its use in Fucshia TCP/IP stack, file system management tooling, Android GPU debugger, not everyone at Google thinks like that.

Likewise those universities doing OS research in Go, submitting their findings to USENIX.

> you now have significantly stronger runtime guarantees about your application in terms of safe and proper concurrency.

I agree, but I think many people assume that this is the only benefit achieved. The presence of the borrow checker and rigorous memory safety requirements allows the compiler to take substantially more advantageous paths in allocation/deallocation compared to e.g. C. The benefit attained is similar to the benefit of switching from C to very well memory-managed C++, except it comes by default.

This is a significant advantage even in code that is not concurrent at all. I feel like it's a shortcoming of Rust's marketing, if anything, that the safety restrictions are often pitched only in context of thread-safety rather than memory-usage-optimization.

Yes I agree with those points as well...because Rust is now able to statically have such guarantees, this additional knowledge allows for some great optimizations under the good.

Is there a reason this guy keeps posting about Rust, especially on articles about other programming languages (ex: also a recent Elixir post)? Overall across posts, I sometimes agree with this guy, but it's getting really obnoxious that people continue to leave such replies every language post.

I really like Rust and use it for major projects, but I fail to see how it's much on topic. I agree with other comments that it gets compared to Go all the time, often without prompting or relationship to articles. Want to do that, why not write an article or do a separate post? Hijacking the comments and/or shilling Rust is getting old.

I have to say that although I love Rust and somewhat despise Go, if it works for you, use it. Go is good at a lot of things - identify what they are and use it because it solves your problem. If another language does that better, use that instead. If you don't know what those things are, you probably need to spend some time not only reading, but writing actual code in that language.

Don't pick one language to solve all your problems and don't look for problems because you like a language or some specific features of a language. Consider the entire scope of your issues, both technical and non-technical. In that sense, I can see why a lot of people choose Go and it is just as valid as any other language choice.

I'm sure this was well-intentioned but it had the effect of turning half the comments on an otherwise interesting thread into a Go vs. Rust language battle, which is not the topic of the story we're commenting on.

I'm commenting on the pain points specifically being addressed in Go v2, so I feel it's appropriate to talk about the alternatives here. I also tried to focus on specifics.

This document is in fact not about the features in Go 2, but rather on the migration path between two languages, whose features are (in the piece) an abstraction. Please don't start language wars.

Why do people feel the need to promote Rust on many Go topics? Also can someone explain the "lack" of strong type system in Go, I don't use interface{} so where is the problem?

Why do people feels the need to promote rust on many Go topics?

Its more fun for some to do so, for ex: the Go2 proposal might be too boring to discuss.

I think since there are so many languages being rapidly developed these days (including c++), comparing language features is a good way to know how things are and aren't used in practice.

Rust just happens be extremely popular right now, along with python and go.

I like Rust a lot, but lets be realistic here, being extremely popular is very subjective to which bubble one moves on.

That true. I always assume HN is reflective of the community at large, but at work it's very different.

One limitation is that although "int" can be sub-typed, such a variable cannot directly index a slice.

I’m confused. First, there’s no notion of sub-typing in Go. Second, the closest thing I can think of what you mean does work: https://play.golang.org/p/IE9sg4CwCd_C

Rust doesn't have proper integer subtypes either. Ada has.

Aren’t ada’s runtime checked? You can do that in Rust.

Only if it cannot be proven at compile time.

Interesting. You wouldn’t happen to have a link to docs, would you?

The docs are the Ada language standard.

http://www.ada-auth.org/standards/index.html

Like with other languages, each vendor is free to do their best for optimizations, while keeping language semantics.

Besides Ada Core, there are a couple others but at enterprise budget levels.

http://www.adaic.org/ada-resources/pro-tools-services/

Thanks

Two very important things for me that Go offers are the garbage collection and the stackful co-routines (i.e. go-routines). Makes code so much easier to read and write.

If they would give me generics and ADT, I don't think I would ever use any other language.

Another quite fast language with GC(actually you can choose between several), generics and ADT(also pattern matching with libraries) is Nim. People also use it for concurrent code, but I don't have so much experience in that aspect

Rust has the borrow checker, which gives you the safety of garbage collection coupled with the power of manual memory management. As of Rust 2018, Rust also has async and await, and futures can be cooperatively scheduled on a green thread model (but you're not limited to that model).

I personally prefer having a good GC because I need the speed of manual management in only a minuscule percentage of my code and it's much simpler to use a GC instead of constantly fiddling around with manual memory management, let alone the borrow checker and lifetimes. It's a matter of productivity and fun.

In addition, it's pretty easy to avoid heap allocations in Go, so you can do some basic (but effective) management without breaking a sweat.

Rust is a great language, and has its uses, but it's not a cure all. IMHO stackful co-routines are superior to stackless (i.e. async-await). Also if I am not mistaken the futures library is still in the nursery and subject to change.

When I write code that is going to run on the customer’s device, I choose Rust for the guarantees it offers me, (I know it will not crash because of my mistake). For server side code on the other hand, something easy going as Go is much preferred.

Futures are subject to some more change, though it’s getting close!

FWIW, async/await does produce a “stack full” coroutine: you get a single, exactly sized stack for each task, every time. This is made possible by coroutines being fundamentally stackless, but in the end, tasks still have stacks.

> FWIW, async/await does produce a “stack full” coroutine: you get a single, exactly sized stack for each task, every time. This is made possible by coroutines being fundamentally stackless, but in the end, tasks still have stacks.

I see, thanks for the info. I wasn't talking so much about the implementation but the difference between the program control flow differences between the two models, go-routines vs async/await.

Cool cool. Both have advantages and drawbacks; I think both languages have made the right choice given their contstraints.

While it gives the safety of a GC, it still doesn't give the ergonomics, specially when doing GUIs.

Rust and Go are very different languages for very different use-cases and with very different goals at every level of design.

Rust is a C replacement, Go is a replacement for everything else ;)

But simple reality checks reveal that Go is an evolution of C and Rust grow out of frustration with C++.

Rust is not a good replacement for C++, though. It doesn't even have inheritance, let alone multiple inheritance and/or multiple dispatch.

It's kind of in-between C and C++ in terms of capabilities, and neither a subset nor a superset of Ada's features in terms of safety. Some of Rust's memory safety features are only now being added to Ada and not yet in the forthcoming standard, whereas Ada has many features that Rust still lacks (e.g. integer range subtypes, OOP with inheritance). Rust is less secure than Ada/Spark, though, and clearly not intended for high integrity systems.

It seems that the niche Rust is aiming for is "safe general system's programming for people who primarily use C and C++ but have never used much Ada or Haskell", and in that area it's quite successful.

Both Rust and Go are odd, because they have less features of C++ (plus added safety) and attempt to sell a lack of features as advantages, whereas in reality no one forces you to use a feature and their developers are merely pushing their own, personal agenda about "what's the right thing to do". I personally don't like C++, but one of its benefits is that it leave its users the choice of what's the right thing to do and offer as many zero-cost abstractions as possible. Rust and Go are way more patronizing.

What do you mean Go doesn't have a strong type system? Are you refering that it allows for interface{}?

I think it's more that it requires it in many cases, due to the lack of generics.

I always find work arounds or just write more code. I feel like it's annoying sometimee but when reading code I feel blessed that generics are not supported.

Reading redundant code is always more work than letting the computer handle those low-payoff details.

And nobody's going to provide their data structures specialized to every type you could possibly want. Case in point: container/heap from the standard library takes and returns interface{}.

Oh no. Believe me reading code full of templates is not a pleasure. There is a reason Go is so pleasant to read.

C++ templates are hardly the best example of generics out there, and certainly not what you should be looking at from a Go perspective, seeing how Go is a higher-level language that doesn't concern itself with zero-cost abstractions anywhere near as much as C++ does. Look at C# or D generics instead.