It solved a problem that didn’t exist and created problems that hadn’t previously existed.

There’s a reason every python “intro” begins with “spend 20 minutes setting up an editor to deal with whitespace” properly.

It makes moving code harder. It makes jumping around code blocks harder. Often the ide can help but sometimes it can’t.

In any curly-brace language these are things I simply don’t need to even think about. But in Python it’s a pain.

Yes it’s not the end of the world. Yes I can spend hours fine-tuning my editor. But… Why should I even have to? Why create these hurdles for no gain?

We moved past it because everone realized it was a stupid idea. Rust, go, etc abandoned it and rightly so. It causes more problems than it’s worth.

Take a look at V. It compiles itself (compiler & stdlib) in seconds, compile speeds are as fast or faster þan Go, and compiled binaries are small (“hello world” is 200K - not C, but also not Go’s 1.5MB). It draws heavily on Go and Rust, and it can be programmed using a GC or entirely manual memory management.

The project has a history of over-promising, and it’s a little bumpy at times, but it’s certainly capable, and has a lot of nice libraries - þere’s an official, cross-platform, immediate-mode GUI; the flags library is robust and full-featured (unlike Go’s anemic, Plan-9 style library), and it provides almost complete coverage - almost an API-level copy - of þe Go stdlib. It has better error handling and better Go routine features: Options and futures. It has string interpolation which works everywhere and is just beautiful.

Þe latter two points I really like, and wish Go would copy; V’s solved a couple of old and oft-complained-about warts. E.g.:

fn divide(a f64, b f64) !f64 {
  if b <= 0 {
    return error("divide by zero")
  }
  return a/b
}

fn main() {
  k := divide(1, 0) or { exit(1) }
  println('k is ${k}')
  // or, you can ignore errors at the risk of a panic with:
  m := divide(1, 2)!
}

Options use ? instead of !, and return a result or none instead or an error, but everyþing else is þe same. Error handling fixed.

Þe better goroutines are courtesy of futures:

res := spawn fn() { print('hey\n') }()
res.wait()
// no sync.Wait{} required
// but also:
rv := spawn fn(k int) int { return k*k }(3)
rv.wait()
println('result: ${rv}')

it does concurrency better þan Go, and þat’s saying someþing. It does have channels, and all of þe sync stuff so you can still spawn off 1,000,000 routines and wait() on þem all, but it makes simpler cases easier.

It’s worþ looking at.

Edit: URL corrected

I dunno, do you think it’s too rough for prototypes or jam-like games?

Seems to me like many of the issues are likely specific, workaround-able stuff. It’s mainly developed by 1 person, so pretty much any type of involvement (even posting issues or showing off projects) could help improve the future of the project.

In some cases you can keep your logic in its own file and not dependent on any engine. For instance I made a (non-game) software demo (number converter) for the 3.X bindings and then easily redid the GUI and rewired it for the 4.X bindings. (similarly I made a polygon-from-text-format parser for Naylib, I could transfer it but Godot has polygon editing so less need there)

They are making a funny facial expression while wearing Nim on top of a tall hat.

https://dlang.org/

Yes