What's your experience with Nim?

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.

@communism @FizzyOrange Sometimes you want modern features and safety without the headache that is writing Rust. Rust is a complicated language. I just want something simple without a million footguns.

I dunno I would say Lisp syntax is probably the worst option. Or APL style.

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