Why Go and Not Rust? (kristoff.it)

Yep!

It's not asking me actively, but it's just crazy that I'm offered to install a random blog as an app.

Though impolitely made, I think he has a point.

Why does a blog need to be a progressive webapp? Why would one want to “install” it?

I replied to the parent comment on my experience, but I do agree that Java and C# can be very fast.

I also agree on the problem with null pointers with is really ridiculous. Another complaint that I have about Go is how for some reason Google decided to implement many web protocols in the standard library, but never really cared to get websockets right, to the point that they just sedn you to a third-party library from their own documentation. That + QUIC/HTTP3 make me want to take my tinfoil hat out from the drawer.

https://godoc.org/golang.org/x/net/websocket

Has there been a statically typed language with no null and no generics? I'm pretty sure that every language I've used that implements an Option-like type has it be generic. Maybe TypeScript, where you can have "number | null"?

I would add parametric enums to your excellent rant. When I first learned Go I thought it’s use of constants with iota as quite a clean approach for enums. But after spending some time with Scala, Rust and Swift, well, I was wrong. Being able to exhaustively pattern match is simply excellent. And like non-nullable types, this is a zero overhead language feature that is simple, feels great to use, and reduces bugs.

It feels like a real step backwards using languages without parametric enums. My litmus test when learning a new language involves porting across some plain text operational transform code. The go code came out about 40% larger than the rust and swift implementations for this reason. It was also much uglier and harder to read. Like, those extra lines were pure overhead.

Eg this rust code is beautiful: https://github.com/josephg/textot.rs/blob/bb14b4b483e7dace67...

And that’s prettier and about as performant as this C implementation of the same function (I think I somehow lost the Go code - but it wasn’t much better than this): https://github.com/ottypes/libot/blob/902470a22d3a99d9b776ce...

The equivalent javascript code (my go-to language!) is larger than the equivalent swift / rust code and, last time I checked, about 8x slower. Most of the gap in readability is this one beautiful feature!

Interesting, given the Go footguns of nil interfaces, reading from closed channels, gc of goroutines, reflection via magic struct tags.

Can you describe (or link) a scenario where more advanced mutability options would be preferred / better practice?

I agree with this assessment. Swift has a lot of the things that make Rust nice to work with, but favors usability over performance while Rust does the reverse.

> Too bad that outside of iOS development it's still unusable.

Sub-optimal for sure, but not unusable. It's being used in production on the server in several instances.

I have a swift web service running in production, it's definitely not unusable. You're right it's rough around the edges but it's early days.

I would second this. I moved from Go to Crystal. Crystal has been great to work with. Due to a rich standard library, the absence or fewness of third-party libraries may not be much of a problem, especially if you are looking for developing web applications and command line tools (two areas where I have used it). It also has a very friendly and helpful community.

Rust is more than just memory safety. For example, it also enables safe concurrency, which sounds like something you would want in a renderer.

Graphics code has a long history of memory unsafety, in more recent years causing serious security issues when we tried to put OpenGL on the web with WebGL, resulting in every device driver bug turning into a kernel-level vulnerability in the JS code. You've got a lot of people writing code with more brains than discipline [1], writing in an environment where performance is priorities one, two, and three, writing in memory unsafe languages... yeah, memory unsafety in rendering code been a big problem for a long time.

