[ art / civ / cult / cyb / diy / drg / feels / layer / lit / λ / q / r / sci / sec / tech / w / zzz ] archive provided by lainchan.jp

lainchan archive - /λ/ - 6735



File: 1434539907934.png (52.88 KB, 300x300, gophercolor.png)

No.6735

What do you think about golang? I've started learnig it and it looks good to me so far.

  No.6736

It's OK, but its type system makes me uncomfortable.

  No.6737

>>6735
The standard library ok, but the language feels akward to me.

  No.6767

If Go had any less features, it wouldn't be turing complete.

  No.6770

I think its main attraction is it's created by the old Bell Labs guys. It's a great improvement from what was Limbo on Inferno, which I used to have fun playing with. Go is pretty good for programming network related things, imo.

  No.6773

I don't know much Go myself, but I love the fact that services written in it, like gogs, are really easy to get running.

  No.6776

>>6767

Old article, but Go is pretty popular:
http://redmonk.com/dberkholz/2014/03/18/go-the-emerging-language-of-cloud-infrastructure/

Seems like a lot of people who used to be writing ruby, python and node have switched to it as well. It's fairly easy for high-level programmers to pick up and though its not as performant as the fastest, it's much quicker than what they were using before.

  No.6906

I started reading about it. I am going to learn it during the holidays but I have to finish with my exams first. I checked out the interactive introduction and I found certain things confusing at first glance, For examples interfaces seem to be implemented in a weird way. Furthermore the syntax is slightly confusing at first but I like it overall. The capital letter used for public properties might be annoying though. Also they claim that there are no classes, only methods declared on structs. Well guess what, that is what a class is, only their implementation is slightly different. I also really like the fact that binaries are statically linked by default.

  No.6924

Go is never going to go mainstream until it gets regular class based OO. The fact that only python and ruby programmers like it should be an indicator that it is missing something. That something is its inability to seamlessly integrate with APIs that use conventional OO

  No.6925

>>6924
What's it missing besides inheritance?

  No.6926

>>6925
its not object based OO, its module based OO, that does not translate as a passable self contained struct object

  No.6928

>>6926
I don't understand what you mean. Go has methods.

  No.6929

>>6928
>Go has methods.
so?? that means nothing

In order to have class based OO, you need the idea of a struct. A struct is a data structure which something you can assign to a variable, pass into functions, copy into other objects. All modules do is give viability to methods and data within the module, that is not enough for real OO. You dont pass around references to modules. The only two compiled languages that I know of that use module based OO are Ada and Modula2. Ada is has zero tolerance for error and so can not safely pass around references to data structure and must use modules to fake OO. Modula2 is entirely module based, it is a very clever language, but it does not co-habitate with regular OO. A lot of scripting languages and functional languages use modules because it is good for providing namespaces to libraries, it is not a replacement for OO.

  No.6930

>>6929
>All modules do is give viability to methods
visability, meant to say visability

thats all modules do is provide namespaces (visability)

  No.6934


  No.6971

In my opinion, the concurrency in Go is nice, but the type system is way to powerless (No generics, templates, or something along those lines) and the way they do error handling is quite annoying.
Native unicode support is a gift, though.

  No.7146

File: 1435567369551.png (144.14 KB, 134x200, woody.jpg)

>>6906
Follow up:
>no exceptions
I wish it had those
>$GOPATH
This is very stupid, they basically want to put my own code in the same directory as other people. I want to put my code in ~/repositories/<project> not $GOPATH/src/<username>/<project>. I opted not to use this weird directory at all. Also a path $GOPATH/src/github.com/<username>/<project>/ is insane. What if I change the location where my repository is hosted? Why am I basically supposed to include a name of some unrelated proprietary website I happen to be using in my package import path?

I will continue this rant later.

  No.7149

>>6971
>, the concurrency in Go is nice, but the type system is way to powerless (No generics, templates, or something alo
ng those lines)
Ive heard that before. Scratched go from my learning list, will do erlang, ruby or elixir instead :-) looking forward to it

  No.7154

>>7149
It's a shame though.
If Go's typesystem was a little nicer, it'd probably be my favorite imperative programming language.

  No.7157

>>7146
>I opted not to use this weird directory at all. Also a path $GOPATH/src/github.com/<username>/<project>/ is insane.
Have you not seen three level empty directory nestings for Java projects?

  No.7159

>>7157
>Have you not seen three level empty directory nestings for Java projects?
i'm not that guy, but i find it harmful that java enforces the directory structure to reflect namespaces

especially in combination with using the domain names of the library vendors, enyoy your com/whatever/somethingelse/ohmygod/this/is like kicking dead whales down the beach

i strongly feel like go should use a package manager. is there one? how do you manage dependencies in go?

  No.7167

I like the forced gopath project structure. I am learning programming with go, but i used to dick around with Python, and not having a standardised project structure was a hurdle iI had run into.


However it also might have something to do with all the tooling with the Langs, because I loved playing with rust as well

  No.7169

>>7159
> how do you manage dependencies in go?
Go comes with a package management facility by default. When importing libraries, you can specify, for example, github urls and if someone tries to build your project, Go will go out on its own, clone the repo and build it.
I'm not sure how it handles other package-managery things, such as specifying certain versions of dependencies and having multiple instances of the same library installed.

  No.7172

>>7159
go get github.com/username/repository

or in your source file
import "github.com/username/repository

and any go command that will need this repo, will download and install it in your $GOPATH (e.g. go get, go build, go test).

Personally I'm using GOPATH=${HOME}/bin/GoPath (in .zshenv) and GOPATH=$(pwd) while working on some project.

>>7146
It's only for external packages. No one says you can't set GOPATH to ~/repositories/myProject/ while working on it.
You can use imports like these:
import (
"fmt" // standard library
"github.com/golang/example/stringutil" // remote library
"rsc.io/pdf" // remote library currently hosted at
// github.com/rsc/pdf [1]
"mylibrary" // $GOPATH/src/mylibrary
// keep in mind it won't work with 'go install'
// you need to provide it along with
// the source of your package
)

If they are not found in GOROOT or GOPATH, they will be downloaded to the (first path in) GOPATH. See 'go help gopath'.
>What if I change the location where my repository is hosted?
[1] https://docs.google.com/document/d/1jVFkZTcYbNLaTxXD9OcGfn7vYv5hWtPx9--lTx1gPMs/

More info here: https://golang.org/cmd/go/#hdr-Remote_import_paths

You most likely will want your workspace to be

myproject/ ($GOPATH=~/path/to/myproject/:/maybe/system/wide/gopath/)
myproject.go // package main
// import "fmt" (found in $GOROOT)
// import "mylib" (found in $GOPATH)
// import "github.com/user/example (downloaded to $GOPATH)
src/
mylib/
something.go // package mylib
github.com/user/example/ (downloaded by 'go' tool)
example.go // package example

  No.7257

>>7157
It is harmful that my package name is supposed to contain the name of an unrelated website which hosts it and which can change any day.


But honestly I still don't understand how those packages work. It is rather confusing for me. I am never sure what is the actual name of the package I am writing and so on. ALl examples are so basic that they are basically useless.

  No.7320

>>7257
To clarify: I am not sure what is the point of writing

package my_package

on top of each file if the packages are imported by directory names anyway. For example if we have a file:

$ cat directory/my_package.go
package my_package
...

This would have been imported as `import directory` anyway, right?

  No.7631

File: 1437303088566.png (23.57 KB, 185x200, glenda_glasses.png)

Okay after working with it for a while I have to say the language is pretty cool, although the interfaces were a bit confusing at first. Also I found something really stupid in the Go supplementary cryptography libraries
https://github.com/golang/crypto/
but nobody responded to my email on the golang-nuts ML and I can't get my fix in on my own because the process is very complex and complicated ad requires you to register in 1000 places with a Google account.

  No.7645

>>7257
The import line describes where to get it, not what it is. The alternatives are:
1)No builtin package management. This is the solution C and C++ take. And it is terrible. Obviously you can do this just fine by downloading the packages manually and sticking them in whatever subdirectory you want.
2)Centralized repo like pip. All packages must be vetted and added manually by some trusted third party. You complain about github but would rather have every package you can use be controlled by google?

  No.7648

>>7645
I understand it now but it could be written somewhere more clearly. When you
import "dir1/dir2/package"
you specify a directory where the stuff resides. But the name under which it will be available to you might be different than the last part of that path. That name is specified by
package name_of_the_package
line in the source file.

  No.7649

>>7648
How else would the compiler find packages? It could search the entire directory for packages by parsing each file, but one of the major design goals is fast compilation so it can be used like an interpreted language. Yes, you could generate some kind of manifest and stick it in a file somewhere, but that adds needless complexity and the manifest would still have to be generated at some point. And it still doesn't address the problem of downloading packages, you would need an entirely separate system to map package names to where they can be downloaded and have to set up some config file for every package instead of just pasting in a URL. I suppose they could make it a rule that package names have to match the directory, but what's the point when everybody does that anyway? Plus you can always import a package under a different name if you don't like the one specified.

  No.7653

>>7631
What did you find?

  No.7657

