I always found languages which require you to always remember to manually call destructors to be quite hard, be they C or Go or JavaScript, when the system has lots of moving parts and performance is a concern. A single mistake and you're leaking.
> 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…
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 remember to call if you want to avoid leaking resources.
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 get that everyone has their own favorite tools, but "use a version that isn't out yet, or use separate processes for parallelism" is a non-answer. 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.
It is more powerful than Go on every sense, and I really don't get what people think using Go runtime into a completly different language would help.
Maybe they should spend more attention in their compiler design classes regarding runtime implementations and language semantics.
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…
Rust has set the bar so high that it’s going to be hard for other languages to justify their use. If I had to make a bet, I’d say Typescript will take over for everything not performance critical and Rust will fit in every spot that either requires high quality assurance or high performance.
Rust users don't even register as a rounding error in the grand scheme of things. Don't get me wrong, I like Rust _the idea_. But to suggest Rust in it's current form, managed by it's current team, will be anything but a niche language for performance and safety critical corner cases is deluding yourself. The vast, vast, vast majority of programming to this day is still maintaining perfectly functional (but old) C++/Java/C/C# code bases. Anything overthrowing those thrones has to be both easy and better. Rust only fills one of these tasks. Go is far more popular because of the lower cognitive load, comparable speed, and relative ease at which you can become productive. Go won't replace Rust and comparing them is wrong. Go will, however, always be more popular than Rust. At least until Rust is adopted and supported by more major companies, used in major roles, and expands beyond it's niche.
Still yearning for an Ocaml-like language that uses the Go runtime.
go runtime is not VM like JVM [0]. Go doesn't run on top of runtime, more like run along side it. That's why there's go for embedded where it has no runtime. So it's very less likely other language reuse go runtime. [0] https://go.dev/doc/faq#runtime
There are also bare metal JVMs for embedded development, here are the two best ones.
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.
No one really care about binary size increase , especially because you can run a Go binary in a docker image with 0 dependencies ( scratch image ) which has a very small size.
That's not true. I've warmed up a lot to Go over the last 6 months. I enjoy writing it and I find it useful. However, it still frustrates me that the base binary size is something like 15 MB. That being said, if you add a bunch of static linking into a C++ or Rust app the sizes may be comparable. But because Go frontloads so much stuff with it's forced static linking the binary sizes can become unruly.
You can imagine transfer costs in a CDN, storage, etc all mattering in the edge cases. Not everyone would have this problem but if your Go app is sufficiently popular and you need to distribute it you may see this as a problem.
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…
For me error handling adds a significant distraction due to high vertical space consumption leading to a lot of extra scrolling.
I wished Go formatter would compress
if err {
return err
}
to
if err { return err }
Even better would be to extend the syntax to allow
It's not about refactoring for me. It's about trying to grok what the heck some library author or coworker was thinking when they went all Architecture Astronaut with the type system and traits. It reminds me of how people go crazy with OO and end up with delegation spread across several files. I already have to hold the problem in my head. I find that Go takes such a mental load off my shoulders that I find it the e…
That's fair. In my mind, they're at least related: if I'm trying to learn about some code, I change stuff and see what breaks.
Just as parent, my greatest struggle with learning Rust is to open someone else's code and trying to understand what is going on. With C that's a lot easier.
I you were to learn Rust from scratch, what project would you recommend for the "changing and breaking" approach?
Plugins for a compiled binary are just plain hard. Changing the code works better with an interpreted language. Usually you see the software implement it's own interpreter or a scripting language on top to handle this.
Plugins for ELF- and Mach-O-based systems aren't any different than regular shared libraries, modulo slightly different symbol precedence. AFAIU, while a quite different architecture, Windows PE linking treats them quite similarly, too. Perhaps you meant statically compiled binaries? Even then I'm not so sure about that. Right now I'm working on a project that statically compiles a plugin so its various libraries can…
Beyond linking it is also a problem with ABI compatibility of object layouts, etc. It is so much simpler with more dynamic languages.
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 used to dislike it too, but after being “forced” to use it daily (chose a job thats 100% golang on the backend), you really grow into it. It would be really, really nice to have better error handling and a bit less verbosity all around, but in terms of cost/benefit it still beats any other language I’ve worked with by a fair margin.
To get into it, it might help to start by modifying an existing project, a lot less painful than trying to write something from scratch without being familiar with the idioms.