501–510 of 534 posts
Earlier quoted context omitted.
It's a rational practice when your language allows casting pointers to integers. Since the size of the pointer itself will vary based on the underlying architecture, you need an integer type which will also vary based on the underlying architecture.
I feel you, but, that's uintptr. int is more useful as the "native type" for array/slice length/cap/indexing
Earlier quoted context omitted.
It’s C’s lack of complexity which makes it necessary to do dangerous things for everyday purposes. I’d much rather a novice interact with generics, where the compiler is a safety net, than with void * and interface{}.
void * and interface{} are not going away when generics come. Try searching for "Object" or " " in some Java code...
At least it'll definitely get rarer.
Earlier quoted context omitted.
I really don't get the people opposed to generics. Is there actually a cross between experienced developers who have come from languages that have generics and understand them, yet don't want them in go? If so, why, and what do they use instead? Because go has no compromise-free answer for generics. You either lose type safety, maintainability, or performance. I suspect a lot of the generics hate is due to a large ch…
Increasing language surface area will generally increase the complexity of all api surfaces written in the language. This has obvious costs. It’s true genetics will shrink some specific APIs, where they are a good fit. But they will also be used opportunistically by developers excited to push their boundaries. Of course you can say “just don’t do that” which works if you have a tightly controlled codebase. But most c…
This exactly. The beauty of Go is that currently you do not need a book called "Go, The Good Parts".
Yes, generics would make a lot of things easier, but almost everything more complex and footgunnish.
I'm pretty excited by the idea of Go getting generics. This has always been my deal-breaker issue with Go and I'm glad that what appeared to be a disingenuous "let's pretend to be hunting for the truth until people go away" stance was actually really a hunt for the truth! Goes to show that you shouldn't make snarky snap judgments. As for all the folks claiming they'll leave Go if it gets generics, it's faintly remini…
I really don't get the people opposed to generics. Is there actually a cross between experienced developers who have come from languages that have generics and understand them, yet don't want them in go? If so, why, and what do they use instead? Because go has no compromise-free answer for generics. You either lose type safety, maintainability, or performance. I suspect a lot of the generics hate is due to a large ch…
I don't hate generics. I see the value of generics, especially after having worked with Go for so long; I've had to do some mental gymnastics to get around not having proper generic collections.
That being said, I'm not excited about seeing generics in other people's code. The added complexity doesn't really solve problems I have anymore.
That being said, I'm actually way less excited about overloading.
I think generics and function overloading is going to make me think "where the hell is this coming from?" a lot more often and then I'm going to need to load it up in my IDE, or vim with way too many plugins, and start following definitions.
Earlier quoted context omitted.
Design choices, to be blunt. Some of it is simple stuff, like CPython being interpreted, so PyPy get's a huge boost by JITting. Some of it is much harder stuff, like the way Python is designed to store objects in memory (a list is a pointer to a contiguous space of pointers to things that might be pointers...), and everything that hangs off each object (everything has a dict), and the awful GIL ([0]). Awful for perfo…
To be fair, all of the aspects of the language itself you mentioned apply to JavaScript (save perhaps differences in how literally it takes `int`, etc. being objects vs. JavaScript's unboxed `number`, etc.). I suspect most of the difference is that one has had three of the largest corporations in the country competing to have the fastest implementation, in some cases for decades, and the other hasn't.
Earlier quoted context omitted.
Yeah, sounds crazy. It only worked for C for 40+ years...
Ignoring the basic int type and using a zoo of preprocessor defines instead is what has worked for C all that time. But I still think that native types have their place. It can often be quite reasonable to accept serious limitations on narrow machines where the performance gains won by the trade-off are desperately needed, lift those limitations on wider machines and grant an enormous safety margin on the widest arch…
My C is a bit rusty but why should #defines be used in this scenario? A typedef set in a config.h.in is more than enough to meet the requirements of this usecase.
Earlier quoted context omitted.
Increasing language surface area will generally increase the complexity of all api surfaces written in the language. This has obvious costs. It’s true genetics will shrink some specific APIs, where they are a good fit. But they will also be used opportunistically by developers excited to push their boundaries. Of course you can say “just don’t do that” which works if you have a tightly controlled codebase. But most c…
>I believe in the future all languages will fork into a simpler novice subset for general use and an expansive language for infrastructure. These will both be valid in the same parser, but the subset will be quarantined at the package management level. I don't think we'll see this happen much for existing languages, but it could be a very interesting angle for a newly-designed language (or rather pair of languages).
Earlier quoted context omitted.
Are there normal coding patterns that are much faster with explicit gotos? Modern compilers seem to do a pretty good job of converting normal (goto-less) code into efficient binaries. E.g, the simple switch statement has several possible machine-code implementations that compilers will switch (heh) between, depending on the characteristics of the cases.
In bytecode interpreter VMs, one often encounters the "computed goto" [1] pattern in use to dispatch opcodes. This is one that tends to be a little faster than a switch statement, enough to matter in the dispatch inner loop. Of course, if you are going to JIT compile the bytecode, that'll usually be a lot faster. But at that point you're changing one form of low-level wizardry for another. [1] https://eli.thegreenpla…
Earlier quoted context omitted.
> In addition to those, I found I really missed a REPL console and moreso something like byebug that RoR has. For those that aren't familiar, byebug lets you put the command "byebug" anywhere in your code that opens an in context REPL. It's enormously helpful for hard to figure out bugs. This is like comparing apples and oranges, or at least, like comparing apples and apple-orange hybrids :) Just saying that Rails (R…
>This is like comparing apples and oranges, or at least, like comparing apples and apple-orange hybrids :) >Just saying that Rails (RoR) has a command like byebug that opens an in-context REPL, seems to ignore the fact that compiled languages like Go catch many errors earlier, at compile time, so you don't even need an in-context REPL or a debugger to find those. I definitely liked the type system of Go and the compi…
Got you now. The classic use case(s) of an REPL. I may have misunderstood your earlier comment, which is why in my own earlier on, I had said "seems".
Earlier quoted context omitted.
> In addition to those, I found I really missed a REPL console and moreso something like byebug that RoR has. For those that aren't familiar, byebug lets you put the command "byebug" anywhere in your code that opens an in context REPL. It's enormously helpful for hard to figure out bugs. This is like comparing apples and oranges, or at least, like comparing apples and apple-orange hybrids :) Just saying that Rails (R…
Yeah, and having access to a REPL can catch semantic and architecture issues before you finish integrating and fire up the whole application. As do testcases. Compilation is not a magic bullet. Although, to be fair, I pushed Golang at work precisely because you have to compile it first. Not everyone is diligently testing their code...
True about the semantic and testcases parts. Not clear how it helps with architecture.