6 ms·

What is the benefit of this? I was under the impression that go isn't that far off from rust on most speed metrics being both compiled. So this adds complexity

by Havoc 2y ago

What is the benefit of this? I was under the impression that go isn't that far off from rust on most speed metrics being both compiled. So this adds complexity for what gain?

Yoric 2y ago
In benchmarks I've seen, Go is ~6 times slower. But generally speaking, the reason I prefer Rust to Go for most developments is its type system. I could see myself using Rust to handle business-specific/safety-critical logic and Go as a fast prototyping language to assemble them.
- dewey 2y ago
  What part of the Go typing system is lacking for "business-specific/safety-critical logic"?
  - randomdata 2y ago
    It lacks expressiveness, which means you actually have to put some thought into your design to avoid butting heads with it. You can't throw up garbage and then keep massaging the types until you can make whatever gobbledygook you came up with fit. Business/safety critical logic tends to get complicated, and, at least in the case of business software, is more than likely is venturing into unexplored territory, so when you're not very skilled at programming finding the right design can become an insurmountable challenge. A more expressive type system offers a bandaid to work around that.
    - mr90210 2y ago
      [flagged]
      - randomdata 2y ago
        Strictly speaking, that is true. Even the worst code ever written had some thought put into it. But the "actually put some thought" was meant to imply more than putting down the first characters that spew out; to consider the design more holistically and carefully. But you are right to not take anything that software says seriously. Seriousness is for interactions with humans.
    - smodo 2y ago
      A bit of cart-horse-y reasoning…. An expressive type system helps me to model the nuances that are actually present in the business logic. If I simplify or restructure my model more than real life allows for I would say that causes much more trouble than actually modeling what’s happening on the ground. Yes, when I’m behind my desk I always find ways to make the business logic better and simpler and more fitting. But those damn humans never follow my rules.
  - kbolino 2y ago
    Go doesn't have any closed or sealed types. An "enum" is just a subtype and subtypes can't restrict the range of their values. It's possible to have something like a closed tagged union using an interface with an unexported method and type-switching, but the language won't understand this for e.g. detecting whether a switch without default is exhaustive. There's also no way to declare a non-nil pointer nor to work cleanly with nested nil-able struct fields.
    - pjmlp 2y ago
      Go's enums aren't even something to talk about when compared with classical Pascal enumerations. Naturally this is much better to type, type Weekdays int const ( Monday Weekdays = iota Tuesday Wednesday Thursday Friday Saturday Sunday ) than something like this, type Weekdays = (Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday) /s
  - Yoric 2y ago
    I wasn't planning to turn this into a language flame war, so I'm not going to give details. Let's just say that the designers of Rust and Go have prioritized very different feature sets when designing their type systems. If you develop in Rust, it's typically because you want to write "fearless code", i.e. attach sophisticated invariants to types to avoid safety issues later in development/coming from client code. If you develop in Go, it's typically because you want "productivity", i.e. reach quickly a point where you code can run and you can start testing it. As usual, it's a tradeoff. For most tasks, I happen to click better with the former. YMMV
null_investor 2y ago
That's widely incorrect, Rust and C are like 2-5x faster than Go? Go has arguably a better concurrency model, so for some usecases it can work much better, but for some realtime programming stuff, Go is a no-go ba-dum-tss. For webdev I would never chose Rust over Go, each language has their own advantage.
- lionkor 2y ago
  Go's concurrency model lets you just access the same mutable variable from multiple goroutines - that kind of "good model" you can also get with C and some implementation of channels and green threads.
  - brightball 2y ago
    It still offers good structures to help you be careful in these situations, but you’re right. It’s not as complete of a concurrency model as BEAM languages.
  - null_investor 2y ago
    Yes, but having coded in both languages you can see how Go's concurrency system works well with it and fits neatly. Try using async in Rust and you'll see what I mean, it sucks to use it. The same applies to cpp, you'll need years and years of experience to write somewhat decent cpp what you can write in Go with a few weeks learning coroutines, and will still be prone to make mistakes. I've done lots of cpp and can affirm that after decades I'm still not sure if my concurrent solution will run as well as my half-assed Go coroutine code. Go coroutines is a good abstraction that is very fitting to the language, similar to the actor model and the BEAM VM (erlang/elixir). Use the same abstraction in another language (like JVM or C) and you'll see how the devex makes a huge difference.
    - littlestymaar 2y ago
      I'd chose async/await over threads any day, and many people do too, that's why this construct has gained so much popularity in many different languages. Async/await is a rare example in PL design where a new concept is implemented in one language and then adopted by many in the following years. In fact, the “threads are more ergonomic than async/await” seems to be more of an HN meme than a popular opinion in the wild. (And please don't quote What color is your function since it's mostly a rant about callback-based concurrency which everyone agree it sucks).
