4 ms·

I'm going to try and not come off as frustrated, but as someone who really enjoys and sees a place for both languages, I'm getting a little tired of the rust vs

I'm going to try and not come off as frustrated, but as someone who really enjoys and sees a place for both languages, I'm getting a little tired of the rust vs go zero-sum game thing here on HN. And at least you end your first paragraph with the acknowledgment that it's really "Apples to oranges really though." But -- since you did write that paragraph I'm going to address your points. > Rust is an epic and amazingly rewarding to learn I liked learning it too because it filled a pain point I've been feeling for years when it comes to systems programming. Can you specifically explain a bit why its "epic" and "amazingly rewarding" to learn? > Rust is far and away the most modern, state of the art and most important programming language of our time Holy guacamole that's quite the assertion by someone who, by their own admission, is still learning the language, how do you feel qualified to make such a ... well.. hyperbolic statement? > Go compiles easily (pay for it later!) By easily, I assume you mean quickly. How do you pay for it later? > there's a lot of guarantees Like what? > After picking up Rust I feel like Go just offers nothing. Why? > Why not use Java or .Net instead of Go? Highly unlikely Go will be more performant than the JVM. It already is, in some ways. Can you be more specific? > Want something less safe and easier to write in, why not use Python, etc? Go is less safe than rust? > You can't write real time systems in Go and you never will be able to. You probably shouldn't write "systems" programs in Go. Why do you personally think that? For example, I'd say that Rust gives you more control over memory. And has smaller binary sizes. But still, I've been frustrated by the overall size of binaries in both languages. Go in particular makes embedded programming near impossible (I was hoping to write software for my MIPS router in Go but was unhappy to discovery a nearly 12 MB binary file) >Go has a couple built-in features that other languages can and will get with library addition. Go is a 1-trick pony I feel sometimes. It's an "in thing" that doesn't serve much of a purpose overall I feel. It looks like C but lets face it, it's nothing like it in terms of performance and never will be. It isn't a replacement for C. Why do you get the impression that is Go's purpose? > Is it Google looking at the same strategy as Sun/Oracle and Microsoft? Who knows. Which is what, exactly? > it feels like a regression From what? Why? > Developers, developers, developers! Oh my god, you are a troll bot.

copsarebastards 12y ago
I'm not the person you're responding to, but I agree with most of what they said, and here's how I would respond to what you're asking: >> Go compiles easily (pay for it later!) > By easily, I assume you mean quickly. How do you pay for it later? I think they actually meant easily, not quickly, in the sense that the type system doesn't require a lot from the user. However, you pay for that later when your codebase becomes larger and you start experiencing bugs that could have been caught by a more sophisticated type system. >> Rust doesn't compile easily but when it does there's a lot of guarantees. > Like what? Rust guarantees a number of kinds of memory safety. It's important to note that this is in comparison to C, not to Go (Go actually has stronger guarantees because of GC, I think). But Rust's strong typing also catches a lot of kinds of bugs that are hard to quantify mathematically but are pretty apparent to anyone who has worked in both strongly and weakly typed languages. I wouldn't call these "guarantees" but I would say that I'm definitely more confident in strongly-typed code than in weakly-typed code. >> After picking up Rust I feel like Go just offers nothing. > Why? Because after using both languages, he hasn't found anything that Go offers. What exactly do you think Go offers that isn't available in other languages? >> Why not use Java or .Net instead of Go? Highly unlikely Go will be more performant than the JVM. > It already is, in some ways. Can you be more specific? For general use cases, the JVM has years of tuning behind it. You can't get more specific than that, as obviously there are some use cases where Go might shine. But as projects grow large, many use cases come out and it's highly unlikely that an arbitrary project will just happen to only have use cases that favor a new language without years of performance tuning behind it, especially when the designers of that new language shows no interest in looking at the last few decades of language research. >> Want something less safe and easier to write in, why not use Python, etc? > Go is less safe than rust? Absolutely. Go's type system is decades behind. C++ has a stronger type system. Rust's, meanwhile, is extremely sophisticated, using ideas from strongly typed functional languages. There are some cases where compromises were made to allow low-level memory access which might allow some bugs which aren't likely in Go, but those are calculated compromises. Go's type system offers neither the safety of a modern statically-typed language nor the flexibility of a modern dynamically-typed language. Go's type system is just pitiful. >> You can't write real time systems in Go and you never will be able to. You probably shouldn't write "systems" programs in Go. > Why do you personally think that? Because GC simply isn't to the point where it can be used for real-time programming, and systems-level access often is just easier to do with manual memory management. >> it feels like a regression > From what? Why? From any other major recent language, because it offers no new innovations and actively doesn't include ones that have proven effective elsewhere.

copsarebastards 12y ago

I'm not the person you're responding to, but I agree with most of what they said, and here's how I would respond to what you're asking: >> Go compiles easily (pay for it later!) > By easily, I assume you mean quickly. How do you pay for it later? I think they actually meant easily, not quickly, in the sense that the type system doesn't require a lot from the user. However, you pay for that later when your codebase becomes larger and you start experiencing bugs that could have been caught by a more sophisticated type system. >> Rust doesn't compile easily but when it does there's a lot of guarantees. > Like what? Rust guarantees a number of kinds of memory safety. It's important to note that this is in comparison to C, not to Go (Go actually has stronger guarantees because of GC, I think). But Rust's strong typing also catches a lot of kinds of bugs that are hard to quantify mathematically but are pretty apparent to anyone who has worked in both strongly and weakly typed languages. I wouldn't call these "guarantees" but I would say that I'm definitely more confident in strongly-typed code than in weakly-typed code. >> After picking up Rust I feel like Go just offers nothing. > Why? Because after using both languages, he hasn't found anything that Go offers. What exactly do you think Go offers that isn't available in other languages? >> Why not use Java or .Net instead of Go? Highly unlikely Go will be more performant than the JVM. > It already is, in some ways. Can you be more specific? For general use cases, the JVM has years of tuning behind it. You can't get more specific than that, as obviously there are some use cases where Go might shine. But as projects grow large, many use cases come out and it's highly unlikely that an arbitrary project will just happen to only have use cases that favor a new language without years of performance tuning behind it, especially when the designers of that new language shows no interest in looking at the last few decades of language research. >> Want something less safe and easier to write in, why not use Python, etc? > Go is less safe than rust? Absolutely. Go's type system is decades behind. C++ has a stronger type system. Rust's, meanwhile, is extremely sophisticated, using ideas from strongly typed functional languages. There are some cases where compromises were made to allow low-level memory access which might allow some bugs which aren't likely in Go, but those are calculated compromises. Go's type system offers neither the safety of a modern statically-typed language nor the flexibility of a modern dynamically-typed language. Go's type system is just pitiful. >> You can't write real time systems in Go and you never will be able to. You probably shouldn't write "systems" programs in Go. > Why do you personally think that? Because GC simply isn't to the point where it can be used for real-time programming, and systems-level access often is just easier to do with manual memory management. >> it feels like a regression > From what? Why? From any other major recent language, because it offers no new innovations and actively doesn't include ones that have proven effective elsewhere.