4 ms·

At risk of derailment isn’t this a much better fit for Rust? I am saying this as someone who has used both extensively professionally and prefer Go in most case

by klabb3 3y ago

At risk of derailment isn’t this a much better fit for Rust? I am saying this as someone who has used both extensively professionally and prefer Go in most cases. If you’re dropping GC, then RAII is extremely useful (which Go doesn’t have). If you’re dropping runtime concurrency, Go’s (subjectively) strong multitasking, cancelation, timeouts go away. And finally, if you’re dropping std, which is perhaps the strongest suit of Go, then what are the remaining strengths of Go vs Rust? Tooling? Compile time speed? TLDR a simple subset of Rust (enums, pattern matching, RAII, etc) sounds appealing, but a simple subset of Go seems quite… limiting. That said, I’m not an embedded programmer.

Leotard6963 3y ago
> dropping GC, dropping runtime concurrency Making GC/goroutine optional & customizable requires building a std works with no GC/goroutine. > dropping std relax, this is a new std, let's spare the baby some hope?
- mst 3y ago
  > Making GC/goroutine optional & customizable requires building a std works with no GC/goroutine. Right. You've picked a goal that require you to do some hard things to make that goal even possible. OTOH even if you never reach the -final- goal, making any of those hard things work would be an achievement. The only way to find out is to try. So: Good luck!
  - Leotard6963 3y ago
    Thanks, but the actually hard things are done by the Go team, the design of the interface type and availability of runtime type information made it relatively easy to complete that final goal, but let's go find out!
- klabb3 3y ago
  > Making GC/goroutine optional & customizable requires building a std works with no GC/goroutine. Isn’t there a big difference between customizable, ie changing the runtime backend, vs NO runtime where goroutines and GC don’t work at all? In the latter case, you’d have to write very different, restricted Go code, no? And you’d even have to add some new features for manual memory reclaim? > relax, this is a new std, let's spare the baby some hope? Yeah, depends on what hat you put on. I wrote it wearing the “when would someone use something like this?”-hat. I don’t claim to know one way or the other.
  - Leotard6963 3y ago
    [dead]
deleted 3y ago
[deleted]

by klabb3 3y ago

Leotard6963 3y ago

> dropping GC, dropping runtime concurrency Making GC/goroutine optional & customizable requires building a std works with no GC/goroutine. > dropping std relax, this is a new std, let's spare the baby some hope?

mst 3y ago
> Making GC/goroutine optional & customizable requires building a std works with no GC/goroutine. Right. You've picked a goal that require you to do some hard things to make that goal even possible. OTOH even if you never reach the -final- goal, making any of those hard things work would be an achievement. The only way to find out is to try. So: Good luck!
- Leotard6963 3y ago
  Thanks, but the actually hard things are done by the Go team, the design of the interface type and availability of runtime type information made it relatively easy to complete that final goal, but let's go find out!
klabb3 3y ago
> Making GC/goroutine optional & customizable requires building a std works with no GC/goroutine. Isn’t there a big difference between customizable, ie changing the runtime backend, vs NO runtime where goroutines and GC don’t work at all? In the latter case, you’d have to write very different, restricted Go code, no? And you’d even have to add some new features for manual memory reclaim? > relax, this is a new std, let's spare the baby some hope? Yeah, depends on what hat you put on. I wrote it wearing the “when would someone use something like this?”-hat. I don’t claim to know one way or the other.
- Leotard6963 3y ago
  [dead]

deleted 3y ago

[deleted]