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

421–430 of 534 posts

Re: Go 2, here we come

#421

Post by johncolanduoni »

paulddraper wrote: post #387
djur wrote: post #364

Earlier quoted context omitted.

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…

> It is very common for language runtimes to link and depend on libc on Unix It is, and this is where you have to choose between a fragile executable that linked to a specific vendor and version of libc (glibc, musl, etc.). or a bloated executable that statically links it. > MacOS doesn't guarantee backward compatibility for direct syscalls. Sounds like Go should use the stable API MacOS does offer. If the stable API…

It's also worth considering that none of the major systems are actually POSIX-compliant today. You're always going to need to make specific allowances if your standard library supports anything beyond the absolutely trivial even if you ignore Windows.

Re: Go 2, here we come

#422

Post by opnitro »

acdha wrote: post #68
rootbear wrote: post #36

Earlier quoted context omitted.

I would like to see more Unicode operators, at least as options. It's crazy that we still use * for × in 2018. Yes, I know that most US keyboards don't have that symbol but that's a solvable problem. I use an international layout on my Linux systems and can type it easily. Also, I prefer using ' for the thousands separator and was happy when C++ adopted it. It's less visually intrusive, especially with variable width…

> It's crazy that we still use * for × in 2018. Yes, I know that most US keyboards don't have that symbol but that's a solvable problem. I see the appeal but there are two problems with this: “solvable” is not the same as “easy”, and that similarly also wants fonts which make × more distinct from x. In both cases that's something which is perhaps approachable for dedicated developers but it seems likely to turn newco…

It's interesting though, Racket certainly doesn't shy away from it. It allows you to use the lambda symbol as a replacement for the `lambda` keyword. (The keyword still works however)

Re: Go 2, here we come

#423

Post by EricBurnett »

jniedrauer wrote: post #410
EricBurnett wrote: post #390

Earlier quoted context omitted.

(Disclaimer: at Google) My team has ~200k lines of Go code and I'm exceedingly happy with the state of the codebase. Having previously maintained a C++ codebase of similar size, I can say that the pace of changes is higher, the effort necessary for large scale refactorings is lower, and our ability to reason about the system is similar. A few examples: - Refactorings are simpler due to the use of consumer-side interf…

> Simple scripts, bash until they need their first 'if' or flag or loop, then Go too. If you don't mind, can you give a little insight on what this looks like in practice? I'm not sure how to use a compiled language as a script. I've played with executing go as a script using a shebang hack, but I somehow don't think this is how others are doing it. For reference, the shebang hack I was using looked like this: //usr/…

It looks more like Go code than a bash script - the tradeoff we settled on is that pretty much as soon as you need to add any sort of logic it's no longer really a simple "script" and you _know_ it's just going to grow into a monstrosity. Better to use a language with real functions, real error handling, that you can actually unit test, etc. In that sense, I guess you could say we write lots of little tools moreso than we write scripts.

For something of this form, if the standard library has the functionality, we us it - os.Mkdir() instead of `mkdir` and so on. But to simplify shelling out, we have a little library that includes the interface

  type Runner interface {
	Execute(dir, name string, args ...string) (*CmdOutput, error)
  }
so it's easy enough to call miscellaneous programs and get the exit code / stdout / stderr. It also supports printing and executing a command, etc.

Iteratively executing a program of this form looks like `go run whatever --flag=value`, though your shebang hack looks like it'd also do nicely.

Re: Go 2, here we come

#424

Post by wbl »

themihai wrote: post #380
closeparen wrote: post #362

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{}.

>> It’s C’s lack of complexity which makes it necessary to do dangerous things for everyday purposes. That's not the case anymore. We have C++ which has generics and "fixed" C's lack of complexity for sure...Now for some 'weird' reasons some people still use C. Wonder why ?

Compare C++ to Standard ML. Simplicity is compatible with generics.

Re: Go 2, here we come

#425

Post by johncolanduoni »

shakna wrote: post #417
mrfusion wrote: post #408

Earlier quoted context omitted.

Now I have to ask, what would you say does make python slow?

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.

Re: Go 2, here we come

#426

Post by johncolanduoni »

jerf wrote: post #356
kbirkeland wrote: post #301

Earlier quoted context omitted.

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

Despite most of my professional programming being in Go nowadays, I am extremely sympathetic to the Haskell/FP way of thinking about things, and trying to make invalid state unrepresentable. However, having made the mistake a few times now of trying to use "unsigned ints" for things that I want to assert are never negative, I've learned the hard way not to do that. The problem is, there's always some bug you have in…

Rust does this in debug builds by default, and you can switch it on in production if you'd like.

Re: Go 2, here we come

#427

Post by johncolanduoni »

icedchai wrote: post #249
tigershark wrote: post #88

Earlier quoted context omitted.

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

Yeah, sounds crazy. It only worked for C for 40+ years...

And what percentage of programs written in those 40 years are actually able to run on systems with more than one or two different memory layouts?

Re: Go 2, here we come

#428

Post by LanceH »

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 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 standard library thinks math should be done with.

Re: Go 2, here we come

#429

Post by shaklee3 »

sieabahlpark wrote: post #244
simfoo wrote: post #66

Earlier quoted context omitted.

Same here. For me it was primarily the syntax. So many people think that syntax is something you get used to, but I don't. Syntax matters a lot for me, and the way Go does it just isn't compatible with my brain. Regular grammars are great for parsers. But really, having an easy to read (conceptually!) language is way more important imho. But call me crazy when I say that I like C++ and can read it effortlessly :)

If you like c++ then you just haven't given Go enough time to sink in. It reads more left to right then right left like c++.

I've given go plenty of time to sink in, and I still prefer c++. Things like not allowing implicit type conversions on things that clearly are not a problem (int16->int32) are just annoying.

Re: Go 2, here we come

#430

Post by pjmlp »

w8rbt wrote: post #392
mrfusion wrote: post #355

Earlier quoted context omitted.

What are generics?0

Rather than writing multiple functions that take different types as args and return different types (say int8, int16, int32, etc.) but do the exact same thing, with generics, you can instead write one function that takes a number (which could be any int type) and return a number, and you only wrote one function. That is generics in a nutshell. The function is generic, not specific to one type. Generics allow for less…

C has minimal generics support since C11.
Post reply on HN