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

The State of Go

talks.golang.org

Post reply on HN
Print view View original

31–40 of 172 posts

Re: The State of Go

#31

Post by TazeTSchnitzel »

aplummer wrote: post #20
chowells wrote: post #18

Earlier quoted context omitted.

Why Rust? It doesn't really compete with Go anywhere. Haskell is a much stronger player in the space of high-level, garbage-collected languages. The only thing Rust and Haskell really have in common is not willfully ignoring the last 50 years of programming language design research.

Doesn't it? Why do people seem to compare them all the time...

Rust is a systems-level programming language. Go isn't: it's garbage-collected.

Re: The State of Go

#32

Post by learc83 »

aplummer wrote: post #20
chowells wrote: post #18

Earlier quoted context omitted.

Why Rust? It doesn't really compete with Go anywhere. Haskell is a much stronger player in the space of high-level, garbage-collected languages. The only thing Rust and Haskell really have in common is not willfully ignoring the last 50 years of programming language design research.

Doesn't it? Why do people seem to compare them all the time...

Go gets compared to Rust because go was originally labeled a "systems" language. But the designers had a different older view of what "systems" meant than what is commonly used to day. People heard systems and thought they meant low level/operating system/embedded systems. That is not what Go is good for because it's garbage collected.

They also planned to attract C++ programmers, but they've basically been attracting dynamic language programmers instead. Why that was a surprise is beyond me--I can't imagine that anyone currently using C++ would be OK switching to a garbage collected language.

Rust on the other hand, is shaping up to be a C++ replacement.

Re: The State of Go

#33

Post by [deleted] »

aplummer wrote: post #20
chowells wrote: post #18

Earlier quoted context omitted.

Why Rust? It doesn't really compete with Go anywhere. Haskell is a much stronger player in the space of high-level, garbage-collected languages. The only thing Rust and Haskell really have in common is not willfully ignoring the last 50 years of programming language design research.

Doesn't it? Why do people seem to compare them all the time...

[deleted]

Re: The State of Go

#34

Post by DrJokepu »

zak_mc_kracken wrote: post #28
melling wrote: post #2

Nice little change in syntax. m := map[Point]string{ Point{29.935523, 52.891566}: "Persepolis", Point{-25.352594, 131.034361}: "Uluru", Point{37.422455, -122.084306}: "Googleplex", } may now be written as: m := map[Point]string{ {29.935523, 52.891566}: "Persepolis", {-25.352594, 131.034361}: "Uluru", {37.422455, -122.084306}: "Googleplex", }

I'm puzzled about the asymmetry of the syntax. What's the reason behind map[Point]string as opposed to something more symmetrical?

It makes sense if you're used to Go. In Go, in function declarations return types come after the argument list, e.g:

    func doSomething(input string) string { ... }
The go map declaration syntax is analogous to the function declaration syntax: the keyword (map, analogous to the func keyword) followed by the type of the keys in brackets (analogous to the argument type in parentheses) followed by the type of the values (analogous to the return type).

Re: The State of Go

#37

Post by NateDad »

giaour wrote: post #3

Shared libraries? I thought "no DLLs" was one of the major design philosophies of Go.

There was a big push from the linux distros as the maintainers had anneurisms thinking they'll need to rebuild hundreds of Go applications when/if a big bug is found in the Go standard library. They also don't like the idea of having N copies of the code for the standard library in N Go applications.

Personally, I find that kind of thinking to be a relic of the past when memory and disk space were expensive and compilation took a long time.

Sure, if you're running on a raspberry pi, a few megs here and there might actually matter... but even my phone has 2gigs of RAM and 32gigs of disk space.

Re: The State of Go

#38

Post by jdoliner »

sanderjd wrote: post #17

The analysis and tracing tools look really wonderful. Have those been in the works / maturing for awhile, or is that all new tooling for 1.5?

I think the tracing tool [0] isn't go specific but rather just a general tracing tool that's been maturing for a while. The support for outputting compatible traces is new to 1.5 AFAIK but that would explain how they have such a nice looking interface already :)

[0] https://github.com/google/trace-viewer

Re: The State of Go

#39

Post by coldtea »

giaour wrote: post #23
chenzhekl wrote: post #9

Earlier quoted context omitted.

This feature may be prepared for building shared libraries for C. After all, Using shared libraries is popular in C world.

It might also make it possible to write Node/PHP/Ruby/Python libraries in Go instead of C++. I've been looking at Rust for that use but the ability to compile Go to a C archive throws in back in the running.

I don't think you can compile go to a C archive that runs without the runtime.
Post reply on HN