>>7653
https://github.com/golang/crypto/blob/326f0c56aaa360d621f27fe3ff4a89735582822c/openpgp/keys.go#L458
It is impossible to generate stronger keys. I switched to pure RSA from stdlib in my program because of that.

History of this soykafcode:
- Moved from the main repo by Russ Cox (and therefore I hold him partially responsible) [1]
- Originally written in the main repo by Adam Langley <agl@golang.org> in 4fdcb7b684d7719c0beedf247787be06751f1b2c [2]
- Of course it passed the code review which is useless and only makes contributions hard [3]



[1] https://github.com/golang/crypto/blame/326f0c56aaa360d621f27fe3ff4a89735582822c/openpgp/keys.go#L458
[2] https://github.com/golang/go/commit/4fdcb7b684d7719c0beedf247787be06751f1b2c
[3] https://codereview.appspot.com/4551044

fuarrrk YOU ADAM

  No.7670

>>7645
There are other solutions
3)Facilities for package management are provided, but which repo(s) you use can be configured by the user. Think how Emacs does package management. Sure, google could maintain the primary repository, but you could add third-party ones easily.

Also, having google pick which packages are available wouldn't necessarily be a bad thing. While the company itself is somewhat shady, I can't really see any drawbacks to letting them manage libraries for their own language, especially if other people are free to make their own repositories. They certainly have the resources to do a good job of it. I would have preferred that to the GitHub approach.

  No.7672

>>7670
"distributed" is a good thing, "fragmented" is not. Do you really want to dig through the web to find the 8 different repositories you need just to build something? Because of course everybody will be too cool to put their packages on the most popular ones.
>having google pick which packages are available wouldn't necessarily be a bad thing
They already do, it's called the standard library. The great thing about git import is that you can get packages that are so obscure or experimental they'd probably never make it into any moderated repository.

  No.7685

>>7672
>The great thing about git import is that you can get packages that are so obscure or experimental they'd probably never make it into any moderated repository.
What's wrong with just using 'git clone'?

  No.7718

>>7257
As I already said in >>7172 ("mylibrary") you don't have to use any resolvable domains. You can self-host your code (most CVSes are supported), you can use meta rule in html on your website (like rsc.io/pdf), you can ignore github-style naming and make your package "incompatible" with 'go get' tool.

>>7320
Imported, yes. Referred in code as "directory", no.
You need to use my_package.ExportedFunction() to access something. Even if your package is in directory/pulled/out/of/my/ass/

It's stated in docs, that it's a good thing to name the directory the same way you name your package. It could be confusing to have package imported as "foo/bar", which you access with "baz" in code.

You can't have multiple packages in one directory.
If you use "package main", then it will be compiled to an executable and it will not be possible to import it.

>>7648
>it could be written somewhere more clearly
https://golang.org/doc/effective_go.html#package-names
>Another convention is that the package name is the base name of its source directory; the package in src/encoding/base64 is imported as "encoding/base64" but has name base64, not encoding_base64 and not encodingBase64.
https://golang.org/ref/spec#Package_clause + #Import_declarations
>A package clause begins each source file and defines the package to which the file belongs.
>The import names an identifier (PackageName) to be used for access and an ImportPath that specifies the package to be imported.
>If the PackageName is omitted, it defaults to the identifier specified in the package clause of the imported package.

These two links are a must-read, especially Effective Go. Whole pages.

>>7670
Oh, but there is package management provided. It's called 'go get'. And the repo can be can be configured in package's import line.
Protip: packages "dicks/whatever" and "localhost/something" will try to be resolved first, if not already present in $GOPATH.

There are countless Go packages, no one at Google got time to manage them all. You have DNS and hosting in repo of your choosing. Don't like GitHub? Don't use it. BitBucket is supported out of the box. Google Code is, Launchpad is. Have own server? Bazaar, Git, Mercurial and Subversion are supported. Have own domain/website, but don't want to host code repo? Use HTML's <meta> tag.
https://golang.org/cmd/go/#hdr-Remote_import_paths

>>7685
The fact that you can make 'go' command to do it for you?

  No.7721

>>7718
>The fact that you can make 'go' command to do it for you?
Why would I want that? I can always download source code and stick it into somewhere my language can find it. I don't need support from a website or the language; I can just use the existing source control tools. The only reason to use a special tool is to manage dependencies and versions, but that's a package manager.

  No.7744

>>6767
>If Go had any less features, it wouldn't be turing complete.

No, it would be C then.

  No.7752

>>7744
C without pointer arithmetic, macros, do/while loops, and so on.

  No.7766

>>7721
because automatic recursive dependency resolution that justwerx (tm)
and don't you fuarrrking dare tell me about submodules

  No.7822

>>7752
Macros are not a good idea.

  No.7823

>>7822
Sounds like "нинужна" or "if I do not need it, nobody needs".

  No.8686

File: 1440165131694.png (57.49 KB, 200x133, 1363211919.jpg)

Go 1.5 is released

https://blog.golang.org/go1.5

>The compiler tool chain was translated from C to Go, removing the last vestiges

>of C code from the Go code base. The garbage collector was completely redesigned,
>yielding a dramatic reduction in garbage collection pause times. Related
>improvements to the scheduler allowed us to change the default GOMAXPROCS value
>from 1 to the number of logical CPUs.

Unfortunately:
>Changes to the linker enable distributing Go packages as shared libraries to link
>into Go programs, and building Go packages into archives or shared libraries that
>may be linked into or loaded by C programs.

  No.8692

File: 1440197161269.png (755.73 KB, 200x152, giphy.gif)

>>8686
>shared libraries
I suppose it had to happen at some point

  No.8703

I recall someone from the Go devteam said they were surprised people are using Go as a replacement for Python.

Cannot find a damn link.

  No.8704

>>8703
s/a damn/the damn/

  No.8717

>>8703
For me it is a replacement for C for writing native programs easily, especially if you need networking. And the concurrency is amazing. Webdev is easier in scripting languages like Python though.

  No.8728

>>8717
If Go will bring the C nerds halfway to Lisp, then maybe I can learn to hate Go a little less. Buffer overflows should have stopped being acceptable in application code over a decade ago.

  No.8730

>>8728
>If Go will bring the C nerds halfway to Lisp
why would it do that exactly?

  No.8735

>>8730
It's close enough to C to trick them into using a language without pointers or manual memory allocation, but it does have first class functions and a garbage collector. Every time you read about an exploit involving writing past the end of an array, remember that in most modern languages that isn't possible.

  No.9688

>>8735
but golang has pointers,just no pointer arithmetic

  No.9694

File: 1442939476425.png (272.96 KB, 200x200, opiniondiscarded1.jpg)

>>6924
Typical person who does not understand Go.
Go to hell.

  No.9701

>>9694
not the same guy but
not a lot of people like go.
With better designed languages out there such as those of the applicative/functional type, other more popular C descendants such as swift rust and nim, and filling no particular niche, go isn't going anywhere.

  No.9826

>>9701
i'm not a go enthusiast but certainly rust, swift and nim also have their weaknesses

for example, i happen to know that swift is still under heavy development by apple and nowhere near finished, and rust always seemed too obscure for me to even find out details about it. i never even heard of nim

go does fill a niche:
- simple, shallow language, especially compared to c++: this puts a limit on the complexity of programs so people can learn the language more easily
- statically typed
- has a compiler and is fast. i would agree that we don't need another slow SCRIPTING language

seriously with all the hype in some places i would think that go most certainly fits some scenarios. isnt that written up somewhere? i mean google created go for a reason? i'm too lazy to look atm

  No.9829

>>9826

Google did Go the same way they did Dart, and all their other proprietary languages, OSs, frameworks, etc, etc, and that is to make you do it the Google way.

That is not bad, or sinister. Its just Google wants to build an 'everything' platform, that their A.I. can eventually step into and control.

A huge part of Go is about writing for the App Engine platform from what I've experienced, in a way that Google can most easily collect data from and consume, and further expand their web services footprint. Yeah, you can use Go outside AP, but to fully leverage it, and have a higher value prop than other languages, you're gonna look to make it for the Google Cloud infrastructure.

Personally, I'd rather stay with something firmly in open standard hands, as Google is very much a 'dead man walking' with its current direction. The apocalyptic impact for Google, Apple, MS, etc, from Prism and such has the best and brightest waking up to the need for as decentralized and free (free as in wild) a global network as can be conceived. That means tossing out things such as HTTP, a technology that Google has a lot riding on, and creating a far more complex, dispersed, yet robust with more potential network.

TLDR: To make sure nation states and oligarchs don't control the web, the web will remake itself beyond their control, thus making Google and its tech obsolete much faster than many would expect.

Sorry for the rant.

  No.9830

>>9829
Fuck, I forgot that Dart even existed.

  No.9831

>>9830

Yeah, my experience with Dart is it is everything wrong with Javascript reworked and made everything wrong with Dart. Also threeDart didn't stack up to three.js when I tried it.

  No.9892

>>9826
google didn't create go, it was just 2 google employees who did it on their own.

It's seems great for small projects. IPFS and Syncthing are both written in go and I am nothing but impressed by them.

  No.10717

File: 1445273358492.png (370.96 KB, 162x200, cover.png)

First chapter available:

http://www.gopl.io

  No.10719