[1]: One of the most dangerous types of coder there is is the brilliant one, who has several times the working memory capacity of a normal person, and who can write 1000-line "functions" without breaking a sweat, and builds entire codebases out of such things. (Sometimes, perhaps the core loop of a program will be a bit of a monster, but the whole program isn't like that.) The cost of salvaging such things can be disturbingly close to the cost of rewriting such things, and indeed, the process for either may not be all that different.

It's close enough with its syntactic sugar and type system. There's no gap at all, really.

One place where Java and C# win, and sometimes C++, is the availability of excellent libraries. Rust doesn't have as many and not as fleshed out either. Go has the same problem though.

>> cases where you would like to use Python but it would be too slow.

> Would be cool if Rust could cover that gap.

To really cover most of that gap, writing Rust would need to be as easy as writing Python, since that's one of the main selling points of Python. But Rust's massive benefit, compile-time memory management, is definitely not as easy to write as code that uses GC.

GC has overhead that you sometimes can't tolerate, but it's just simpler to write. If you have a graph of objects, it's easy to do in Python or C# or JavaScript. In Rust it's more complicated, because it's hard to do that at compile time!

The huge benefits of Rust are directly relevant for systems code, but for most Python code it's probably not the best tool.

>I use Rust as a python replacement for most tasks

Wie bitte??? My wig has been snatched.

How do you get that C# is way behind Go on this one? If anything, those benchmarks show these groups of languages performing at roughly the same level:

1. C/Rust

2. Go/C#

3. Java/OCaml/Haskell

4. JavaScript/Swift

5. Python

> User-space network driver? The benchmarks group Go closer to Rust with Java / C# way behind

That's a very generous reading of those benchmarks. What you said is true in the latency benchmarks, but in the throughput benchmarks, C# _beats_ Go at high packet rates and is much closer to Go than Go is to Rust at low to medium packet rates.

Concise, clean, effective and without cruft. That's the main reason for Golangs unstoppable growth.

Java is a language and computing platform from the 90s and it shows. It really needs to just stop and the mess around licensing only serves to help kill it.

I also wouldn't tout the concurrency of Java over Golang - having the concurrency model baked into the language and runtime means a clear advantage for Go and one which simplifies the communication among different agents.

Please learn some basics.

I'd always assumed he was using "systems language" to just mean "as opposed to a scripting language" like perl or bash.

If you dig into those machines, anything vaguely real time including huge chunks of the drivers were written in user writable microcode.

It was also found in the 80s that any operating system written in LISP was dog slow. They even started making dedicated hardware interpreters of LISP to try and get around this. https://en.wikipedia.org/wiki/Lisp_machine

When you need to start designing your hardware around your computer language you know there's a problem going on.

How do you explain the throughput and latency numbers posted by https://github.com/ixy-languages/ixy-languages? Go is beating Java in both latency and throughput, and the author attempted many different Java GC tunings (https://github.com/ixy-languages/ixy-languages/blob/master/J...)

Maybe tuning for latency is the appropriate trade-off given Go's high level of control over allocation and data layout?

Sounds very similar to "leaking" event listeners in other languages.

The handler and all of the scope it can reach stick around forever even though they should have been replaced or removed.

GC is more than just pauses. Throughput matters too; in fact, it often matters more than latency (for example, when writing batch jobs like compilers).

I'm not disagreeing with you, but the example you're using (the ixy driver) is a pretty poor one to compare garbage-collected languages: Go performs particularly good on this one, because the go implementation doesn't allocate anything on the heap (and then the GC has nothing to collect). Being able to work on the stack only is a feature of the Go language, but it has nothing to do with its garbage collector.

I view it as a problem of scaling comprehension. Not scaling of performance.

Yes this is still true[1]

[1]: https://www.youtube.com/watch?v=4VNDjwzzKPo

I wonder if it is actually more complex. Emergent complexity is a thing, and one only needs to look at Go (the game; pun definitely (not) intended). The rules are dead-simple; you can learn them in under a minute. But to actually play the game well, you have to learn a lot more. You have to memorize openings, learn to identify and utilize patterns, etc. There is a lot of "meta-play" going on, and you could say that high-level Go play is full of abstractions. In fact, you won't have a chance without the abstractions. If you only see individual stones rather than shapes, you're done for. I think the same applies to languages like Go. You don't have generics, but if you want to effectively re-use code, you need abstractions. The difference now is that in languages like Rust, you have predefined and marked abstractions, while in Go, you define them yourself and need to recognize them yourself. Granted, Go also makes certain kinds of abstractions difficult or impossible to manually define within the language, so you may end up with copy-pasted code, but I imagine even that will be manually abstracted through naming and such.

The Rust iterator is a pretty simple abstraction in my opinion. It's essentially a lazy list. You see an iterator used, you know what you're getting. You see the map function used, you know it's the same as a for loop over all the elements. A fold/reduce is just a for loop over all elements with a result variable that gets returned. I really don't think using iterators is any more complex than a for loop, and with a for loop, you actually have to look through it to identify the pattern used and find out what it does. I'd say having to manually check for patterns is more work, but I couldn't say which one is more complex; maybe neither is.

You can encapsulate iteration logic in Go.

I do it in my libraries when warranted.

The pattern is:

  v := NewIteratedValue()
  for v.Next() {
    item := v.Item
    // process item
  }
  if v.Err() != nil {
     // process error
  }

A variation of this pattern exists in standard library and third part libraries.

I know that you meant implementing some sort of iteration protocol natively supported by the language, so that you can write:

  for v { ... }

vs:

  for v.Next() { }

But you ended up making much stronger and untrue claim that one can't write re-usable iteration logic in Go.

  type Iterator interface {
    Next() (Foo, error)
  }

  func Map(it Iterator, mapper func(Foo) Foo)) Iterator

  func MapFooToBar(it Iterator, mapper func(Foo) Bar)) Iterator

