231–240 of 296 posts
Earlier quoted context omitted.
> However, (stable) OCaml not having multithreading support is still a gigantic limitation. OCaml 5 still seems a lot more real and coming-sooner than the imaginary OCaml-on-Go. Sure, it's not ideal that multicore OCaml isn't yet stable, but it does exist, and will become stable.
Absolutely - I was only replying to the question of why you may want this in principle.
Earlier quoted context omitted.
> remember to manually call destructors to be quite hard, be they C or Go or JavaScript I thought JacaScript doesn’t have destructors (in the memory/resource management sense) or finalizers…
File handle destructor: https://nodejs.org/api/fs.html#filehandleclose WebSocket's destructor: https://developer.mozilla.org/en-US/docs/Web/API/WebSocket/c... HTTP server's destructor: https://nodejs.org/api/http.html#serverclosecallback Etc etc etc. You're right that JS/C/Go don't have language features called destructors, but they have a whole bunch of types with ad-hoc destructor functions which you have to rememb…
Love go as a platform.. self contained binaries have been a miracle for ops..but have a few big hangups about using the language full time because of the sucky ergonomics. * No optional/named parameters. Writing a whole function per parameter for function chaining is excessive. This would not be difficult to add to the compiler (i've done it and have seriously considered using the fork) but it seems like the team is…
I think if Golang would have been invented a couple of years later it def would have had sum types. But then, Rust probably wouldn’t have had its insane tooling that is most likely inspired by golang
How to combine sum types and a precise garbage collector?
Earlier quoted context omitted.
So if GetFoo returned a non-nil error, would the function abort and immediately return the error? I'm used to a question mark being around null handling, but you know, JVM languages lol, null is thought about a lot.
Yeah exactly, it makes everything so much more ergonomic, especially with combinators, as in chaining method calls that might return an error
Go is an experiment in the exactly opposite direction: language puts pressure to really handle the error in a meaningful way every time. And if you bubble up, at least describe the situation a little bit better. Or explicitly give up and receive a penalty for that: the `return err` is nothing to be proud of, it's just a visual penalty for _lack_ of error handling.
I'm not saying it's better in every project, I'm saying it's valuable on some projects.
Earlier quoted context omitted.
That’s probably because you’re not used to it. I think it’s common knowledge that Golang is easy to read.
Couldn't the same be said of rust though? The biggest barrier, in my experience, is almost always familiarity with the syntax.
I think my comfort with Rust moreso comes from it feeling like any other C-ish language in appearance. It reads as expected to me.
Earlier quoted context omitted.
Async code is way nicer in Go than it is in Rust. It makes up for a lot for me when writing web services. Also Go is much easier to read vs Rust.
>Also Go is much easier to read vs Rust. This is subjective - I for example have no real issues reading Rust code, but find Go to look like utter spaghetti on the screen.
Earlier quoted context omitted.
> needs better error handling First it would need to add error handling before it could look to improve upon it. I'm not entirely convinced it should. I spend my days in a variety of other languages that have added error handling in various ways and, in my experience, it always ends up making errors unnecessarily difficult to do deal with. I regularly wish the idioms of those languages recognized errors as being core…
Just make it so: varFoo, err := GetFoo() if err != nil { return err } Can be written as: varFoo := GetFoo()? Just like Rust, everyone would stop complaining about Go error handling. But they have this absolutist position on syntactic sugar, even for something like this that would make the language that much nicer to look at and work with.
The nature and culture of Go makes it harder to change direction and be as amenable, but the merits of such conservatism is a "depends" type of thing and can mean incorporating things many years after it has become fashionable or accepted.
Earlier quoted context omitted.
V fixes most of these, but it doesn't use Go's runtime: https://vlang.io/compare#go
Quoted post unavailable.
It's one thing to like some other language, its another thing to spew disinformation, lies, and flames about others.
Earlier quoted context omitted.
This is pretty much exactly how I feel. I have great respect for the Go team. I broadly agree with their design philosophy. I think CSP is a great theory for concurrency. And I just don’t really like writing Go. I don’t hate it, but I feel like I have to either fight the language or just repeat myself an awful lot. Honestly, I suspect the deficiency is on my end. Perhaps I’ve just spent too much time with Lisp and ha…
I sorely wish CSP was enforced in any way by Go, but it's not. The only thing which arguably makes Go more "CSP-y" than, say, C++ is that it comes with a decent built-in concurrent queue and some syntax sugar. Goroutines have full mutable access to all the variables in their scope, and lots of Go code ends up being your good old mutex hell -- just more of it, since threads are so easy to create. I think something way…
Earlier quoted context omitted.
V fixes most of these, but it doesn't use Go's runtime: https://vlang.io/compare#go
It also doesn’t work :)
Watch, learn, download, and enjoy this V program (https://youtu.be/6H7dprSwr74), among so many other examples (https://github.com/vlang/V/tree/master/examples).