I don't consider Go much of an improvement over C, but only if you define C not to be GNU C or ANSI C, nor even K&R C, but Plan 9 C. On any other platform (Linux, OS X, Windows), though, the sanity of the interfaces is a godsend. On that note, I suggest that anybody who likes Go's ideas should look at Plan 9 C to see where Pike and the gang were coming from. It'll open your eyes.

  No.10721

go is literally 2015 - 50

  No.10735

>>10717
couple MEAP books on Go out there now as well
- Go in Action by Kennedy et al
- Learn Go by Youngman

some serious soykaf talk ITT...

  No.10832

>>10735
Cool, cool. I think I will give Go a try during winter break... maybe. I feel like I "language-hop" a lot.

  No.10936

>>10717
I'm holding off learning Go until this book gets released

  No.10939

>>10721
What do you mean?

  No.10941

>>10939
My interpretation is that the language will become popular and be in use until 2050

  No.10943

Golang is better than most blub languages, but its low adoption rate and some questionable designs (like no interfaces and difficult to shut off the GC) make me choose to not use it much.

  No.10957

>>10939
I mean that it's a huge step-back, Go decided to ignore 50 years of PLT. A true disgrace for computer science. Go is the language of the future for the programming techniques of the past: it creates a new generation of coding bums.

  No.10959

>>10957
The anti-go brigade strikes again! I can't wait to hear about how any language without generics is useless.

  No.10961

File: 1445798341336.png (29.03 KB, 195x200, cirno2.jpg)

>>10959
Go is bad because it exists to make companies productive, not programmers. Learning Go now is like being an early Java adopter.

>Employers much prefer that workers be fungible, rather than maximally productive.

http://www.loper-os.org/?p=69

>Some programmers find it fun to work in; others find it unimaginative, even boring. In this article we will explain why those are not contradictory positions.

>Go was designed to address the problems faced in software development at Google, which led to a language that is not a breakthrough research language but is nonetheless an excellent tool for engineering large software projects.
>It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical.
>Gofmt also affects scalability: since all code looks the same, teams find it easier to work together or with others' code.
https://talks.golang.org/2012/splash.article

Reading between the lines, Go is a language intended to make recent college graduates productive in writing code that other recent college graduates can understand well enough to replace them at a moment's notice. This is one part of Google's labor exploitation strategy.

Hiring Collusion
http://www.theguardian.com/technology/2014/apr/24/apple-google-settle-antitrust-lawsuit-hiring-collusion

Saturating the Labor Pool
https://code.org/about/partners

Deskilling Programming
https://golang.org/

Remember that when a cabal of software corporations say there is a shortage of programmers there is an obvious bias. What looks like a labor shortage to an employer may look like a surplus to an employee.

  No.10962

>>10943
Of course there are interfaces.

  No.10963

>>10962
Sorry, I meant generics, not interfaces.

  No.10995

>>10961
I don't see how this is bad. All companies need programmers and most of programming is easy, CRUD/API stuff that should not pay six figures.

  No.11018

>>10995
>I don't see how this is bad. All companies need programmers and most of programming is easy, CRUD/API stuff that should not pay six figures.
Programming is hard. The CRUD/API stuff isn't hard for a trained individual but training an individual to a point where they can actually generate value is very time consuming and/or expensive. Teach them programming at some college and then if they're not using Java at their job like they were at school they now have to learn some new server side language. Either way they'll have to learn JavaScript for the client side. They have to learn enough CSS and HTML to make a basic web page. They'll need to know HTTP. They'll need to know the operating system of their shitty web server, they'll need to understand one or more text editors and debuggers or a whole fully featured IDE. These are only the tools and basic technologies they need to understand. On top of them they need to know how to program. That means software design, which is a topic of its own that has entire books written on it. They need to know security. They need practice. They need to know how to self teach anything they don't know. It takes years of study to get half decent at all of this.

Programming is very hard.

  No.11022

I think Go is just a meh language. It does some stuff well, and some stuff not so well and a lot of that stems from its simplicity.

Go has no exceptions. Instead code is littered with:

res, err := do_something_that_might_fail()
if err != nil {
// handle error
}

This makes for ugly and rather verbose code, but generally forces you to deal with errors outright. However, it's easy to get into the habit of just using a _ in place of an error or calling a procedure with side effects without checking if it has an error. You can attempt to emulate exceptions with panic() and recov(), but theses are honestly shitty alternatives.

The type system has some issues. The main one is interface{}, which allows for anything to be passed in as a type. Rob Pike himself says to be careful of code which relies on interface{} and Reflect to deal with them, and it's for good reason.

I think the duck-typed interfaces are definitely one of the better parts of the language, you can do all sorts of neat stuff with them. I also appreciate Go's take on OO which I do personally prefer to inheritance.

From a concurrency standpoint Go really isn't very significant. Erlang has had its powerful Actor based system for decades and I think it's a much better system than CSP honestly. Concurrency is honestly much more difficult in the imperative paradigm. Languages like D and Rust have recognized this and created a decent set of functional-like data structures to help solve these problems, but Go has none of that. When you compare an Erlang OTP GenServer to some big unwieldy for { } loop with 50 different case statements in Go, there's just no comparison between which is simpler, cleaner, and more understandable.

I really dislike Go's tooling. It just feels inferior to those of Elixir and Rust and the $GOPATH stuff is a big pain to deal with. I do appreciate go fmt, especially its auto-alignment of stuff like struct fields, though I'm not a fan of it using tabs instead of spaces.

Overall I say if you're looking to learn a new language Go shouldn't really be the one. Languages like Rust and D are better at the systems level, and Erlang/Elixir at concurrency.

  No.11031

>>11022

Why not just:

if ( do_something_that_might_fail() != nil) { ... }

  No.11033

>>11031
I assume the function has multiple return values that he wants to assign variables to.

  No.11036

>>11018
>Programming is hard. The CRUD/API stuff isn't hard for a trained individual but training an individual to a point where they can actually generate value is very time consuming and/or expensive

Not really. If you're an intelligent individual you can learn enough to get a entry-level web development job in six months, assuming you study full time and do projects. You just start slow and learn one thing at a time.

I have plenty of anecdotal evidence for that, though no real evidence I will admit. A good portion of my liberal arts major friends either taught themselves while serving coffee or attended a bootcamp and are now employed. Of course, I am not sure if they'll get promoted or what will happen to them in five years, but they didn't need much time.

Programming is hard. A lot of programming jobs aren't. That's just the truth.

  No.11055

>>11033
Yes, it's generally nicer(and idiomatic) to do

if err := something_that_might_fail; err != nil {

}

but that won't work when you have a function that actually returns something and isn't used for a side effect, because the scope of your results won't exist outside of the if statement.

  No.11063

File: 1445990191971.png (33.08 KB, 200x100, see_me_after_class1.png)

>>11036
Nothing but anecdotal evidence and an assertion makes a bad argument. See the picture for a more autistic break down of why you're wrong.

Once again.
A) Google is using their resources to drive down wages through collusion, creating a surplus of workers, and deskilling a profession. >>10961
B) Training a programmer is an expensive task taking lots of money and/or time if only because there are so many things a programmer needs to know and be capable of to be productive. I have listed some of those things. >>11018

The thing that annoys me most about you though is the attitude behind the following.
>CRUD/API stuff that should not pay six figures.
Who are you to decide they're paid too much and things need to change? Where does this line of thinking end? Is welding too easy for good pay? What about being an electrician or plumber? Why do you assume the market is wrong and big software corporations and the government need to fix it so programmers are paid less?

  No.11071

>>11063
Luckily programmers have been fighting back.
http://harmful.cat-v.org/software/c++/I_did_it_for_you_all

  No.11074

>>11071
If only this part was a joke too.
>IBM got sick of it, and invested millions in training programmers, till they were a dime a dozen..

  No.11093

>>11071
Good read, but how is it proof programmers are fighting back? If anything, I see the opposite in college students.


  No.11129

Stop bumping this soykaf and learn Java/C++/whatever but not Go.

  No.11151

>>11129
Why?

Go is much saner, easier to understand and more maintainable than c++. And to my knowledge java isn't fully opensource. There is the openjdk but that requires java to compile before you can use it.

  No.11153

Rob Pike is good at making text editors, but he should stay away from programming languages tbh.

  No.11157

>>11128
>They don't care about the hot new framework. The don't care about doing something up to the latest "best practices". They wish to only "get soykaf done".
>Go excels at this practice. It really enables the end developer to just get it done.
The ironing is delicious.

>the problem I see is not that Bill Gates has shaped the world of useless trinkets in software, but has also managed to spread his competitiveness and his personal fear of losing to imaginary competitors to businesses and homes everywhere, so now everybody is _afraid_ of losing some battle which isn't happening, instead of getting about their own lives. like, if you aren't using today's fad language in the very latest version of the IDE, you'll be left behind. aaaugh! but it's good that some people run like they are scared out of their wits. if they suddenly disappear over the edge of a cliff, a good number of people will notice in time and _not_ follow them. those are the ones that matter.

>https://groups.google.com/forum/#!topic/comp.lang.misc/cfwJMt3YX60

Go really is Java.


  No.11422

>>11420
yeah definitely, I saw the chapter preview earlier ITT.

  No.11444

