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

431–440 of 534 posts

Re: Go 2, here we come

#431

Post by s_trumpet »

vram22 wrote: post #103
treis wrote: post #48

Earlier quoted context omitted.

>I tried Go a while ago. I was hooked by the performance , the community around it and vendors support ( AWS , Heroku , GCloud etc...) but I got quickly fed up by the awkward package management system, the weird syntax and the horrible idea of $GOPATH, especially on Windows. My experience was similar. In addition to those, I found I really missed a REPL console and moreso something like byebug that RoR has. For those…

> 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…

Elixir's IEx.pry/0 function, that opens a REPL at a particular point of execution, is probably the stdlib function I call the most while developing. In a compiled language, to boot.

Re: Go 2, here we come

#432

Post by pjmlp »

djur wrote: post #364
paulddraper wrote: post #279

Earlier quoted context omitted.

> direct usage of syscalls instead of libc Why do you want to use libc for Go? You wouldn't use the Rust standard library for Go, why the C standard library?

It is very common for language runtimes to link and depend on libc on Unix, even if the libc API is not directly exposed in those languages. Go is somewhat unusual in this regard. MacOS doesn't guarantee backward compatibility for direct syscalls. This has caused bugs like this with compiled Go binaries: https://github.com/golang/go/issues/16570 Go has very recently started using libSystem (which is analogous to Linu…

Windows syscalls are exposed via User32.dll, Kernel32.dll and friends, not MSVCRT.dll.

Re: Go 2, here we come

#433

Post by privateSFacct »

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?

It's worked pretty well for go.

I'm a relative expert in some domains, but I just find the fancy languages tiresome. I even find so called experts who find it condescending to use a straightforward language tiresome. Seriously - these so called experts never actually deliver any actual product. They just loop around writing line noise that is unreadable.

If you code with others, look into the idea of write-only languages. I think you'll find some of the ideas behind go make some more sense if you understand what they are working to avoid.

I don't hate generics, but don't think they are critical to go's success.

Re: Go 2, here we come

#434

Post by pjmlp »

ilovecaching wrote: post #337
pjmlp wrote: post #31

Earlier quoted context omitted.

Languages are products as well, either they grow to fulfil the needs of their customers or their fade away.

What if the need is for a small language without generics?

If there was such a need, the languages without them would still have a major market, which isn't the case.

Naturally those of us coding since the early days have experience with programming languages without generics support, yet a large majority eventually adopted generics.

Even C has minimal generics support since C11.

Re: Go 2, here we come

#435

Post by pjmlp »

AsyncAwait wrote: post #277
pjmlp wrote: post #259

Earlier quoted context omitted.

Just because the majority of them are commercial doesn't change the fact that they exist. They are more expensive than a stack of laptops, because FOSS made the business of selling software tooling only worthwhile when targeting enterprise customers. Those enterprise customers have developers using these compilers almost since Java exists.

> Just because the majority of them are commercial doesn't change the fact that they exist. No, but it does explain why Java is not a worthwhile option for OP.

Moving goal posts? The OP asserted they did not exist.

Re: Go 2, here we come

#436

Post by geezerjay »

danielhlockard wrote: post #213
geezerjay wrote: post #95

Earlier quoted context omitted.

> they're as un-risky as anything labelled "experimental" could be. Yes, that's exactly the point, and why any decision to take a hard pass is more than obvious.

A ton of projects have upgraded to work well with modules already. Seriously, it's set and forget in your zshrc / bashrc / whathaveyou.

> Seriously, it's set and forget

If that was true they would not be euphemistically labelled as experimental.

Re: Go 2, here we come

#437

Post by lasagnaphil »

shakna wrote: post #403
mrfusion wrote: post #396

Earlier quoted context omitted.

Wouldn’t this make golang slow though? Isn’t that what people claim makes python slow?

In a ahead-of-time compiled language probably not. The generic function is just a code generator for several functions that will get called in the right places, generated and put in the right places by the compiler, and then get optimised as per normal. And no, being a dynamic language is not what makes Python slow. Lua, Nim and Scheme are all examples of dynamic languages with fast implementations.

- 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 dynamic language slows it down a lot. For example, when evaluating a+b, 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). Even with JIT (just in time compilation) the compiler has to initially “guess” that the variables are numbers, and fall back if that is not the case. Statically typed languages do not have this problem, because you know the types of variables beforehand at compile time.

By the way, Nim is not a dynamic language. And LuaJIT is one of the the fastest dynamic language implementations because the language is very simplistic (compared to Javascript/Python/Ruby) and Mike Pall is a robot from the future...

Re: Go 2, here we come

#438

Post by geezerjay »

AsyncAwait wrote: post #284
Cyph0n wrote: post #172

Earlier quoted context omitted.

Think of it this way: if you spend time learning and using a feature that is not guaranteed to be there, say, a year down the line, is that a good investment?

> a feature that is not guaranteed to be there, say, a year down the line, is that a good investment? The Go devs have been extremely clear that Go modules is THE solution to Go packages.

If they do mean what they say then they will release a version of Go where the GOPAH nonsense is over and a fix for that design problem is not euphemistically described as experimental.

Until then, no LTS means not ready for production.

Re: Go 2, here we come

#439

Post by Too »

tigershark wrote: post #88
joppy wrote: post #27

I’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 am misunderstanding or really go is using the ‘int’ type that can be 32 or 64 bit depending on the system that it runs on??? If this is the case I think that is crazy and I can’t think of any useful use case for it. If it’s not the case then please explain me what that proposal is really about...

Crazy indeed. This was like lessons learned #2 from C, which later introduced the stdint types int32_t et. al.

A modern language with this type of confusing and platform dependent behavior is inexcusable. By all means, include a native data type as big as the processor can handle (size_t), but don't call it int which is the default data type most people will use out of pure laziness.

Re: Go 2, here we come

#440

Post by shakna »

lasagnaphil wrote: post #437
shakna wrote: post #403

Earlier quoted context omitted.

In a ahead-of-time compiled language probably not. The generic function is just a code generator for several functions that will get called in the right places, generated and put in the right places by the compiler, and then get optimised as per normal. And no, being a dynamic language is not what makes Python slow. Lua, Nim and Scheme are all examples of dynamic languages with fast implementations.

- 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 the number of choices that will have to be made at runtime, at compile time. The interpreter may not have to lookup what the data type is, because it may just have two bits of memory and an instruction to call. You can know what the data will be, and optimise for it. [0]

There's no reason that: b = 1; c = 2; a = a + b needs to be slower than a = 1 + 2 if b and c are never referenced before or after. But in Python, it is, because the design makes it harder to know whether or not an object should get optimised away.

> And LuaJIT is one of the the fastest dynamic language implementations because the language is very simplistic

Right, Lua is dynamic, and one of the design choices was making it simple, and so it's easier to make it faster.

[0] http://home.pipeline.com/~hbaker1/CheneyMTA.html

Post reply on HN