291–300 of 384 posts
Can anyone convince me to use Rust over Go, or the other way around? My target machines range from i7s with massive amounts of RAM to Raspberry Pi with slightly-less-massive amounts of RAM.
Rust: Best suited for writing OS, network stack, embedded systems, and webservers like Nginx.
Go: Best suited for writing micro-services, CRUD apps, API servers etc
pick your poison
> Go differs from Java in several ways
> Programs compile to machine code. There's no VM.
This tries to imply that having a VM is a bad thing.
> Simple, concise syntax
The syntax is simple, but not overly concise. For example the lack of generics leads to a lot of repetition.
> Statically linked binaries
You can have them with Java, too.
> Built-in strings (UTF-8)
Should this suggest that Java doesn't have trings?
> Built-in generic maps and arrays/slices
Yeah! Some of the most awesome things about Go is the limited set of data structures and the limitation of generics for exactly this few structures.
> Built-in concurrency
It is questionable whether this is good or not. There are a lot of good concurrency libs for the JVM.
> Sometimes this means writing out a loop instead of invoking an obscure function.
This is completely strange! The lack of abstraction is sold as a good thing. Actually a lack of abstraction leads to redundant and error prone code.
Can anyone convince me to use Rust over Go, or the other way around? My target machines range from i7s with massive amounts of RAM to Raspberry Pi with slightly-less-massive amounts of RAM.
> Rust over Go Rust: Best suited for writing OS, network stack, embedded systems, and webservers like Nginx. Go: Best suited for writing micro-services, CRUD apps, API servers etc pick your poison
Earlier quoted context omitted.
What is "ninja coding"? Sounds stupid.
I think it refers to the Perl-era idea that good code should be somehow "clever" rather than maintainable. It's how bad programmers who spend hours agonizing over how to reduce their line count (presumably to save disk space?) justify their behavior.
Earlier quoted context omitted.
> We continue to use Go because of its strengths, but it just really surprises me how little Google seems to care about the language and ecosystem. Go is certainly a language that is used at Google, but AFAIK a lot of "Googlers" don't really like it and don't use it. It certainly not the "official language at Google", given the weight of C++ and Java there. But that's the consequence of being opinionated. Using Go me…
>> given the weight of C++ and Java there. Python as well. >> how little Google seems to care about the language and ecosystem Let's compare with Microsoft. The top four out of five users at StackOverFlow have top tags in C#, I guess Google have a long way to Go.
Earlier quoted context omitted.
And yet the os group at ms is famous for their naked derision of the .net Framework.
Hum .Net is their own dog food .. did you mean Android/iOS? :-D
Earlier quoted context omitted.
For optimal code maintainability, there is a happy compromise between excessively terse and excessively verbose code. There is a lot of code in the wild that's too spread out.
Well sure, but erring on the side of verbosity at least ensures that someone can follow your thinking as long as the code is well structured. I would prefer to read 25 lines of decent Python over 3 lines of regexes in Perl.
There are some questionable statements: > Go differs from Java in several ways > Programs compile to machine code. There's no VM. This tries to imply that having a VM is a bad thing. > Simple, concise syntax The syntax is simple, but not overly concise. For example the lack of generics leads to a lot of repetition. > Statically linked binaries You can have them with Java, too. > Built-in strings (UTF-8) Should this s…
One important niche I see that Go serves very well is in distributed, fault-tolerant deploy platforms (aka schedulers), like Kubernetes or Mesos. If you look at the amount of tooling that uses Go, you almost feel there just is no other choice out there. I would not adventure to say state-of-the-art schedulers would not have been possible without Go, but for sure Go fits the requirements pretty well.
> I would not adventure to say state-of-the-art schedulers would not have been possible without Go, but for sure Go fits the requirements pretty well. AFAIK Mesos is mostly written in C++. Aurora - a Mesos framework & scheduler from the same folks is written in Java & Python.
Earlier quoted context omitted.
Likewise. I use for set and forget services. Once a Go application has been properly tested it runs quietly like a mainframe in the corner of a datacenter.
Same experience here. Writing tiny, focused, small footprint services with Go has been a blast. It really has its niche. Especially since learning to write (and read) Go is a matter of hours, more than days (or even weeks).
It's amazing how good they perform with minimal memory usage.