>>11151
Gj grasping at straws:
>Java/C++/whatever
You forgot to notice the last option, highlighting the fact that there's plenty other languages than Java, C++ and Go.

Go is not expressive, not rich in features, not popular outside of Google and Piketard circles, and as a sytems language it's substandard.
>easier to understand
Literally the only thing it has going for it, and is by no means the only contender when it comes to ease of understanding.
>more maintainable than c++
Whoop de fuarrrking do, it's better than C++ at something, someone bring in the medal! C++ is notorious as a jack of all trades, master of none (emphasis on "master of none" here), so any language is better than C++ in some way or another.

  No.11445

Here's an article that does a good job at explaining why Go is so popular these days:
https://honza.ca/2015/11/language-choice

  No.11446

>>11444 Go's actually getting really popular in the world of scalable services because of it produces fast and deployable apps with web functionality builtin. As a language in that space it has serious potential to be huge in the next few years (and we're even seeing it now to an extent) and that's a serious thing. That's a big deal and a serious plus for the language in the long term.

>>11157 How in Lain's name is Go anything like Java? Go's barely a member of the C syntax family and it's focused on concurrency instead of events. The garbage collector is also fast instead of intrusive and historically annoying, and it produces standalone statically linked binaries, the opposite of what Java produces??

  No.11453

>>11446
>Go's actually getting really popular in the world of scalable services because of it produces fast and deployable apps with web functionality builtin. As a language in that space it has serious potential to be huge in the next few years (and we're even seeing it now to an extent) and that's a serious thing. That's a big deal and a serious plus for the language in the long term.
Stop. Read what you have written. It's just buzz words and appeals to popularity. Any language can be used to produce fast and deployable apps with web functionality, whatever that means, and Go doesn't make it any easier. A question to ponder; if Go is so easy to learn why is it so very important that I learn it now?

  No.11455

>>11446
>How in Lain's name is Go anything like Java? Go's barely a member of the C syntax family and it's focused on concurrency instead of events. The garbage collector is also fast instead of intrusive and historically annoying, and it produces standalone statically linked binaries, the opposite of what Java produces??
Go is like Java because it most definitely is a member of the C syntax[0], it is being pushed by a large company, and it prioritizes interchangeable software engineers over abstractions. "Go is efficient, scalable, and productive. Some programmers find it fun to work in; others find it unimaginative, even boring. In this article we will explain why those are not contradictory positions. Go was designed to address the problems faced in software development at Google, which led to a language that is not a breakthrough research language but is nonetheless an excellent tool for engineering large software projects."[1]

[0] https://golang.org/doc/faq#ancestors
[1] https://talks.golang.org/2012/splash.article

  No.11458

>>11455
I think he meant that it's not like Java in the sense that it's a terrible language.

  No.11460

>>11453
It isn't important that you learn it now or if you even learn it at all. I apologise if I accidentally implied that in my response. It's a simple language, there's no stress. But it is becoming popular for the reasons that I outlined, and if you don't believe me look at it's adoption at bigger companies, the New York Times (https://www.youtube.com/watch?v=bAQ9ShmXYLY), Dropbox (https://blogs.dropbox.com/tech/2014/07/open-sourcing-our-go-libraries/) and the BBC (https://blog.golang.org/go-turns-three) immediately spring to mind for me. You can even read a list here (https://github.com/golang/go/wiki/GoUsers). While the fact that a string of companies using a developing language should be nothing surprising, a common theme across the board of their use is how each of these companies produce services that need to scale that handle thousands of requests a day. That speaks for itself. It's a fact that Go's fast (https://blog.golang.org/go15gc) and that concurrency goes hand in hand with distributed services design and that's a major feature and pattern of Go.

>>11455
The syntax features similarities with C that the Go team does acknowledge, but it is still a language that is on the fringe.
The developers list the syntax as being inspired by C here but that doesn't necessarily mean that it is a part of it of the language family. And even still, is the language like Java because of it's similarities in syntax? It's very different at a design and implementation level. I mentioned in my reply that you responded to that the language is prominent in distributed services. That is of Google's interest, and they state in the block that you quoted that they designed the language with their needs in mind.

  No.11468

"go" away.

  No.11470

>>11151
>Go is much saner, easier to understand and more maintainable than c++.
I agree with that, but you do not mention its simpleness. It's easy, that is good, but it's simple.
Another point is syscall package. I have no time to explain this, sorry, vut you understand what I mean.
The third point is community. Google "golang coc". If you do not want to google, i'll try to explain: they wanted to stop accepting pull requests from those who argues a lot. Even if those pull requests are more useful than Pike's.
>And to my knowledge java isn't fully opensource. There is the openjdk but that requires java to compile before you can use it.
OpenJDK does not require Java to compile, lol. That would be as autistic as go (compiler) 1.4.

  No.11473

I'm just going to say that Go, Java, C++, Python, Ruby, et al. are all members of the Algol family of languages.

Examples of languages not in this family include APL, Forth, Lisp, and early Fortran.

  No.11475

File: 1446667136050.png (8.33 KB, 200x200, 1431712235783.jpg)

>>11473
This superficial, meaningless, memetic, discussion-killing "ALGOL family" categorization needs to stop. It has been a favourite hot button for argumentative fuarrrks on Usenet and the Internet to press for decades, and it doesn't help anyone nor foster any productive discussion. It's even worse in the context of education: You have people saying "Oh, if you know Java, C is going to be easy to learn!", when they may as well be saying "Oh, if you know Smalltalk or Eiffel, you're going to have such an easy time learning Fortran!". They're both equally meaningless, and plant this conflation of syntax with semantics in growing programmers' brains, which is a tumour that they must then take it upon themselves, years later, to painfully remove. Where are Go's concurrency semantics in C? Where are Python's dynamic typing or Java's Common Lisp Object System/Smalltalk-style late binding in C++? Ruby is more like Scheme mixed with Smalltalk than anything ALGOL-ish.

You're doing the entire world of programming a disservice by implying that such a loosely-defined "family" constitutes some oppressive paradigm that needs to be broken out of, especially when a considerable portion of the modern world (Haskell, Clojure, Scala, ...) already lives outside of it even by the loosest, weaseliest definitions of "ALGOL-like". Even if the aforementioned languages aren't in somebody's day-to-day-repertoire, more people are more aware every day that they exist.

So, please, fuarrrking stop polluting everyone's mind space by pretending that just being contrarian constitutes insight. Yes, I'm mad.

  No.11483

>>11445
this has nothing to do with Go. he just needed a language to talk soykaf about that wasn't Haskell.

  No.11485

>>11445
>Mind you, the language is objectively poorly designed.
poor·ly  (poor′lē)
adv.
In a poor manner. See Usage Note at poor.
poor (poor)
adj. poor·er, poor·est
2. Deficient or lacking in a specified resource or quality: an area poor in timber and coal; a diet poor in calcium.
3. Not adequate in quality or quantity; inferior: a poor performance; poor wages.

objectively poorly is an oxymoron, literally by definition.

>The error handling

Because exception handling is so delightfully elegant, right.
>the lack of generics
This is a matter of taste and imagination, and can't possibly be an objective judgement.
>the ridiculous package manager
At least the go package manager knows what it is. Cabal is schizophrenic.
>the absurd type system
I'm assuming absurd here means "not algebraic".
>the range thing
It's a lot more regular than other ridiculously decorated loops. (I'm looking at you, Python.)
>It’s almost exactly the opposite of Haskell.
Nah, the opposite of Haskell would be something purely object-oriented.

  No.11487

I just started programming in Go. Coming from C and java, I like it so far and it was really easy to jump into.

Im not sure if I am going to go deep into it(I was originally planning on learning python, not sure about that either) but Im thinking about getting the Go programming language book coming out in a couple days. Anyway thanks for the thread it was a good resource to inform me about the pros and cons of go.

  No.11492

>>11475
I disagree with you.

Your C and Java comparison is a good example. They have a similar syntax, are both very weak languages, have similar scoping conventions from what I know, and share many other semantic qualities, like expressions and statements being different just as functions and operators are different, for no real reason.
C requires some manual memory management and is filled with undefined behavior. Java has OOP and runs on a VM. They have other differences, but they are still much more similar to each other and other members of the Algol family then they are to languages outside of that family.

>"Oh, if you know Smalltalk or Eiffel, you're going to have such an easy time learning Fortran!"

Fortran is not a member of the Algol family. I don't know much of anything about Eiffel.

Please don't compare a language like Ruby to anything in the Lisp family. It's clearly not true and gets old. Ruby isn't even homoiconic.

You should be able to realize that the Algol family is characterized by complicated syntax describing complicated semantics, followed by scope delimiters, be they {}, begin end, or Python's whitespace, and a general lack of power in comparison to other languages.

If you want more proof, know that C is derived from B, which was derived from BCPL, which was derived from CPL, which was derived from Algol 60. C is just a more tedious and less powerful derivative of Algol derivatives.
C++ is a derivative of C and heavily influenced Java and other Algol clones, like PHP.
I'll let you discern the similarities with the other Algol lookalikes, such as Ruby, Python, and Go.

  No.11500

