Go 1.14 Released - Performance Improvements, Go's Module Support Production-Ready

[Guest]

Maybe you missed the memo about https://golang.org/pkg/sync/#Map which is part of the standard library, added around 3 years ago to provide a baked-in solution for concurrent access for folks who didn't want to manage their own locking.

You were always able to use sync.Mutex on maps, and the documentation was very clear about the need to protect it from concurrent use. Your stated definition of a mutex is an opinion, not the actual definition of a mutex.

What official go documentation states, that map needs to be protected from concurrent use, and what operations? I failed to find that, and it's also not mentioned in https://golang.org/ref/mem, as there's not a single word "map" there. For example, if map is being only read by different go routines, after it's built in single go routine, then does this map need some form of protection?

EDIT: just found it on https://golang.org/doc/faq#atomic_maps :

Map access is unsafe only when updates are occurring. As long as all goroutines are only reading—looking up elements in the map, including iterating through it using a for range loop—and not changing the map by assigning to elements or doing deletions, it is safe for them to access the map concurrently without synchronization.

[bug77]

What official go documentation states, that map needs to be protected from concurrent use, and what operations? I failed to find that, and it's also not mentioned in https://golang.org/ref/mem, as there's not a single word "map" there. For example, if map is being only read by different go routines, after it's built in single go routine, then does this map need some form of protection?

EDIT: just found it on https://golang.org/doc/faq#atomic_maps :

Map access is unsafe only when updates are occurring. As long as all goroutines are only reading—looking up elements in the map, including iterating through it using a for range loop—and not changing the map by assigning to elements or doing deletions, it is safe for them to access the map concurrently without synchronization.

I'm not even sure what you're complaining about here. It is idiomatic in Go not to change an object once you have passed it into a channel. If you follow that simple rule, concurrency in Go is pretty straightforward. It's really like ownership in Rust, only not compiler enforced (big difference, I know).

[Guest]

I'm not even sure what you're complaining about here. It is idiomatic in Go not to change an object once you have passed it into a channel. If you follow that simple rule, concurrency in Go is pretty straightforward. It's really like ownership in Rust, only not compiler enforced (big difference, I know).

You're right. It's idiomatic to not change an object, once the object is shared... It was just a tiny rant about missing documentation, where it should be,..

I was complaining, that it's not mentioned in map data type reference ( https://golang.org/ref/spec#Map_types ). Thread (non)safety of operations on a type is something, that just must be mentioned there,... Well, it's at least described in FAQ.

[squash]

Doesn't go depend only on libc, therefore these 342M represent whole build system/tools, and also standard library? Which is much less, compared to gcc/clang and other languages, including build tools, standard library, headers if necessary for compilation, and other dependencies except libc?

Right. if you compare apples to apples, it's a non-issue. When you install gcc or perl or python or php or whatever, you're also going to need to install a bunch of additional (often third party) packages to get the same level of functionality as you get from Go's standard library. And then you'll still be missing tools for dependency management, cross compilation, debugging, etc. You can write a multithreaded static file web server in something like 10 lines of code in Go and build it for linux, windows, bsd, osx, solaris.. on multiple cpu platforms without reaching outside of the standard library.

[benjiro]

Go is a like and hate language.

• Too much boilerplate code is needed to get even simple stuff done
• Go its goroutines / channels are over-hyped and can be extreme dangerous in the hands of people who are used to script language programming ( like most of its actual user base ). Say "hello" to race issues as the compiler really has no build in support to detect issues.
• The entire error system is simply a pain in the behind. Exception are much easier to handle. The so called advantages that individual error messages reporting / handling are limited to even useless beyond writing more code. Its so much easier to simply have try/ensure/rescue ( Crystal example: https://crystal-lang.org/reference/s..._handling.html ) or block based handling.
• Lack of flexibility results in your reinventing code with interfaces because else your spending 5 times to code that can be done in any language like Swift, Rust, hell even script language like PHP. You spend more time writing code then actually doing work.
• The constant reinventing the eco system. Gopath + fixed structure = most idiotic design in any language because again it forces you into only one way of working. The whole "we at google like this structure, you get used to it". Making local modules a royal pain in the behind if you did not want to put your code into a code repository solution like github. Now after how many years we get Vendor as a solution... and modules with versioning.
• Talking about Modules ... nobody ever say the issue with versioning modules coming... nobody ... really ... /looks at the 100.000 comments online. Its not because Google internally does not care about versioning, that the rest of the people needed to ignore it. And it created real world issue for many. The hours lost simply because a patch was not yet accepted on a external module but we manually patched it, only to lose that patch again when somebody updated the module by accident.
• The slow changes ... Its google way or the highway, this for years! A lot of issues that still plague the language today or only just get "fixed" are a result of years "highway".
• With every version and the more code, the worst the executable size becomes. Some companies now are already looking at 200 a 300MB executable's simply because
• Pointers that can turn into massive *whoepsies*. A GC language with pointers into its default usage. *sigh* ...

For a language designed to be amateur friendly, ... the real power of Go was that it came ( at the time one of the few ) with a default build in HTTP server solution and this got people going out of the box. That was its really major power in my opinion.

Frankly, these days languages like Crystal ( https://crystal-lang.org ) simply are better as languages / design ( does the same thing as Go but more user friendly with a ruby like syntax, flexible with modules, macro's, ... ). I prefer if Swift was more available but Apple seems to be happy keeping it inside their own eco system.

[Ironmask]

Go started as a systems programming language, which to some extent explains the absence of support for exceptions in the language.

I'll accept that, just because it's very possible to do exceptions on bare metal and I am fairly confident google employees are too stupid to know that or figure it out.

[onlyLinuxLuvUBack]

Does anybody know what the oldest linux distro version I can compile the go binary file on and with a smaller amount of hassles?
Centos6?
This java+quarkus will I have to give oracle an arm+leg for a production use license of java?
Does Golang have any license cost ?