You can solve any problem in a language without generics, such as Go, C, Fortran-IV, or any other Turing-complete language, including the Turing machine "assembly".

The difference is in speed of producing such code, amount of bugs introduced, ability to understand, modify, and evolve the code, etc.

The simplest example I can think of is: Map(slice, func)

You can can implement this generically in Go using interface{} types and runtime type checking, but then you have runtime type checking failures.

A java/c++-esque "generics" implementation would be able to type-check at compile time.

For a Math.max function you would normally have generic comparables and implement on that.

Go makes you implement max and min in all your codebases.

In fact with Go is even more obvious. Go don't have inheritance!

Traits is a way to solve it. But the problem is that in Go types are "too open". If you wanna constrain it more traits is not an elegant solution.

Generics is better in this case.

BTW: This is how is in Rust. Rust have traits but you fill the rest with generics.

I made a mini-go database command liner that I call from rust (so I get access to drivers that are not yet available in rust). Is much more boilerplate from some stuff that in the rust side is just Value<T>.

And type errors that Go have that rust don't.

I think that Rust & Go sharing some(most?) design principles (about how model types) make easier to see what each side make harder...

A lot of the time you’ll end up with an implementation for each discrete possibility, but that’s pretty crappy especially if you have more than 3 or 4 discrete types you need logic for (though not always bad, some go libs follow this pattern e.g. sort offers a method for each basic type). You could use the empty interface (which is essentially ‘any’), but that generally requires you to do casting or runtime type checking and that’s suboptimal in a statically typed, compiled language.

Generally it makes more sense to describe an interface that can be satisfied by different types, and writing logic to handle that interface instead. Go may not have traditional generics but the interface pattern is certainly a kind of generic programming that can be used to achieve some powerful results. Because structs can satisfy many interfaces and interfaces can be satisfied with any kind of struct (if you want an in language example check out the io.Writer interface and the many functions that use it) you can end up with highly reusable code despite not having traditional generics.

One example is n-dimensional arrays where each element could be a byte, uint16, int16, ... , uint64, int64, float, or even some custom vector. In a language with generics, you could describe the nD array more simply and the operators work depending on what was passed. The implementation can also be shared across a number of similar element types. In Go, though, you’d need to use interfaces and at some point you’d have to make tradeoffs about speed, simplicity of the implementation (e.g. hand-coding each element implementation) vs use of interface function calls to get properties, etc.

One example is to look at how Go handles the Image package vs other languages with generics. https://golang.org/pkg/image/

literally any data structure that stores different types similarly. hashmaps, linkedlists, vectors, binary trees (assuming you can bound on some ordering function), etc, then all the operations you expect to work on those data structures. You could also define mapping operations that work on the containing structure and don't care much about the specific type of the contents. There's a million and one uses for generics (polymorphism).