>>11492
>Fortran is not a member of the Algol family.
Neither is Smalltalk. I'll give you a hint: They're wildly different. So are C and Java. Sure, on the surface, some operations are vaguely the same, but you can't solve anything of scale in either with only working knowledge of the other. There are no unboxed values in Java; everything is behind a level of indirection. Primitives may not exist outside objects. The only difference, semantically, from Smalltalk, is the fact that primitives even exist. Yes, it's superficially similar to C, but you'd have a better time teaching somebody Smalltalk and then showing them Java than teaching somebody C then showing them Java.

>Please don't compare a language like Ruby to anything in the Lisp family. It's clearly not true and gets old. Ruby isn't even homoiconic.

Don't get upset that your sacred cow is getting whipped. I didn't even say it took any of Scheme or Smalltalk's *good* qualities, like homoiconicity. As a matter of fact, the quote that comes to mind is: "Ruby is Scheme mated to Smalltalk such that both failed to exert a phenotype." --anonymous

>You should be able to realize that the Algol family is characterized by complicated syntax describing complicated semantics, followed by scope delimiters, be they {}, begin end, or Python's whitespace, and a general lack of power in comparison to other languages.

If you think complex syntax is a trademark of the "ALGOL family" you're delusional.
http://xahlee.info/UnixResource_dir/writ/lisp_problems.html
A lack of power also comes to mind with anaemic parallelism and concurrency in non-purpose-built Lisps, or even when it is full-featured, it's a ridiculously intricate afterthought:
http://xahlee.info/comp/Guy_Steele_parallel_computing.html
For the record, Scheme's main feature over earlier Lisps is ALGOL-style lexical scoping, instead of older Lisp's historical accident of a dynamic scoping system. I bet you'd be reluctant to call Scheme a member of the ALGOL family, though, because, while it's about as sensible as your baseless, meaning-destroying categorizations, it puts something you appreciate into a group you have reserved for "things I don't like".

>If you want more proof, know that C is derived from B, which was derived from BCPL, which was derived from CPL, which was derived from Algol 60. C is just a more tedious and less powerful derivative of Algol derivatives.

I'm not going to address your opinion on C, but I never denied that C has a long, twisty family lineage to ALGOL. It's a leap to say that block scoping makes anything ALGOL-like though.

Taxonomy, among other bookkeeping, truly is the lowest form of science, and it can not only be mindless, but *harmful* when it attempts to synthesize meaning out of thin air. Using it to express an opinion is an equally heinous crime. Stop using ill-defined categories to pass judgement.

  No.11512

>>11500
I don't know enough about Smalltalk to comment. I failed to mention a particularly telling characteristic of the Algol family, which is both the semicolon and all of the reserved keywords you find in these languages. Now, some languages have keywords, like Fortran, but older Fortran is not structured like Algol, among other differences.

Now, you may say, "But Lisp has special forms and that's the same thing." but I would disagree. Common Lisp has a module system that allows you to assign any meaning to any symbol and you can easily override even the dreaded parenthesis syntax by manipulating the readtable, among other things.

Forth is a language with almost no syntax. Words are separated by spaces and some words, like : ;, if then, and for next, have to be matched up, if you don't change their definitions before using them.

APL has primitives, but you also need a special input method just to use it and so I wouldn't consider them reserved keywords. There are probably APL systems that allow you to redefine them if you really wanted to.

Meanwhile, Go has implicit semicolons and boasts about a compiler hack from, none other than, BCPL.

https://golang.org/doc/faq
>Go uses brace brackets for statement grouping, a syntax familiar to programmers who have worked with any language in the C family. Semicolons, however, are for parsers, not for people, and we wanted to eliminate them as much as possible. To achieve this goal, Go borrows a trick from BCPL: the semicolons that separate statements are in the formal grammar but are injected automatically, without lookahead, by the lexer at the end of any line that could be the end of a statement. This works very well in practice but has the effect that it forces a brace style. For instance, the opening brace of a function cannot appear on a line by itself.

>Don't get upset that your sacred cow is getting whipped. I didn't even say it took any of Scheme or Smalltalk's *good* qualities, like homoiconicity. As a matter of fact, the quote that comes to mind is: "Ruby is Scheme mated to Smalltalk such that both failed to exert a phenotype." --anonymous

That's a funny quote.

>If you think complex syntax is a trademark of the "ALGOL family" you're delusional.

That was poor phrasing on my part. I was primarily talking about all of the reserved keywords and other syntax one must learn. It's rather strange to me.

>A lack of power also comes to mind with anaemic parallelism and concurrency in non-purpose-built Lisps, or even when it is full-featured, it's a ridiculously intricate afterthought:

That's a fair point. The problem is with the lack of standardization. You just have to chain yourself to an implementation or use a library that gives a common interface over many implementations.

>For the record, Scheme's main feature over earlier Lisps is ALGOL-style lexical scoping, instead of older Lisp's historical accident of a dynamic scoping system. I bet you'd be reluctant to call Scheme a member of the ALGOL family, though, because, while it's about as sensible as your baseless, meaning-destroying categorizations, it puts something you appreciate into a group you have reserved for "things I don't like".

I wouldn't consider Scheme a member of the Algol family just because of that.
I really am sorry for being rude earlier. Just now that I find it strange to look at a language like Go, where you can't mess with the compiler on a whim (Unless I'm wrong?), and I call that less powerful. It's alien to me to look at a language where you have to be so redundant and verbose.
I'm not trying to be a zealot. I just firmly believe that most of these languages out nowadays are just superficially different flavors of Algol and I feel I've made the case for that. I didn't insult Go in >>11473, I just stated what I felt was a reasonable assertion.

  No.11513

>>11500
>>11512
>I'm not going to address your opinion on C, but I never denied that C has a long, twisty family lineage to ALGOL. It's a leap to say that block scoping makes anything ALGOL-like though.
I have now pointed out many other similarities.

>Taxonomy, among other bookkeeping, truly is the lowest form of science, and it can not only be mindless, but *harmful* when it attempts to synthesize meaning out of thin air. Using it to express an opinion is an equally heinous crime. Stop using ill-defined categories to pass judgement.

I don't feel that I've done anything wrong and I continue with my belief that these languages are simply versions of Algol.

Once again, I'm not trying to be rude or ruin this thread or anything like that. I would like to know why you like Go, if you'll tell me.

  No.11520

>Meanwhile, Go has implicit semicolons and boasts about a compiler hack from, none other than, BCPL.
So does Haskell, albeit merged with Python's off-side rule, such that specifically aligned whitespace inserts semicolons and braces in constructs like "do", making both
take m ys = case (m,ys) of
(0,_) -> []
(_,[]) -> []
(n,x:xs) -> x : take (n-1) xs

and
take m ys = case (m,ys) of {
(0,_) -> [];
(_,[]) -> [];
(n,x:xs) -> x : take (n-1) xs;
}

equally acceptable; in fact the former renders to the latter. Haskell isn't exactly ALGOL-family.

Also, I wouldn't say Go *brags* about borrowing the trick from BCPL, but rather gives credit where credit is due. There, you could indeed deduce a specific link, but it's not like the feature is a specific mark of the ALGOL family, as seen in the Haskell example.

>I was primarily talking about all of the reserved keywords and other syntax one must learn. It's rather strange to me.


Inflexibility to one person is consistency to somebody else, and consistency is key in large-scale development. Imagine the chaos that would ensue if choice of keywords were up to a *style guide* in a large project. Go is built for development in the large. However, unlike Java, Go was not built explicitly for people dumber than the creators, otherwise Rob et al. would still be using C. In fact, they wrote a language *they* wanted to use.

>Just now that I find it strange to look at a language like Go, where you can't mess with the compiler on a whim (Unless I'm wrong?), and I call that less powerful. It's alien to me to look at a language where you have to be so redundant and verbose.


See above, although the compiler's mechanics are mostly found in the standard library. For instance, gofmt (pretty prints to the vetted format) is a relatively trivial application that uses the standard library's built-in resources for manipulating the language's AST. It parses, but does not lex, then spits out the AST pretty-printed. This isn't accessible at run time on the code itself, since it's compiled, sure, but the language is far easier to manipulate itself with, than, say C. At the cost of being even less syntactically flexible than C, the grammar *is* much simpler, and as a result, it's remarkably easy to write utilities of this style.

>I would like to know why you like Go, if you'll tell me.

You'll find a lot of reasons in what I just typed. There are probably others.
The most important, I suppose, is that I actually enjoy writing code in it, and going back to Python, Ruby, Java, C++, or GNU/POSIX/BSD C just feels depressing. The only languages that I *enjoy* as much as Go are probably Plan 9 C and R5RS Scheme.

  No.11523

>>11520
Any resources for learning Plan 9 C? I keep hearing that it is the only sane way to write in C.

  No.11524


  No.11527

>>11520
>Haskell isn't exactly ALGOL-family.
I don't know enough about Haskell to determine if I would call it a member of the Algol family or not.
We don't exactly agree on what constitutes the Algol family or not.
What differentiates Haskell from other languages, asides from its using pure functions where other languages have procedures?

>Inflexibility to one person is consistency to somebody else, and consistency is key in large-scale development. Imagine the chaos that would ensue if choice of keywords were up to a *style guide* in a large project.

