Earlier quoted context omitted.
The subset of Go users who deploy on 32bit hardware in 2018 and care about performance at that level, is likely to be vanishingly small.
32 bit ARM is still very common.
What about Go in 32 bit ARM?
Go 2, here we come
481–490 of 534 posts
Re: Go 2, here we come
#482Earlier quoted context omitted.
The subset of Go users who deploy on 32bit hardware in 2018 and care about performance at that level, is likely to be vanishingly small.
Even if it's OK to degrade the performance of a small minority of users, is there a big benefit to emulating 64 bit ints everywhere on 32 bit hardware? (I'm not saying there isn't a benefit, just that it's not clear to me what it is). I don't know how many users are still on 32bit. Maybe low power network devices? Older mobile phones (Go isn't usually run on mobile, but it's possible...). If at some point in the futu…
>I don't know how many users are still on 32bit. Maybe low power network devices? Older mobile phones (Go isn't usually run on mobile, but it's possible...).
Well, 16 bit would also be possible if someone took the effort. Perhaps it just shouldn't be encouraged.
Re: Go 2, here we come
#483Earlier quoted context omitted.
I think the main fear people have isn't the concept of generics, but the implementation of generics. Go's primary goal is simplicity, and implementing generics isn't simple.
If language features were free we'd likely have had generics for a long time now. Unfortunately generics is a trade-off: you get development speed/ease and pay for it in compile time, binary size and/or execution speed. This seems to be slowly changing, but Go was designed to be a solution to Google problems - python being slow but some c++ applications taking literal hours to compile. Keeping that perspective in min…
If you maintain type safety, you'll pay in increased compile times with or without generics. You'll either hand-roll an implementation for each type (https://golang.org/pkg/sort/) or you'll generate code before actually compiling. The problem doesn't go away.
Re: Go 2, here we come
#484Earlier quoted context omitted.
> Why not introduce a primitive type "num" for arbitrary precision rational numbers instead? Rationals aren't supported natively by processors, so there's no real need to handle this as a primitive instead of letting people to use a library for it. Adding them to the base language just because some people would find it convenient would clash with Go's explicit minimalist philosophy.
This argument falls flat for me. Classes aren't supported natively by processors either, yet any number of OOP languages use them. It's generally nice when you can do simple things with the language's built-in standard library. I tend to prefer languages with more powerful standard libraries because it means that you can more easily move across codebases since they'll all be the same. If commonly used data types like…
Yes, standard library. I understood the poster above you to suggest they shouldn't be a part of language by that's used by default, for sure though it would be convenient to have centralized implementation.
Re: Go 2, here we come
#485Earlier quoted context omitted.
I just started learning Rust for a small project, and I found its "one clear path" model very appealing (I don't know if it is a formal goal, or if it's just a happy accident based on a smaller, more focused, community). It doesn't just apply to the package manager, but that's one of the first bits a beginner sees. Rust has a single, easy-to-find, "pretty good" answer for nearly every question a beginner asks, at lea…
As a beginner, I really like rust. It has excellent package management, robust compiler messages, pattern matching... etc. But once I start trying to build non trivial data structures it becomes a nightmare. For example, doubly linked list, any sort of graph is extremely hard for me to build in rust but extremely easy to build in golang. I am still learning the full capability of rust, hopefully as I do more practice…
I have heard this is a really good resource for understanding this exact aspect of Rust
Re: Go 2, here we come
#486Earlier 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.
I think a bigger reason is that Python prioritizes simplicity of internal implementation.
To be sure, the internal implementation of CPython (the only one I'm familiar with) is complicated as hell. But it's a whole lot simpler than any fast JavaScript runtime I've ever used. I think that's the result of a conscious choice by the maintainers/BDFL/community in Python, not a side effect of it having less funding (assuming that's the case).
Re: Go 2, here we come
#487I’m hoping that https://github.com/golang/go/issues/19623 will come through, and we’ll get a native “true integer” type (and hopefully a rational one as well, though maybe this is pushing it a bit). This is really something that should be implemented at the language level, so that “int” can become a true integer, yet still remain efficient in many cases. It is bizarre to me that languages boasting built-in language-l…
I don't know how many times I've been writing a program using int, then suddenly I have to do some math on the index of a range (for example), and the math.* functions require int64. I start casting to int64, but things get infected and it spreads. Eventually I refactor everything to use int64 and wonder why int can't just be an alias for one of the others. Personally I would make it int64, since that is what the sta…
Odd, I've rarely had this issue, and almost never need to do complicated math on the index of a range (maybe "multiply by two and add one" kind of stuff, but nothing from the "math" pkg). Also, note that the math.* functions all use float64, not in64.
Re: Go 2, here we come
#488I’m hoping that https://github.com/golang/go/issues/19623 will come through, and we’ll get a native “true integer” type (and hopefully a rational one as well, though maybe this is pushing it a bit). This is really something that should be implemented at the language level, so that “int” can become a true integer, yet still remain efficient in many cases. It is bizarre to me that languages boasting built-in language-l…
My (admittedly unsophisticated) mental model is that int32 and the like are simple primitives that can be stored in registers and use the processor's native ADD/MUL codes, while BigInt is going to be some boxed structure with its own implementation of arithmetic operations. For as common as number munging is (especially in somewhat lower level code that Go shoots for), it would carry a huge performance penalty, wouldn't it? Or are there more sophisticated ways of offering a "true integer" type that I'm not aware of?
Re: Go 2, here we come
#489I am torn apart between investing the next one year between Go and Rust. I want to do some cool systems level programming. Both seem to be very good at it. Go has additional advantages of being older (and may be wiser). What does the hivemind think?
> some cool systems level programming.
What projects did you have in mind? I think the answer to your question depends on what you mean by "systems level programming" and what you plan on doing/trying.
Re: Go 2, here we come
#490As a newcomer to Go, by an immensely wide margin, the hardest, most frustrating thing, which soured the language for me, is whatever the heck package management is in Go. There's like three or four different angles, all of which overlap. Some are official. Some aren't. The unofficial ones seem more popular. They're all kind of incomplete in different ways. And it was all such a frustrating migraine to try and figure…
Having used the new Go module system (introduced in Go 1.11 as an option, to be the default choice in 1.12) since August, it's my opinion that this is now a solved problem. The biggest source of pain moving forward is going to be the projects that haven't transitioned, including the various command-line tools that work on parsing, generating and manipulating Go code (e.g. linters, code generators). Most of the import…
There are still some rough edges, but I agree that the new module system is very good. And it's given me the confidence in Go to start using it far more broadly than I had before, when every new project meant hang-wringing over how to handle dependencies. Now it Just Works well enough for 90+% of use cases, with no extra steps required. It just works.