In Go, I believe you need to give up type safety to write these implementations, by using Interface{}

In my experience Generics become much more useful, when your typesystem is strict. I use them quite often in Rust, especially when writing functions that should take many different types as inputs/outputs.

You can get away without them in many cases, but if you are working on stuff that you want to reuse, generics are the way to go. In combination with Rust’s traits this is especially cool.

I have functions that have to deal with hierarchical data objects, JSON like things. All collections are identically typed (although they have optional fields, different length arrays, etc.), but there is more than one type. In order to write simple code, I wanted to write one function that gets them from the database, one to update a single record, one to notify of changes, etc. So my top-level type to cover all of these collections is map[string]interface{}, which in TypeScript would be Map<string, any>.

Then I ran unit tests, and sometimes a weird error cropped up. Turns out I made an error in an append: instead of concatenating two arrays, I added the second array as the last element of the first. That was a time consuming bummer.

This problem could have been prevented by two approaches: copying every function for every type, or generics.

Go is a nice language, which makes some tasks easy to implement, almost fool proof, but it still lacks in other areas.

suggest reading:

https://blog.golang.org/why-generics

Non-nullable types in are implemented using a combination of (powerful) enumeration types and generics.

Enumeration types in rust can be the usual ones you find in other languages:

    enum UserStatus {
      Anonymous,
      Registered,
      Confirmed,
    }

But their variants are not limited to names, they can be other things[1]:

    enum UserStatus {
      Anonymous,
      Registered{ email: Email, date: Date }, // a struct
      Confirmed(date), // a tuple
    }

Enum types can also be made generic. For example the Date type could be a parameter in the example above:

    enum UserStatus<T> {
      Anonymous,
      Registered{ email: Email, date: T }, // a struct
      Confirmed(T), // a tuple
    }

Which brings us to the Option type[2] in rust. It is an Enum with a generic type attribute, defined like this:

    enum Option<T>  
    {  
        Some(T), // a tuple with a single item of type T 
        None,
    }  

In rust, when a function says it returns an `i32`, it will always return an `i32`. It never returns `i32 or null`.

If you want not return an `i32` sometimes, you must specify exactly what else it can be. It is often convenient to return an Option<i32> instead. Then it can return `Some(i32)` or `None`. The difference with the "implicit null" from before is that the compiler will force you to "deconstruct the option safely", in compile time. You will never get a "Null Pointer Exception" in run time because of this.

For me, this is huge, and one of the reasons I like Rust more than Go.

[1]: https://doc.rust-lang.org/rust-by-example/custom_types/enum.... [2]: https://doc.rust-lang.org/std/option/

Have you gone back and read that post you linked recently?

It seems to me like the final section has a lot of bad things to say about the methodlogy of a go developer. Huge, bloated toolchains required to make progress. Code volume rather than appropriate abstraction. To me, your MS Word vs LaTeX graph sure seems like it's damning "easy" languages like Golang in favor of other languages with more powerful abstractions.

You also assert that Golang is easier to learn than other languages. I don't think you've really got a leg to stand on there. It's "easy" for folks doing service development because the arbitrary decisions made by Golang were made from the perspective of someone experienced at writing web services. If you already know C and Python a bit, Golang cherrypicks a lot of good stuff, but if you don't (or you're not writing a bunch of web services that essentially do nothing but punt to C frameworks and validate strings in request headers) then Go's going to struggle, and folks have pointed this out.

It's pretty surprising to me that you write about how Generics are the death of enterprise software when so much quite-usable software uses generics. Why do yo simply get to forget the existence of the huge body of Java work and instead assert it's bad? Android uses generics in many cases where appropriate and it's one of the better UI kids available these days.

Even the Actor methodology you're citing as part of Golang as good is actually a fairly sophisticated abstraction with lots of implications for the runtime and execution order. Why is that specific programming abstraction given a pass because of its benefits, but writing a generic linked list is going to be the death of your programming organization?

You also defend the structuring of many enterprise groups even as you suggest that they lack training, refuse to pay technical debt, and place unreasonable burdens on developers. You seem to have just accepted this and said Golang helps you be more complicit in this mode of operation that you also seem to suggest is somewhat bad. Why would we want to pander to a methodology that asks junior developers to proceed without training and places focus on process and hyper-specialized domain experts rather than clear communication, sound architecture and sustainable velocity?

I'm quite confused how you can hold both these opinions at the same time. It seems like they're contradictory.

     new TypeReference<FooResponseCollectionResource<MemberUpdate>>(){})

    using NiceType = TypeReference<FooResponseCollectionResource<MemberUpdate>>
    // ....
    new NiceType ()

