Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go 2, here we come

blog.golang.org

Post reply on HN
Print view View original

441–450 of 534 posts

Re: Go 2, here we come

#441

Post by Too »

throwaway34241 wrote: post #238
the_clarence wrote: post #104

Earlier quoted context omitted.

Why oh why do people want a value to have different bounds depending on which system it is used? This is a source of huge confusion and why people stick to uint8 and other precise types

On 64 bit systems you can have large arrays that are bigger than a 32 bit int. For example, it's nice to be able to load a >2GB file into a byte array. For comparison, Java's int type is 32 bits on 64 bit systems, but then this limits the array size. It seems like a lesser evil to have a platform-native int type than to limit the size of arrays (especially since servers can be expected to increase their max memory go…

C# is the same, int is merely an alias for Int32 and the default Array type only holds 32bit.

If you really need to, it's easy to wrap this into your own BigArray-class holding a 32bit-array-of-32bit-arrays and overriding the []-operator with Int64 as argument.

Re: Go 2, here we come

#442

Post by sidcool »

I 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?

Re: Go 2, here we come

#443

Post by lasagnaphil »

shakna wrote: post #440
lasagnaphil wrote: post #437

Earlier quoted context omitted.

- Generics do not make runtime performance slow, but it sure does make compile times slower (although it really depends on the type system and its implememtation) For example, C++ templates, although very powerful, makes build times order of magnitudes slow when used poorly. One of the most important features of Go is its fast compile times, but generics/contracts can potentially slow it down a lot. - Yes, being a dy…

> the interpreter has to check the types of the variables a and b at runtime beform performing the right form of addition (it might be an int, or a string, you dont know) That's not necessarily true. In Scheme, a very dynamic language, the compiler will generally make choices about memory layout of the various values before launching into the evaluation phase. Where safe or possible to do so, it will probably reduce…

Didn't know about Scheme. Thanks for the link!

Re: Go 2, here we come

#445

Post by SwellJoe »

gBecks wrote: post #414
SwellJoe wrote: post #320

Earlier quoted context omitted.

I explicitly said above that Go is an easy language to learn. But, I found Rust easier. And, yes, I'm finding Rust easier to learn than JavaScript. Without question. It is a much, much, smaller and more cohesive language. It has some new concepts (features or techniques that I have never used in any other language), but so does modern JavaScript, and with JavaScript there's usually five ways to do it, and half of the…

I for one totally agree on rust being easier to learn than Javascript. I suspect it is because of the explicitness of rust vs the flexibility of javascript where you can do literally anything you wish without any sort of guard rails, then there's the ecosytem with like a gazillion tools in your build pipeline. I really admire front end devs because they do what I cannot, I guess i'm not as clever a programmer, I need…

I don't really care about the guard rails. I grew up in Perl (pre-strictures and warnings), and BASIC was the first language I ever built something in, so I'm not too fussed about things always feeling a bit loose, and having to defend yourself with tests and imposing some rules on yourself by convention.

While I think it's likely that having a stricter language is more likely to produce better software, especially as complexity grows, I don't think it has a huge impact on whether the language is "easy to learn" for me. Python is very lax (contrary to popular belief, Perl with strict/warnings is stricter than Python, and protects you against a wide variety of scope-related bugs, in particular) but I consider it an easy language, too, because it is consistent and small(ish). There's some kind of balance to be struck between elegance and simplicity, and between explicitness and concision, and Rust feels very good, so far. I don't think that balance will be the same for everyone.

JavaScript, to me, is hard just because it's so damned big and incoherent. It's been pulled in twelve directions at once for its entire life, and it shows. JavaScript is like a buffet that has Chinese food, Indian food, pizza, sushi, and tacos. Most of the food isn't very good, but there's a lot to choose from. It doesn't help that learning JavaScript also entails trying to make sense of the maelstrom of tooling that's available. While Rust has one clear path for beginners, JavaScript has a haunted corn maze.

Re: Go 2, here we come

#446

Post by joppy »

kbirkeland wrote: post #301
jerf wrote: post #178

Earlier quoted context omitted.

"int" in Go the native index type for arrays. I consider it an error to use it for anything else, and since I've adopted that policy, I've had no particular problem with ints. Probably a good linter idea in there somewhere.

I'm curious what the motivation was to use int instead of uint considering indexes cannot be negative in Go.

Using unsigned indexes would be fine if the program automatically throws an error on wrapping. Otherwise, it’s an accident waiting to happen, since you have to code all of your arithmetic keeping in mind the fact that the numbers are trying to blow up in your face.

If x is unsigned, then you can’t rearrange an inequality like x >= 4 into x - 4 >= 0, since the first inequality is only true sometimes, whereas the second is true always. This looks obvious, but bury it a little way into some nontrivial index arithmetic and boom.

Another more aesthetic reason is that indices can represent offsets into a structure relative to some other index, and in this case you really need negative numbers.

Re: Go 2, here we come

#447

Post by Groxx »

Groxx wrote: post #404
int_19h wrote: post #373

Earlier quoted context omitted.

The main advantage of the async/await model is that it's just syntactic sugar on top of CPS, so you can bolt it onto any language that is capable of handling callbacks (even C!). For a good example of that, consider WinRT - you can write an async method there in C#, the task that it returns can pass through a bunch of C++ frames, and land up in JS code that can then await it - and all that is handled via a common ABI…

it's true that it's "just syntactic sugar", but in most languages it has call-site contracts that are either part of the signature (`await x()` to unpack the future/coroutine) or implicit (`x()` in an event loop host). and to change something deep in the stack means changing every call site everywhere. that's a huge burden on a library (and thus the entire language ecosystem). it splits the world. to avoid that, you…

Halide! That's the one I was thinking of: https://www.youtube.com/watch?v=3uiEyEKji0M

I'd love to find out if this could be a more generally-applicable technique, but it's fascinating regardless.

Re: Go 2, here we come

#448

Post by yiyus »

Felz wrote: post #308
pjmlp wrote: post #266

Earlier quoted context omitted.

“The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.” -- Rob Pike From…

What a remarkably condescending philosophy! Do people really think that poorly of their coworkers? Of themselves?

Treating users like idiots is a common engineering practice, not only in programming. Assuming users only make intelligent choices is just unrealistic. It is not that you underestimate any particular person.

You may argue if Go finds the right compromise between giving enough power to their users and not allowing them to shoot themselves in their feet, but the general premise seems to be a very sound one to me.

Re: Go 2, here we come

#449

Post by [deleted] »

IshKebab wrote: post #357
ryeguy wrote: post #347

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…

It's people that have seen the abuses of C++ templates. They're very powerful and therefore people tend to want to use them for really complicated things. Look up things like SFINAE and compile time metaprogramming. Templates were not intended for those things. When they work they're ok, but if they go wrong good luck following the 10 line error message. Here's an example from Rust: https://www.reddit.com/r/rust/comm…

[deleted]
Post reply on HN