aranw 2y ago
The benefit isn't necessarily for speed there are some libraries for example available in Rust that are not in Go. This is something I am exploring at the moment rather than having to totally rewrite the library in Go
gkbrk 2y ago
> go isn't that far off from rust on most speed metrics being both compiled The only way I see this happening for the same code snippet is if the Rust code was being compiled in debug mode instead of release mode.
deleted 2y ago
[deleted]
Kinrany 2y ago
Libraries can be written once and then used in both languages.
afdbcreid 2y ago
Allocating is much easier in Go and much harder to eliminate in it, for example. Also, for some kinds of code (usually not CRUD), LLVM does better job than the Go compiler. And if you do concurrency, Rust's async await can be faster than Go's approach (but it is a lot more complicated, and the perf gain usually doesn't matter).

by Havoc 2y ago

What is the benefit of this? I was under the impression that go isn't that far off from rust on most speed metrics being both compiled. So this adds complexity for what gain?

Yoric 2y ago

In benchmarks I've seen, Go is ~6 times slower. But generally speaking, the reason I prefer Rust to Go for most developments is its type system. I could see myself using Rust to handle business-specific/safety-critical logic and Go as a fast prototyping language to assemble them.

dewey 2y ago
What part of the Go typing system is lacking for "business-specific/safety-critical logic"?
- randomdata 2y ago
  It lacks expressiveness, which means you actually have to put some thought into your design to avoid butting heads with it. You can't throw up garbage and then keep massaging the types until you can make whatever gobbledygook you came up with fit. Business/safety critical logic tends to get complicated, and, at least in the case of business software, is more than likely is venturing into unexplored territory, so when you're not very skilled at programming finding the right design can become an insurmountable challenge. A more expressive type system offers a bandaid to work around that.
  - mr90210 2y ago
    [flagged]
    - randomdata 2y ago
      Strictly speaking, that is true. Even the worst code ever written had some thought put into it. But the "actually put some thought" was meant to imply more than putting down the first characters that spew out; to consider the design more holistically and carefully. But you are right to not take anything that software says seriously. Seriousness is for interactions with humans.
  - smodo 2y ago
    A bit of cart-horse-y reasoning…. An expressive type system helps me to model the nuances that are actually present in the business logic. If I simplify or restructure my model more than real life allows for I would say that causes much more trouble than actually modeling what’s happening on the ground. Yes, when I’m behind my desk I always find ways to make the business logic better and simpler and more fitting. But those damn humans never follow my rules.
- kbolino 2y ago
  Go doesn't have any closed or sealed types. An "enum" is just a subtype and subtypes can't restrict the range of their values. It's possible to have something like a closed tagged union using an interface with an unexported method and type-switching, but the language won't understand this for e.g. detecting whether a switch without default is exhaustive. There's also no way to declare a non-nil pointer nor to work cleanly with nested nil-able struct fields.
  - pjmlp 2y ago
    Go's enums aren't even something to talk about when compared with classical Pascal enumerations. Naturally this is much better to type, type Weekdays int const ( Monday Weekdays = iota Tuesday Wednesday Thursday Friday Saturday Sunday ) than something like this, type Weekdays = (Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday) /s
- Yoric 2y ago
  I wasn't planning to turn this into a language flame war, so I'm not going to give details. Let's just say that the designers of Rust and Go have prioritized very different feature sets when designing their type systems. If you develop in Rust, it's typically because you want to write "fearless code", i.e. attach sophisticated invariants to types to avoid safety issues later in development/coming from client code. If you develop in Go, it's typically because you want "productivity", i.e. reach quickly a point where you code can run and you can start testing it. As usual, it's a tradeoff. For most tasks, I happen to click better with the former. YMMV

null_investor 2y ago

That's widely incorrect, Rust and C are like 2-5x faster than Go? Go has arguably a better concurrency model, so for some usecases it can work much better, but for some realtime programming stuff, Go is a no-go ba-dum-tss. For webdev I would never chose Rust over Go, each language has their own advantage.

lionkor 2y ago
Go's concurrency model lets you just access the same mutable variable from multiple goroutines - that kind of "good model" you can also get with C and some implementation of channels and green threads.
- brightball 2y ago
  It still offers good structures to help you be careful in these situations, but you’re right. It’s not as complete of a concurrency model as BEAM languages.
- null_investor 2y ago
  Yes, but having coded in both languages you can see how Go's concurrency system works well with it and fits neatly. Try using async in Rust and you'll see what I mean, it sucks to use it. The same applies to cpp, you'll need years and years of experience to write somewhat decent cpp what you can write in Go with a few weeks learning coroutines, and will still be prone to make mistakes. I've done lots of cpp and can affirm that after decades I'm still not sure if my concurrent solution will run as well as my half-assed Go coroutine code. Go coroutines is a good abstraction that is very fitting to the language, similar to the actor model and the BEAM VM (erlang/elixir). Use the same abstraction in another language (like JVM or C) and you'll see how the devex makes a huge difference.
  - littlestymaar 2y ago
    I'd chose async/await over threads any day, and many people do too, that's why this construct has gained so much popularity in many different languages. Async/await is a rare example in PL design where a new concept is implemented in one language and then adopted by many in the following years. In fact, the “threads are more ergonomic than async/await” seems to be more of an HN meme than a popular opinion in the wild. (And please don't quote What color is your function since it's mostly a rant about callback-based concurrency which everyone agree it sucks).

aranw 2y ago

The benefit isn't necessarily for speed there are some libraries for example available in Rust that are not in Go. This is something I am exploring at the moment rather than having to totally rewrite the library in Go

gkbrk 2y ago

> go isn't that far off from rust on most speed metrics being both compiled The only way I see this happening for the same code snippet is if the Rust code was being compiled in debug mode instead of release mode.

deleted 2y ago

[deleted]

Kinrany 2y ago

Libraries can be written once and then used in both languages.

afdbcreid 2y ago

Allocating is much easier in Go and much harder to eliminate in it, for example. Also, for some kinds of code (usually not CRUD), LLVM does better job than the Go compiler. And if you do concurrency, Rust's async await can be faster than Go's approach (but it is a lot more complicated, and the perf gain usually doesn't matter).