The languages I use don't have keywords, so I can't relate to your example. Heavily modifiable languages seem to do just fine with their compiler hacks and relatively massive changes to the language.

>Go is built for development in the large. However, unlike Java, Go was not built explicitly for people dumber than the creators, otherwise Rob et al. would still be using C. In fact, they wrote a language *they* wanted to use.

That sounds like a fair enough justification. Of course, the people designing the language get to decide what they want, while modifiable languages let everyone decide what they want. Go gets a lot of flack for not including generics, apparently. Imagine being able to add them, or anything else, yourself.

>See above, although the compiler's mechanics are mostly found in the standard library. For instance, gofmt (pretty prints to the vetted format) is a relatively trivial application that uses the standard library's built-in resources for manipulating the language's AST. It parses, but does not lex, then spits out the AST pretty-printed. This isn't accessible at run time on the code itself, since it's compiled, sure, but the language is far easier to manipulate itself with, than, say C. At the cost of being even less syntactically flexible than C, the grammar *is* much simpler, and as a result, it's remarkably easy to write utilities of this style.

Being better than C doesn't really strike me as impressive. Even Forth has words that do things like print the source for a word dynamically and usually printy-printed. It's called SEE.

>You'll find a lot of reasons in what I just typed. There are probably others.

>The most important, I suppose, is that I actually enjoy writing code in it, and going back to Python, Ruby, Java, C++, or GNU/POSIX/BSD C just feels depressing. The only languages that I *enjoy* as much as Go are probably Plan 9 C and R5RS Scheme.
That's fair enough. I'm not telling you your preferences are wrong or anything.

  No.11528

>>11527
>What differentiates Haskell from other languages, asides from its using pure functions where other languages have procedures?

Purely-functional, and models state and side effects through monads. Has plenty of methods for creating operators with the associativity and precedence you want. Some call it Lisp's missing M-expr engine.

>The languages I use don't have keywords, so I can't relate to your example.

What languages do you use?

>Of course, the people designing the language get to decide what they want, while modifiable languages let everyone decide what they want.

Sure. It just so happens that what I want coincides with what some ex-Bell Labs researchers on display at Google wanted. And what plenty of other people want, judging by usage.

>Go gets a lot of flack for not including generics, apparently. Imagine being able to add them, or anything else, yourself.

There would be little point. They would be as out-of-place an abstraction, as, say, a system to create static, restricted objects (C++ style) in Common Lisp, where the dynamicity of CLOS is idiomatic.

>Being better than C doesn't really strike me as impressive.

I think you missed the idea here. The point is that the tools are there, and you can do manipulation of source at any stage of compilation. The pretty-printer is just one of uncountable possibilities. Especially since the self-hosting release, it becomes incredibly easy to mess with the compiler, especially given the lightning-fast compiles that people love Go for.

  No.11530

>>11528
>Purely-functional, and models state and side effects through monads. Has plenty of methods for creating operators with the associativity and precedence you want. Some call it Lisp's missing M-expr engine.
I really wish either I knew enough about Haskell or we had a third party to give an opinion on it.

>What languages do you use?

Forth and Lisp are two languages I use.

>Sure. It just so happens that what I want coincides with what some ex-Bell Labs researchers on display at Google wanted. And what plenty of other people want, judging by usage.

What about when you want something and they don't?

>There would be little point. They would be as out-of-place an abstraction, as, say, a system to create static, restricted objects (C++ style) in Common Lisp, where the dynamicity of CLOS is idiomatic.

I've seen plenty of "pointless" things that can be done in Lisp, but that doesn't mean I wouldn't want to be able to do them.
CLOS was originally designed as macros on top of the base system.

>I think you missed the idea here. The point is that the tools are there, and you can do manipulation of source at any stage of compilation. The pretty-printer is just one of uncountable possibilities. Especially since the self-hosting release, it becomes incredibly easy to mess with the compiler, especially given the lightning-fast compiles that people love Go for.

Out of curiosity, how large is the Go compiler, in terms of LoC?

  No.11545

>>11530
>I really wish either I knew enough about Haskell or we had a third party to give an opinion on it.
Just one important thing: Operators are just functions with an optional special syntax. The names are semantic to how they're parsed. All alphanum makes it prefix; symbols make it infix. You can make binary prefix functions infix by doing op1 `func` op2, and infix into prefix by doing (+) 1 2.

>Forth and Lisp are two languages I use.

Neat, we match up on Lisp.

>What about when you want something and they don't?

I don't know. I don't run into this problem, really. Call it stockholm syndrome, but I'm happy to be a little verbose once if the compiler can, for the most part, blaze through it for the large number of times that code is going to get built.

>Out of curiosity, how large is the Go compiler, in terms of LoC?

Can't remember off the top of my head, but here's a mirror of their repository: https://github.com/golang/go

  No.11546

>>11530
As an addendum to >>11545
https://github.com/golang/go/tree/master/src/cmd/compile

Here is the relevant subdirectory.

  No.11573

I needs easy GUI creation features. Specifically a visual GUI manager.

  No.11574

>>11573
>Specifically a visual GUI manager.
not sure this exists. there are binding libraries for all the usual frameworks, nothing polished though.

  No.11693

There's no reason to be using Golang when Nim can do everything it does but better (except arguably coroutines).

  No.11696

>>11693
Nim has nowhere near the level of corporate backing that Go does, which (like it or not) is a large factor in deciding how successful a language will be. Go also has a better standard library than Nim. However I agree with your point about Nim being more powerful.

  No.11720

>>11696
>how successful a language will be
What does this even mean?

  No.11740

>>11720
s/successful/popular/

  No.11866

It seems that golang does not suck at properly handling unicode, unlike... others.
https://www.azabani.com/pages/gbu/

  No.11874

>>11866
>unlike... others.
You mean Perl. Perl is still kicking ass in 2015 and nobody seems to have learned anything from it except to encourage readable code.

  No.11893

>>10961
I don't understand why making programming languages easier is bad. IMO the more people who know how to program the better it is for our society. Even if most of them are crap programmers the total amount of quality programmers will go up.

Decreasing the value of programmers may be bad for programming wages but demanding more arcane languages like C++ is not the answer.

Its like fully automated production. It can lead to an imbalance between capitalists and the proletariat. But the solution isn't to ban fully automated production. Its to undo the system where everyone must work to live.

  No.11894

>>11893
>I don't understand why making programming languages easier is bad.
Nobody is saying that. It's bad to prioritize easiness over other values in order to exploit programmers. Why do you think so many people hate Java?
>IMO the more people who know how to program the better it is for our society.
Better for society can mean many things and does not necessarily mean better for the people belonging to the society.
>Even if most of them are crap programmers the total amount of quality programmers will go up.
If the supply of quality programmers goes up, the demand goes down, and wages drop. Unless you're a large software company, that's bad.
>Its like fully automated production. It can lead to an imbalance between capitalists and the proletariat. But the solution isn't to ban fully automated production. Its to undo the system where everyone must work to live.
Unions would be a nice start.

  No.11900

>>11874
uh.. no I meant everything mentioned in the presentation except perl and golang. Because they all don't seem to implement a significant amount of the (admittedly huge amount) of standards related to unicode, wtf.

I actually had messed around with unicode in JS an thought everything was fine but that doesn't seem to be the case. I did not know unicode from utf-8 before so yeah

I like that this seems to have been considered from the very beginning in golang so they dont have to worry about legacy shit

  No.11918

>>11894
> If the supply of quality programmers goes up, the demand goes down, and wages drop.

The surplus of programmers isn't the problem. And I still maintain it is good. Wages dropping is the problem. Unions as you suggest, is a solution but I think wages is the root cause. More libre software and libraries puts the means of production back into the hands of proles and for more libre software we need more programmers.

  No.11928

>>11071
this is a known hoax

  No.11930

>>11928

I thought it was obvious satire.

  No.11931

>>11918
Not the guy you're responding to, but

>The surplus of programmers isn't the problem. And I still maintain it is good. Wages dropping is the problem

If you admit that wages dropping is the problem, then surely you shouldn't be in favor of something (a surplus of programmers) that directly causes it?

>More libre software and libraries puts the means of production back into the hands of proles

See, that would only be effective if the vast majority of programmers were or intended to be freelance entrepreneurs. For employed programmers, though, making libre software can be a gratifying exercise, but won't put food on the table.

  No.11936

>>11918
>More libre software and libraries puts the means of production back into the hands of proles and for more libre software we need more programmers.
That's only true for copyleft licensed software. Permissive licenses like the MIT just provide corporations free labor.

  No.11941

>>11931
Let sp = surplus of programmers
Let lw = lower wages for programmers
We agree that sp -> lw and lw is bad.
Your conclusion is that sp is also bad. I say sp is good and the association (sp -> lw) is bad. So instead of fighting to make sp not true we should fight to make (sp -> lw) not true.

>>11936
Interesting please elaborate.

  No.11942

>>11941
>The modern trend in FOSS is away from the GPL and towards MIT/BSD. That's no surprise, because GPL is awkward for corporations. Red Hat endorses the MIT/BSD model. And as corporations encourage the development of these new liberal licenses, we find that Stallman is being exorcised as an aging hippy, not 'with it', an embarrassment, uncouth, and so on. In plain terms, Stallman has outlived his usefulness as a stooge. There are better and brighter ways to encourage FOSS than the aging GPL. Goodbye Mr Stallman.
http://www.shenlanguage.org/lambdassociates/htdocs/blog/the_problems_of_open_source.htm