I almost completely agree with everything in the article except the word "Enterprise", it might just be me but it can mean a lot of things to say it's good for enterprises.

We could say it's good for Web and Services Enterprises (probably) but for a different kind of an enterprise it can vary, depending on their business model and requirements. As the significance of it's features can change.

Tldr; All languages have a place(IMHO), Go is a simpler language with reasonable value in the current industry for various reasons.

I also don't understand your argument on simplicity. You make mention in multiple points about "await". You don't like it. We get it. In what way is it not simple? And how does it follow that Go is more simple (using the same definition).

Yup. This is the origin of this idea.

he also had another talk https://www.infoq.com/presentations/Design-Composition-Perfo...

and I would argue there's idea that simplicity of the instrument/tool is not a problem in itself and we shouldn't lose it in pursuit of 'ease'

Auto-complete turning his name into "Rick Hockey" does actually explain what's been going on with Rich's hair over the past few years.

I assume the GP meant "scale of codebase complexity" – which is orthogonal to whether something is "web scale" (ie. everything Google does).

People may also mean different things by scale.

For me, scale means more micro-services. For another person it means a bigger monolith.

Which is probably the reason Google have made tools like a decorator to transform code with generics to valid go code.

I think OP thinks about different scale.

It's not scale about number of users or data, it's complexity scale.

Last enterprise app i worked on had (provided) something like 10.000 different api calls (and yes mostly because of bad/wrong initial design decisions), and over 50k different possible queries that it could run against database. (my job was to "make database go faster")

Just running unit tests took longer than 6hrs (of course most unit test went out and connected to the database, because why not \s).

It all could be replaced with dozen or so 10k to 30k lines go projects each, that would be a lot easier to maintain and to scale out.

Go is pretty explicitly designed (as in there are quotes from the designers) with a low ceiling because Google doesn't want to trust their engineers to have nuanced programming taste.

Go was designed for Google-scale and Google-style logs analysis, for which it has been very successful. The fact that it comes with a decent HTTP and RPC server is the inevitable consequence of the fact that every process at that company is expected to present HTTP and RPC control and diagnostic services in addition to its primary purpose.

>Go was designed at Google to be used internally at Google

That's not true, expect in a pedantic way. Google was "designed at Google to be used internally at Google" only in that:

(a) a few people at Google, on their own, designed a language (mostly based on an older Plan 9 language some had helped built) - not at the request of Google execs, nor as an explicit company-mandated project to create a language to solve Google's problems. It was almost on of these "20% spare time" things.

(b) these people added the features that they thought, as far as they were concerned that would be nice for programming Google style stuff. Those were based on their ad-hoc (and quite idiosyncratic) intuition and personal experience, and not some special research into programming at scale, or from involving the company at large at it.

Go was designed at Google, but not "from Google", if this makes sense. E.g. a few googler's building a language on their own initiative and among other work is not the same as Google, i.e. some higher-ups, saying "we need a language of our own that's a match for our developers' challenges" and the company devoting resources for this.

Google has 2 language projects they really put money on, Javascript as V8 and Dart. They built a top notch specialist team, spent lots of money for promotion and branding, built an IDE and developer tools for both, etc.

