51–60 of 296 posts
Still yearning for an Ocaml-like language that uses the Go runtime.
On similar lines, Fable [0] project recently announced rust & dart runtime support making F# a very attractive choice.
[0] https://fable.io/blog/2022/2022-06-06-Snake_Island_alpha.htm...
I am not a fan of new knobs like this. It reminds me of Java where you actually have to think about -xMx blah blah and setting it is a dark art. I would really prefer if we could somehow confer the memory limit from the container environment to go so this could be set intuitively at the container level without mucking about in the go GC internals.
https://developers.redhat.com/articles/2022/04/19/java-17-wh...
I really like the engineering principles in general that the Go team uses, however, I just don't like Go. That isn't meant as a slight or anything other than simply my opinion. That said, I really like the idea of a simple language based on the sort of principles demonstrated here. The runtime seems really nice, I just wish I liked the language better (IMO: not expressive enough, needs better error handling, needs mu…
I haven't found any issues with expression, so far. I wouldn't use it to write a UI, but for writing networking code or automated tasks I find it perfectly suited to the task. I appreciate it's error handling. It's burdensome, sure, but it presents almost no additional cognitive load when attempting to reason about control flow. It essentially has no enums. However, it has a comfortable type system that can wrap prim…
Earlier quoted context omitted.
I will agree Rust has a higher "cognitive load", but not if you write it every day. I think Rust might be tough to leave and come back say a year later, but Go admittedly would be easy. That said, having written 50K+ code in both languages, I never want to write Go again. Rust on the other hand is all I want to write now. I do wonder how many people who understand Go's limitations (and work around them as you point o…
The problem with rust is explicitly that cognitive load in large codebases. It is much easier to read go code than rust when working on many things. Rust fits great if you don't scale though.
Earlier quoted context omitted.
I don't understand how this is a response to every "I wish I had blank but like ocaml". Threads exist.
As does OCaml since 1996, no need for sugar substitute instead of using the real deal. Compiles to native code, has a repl, version 5 is multicore for those not happy with Lwt or multiprocessing in the UNIX classical style of each tool does one thing, and a GC only second to GHC in handling immutable types.
I'm excited for version 5, but until it's out, it's hard for people to take seriously in conversations about _Go_ of all things.
Not trying to be inflammatory but has the pclntab taking ~30% for binary size been fixed yet? IMO it's a pretty severe design choice.
> IMO it's a pretty severe design choice. I don't think that's true, otherwise it would've been fixed already. For the main use case of Go ( https://go.dev/blog/survey2022-q2-results ), APIs and web services it just doesn't matter if the binary is 1MB or 30MB. Unless you are working on some embedded systems where space is scarce I don't see it as a big issue.
- Pull the prod image to my laptop in ~1 sec vs. pull the image in 10ish seconds
- CI build and push the image instantly vs. ~2-3+ seconds
- Long-term (1y+) retention of per-pipeline/push artifacts vs. per-branch/tag artifacts.
- All images in each node's cache vs. 50% of images in each node's cache.
Yeah, I don't really give a shit about the 30MB once it's out there. But there's also all the steps to get it / keep it out there.
Earlier quoted context omitted.
> In the end I think if someone were to write a slightly simpler version of Rust with the Go runtime it might be pretty neat. OCaml kind of gives you that, but the dev experience isn't as good as Rust or Go in my opinion. Still, I enjoy it a lot, more than Go or Rust.
Agreed - I really like OCaml. Unfortunately it isn't popular enough to get tons of ecosystem love, so I could never find the libraries I need. I'd be pretty happy if it got more popular. Maybe the new multicore work will help.
I am not a fan of new knobs like this. It reminds me of Java where you actually have to think about -xMx blah blah and setting it is a dark art. I would really prefer if we could somehow confer the memory limit from the container environment to go so this could be set intuitively at the container level without mucking about in the go GC internals.
And on the other hand, it's a simple flag. They added one memory flag in over a decade. I think they're holding the line on complexity pretty well?
I really like the engineering principles in general that the Go team uses, however, I just don't like Go. That isn't meant as a slight or anything other than simply my opinion. That said, I really like the idea of a simple language based on the sort of principles demonstrated here. The runtime seems really nice, I just wish I liked the language better (IMO: not expressive enough, needs better error handling, needs mu…
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 love writing lisp, but I hate reading & debugging lisp.