The State of Go
51–60 of 172 posts
Re: The State of Go
#52Since a large project like Golang has so many auto-build tools and test OSes, how hard is it to provide a binary download for e.g. Ubuntu 14.04 LTS? You know, not tarballs, but actual static binaries as deb packages installable via apt-get.
Good examples:
https://www.percona.com/doc/percona-server/5.6/installation/...
I root for open source movement, but to install something on a popular arch/OS by compiling from source everytime is just meaningless power consumption and adding CO2 emissions.
Re: The State of Go
#53Re: The State of Go
#54Earlier 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.
Re: The State of Go
#55"Go 1.5 provides support for Android and experimental support for iOS." I thought this day would never come.
I wonder how Go can be better than Swift for iOS development.
Re: The State of Go
#56Earlier quoted context omitted.
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 attractin…
Yeah, additionally it would be unwise to use Go in embedded systems because it is so reliant on heap memory for dynamic allocation. In certain situations where things could fail if an operation takes too long - rocketry and robots - it would be difficult to tell how long something would take in Go with any degree of certainty because allocating and freeing memory on the heap is highly non-deterministic.
Re: The State of Go
#57"Go 1.5 provides support for Android and experimental support for iOS." I thought this day would never come.
I wonder how Go can be better than Swift for iOS development.
Re: The State of Go
#58I always have this question: Since a large project like Golang has so many auto-build tools and test OSes, how hard is it to provide a binary download for e.g. Ubuntu 14.04 LTS? You know, not tarballs, but actual static binaries as deb packages installable via apt-get. Good examples: http://wiki.nginx.org/Install https://www.percona.com/doc/percona-server/5.6/installation/... I root for open source movement, but to i…
Re: The State of Go
#59Earlier quoted context omitted.
You created a burn account just to complain about this? As you know, generics won't appear before 2.0, if ever. It's fine if that's a nonstarter for you. Perhaps you'll like Rust instead. It needs a big community too.
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.
I guess people compare Rust and Go because they were released in similar timeframes and people like to view things in competition.
Rust is especially attractive when you can't afford a garbage collector, need deterministic destruction, and full compatibility with C. It's what C++ would be if it could start from scratch.
I think your point needs to be re-iterated more often: if garbage collection and ~2-3x the running time of C is not a problem, OCaml, Haskell, Scala, F#, etc. are the competition of Go. They integrate modern (read: mostly 70ies/80ies) language design insights, while providing approximately the same performance as Go.