Apple has had Obj-C and now Swift like that, MS has C#, etc. Those are language projects with a big weight of the companies behind them.

Golang was not like that, but, according to all official accounts and recollections, a grassroots project, by a small team:

"Robert Griesemer, Rob Pike and Ken Thompson started sketching the goals for a new language on the white board on September 21, 2007. Within a few days the goals had settled into a plan to do something and a fair idea of what it would be. Design continued part-time in parallel with unrelated work. By January 2008, Ken had started work on a compiler with which to explore ideas; it generated C code as its output. By mid-year the language had become a full-time project and had settled enough to attempt a production compiler. In May 2008, Ian Taylor independently started on a GCC front end for Go using the draft specification. Russ Cox joined in late 2008 and helped move the language and libraries from prototype to reality."

It was never officially intended to be "Google's development language" or had a major push from Google. Since then, and after the first few years, Google seems to have devoted more money and time to Go, and several Google internal projects have adopted it, but Google is fine with C++, Java, and Python as well.

It's not that hard to imagine. Dropbox has talked about using Rust over Go for storage because cpu/memory efficiency was considerably better (4x if I recall) in Rust.

Yes, that is why Google mostly uses Java and C++ instead.

isn't the same idea exactly covered by the term "(de)coupled"?

This presentation had an outsize influence on my professional development as a programmer. If I've watched it once (and I have), I've watched it a dozen times.

edit: The "Limits" slide (go to 12:30 in the vid) is one that I really internalized early on. And looking at it again years later, the principles from that slide absolutely guide my app development:

- We can only hope to make reliable those things we can understand

- We can only consider a few things at a time

- Intertwined things must be considered together

- Complexity undermines understanding

All the popular languages from last gen, did not have non-nullable types.

> The C# one was faster then Go

As pointed out over here (https://news.ycombinator.com/item?id=20984503), Compared to C#, Go was faster (higher throughput) for smaller batch sizes, and it always had significantly lower latency.

.NET Core is particularly good these days, so I'm sure there are times when C# is definitely faster than Go, but the network driver isn't a great example to support that.

[Another] keen observation on that network driver thread is performance is bound by memory copying. For which Java, C#, etc. can all be about the same.

FWIW:

Back in ~1998, I wrote a VRML browser that was faster (FPS and event loop) than Sony's. Benchmarks showed Sony's was then the fastest (publicly available). They used 'C'. I used Java (JDK 1.2). We both used same OpenGL stack.

Same kind of deal as a network stack. Most of FPS was due the graphics card and use of OpenGL. Java's JNI added a minor performance penalty.

As for the all the other stuff, like reading files, parsing, user interface, I just figured Sony's VRML team sucked (worse than me).

Update: Others made the point about latencies.

What do you miss in the standard library?

Fwiw, Rust attempts, by design, to not be batteries included, as this would tie Rust to specific architectures, or operating systems – or even require Rust code to run on an operating system, which doesn't have to be the case.

So, yeah, as a Rust dev, I pretty much always rely upon external crates. But hey, that's what they're here for :)

That's a good point. I suppose "usefulness" in today's world reflects the kind of problems being solved today. eg Java had CORBA support for years, just because in the late 90s, distributed objects were going to be a thing. XML/WS support is still there, but it took a while to get JSON/REST, etc.

If you want to remove stdlib packages, I guess you would need Go to ship a tool that automatically rewrites sources to point those package imports to a standard "golang/x" location (or something) that provides the same package.

Or alternatively, some kind of indirection via the go.mod file.

In my experience, the multiple-return `, err` convention and the `:=` syntax sugar are constantly clashing. It's confusing because the `err` is reused, but still has to be created at some point; and because `:=` is allowed even if only one variable is being created, but forbidden if you're only assigning.

It doesn't always lead to a bug, but it's always frustrating. Even when restricting the problem to a single (non-error) return value, there are 6 combinations to consider:

* What do you do with the non-error return value? (none/assign/create)

