161–170 of 211 posts
I'm sorry to hear that. Go is not revolutionary (unless you count "completely ignoring runtime errors" to be revolutionary). If anything, functional languages are the new, old, revolutionary thing.
Earlier quoted context omitted.
whoa!! this is huge - can you talk a bit more about your stack please. This is the first time I have heard something like this - what libraries, code style, etc would get you the same "feel" as clojure ?
I'm assuming Lombok and using the new Lambdas. Maybe even a fibers library.
Earlier quoted context omitted.
If the constrained hardware is more powerful than a Xerox PARC Dorado (Mesa/Cedar), a ETHZ Ceres Workstation (Oberon), DEC Firefly (Modula-3), then Go is certainly a better C. Nothing prevents you to make use of statically allocated data structures, hands off from the GC if really needed. In spite of lacking a few features that I consider any modern language should have, ability to create memory friendly data structu…
> Nothing prevents you to make use of statically allocated data structures, hands off from the GC if really needed. Only if you give up closures, interfaces, defer, strings, the entire standard library, and all sorts of other things that don't immediately come to mind. Programming without the GC in Go is technically possible, but impractical. The language just wasn't designed for that (and this isn't a knock against…
We can use the GC for the 90% of the code that isn't performance critical, enjoying the programming productivity of using a GC enabled language.
After profiling the application and find out where those 10% performance/memory critical hotspots are, re-architect the data structures to use static allocation, either via the stack (compiling with escape analysis validation) or the global memory. Or even doing off-GC Heap allocation via syscalls.
Then make use of pointers or array indexes to access the static allocated data.
Plenty of examples in Modula-3, Oberon, Mesa/Cedar research papers.
There are plenty of languages that I would rather use for systems programming instead of Go, but the language is certainly capable of being used in the same scenarios as Oberon.
For example Astrobe, which sells bare metal Oberon compilers for ARM Cortex-M4, Cortex-M3 and Xilinx FPGA Systems.
If anything, comparing Oberon's SYSTEM with Go's unsafe packages, Go could use a few more intrinsics like CPU register access, but those as also doable with a bit of Assembly help. Which ANSI C also doesn't support.
My goal is just creating awareness that alternatives are possible, it doesn't need to be always C.
I'm sorry to hear that. Go is not revolutionary (unless you count "completely ignoring runtime errors" to be revolutionary). If anything, functional languages are the new, old, revolutionary thing.
You're "sorry to hear" that he got a great job doing something he's excited and passionate about? Wow.
Earlier quoted context omitted.
My coworkers are savvy enough to handle those features.
Then you are a very lucky person. For the rest of us, it is very good to have a manageable language at hand.
Earlier quoted context omitted.
You're "sorry to hear" that he got a great job doing something he's excited and passionate about? Wow.
Funny how taking things out of context can change the meaning. If you look at the second sentence, you can infer what the first one is about.
I'm joining the Go team at Google
Sorry to hear that
Go is not revolutionary...Earlier quoted context omitted.
Dave Cheney gave a talk about error handling in Go that sheds some light on how the Go community thinks about errors: https://www.youtube.com/watch?v=lsBF58Q-DnY
I watched this, and what I saw was a heck of a lot of information about how to extract information from error values and percolate them together up to a handler, all of which would automatically be present in your everyday stack trace in a language that actually threw unexpected runtime errors. ;) I frankly don't see how this is OK, nor better. Errors are real in the sense that they are evidence that the programmer's…
Earlier quoted context omitted.
Funny how taking things out of context can change the meaning. If you look at the second sentence, you can infer what the first one is about.
Not really. It's a top-level comment. If it were a reply to the "in what way is Go revolutionary" comment, the "sorry to hear that" could reasonably be inferred to mean "sorry, but..." I'm joining the Go team at Google Sorry to hear that Go is not revolutionary...
> Not really.
I can assure you that it is indeed funny.
> As I had before, I recognized that this technology had the potential to revolutionize how software was written at a fundamental level. Congrats and all, and I love Hugo (use it all the time). That said, I think the kool-aid was spiked with something. Sorry, but in what way is Go "revolutionizing"? I'd buy "refreshing simplicity" and "yay, static builds again" but it's hardly revolutionary, even in its most touted f…
Go's big success, in my opinion, was to fuse the lightweight, spawn a million threads we don't care, style of programming to conventional imperative, conventional static-type programming. I know of several other runtimes that had that lightweight threading capability, I've been using them since years before Go was even a thing, but they all required programmers to learn a new paradigm. At times, a radically new parad…
I'm ok with the Algol part as it pertains to syntax.
Semantics and expression though, is another thing...
> As I had before, I recognized that this technology had the potential to revolutionize how software was written at a fundamental level. Congrats and all, and I love Hugo (use it all the time). That said, I think the kool-aid was spiked with something. Sorry, but in what way is Go "revolutionizing"? I'd buy "refreshing simplicity" and "yay, static builds again" but it's hardly revolutionary, even in its most touted f…
>Sorry, but in what way is Go "revolutionizing"? By offering simplicity. Taking a step back to before C++. And providing a better C. C + strings + GC + map + slice(array) + json/xml parsing + http transport layer (server & client). What else do you need ? Ideal for minimalists. That's its beauty. Programs are very stable. Takes less memory than Java (some amount more than C/C++). Faster compilation time compared to C…
Language consistency (no magical functions like "make" or magical items like slices), DRYness (generics), better type-safety than C (interface{} is the void * of the 21st century), would be a good start.
Due to the mandatory GC, it's also not a C replacement where C is good at. Hence the backtrack on "systems", etc.