I don't agree with everything in here, but you get the point.

  No.11947

>>11941
>we should fight to make (sp -> lw) not true

How? Let's say you find a way to fix wages at an artificially higher level. What would happen is that companies would hire less. This would be good for the remaining employees, as they would not only have higher salaries but would also be encouraged to explore unconventional programming languages and concepts to make up for the lower number of people working on a project. However, when you add lower hiring to a surplus of programmers, you get a lot of joblessness. Sure, some of these programmers could become freelance entrepreneurs, but it would still be a net loss in terms of job security for a large number of people.

  No.11948

>>11941
This is a simple example of supply and demand. Supply goes up, demand goes down. Surplus always leads to lower demand.

  No.11952

>>11948
No soykaf that's the current case. The idea is to try to create a scenario where people are not products and not subject to supply and demand.

>>11947
I'm not suggesting wage fixing I'm just saying we need to think out of the box and have A solution. I think the solution is to replace wages with something else. What that is I don't know.

More skilled and educated people _should_ lead to a more prosperous society for all but instead it impoverishes many and only strengthens few. I don't want a society that works that way.

nb cause we are real off topic now and should probably start a new thread.

  No.11958

>>11952
>I think the solution is to replace wages with something else.

Fair enough. I suppose you could make something like, say, a programmers' guild. Not that that wouldn't have a few problems of its own, of course.

  No.11959

>>11952
>No soykaf that's the current case. The idea is to try to create a scenario where people are not products and not subject to supply and demand.
It wouldn't be a surplus unless there were more than needed. That is always the case.

  No.12546

Go haters and go lovers read this:
http://www.jerf.org/iri/post/2945

  No.13819

I'm reminded of Ada, which is also built around a lack of metaprogrammability and hacks meant for large organizations.
What does Go offer over Ada?

  No.13822

>>13819
nothing over what you would be using Ada for really. Go uses a different concurrency model, if that has any serious consequences I have no clue. The type system in Go is a lot weaker. Can't speak for Ada's standard library but that's one area where Go shines imo.

  No.13828

My opinion on go is based on how it's being marketed.

1) As being an alternative to Java?
Might work. Needs mature web frameworks and a larger base of coders.

2)As being an alternative to Erlang?
Sure does similar things in a different way. Similar programmer base. I buy it.

3)As being an alternative to C++?
I sympathize, but I don't buy it for most applications. The things that C++ more dangerous make it faster, and more flexible. If you're in absolutely top performance situation, picking an *easy* language shouldn't be your priority.

4) As an alternative to C?
lol no. If you're using C in the right places for the right reasons, Go will never be able to compete. Again, for the same reasons C is dangerous, it is fast, and flexible.

Will we over implement a heap manager in a language like go? No.

An operating system? No.

A high performance video game? No.

Scientific computing? No.

High performance instrumentation? No.

Real time applications? No.

It, by it's very definition cannot do these things. I think the danger of go, is that programmers ready to finally accept that pointers are real, and memory is worth worrying about will take the easy route and learn go instead of C.

Google uses 1000% more C++ and Java than Go. Infer what you will from that.

  No.13834

I like extensibility an Go doesn't, so I don't like Go.
It sounds like something easy and fast which would be nice but I can competently write safe, fast code in C++ or write slow, clear code in Python so it doesn't appeal to me.

  No.13839

>>11520
>>11523
Holy soykaf Plan9 C looks amazing. Actually sane C, having looked at a tutorial for 10 minutes puts the cryptic, awful C stdlib into perspective.
Honestly, "getchar", "fgetc", "gets", "fgets", "puts", "printf", two-argument sizes for soykaf like "fwrite", inconsistent argument order for where the FILE* handle goes.
Enjoying standard C is nothing short of Stockholm syndrome.

  No.13841


  No.13843

>>13841
Yeah but at the same time the compilation times are getting longer and the resulting binaries are getting larger. Hello world is now 2.3MB. I hope that they will for on that for the next release.

  No.13867

>>13843
C coders are laughing their asses off.

  No.13870

You have no idea how happy I am that I can compile my program without 4 automake tools, 3 makefiles and a huge wall of commands scrolling on the screen. The Go toolset is really nice.

  No.13872

>>13867
[tips C string handling and smile]

  No.13873

>>13843
who cares about the size of binaries in this day and age of cheap storage? i wouldn't complain about a return to the stupid fast compile times of <1.4 but even now things aren't so bad.

if you want to know what is happening with 1.7 then check the mailing list:
https://groups.google.com/forum/#!topic/golang-dev/TerfinvPffw

  No.13920

>>13873
The size would matter if everything in your system was written in Go. And I worry about the compilation times because if we keep going downhill with them we will finally reach cpp hell of waiting for 20 minutes to compile a slightly more complex program. Apparently another slowdown is planned for 1.7.

  No.13928

>>13920
It should only matter if you have tons of really small programs all statically linked. For larger stuff, the runtime size overhead observed in the hello world example should be negligible.

  No.14142

i get index out of range when i pipe a longish file (gpl3) to this program:


package main

import (
"bufio"
"fmt"
"os"
"strings"
)

func main() {
letters := [][]string{
[]string{"wh", "w"},
[]string{"th", "d"},
[]string{"af", "ab"},
[]string{"ap", "ab"},
[]string{"ca", "ga"},
[]string{"ck", "gg"},
[]string{"co", "go"},
[]string{"ev", "eb"},
[]string{"ex", "egz"},
[]string{"et", "ed"},
[]string{"iv", "ib"},
[]string{"it", "id"},
[]string{"ke", "ge"},
[]string{"nt", "nd"},
[]string{"op", "ob"},
[]string{"ot", "od"},
[]string{"po", "bo"},
[]string{"pe", "be"},
[]string{"pi", "bi"},
[]string{"up", "ub"},
[]string{"va", "ba"},
[]string{"ck", "gg"},
[]string{"cr", "gr"},
[]string{"kn", "gn"},
[]string{"lt", "ld"},
[]string{"mm", "m"},
[]string{"nt", "dn"},
[]string{"pr", "br"},
[]string{"ts", "dz"},
[]string{"tr", "dr"},
[]string{"bs", "bz"},
[]string{"ds", "dz"},
[]string{"es", "es"},
[]string{"fs", "fz"},
[]string{"gs", "gz"},
[]string{" is", " iz"},
[]string{"ls", "lz"},
[]string{"ms", "mz"},
[]string{"ns", "nz"},
[]string{"rs", "rz"},
[]string{"ss", "sz"},
[]string{"ts", "tz"},
[]string{"us", "uz"},
[]string{"ws", "wz"},
[]string{"ys", "yz"},
[]string{"alk", "olk"},
[]string{"ic", "ig"},
[]string{"ng", "nk"},
[]string{"kek", "geg"},
[]string{"epic", "ebin"},
[]string{"some", "sum"},
[]string{"meme", "maymay"},
}
var str string
var err error
r := bufio.NewReader(os.Stdin)
for err == nil {
var tstr string
str, err = r.ReadString('\n')
if err == nil && len(str) > 0 {
tstr = str[:len(str)-1]
} else {
break
}
lstr := strings.ToLower(tstr)
rstr := lstr
for i := 0; i < len(lstr); i++ {
rstr = strings.Replace(rstr, letters[i][0], letters[i][1], -1)
}
fmt.Println(rstr)
}
}


what do? is there a way to ensure that strings.Replace always reslices rstr instead of just mutating the string?

  No.14143

>>14142
apologies for the ass indenting, it got fuarrrked when i copypasted it

  No.14162

>>14142
i < len(letters)
you want to loop through each letter replacement rather than the length of the input string itself.

  No.14168

>>14162
also, stylistically speaking I would use
range rather than for but whatever.

  No.14179

>>14162
thats one really dumbass mistake, thanks lainon

  No.15661

So, what's the latest update on the development of Go?

  No.15663

Someone's building a "version" of Go that uses explicit option types to make it safer: https://github.com/tcard/sgo

  No.16208

>>7823
It's not that, it's that it encourages bad practices. Like switch cases. It's almost always better practice to write a function that returns functions based on the input (forget the technical name), but switch cases still exist in functional languages and people use them, which prevents them from learning the right way. Same with macros. It enables people to write bad code more easily.

That's actually one of Go's strengths. It may not be super powerful, but you're almost forced into writing good code. That's why I expect it to be successful in the web dev world; you can take a bunch of code monkeys, tell them to write X in Go, and be sure that they won't mess something up and create an unmaintainable nightmare like they could with C.

  No.16212

>>16208
That's the argument that always seems to be used.

>We already enforce the right way. If we let programmers decide for themselves, they would choose the wrong way, so we don't let them.

  No.16216

File: 1462666935155.png (71.9 KB, 200x184, jorge-wants-to-be-hardcore.jpg)

>>16212
There's a similar argument that the power of Java is because it is a "bad" language.

  No.16250

