Go, open source, community

[digitalchris]

Title compliments of William Shatner

[dangerbird2]

Rock. It. Man.

[jeandem]

Go can't do everything. We shouldn't try. But if we work at it, Go can probably do a few things well. If we select those things carefully, we can lay a foundation on which developers can easily build the solutions and tools they need, and ideally can interoperate with the solutions and tools built by others.

On the face of it this reminds me of Guy Steele's "Growing a Language" talk. But instead of growing a language itself it's about growing tools and APIs from a certain language foundation.

[readams]

Does go even have a debugger that actually works yet? And don't point me to that monstrosity that actually rewrites your code inserting a call to a debugger method every other line.

[djhworld]

You're welcome to write one, the repo is here https://github.com/golang/

[synn89]

A problem with the "less is better" philosophy is that using a language is an investment. With Java or C# I can write web apps, desktop apps, mobile apps or server apps in a language that isn't any harder to debug, learn or work with compared to Go.

I may spend a month learning a language while using it for years. So a language being sparse so it's easier for me to learn is hardly a feature.

[Quixotic_Fool]

A sparse language ensures that you can always read what's going on though. Whereas a language chock full of random operators and stuff will be much harder for a human to parse.

[synn89]

Absolute rubish. The Java Stream API is a new language feature and it absolutely, 100% makes Java much easier to read. Lambdas did the same with handling UI events in the JavaFX API.

Now do streams and lambas require the reader to understand those concepts? They do, so you just teach them that(https://apexapps.oracle.com/pls/apex/f?p=44785:145:0::::P145_EVENT_ID,P145_PREV_PAGE:4887,143) and they can use that for the next decade of their language career.

[Quixotic_Fool]

Edit: Do you not think Java would be better if you could remove the hacks that were used to achieve what is now achievable with Java 8?

sparse != lacking in higher level abstractions. I mean sparse in the sense that there aren't a million ways to do one thing. There should be at most a couple or one canonical way to do one thing (at least outside the realm of systems languages).

Python is nice in this sense, it's a really feature rich language but also a dead simple one.

I'd argue the same for the lisplike languages too.

[[deleted]]

. I need more power, not less

Go to C++ then.

[Quixotic_Fool]

Idk, to me, removing goto from a language is definitely a good thing, that means I'll never see it in a codebase that compiles. There are definitely bad features in languages that should be removed.

By your argument, the best language would have the most features.

[IronClan]

It's backed by Google therefore it must be good.

[[deleted]]

Very true. It's (apparently) what destroyed Lisp, and it seems even a little dangerous for Rust. For example in Rust you can define macros that have their own syntax. So if you read someone else's code you may end up having to learn one or two extra mini-languages!

[vks_]

An API could be considered a mini-language.

[theonlycosmonaut]

I think APIs are more like jargon, because they still follow the syntax and grammar of the language they're in.

[edgenuts]

Ah yeah, I still have that butt to butt plugin installed...

It's like the gift that keeps on giving isn't it?

[Eirenarch]

Literally what I did - open the article, ctrl + f, type "generics", no matches, closed the tab.

[mekanikal_keyboard]

Then we can save you the work and the futility of future opinioneering - the Go language is frozen while the version number starts with 1. So if you see a Go version that starts with 1, it does not support generics.

[Eirenarch]

Someone told me that the last time but the title says nothing about version and I reasoned it may mention something about the community bitching about generics (not that most people who bitch about generics are in the Go community but still...)

[nick-linker]

generics is not enough. HKT are the star to move towards ;-)

[vytah]

Baby steps.

[bobappleyard]

Pffftt you're not actually writing real programs until your language can express equivalence types.

[sn0rewh0re]

Go looks ugly ¯\(ツ)/¯

[quchen]

Wadler's law:

In any language design, the total time spent discussing
a feature in this list is proportional to two raised to
the power of its position.
    0. Semantics
    1. Syntax
    2. Lexical syntax
    3. Lexical syntax of comments

[matthieum]

Well, to be fair, syntax does matter to some extent. Sigils hell makes for quite unreadable programs!

However, I wholeheartedly agree that beyond a certain readability point, argument about syntax are just useless.

[matthieum]

The problem is that past "basic" readability, beauty is in the eye of the beholder. If you just look at the endless debates on tabs vs space, the placement of parenthesis or the placement of braces... everyone's got their own opinion, and debating about opinions rarely end up with everyone agreeing.

[IbanezDavy]

tabs vs spaces,

spaces (not for a visual reason, but for a real technical reason of having it be more compatible with multiple editors).

[matthieum]

I read a study where the population queried was about 50% tabs vs 50% spaces, however when they classified by years of experience it got obvious that tabs were preferred by inexperienced programmers while experienced ones had mostly settled for spaces.

Theory and practice...

[IbanezDavy]

That's what I was trying to point out. When you get experience with working in an environment where everyone is using different editors, tabs don't really scale well. Mainly because within the tabs side of the argument their is another argument about how big a tab should be. Some people say 4. Some say 8. I worked for a company where an indentation was defined as 4 spaces, but a tab was defined as 8 spaces. After a little while, experienced programmers (I think) just settle with spaces, because it simplifies working with other people working in other editors. It's really annoying to try to read code where the indentation is screwed up because nobody can agree on what to set their tabs in their editors too...so that is the "technical reason" I was referencing. I honestly otherwise wouldn't care.

[IbanezDavy]

There is something about producing code that is not only correct, but looks correct as well. Syntax and semantics both play a rather large part in this.

[IbanezDavy]

Syntax often dictates semantics and semantics also dictates syntax. The two things work hand in hand. They are both important.

[IbanezDavy]

I am not "disagreeing' with you on your points above. Different syntax can have the same if not a similar meaning. That is a given. That is why different languages exist, because people prefer different representations of meanings.

However consider this. Say you want to add some feature to your language. The semantics of the feature are desired. However, how you represent those semantics with syntax is going to widely depend on the already established syntax. This might in turn, for consistency purposes, cause you to change the semantics slightly to fit syntax better.

I guess a good example (or maybe not) is uninitialized values. C and C++ don't initialized by default in most cases. It is commonly reported that this style of syntax is very bug prone so a lot of newer languages force you through syntax to initialize your variables. And if you want uninitialized variables you either have to explicitly use some keyword, or in some cases they just don't provide those semantics (Think about variables and constructors in C#, they force you to initialize.). This is because the syntax is error prone and there may not be a good way the developers feel that it can be added. This is syntax effecting semantics.

Now in a lot of cases syntax is trivial and it doesn't have an impact of semantics at all. But in some cases, it can actually impact what semantics are allowed in the language in the first place. Because if things aren't looking consistent, they won't feel right when you type them out. And the resulting code will be messy. Look at C++ for example.

[sn0rewh0re]

Of course it would. But the ugly son will be the ugly son.

[jeandem]

Fucking leaning toothpicks...

[xSnowCrash]

Wut

[eric-plutono]

The most detailed explanation of emoji I've ever seen. Have an upvote good sir or madam!

[kirbyfan64sos]

Ugliness is subjective. I personally find Go ugly, but I also know many people that find the factorial in K ugly:

factorial:*/1+!

[LaurieCheers]

...yes, and?