* Is it the first time you've checked an error? (yes/no)

   none, yes    |    err := f()
   none, no     |    err = f()
   assign, yes  |    var err error; r, err = f()
   assign, no   |    r, err = f()
   create, yes  |    r, err := f()
   create, no   |    r, err := f()

The shadowing case comes up infrequently enough to surprise you when it does. You've been trained by the other examples to change `=` to `:=` when you see a certain error, and you don't always get a warning about the shadow this creates.

Compile-time memory safety by default.

Arguably, the point is precisely that Rust lacks features that C++ has which make C++ not as good as it could be at replacing C.

(1) Memory safety guarantees through the ownership model, a clear delineation of unsafe code that doesn't follow it. Also, no UD.

(2) Both Rust and C++ can be used to write most / all of the code that can be written in C, at a zero runtime cost. Their difference is in ergonomics, safety features, ecosystem maturity, etc.

Memory safety?

C++ has lots of bells and whistles, some of which Rust doesn't have (classes, to name one), but those aren't necessarily more important bells and whistles.

Also, the Rust infrastructure is light-years ahead of linking in libraries in C/C++. Compile times are higher, but not horribly so.

I don't think the parent was saying you can use Rust anywhere you can't use C++. I think they were saying, Rust is not only a good C++ alternative, but also a good C alternative.

This is a good question, and it's a shame that none of the responses so far answer it.

Rust has put more effort than C++ into figuring out how much of the standard library can be used in "freestanding environments" (to borrow the C terminology). C++ without exceptions, RTTI, and the standard library is already a pretty effective C replacement.

The other "feature" that C++ has in this space is that it has a bad reputation as far as the C stalwarts are concerned, whereas Rust has not gained that reputation.

Assuming GP's post was not edited, I don't see where it implies that Rust can be used as a C replacement where C++ can't.

C++ isn't very homogenous in the features that people use. I was speaking more to the fact that one can use Rust in situations where C traditionally dominates. OS's, embedded development. It's memory safety model allows you to section off unsafe code and craft safe interfaces while still operating on the bare metal. Like sibling comments mentioned, no_std is pretty great too.

I think it's fascinating that someone could look at those graphs and come away with the conclusion that c# is an order of magnitude faster than go.

As if you have a choice to not use pure Go code, it doesn't play nice with C.

C# had to use C code due to lack of .NET knowledge of the authors as discussed on the other thread.

GUI is definitely an open problem in Rust, but to be fair, cross platform GUI is hard. In all of programming, it seems that Qt is about the best that we have when it comes to cross platform GUI, and I don't think most Rust developers care enough about Windows to write and maintain native Windows-only GUI libraries. C# (or I guess F# or any of the other .NET languages) is definitely a better fit for Windows UI programming.

Go is garbage-collected just like .NET.

Rust indeed always pushes you towards efficiency :)

And yet Go programmers are often happy.

I think the reason is: Go code has a low level of abstraction-construction and a high level of explicitly writing the algorithm. You can see through the language, which is "boring" and does not distract your attention, to what it is trying to achieve, which is interesting.

> I'm probably going to choose something which is more fun to write.

Fun-to-write code isn't always that great to read; and your code will probably be read more times than it was written. I get it - I wrote Perl applications in a previous lifetime and I had fun doing it (Perl's text manipulation is unparalleled): until it was time to grok something a teammate wrote. I appreciate that Go is 'boring'

OTP release tarballs aren't much harder to deploy than static binaries :)

Elixir doesn't need to "cross compile" because its only compile target is BEAM. That's like saying "Java doesn't cross-compile".

But how something is deployed is often not the job of the code author, as deployment has become its own technical craft. The argument should largely go to whether a tool can fit the domain given typical resource constraints (team size), not whether you get a static binary.

Not shootable in the foot in terms of pointer arithmetic, but shootable in the foot in terms of unchecked dereferences of nil. As a C++ programmer historically, I think of references as not being nilable.