8 ms·

I like Go and was seduced by channels and go routines. But, I found time to learn Rust (still learning really - Rust is an epic and amazingly rewarding to lear

by nemo44x 12y ago

I like Go and was seduced by channels and go routines. But, I found time to learn Rust (still learning really - Rust is an epic and amazingly rewarding to learn!) and have to admit Rust is far and away the most modern, state of the art and most important programming language of our time. Go compiles easily (pay for it later!) and is sponsored by Big-G. Rust doesn't compile easily but when it does there's a lot of guarantees. And, it does concurrency just as well. Apples to oranges really though. After picking up Rust I feel like Go just offers nothing. Why not use Java or .Net instead of Go? Highly unlikely Go will be more performant than the JVM. Want something less safe and easier to write in, why not use Python, etc? 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. 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. Is it Google looking at the same strategy as Sun/Oracle and Microsoft? Who knows. But, after using it for awhile and letting the glimmer fade, it feels like a regression. Developers, developers, developers!

CatDevURandom 12y ago
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.
logicchains 12y ago
Go has an well-designed, integrated lightweight thread scheduler. The only popular languages with equivalent lightweight threading systems are Haskell, which takes orders of magnitude longer to master than Go, and Erlang/Elixir, which lack static typing. There's also Clojure with Pulsar, but Clojure lacks statically typed libraries, and the Java equivalent of Pulsar, which is ugly to use compared to goroutines as it's not a built-in language feature and Java syntax can't easily be extended like Clojure's. Rust has libgreen, but it is extremely underdeveloped compared to the schedulers/runtimes mentioned above. For developers interested in static typing, lightweight CSP-style threads and ease of learning, Go hence currently represents a much better choice than Rust.
- rdtsc 12y ago
  > and Erlang/Elixir, which lack static typing. From what I've seen over the last 10 or so years programming in both static (C++,Java,C#) and dynamic languages (Erlang, Python) things like "I got a string but expected an int" are pretty low on the list of what fails or brings a project down. Especially when it comes to distributed systems, thing like netsplits, logic and timing errors, mis-configuration, capacity overload are much more serious things. Now you can argue static typing means really fast speed. And it is generally true. But lately with v8, PyPy and other such things that lines gets a bit blurry.
  - nostrademons 12y ago
    In my experience - also using both static (C++, Java, Go, Sawzall) and dynamic (PHP, Python, Javascript) languages - I don't get type errors either. However, what actually brings dynamic languages down in larger systems is the time spent tracing through code to figure out what the actual type of the variable is, and hence what you can do with it. When a script is small this is negligible, but when you've got large teams and hundreds of source files, you can spend 10x the time doing this than actually coding. I view static typing as essential to larger projects, but for documentation reasons, not performance. The performance and error-checking is a nice boon, but you can recover the former with smart VMs and the latter with unit tests. The documentation can only be recovered by writing your types out in comments, where they won't be checked by the compiler and invariably become out-of-date.
danieldk 12y ago
Highly unlikely Go will be more performant than the JVM. Why not? C still beats Java in many cases (e.g. numeric code) thanks to compiler optimisation and I see little reason why (outside garbage collection) Go cannot achieve similar compile time optimisation (in fact, inlining should be easier than in C). Besides that, Go gives more opportunity for optimisation since it has value types. Also, in my personal experience (having written a fair share of natural language processing tools in Go and Java), they are approximately in the same ballpark performance-wise. More synthetic benchmarks such as the Computer Language Benchmarks Game seem to confirm this. And there is definitely still more low-hanging fruit in Go optimisation. Why not use Java or .Net instead of Go? Because I value the Unix tradition and like small standalone binaries with quick startup time more than dragging around a JVM (although I use Java to for projects)? Because it has value types? Because it is easier to call C from Go? Because I like its profiler more?
- Jweb_Guru 12y ago
  Inlining is actually something JITs are really good at... I'm not sure why you think it would be easier in Go than in C, but the relevant angle is the JVM. Go's value types are hyped up, but they're really not that great. Taking a reference instantly heap-allocates them, C# already has them, and Java is getting them too (in 10). Calling into C from Go is easier than in Java, but it's not any faster (in fact, it's generally slower, because you can't call into it without switching away from one of Go's tiny stacks into one that the C expects). One of the unfortunate consequences of this is that optimizing a hot loop by calling out to C doesn't work nearly as well in Go as it does in many other languages. As far as general points about AOT compilation: many don't apply to go compile simply because it will not waste the time to actually perform those optimizations, because it is very focused on its goal of compilation speed. gccgo, sure.

by nemo44x 12y ago

CatDevURandom 12y ago

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.

logicchains 12y ago

Go has an well-designed, integrated lightweight thread scheduler. The only popular languages with equivalent lightweight threading systems are Haskell, which takes orders of magnitude longer to master than Go, and Erlang/Elixir, which lack static typing. There's also Clojure with Pulsar, but Clojure lacks statically typed libraries, and the Java equivalent of Pulsar, which is ugly to use compared to goroutines as it's not a built-in language feature and Java syntax can't easily be extended like Clojure's. Rust has libgreen, but it is extremely underdeveloped compared to the schedulers/runtimes mentioned above. For developers interested in static typing, lightweight CSP-style threads and ease of learning, Go hence currently represents a much better choice than Rust.

rdtsc 12y ago
> and Erlang/Elixir, which lack static typing. From what I've seen over the last 10 or so years programming in both static (C++,Java,C#) and dynamic languages (Erlang, Python) things like "I got a string but expected an int" are pretty low on the list of what fails or brings a project down. Especially when it comes to distributed systems, thing like netsplits, logic and timing errors, mis-configuration, capacity overload are much more serious things. Now you can argue static typing means really fast speed. And it is generally true. But lately with v8, PyPy and other such things that lines gets a bit blurry.
- nostrademons 12y ago
  In my experience - also using both static (C++, Java, Go, Sawzall) and dynamic (PHP, Python, Javascript) languages - I don't get type errors either. However, what actually brings dynamic languages down in larger systems is the time spent tracing through code to figure out what the actual type of the variable is, and hence what you can do with it. When a script is small this is negligible, but when you've got large teams and hundreds of source files, you can spend 10x the time doing this than actually coding. I view static typing as essential to larger projects, but for documentation reasons, not performance. The performance and error-checking is a nice boon, but you can recover the former with smart VMs and the latter with unit tests. The documentation can only be recovered by writing your types out in comments, where they won't be checked by the compiler and invariably become out-of-date.

danieldk 12y ago

Highly unlikely Go will be more performant than the JVM. Why not? C still beats Java in many cases (e.g. numeric code) thanks to compiler optimisation and I see little reason why (outside garbage collection) Go cannot achieve similar compile time optimisation (in fact, inlining should be easier than in C). Besides that, Go gives more opportunity for optimisation since it has value types. Also, in my personal experience (having written a fair share of natural language processing tools in Go and Java), they are approximately in the same ballpark performance-wise. More synthetic benchmarks such as the Computer Language Benchmarks Game seem to confirm this. And there is definitely still more low-hanging fruit in Go optimisation. Why not use Java or .Net instead of Go? Because I value the Unix tradition and like small standalone binaries with quick startup time more than dragging around a JVM (although I use Java to for projects)? Because it has value types? Because it is easier to call C from Go? Because I like its profiler more?

Jweb_Guru 12y ago
Inlining is actually something JITs are really good at... I'm not sure why you think it would be easier in Go than in C, but the relevant angle is the JVM. Go's value types are hyped up, but they're really not that great. Taking a reference instantly heap-allocates them, C# already has them, and Java is getting them too (in 10). Calling into C from Go is easier than in Java, but it's not any faster (in fact, it's generally slower, because you can't call into it without switching away from one of Go's tiny stacks into one that the C expects). One of the unfortunate consequences of this is that optimizing a hot loop by calling out to C doesn't work nearly as well in Go as it does in many other languages. As far as general points about AOT compilation: many don't apply to go compile simply because it will not waste the time to actually perform those optimizations, because it is very focused on its goal of compilation speed. gccgo, sure.