>>16208
>It's almost always better practice to write a function that returns functions based on the input (forget the technical name), but switch cases still exist in functional languages
You mean pattern-matching and function variants?

iirc, conditionals and switch cases are implemented that way in functional languages anyway.

  No.16266

>>15663
Anyone from the FP world would point and laugh at this, as in languages like Haskell, Rust, ML, you don't need special syntax and semantics baked into the language for that; optional types and all of their safety can be expressed using generics.
I know about Go's aversion to generics and complex type systems and I'm not sure where I stand on it; I love functional programming but I do see the value in a straightforward programming language like Go. However you see here the clear downsides when a "dialect" needs to be created just to resolve the "million dollar mistake"

  No.17428

>>10961
>>11063
Please tell me this is a joke.

  No.17430


  No.17471

>>17430
I mean, it has to be a joke that there's someone out here who actually believes that making things deliberately harder, with no improvement to the design or functionality of the end product, is somehow a good thing.

I mean, do you realize how terribly hypocritical it is to make the case for complexity for the sake of job security in the domain of computer science and engineering? Do you know how many bookkeepers and secretaries the desktop computer has replaced?

This is absolutely absurd.

If you have nurtured a skill that someone else can do better and for less money, so be it. Sorry, but you just aren't able to keep up with the times. If someone can do a better job than you can for less, it's *not* a human rights violation to hire them.

  No.17474

Having now been employed as a Go programmer for about a month and a half, with no prior experience in the language, I have some thoughts. Firstly, the good:

- It's incredibly easy to pick up. I went from knowing no Go to writing a high-performance replacement to a component of an internal system in under a week.

- The garbage collector is fast, has low pause time, and there's work continuously going on in improving it. This is very good.

- Concurrency is easy, and the runtime seems to perform well with even hundreds of goroutines on a two-core cheap-ass AWS machine. Admittedly, in our use-case, a lot of those will be blocked on socket reads, but there's still quite a bit of actual concurrency going on.

And the bad:

- I went from knowing no Go to finding an undocumented segfault (not a panic, a segfault!) in the stdlib in under a week.

- The type syntax feels very weird and bolted on, there doesn't appear to be any sort of unifying idea behind how types should look, so you just have to memorise each case. Thankfully there aren't many of them.

- Lack of generics leads to a *lot* of boilerplate. The commonly-accepted solution to this seems to be code generation, which is also bad because...

- ...the standard library documentation (in particular, the parsing and AST stuff) is absolutely crap, which makes writing a code generator hard! On multiple occasions I have had to dive into source code to figure out what is going on, or what types a value can have.

- The non-code-generation solution to generics is to use interface{} and run-time type assertions everywhere. This is really bad because you can't even tell if something is a pointer or a value type any more. Goodbye, static type checking.

- Returning to documentation, godoc is fucking awful. The markup is supports is absolutely minimal: you have plain text and preformatetd blocks. Want a list? Go fuck yourself. It also arranges declarations lexicographically, which is bullshit because you don't write code like that; you group together related code! Even just preserving the order in the source would be better than lexicographic ordering.

- Dependency management is awful. Unless you vendor dependencies yourself, there is no way to specify any version other than HEAD. If you're writing something which has multiple packages, you have to import those by the full URL, rather than by some sort of relative import. This means if you move the repo, you have to change imports in all your source files.

My overall opinion is that if you can cope with something even more verbose than Java, and you want a high-performance concurrent program, Go is not the worst choice you could make. But I would never choose to use it myself.

  No.17475

>>17474

Oh, I forgot to mention, the go generate tool searches source files for the literal string "//go:generate". So that means that these won't trigger code generation to occur:

// go:generate

/*
go:generate
*/

The Go tooling, other than the profiling stuff, is pretty poor.

  No.17510

>>17471
Nothing you quote says anything like that. Go isn't easier to use; it's easier to learn. Go isn't causing programmers to be unemployed; Go is for large cube farms with many employees. Go programmers can't do a better job for less; Go programmers are easy to create and replace, so they can't expect job security.

  No.17514

I (>>17474) experienced another Go wtf today. When unmarshaling JSON to a struct, the unmarshal function will happily fill in default values for any missing struct fields, and not tell you. Even if the JSON has *no* fields in common with the struct.

So this JSON:

{  
"message":{
"channel":"hello",
"data":"hello world!"
},
"expires":"however the fuck Go marshals dates to JSON"
}

...will happily unmarshal to this struct:

type ExpireCommand struct {
CutOff time.Time
}

I spent 40 minutes today trying to figure out why something was fucking up, and it turned out to be because of this. I fucking hate Go's default values. I now think of Go as a PHP which people won't laugh at you for using.

  No.17516

>>17514
Is there no way to tell that it's bad data besides using a different parser library?

  No.17517

>>17516
Nope. And naturally this is the json handling stuff in the standard library.

People say one of the great things about Go is that the standard library has a lot of stuff you need... but in my experience it has a lot of poor implementations of stuff you need.

  No.17995

Should Iearn golang for an easy beginner language? I was thinking a lisp, or maybe python. but go is what google gives people fresh out of college

  No.17996

>>17995
Fresh out of college with comp sci classes, not just any college. The language is not for beginners. Learn Racket or python.

  No.18002

>>17996
seconding racket for beginner programming.

  No.18007

>>17995
>but go is what google gives people fresh out of college
people who will have seen Java/Python/C#/whatever while they were there, not beginners.

  No.18008

>>17996
>>18007
Go is a very small language. I may not like it, but I don't see why it would be unsuitable for beginners.

  No.18009

>>17995
Go is a doable language for a first-timer -- it wouldn't be any harder than starting with C or something, but I think go is a bad choice for a number of reasons.

The first is that although it tries to be "high-level" in some respects, it is still obnoxiously close to the metal. You end up having to think about pointers vs. values, slice semantics, and a lot of low-level details. Google is phasing out Python in favor of Go, but Go is much less expressive, WAY more verbose (be prepared to write a crapton of if err != nil) (literally bordering on java-tier), and like others have pointed out has crap instrumentation.

The problem is really the go team. Go is Rob Pike's pet masturbation project. They even released it with fucking different binary names depending on the architecture.

I can say from experience Google mostly gives people "fresh out of college" a Noogler project that involves a crappy feature in a legacy codebase, so typically that means Java or C++. Go is used for smaller greenfield dev work that doesn't have to be maintained. Go is basically Google's Python with types. But there's no reason for you to use it, because you don't have to justify Rob Pike's salary to anyone. Learn C, then Python, then Rust if you want to do systems programming, OCaml if you want to do applications programming, and obviously javascript if you want to do frontend because we live in 2016 and it is a shit year to be alive no matter what your job is.

Also protobufs are really fucking weird in Go.

  No.18055

I think that more people are talking about golang than are programming it.

Here's the deal:
It has no good tooling at the moment, besides what's built into the language. If you need to debug anything on a fine grain level you are basically SOL.

Maybe it's gotten better since I last worked with it, but I found it frustrating to debug when it didn't work.

When it did work it was alright though. I'd personally rather have C most times, but if you want something that looks like C, but behaves more like Python, and performs more like Erlang.... I guess Go is that animal.

Wont kill Java tho. Wish it would.

  No.18059

Well this is an interesting thread, thanks for voicing your opinions in such fine nuances!

>>18055
>Wont kill Java tho. Wish it would.
Don't worry, the browser is the new JVM. Enjoy your node.js enterprise apps :-)

  No.18219

>>18009
>They even released it with fucking different binary names depending on the architecture.
What? I thought that only applied to the early versions of Go. Go seems like it's anything BUT minimalist, considering it seems to come with a web server, which is weird considering Rob Pike's working on it.

  No.18288

newb that wants to play around with crypto code here (lol what can possibly go wrong/s)

i've heard lots of talk about go being the recommended crypto lang as of late, because go is self-hosting, as opposed to stuff like c, cpython and python wrappings for c libs, you remove whole bug-classes related to c toolchains

  No.18305

>>18288
It depends on how and what you need. All the basic functions and algorithms are there in standard lib, but you'll have hard time finding addition/rare things.

  No.21262

I see no point in using Go if one also rejects other Google products.

I'm wondering how some of you consider this, given that Google controls most about the language now.

  No.21264

>>21262
What does it matter who controls the language? The tooling is open source.

  No.21266

>>21264
Chromium is also free software, but that doesn't stop the possibility that in all of the hundreds of thousands or millions of lines there's a purposeful vulnerability.

I suppose my next question should be how easy to audit the Go tools are. Have any of you tried doing this?

  No.21273

>>21266
I'm sure that in the standard library it's almost impossible to have a backdoor. Since is very documented (including source code in the docs). In the compiler idk to be honest. You can also use gcc.

  No.21287

>>21262
>given that Google controls most about the language now.
how does it do this exactly? by being the biggest contributor in an otherwise open source project?

>>21266
>I suppose my next question should be how easy to audit the Go tools are.
source is freely available and almost all of it is written in Go. i dig around a lot in the compiler parts of the language it is super easy.

  No.21289

>>21287
>how does it do this exactly? by being the biggest contributor in an otherwise open source project?
It's my understanding that Go is very much a "you get what we give you and nothing else" kind of language and that all or most of the designers work for Google and steer it towards what Google wants.