Hacker News new | past | comments | ask | show | jobs | submit login
Go is Google's language, not ours (utoronto.ca)
885 points by uggedal 5 months ago | hide | past | web | favorite | 659 comments



Actually there are relatively few real (TM) open source projects driven by the community, at least if you look at important projects. Many open source projects are just commercial projects driven mainly by a single company. Look for example at Redis, MongoDB, MySQL, and Elasticsearch. They follow exactly the model described in the article. Technologies like these could have been developed by a community, too, but it is hard to form such a community and keep it alive.

For a community-driven project from the size of a database some serious sponsors would be needed. Good examples are Rust, Linux, and PostgreSQL. I wonder why so many companies are happily paying Oracle (and the likes) tons of money instead of sponsoring an open source project like PostgreSQL.


I disagree about Redis. Redis Labs did a great job at creating an ecosystem of advanced things around Redis. But the Redis core project itself, that is what most people use, is surely sponsored for a big part by Redis Labs, but is executed as a completely OSS community driven project:

1. All the work is done in public, with a license that gives zero protection to the original authors.

2. The project leder (myself) only does OSS work and has no other roles in the sponsoring company.

3. The roadmap is decided by the community (myself with feedbacks from the community), not a company or some product manager or alike.

4. There are multiple people from multiple companies contributing regularly code to Redis: Redis Labs, Alibaba, AWS, ...

5. The main web site is handled by the community.

In the case of Redis this was possible because of the minimality of the project, otherwise I agree that's a huge challenge. But still IMHO Redis deserves to be listed in such "purely community" OSS projects.


There is a slight difference in that all those tools are the basis for their companies' commercial offerings. Google does not sell Go tools or consultancy hours etc. Its interest in Go is to have a programming language that's safe, fast, operationally undemanding and fits the mental model of a recent CS graduate (as per that notorious Rob Pike quote).

This at least makes it easy to work out if incentives are aligned. Do I want to program in such a language? Yes? Then Google is probably not going to completely screw it up, even when they make decisions I disagree with. Do I like to wax rhapsodic about parser combinators? Not ever going to be a good fit.


Actually Mongo doesn't even look at pull requests. So, yes.

Postgres (do we really still need the "QL" reminder?) has demonstrated staying power, and repays invested time in spades. Linux, obvs. Rust, it's still too early to be sure about. Learning it will be at least educational, maybe formative, and at worst it won't be taken away.


Projects like Linux are "community" projects in the sense that there is not a single company backing it, sure. However, for Linux, only 7.7% of contributions were made by unpaid developers as of this 2016 report[0].

I have a hard time calling this a "community" project when the community is paid by corporations. Don't get me wrong, I'm not really complaining, as a project the size of a commercially viable operating system kernel is hardly a project that could be viable without corporate backing IMHO.

[0] https://thenewstack.io/contributes-linux-kernel/


Don't forget that most of the kernel's codebase are drivers and some of the most impactful additions were made by employees of corporations (on top of my mind - cgroups and namespaces by googlers, and not only as a base for containerization).


Been learning Rust for the past few weeks.. absolutely love most of it. It's the first low-level language that actually feels right to me. Of course, I'm one of those weirdos who actually loves JavaScript. I also appreciate Go and C#. Rust just feels like most of the right trade offs, and once Futures and Async/Await stabilize, it'll be IMHO feature complete.

As an aside: The community needs an abstraction for WebAssembly's File System that has something like fcntl/flock functionality. As it stand's the Node interface for emscripten targets isn't good enough. Would love to see a bit more collaboration on this regard for sync and async interfaces for FS I/O that supports file/record locking in a more abstract runtime. Though this has been a pretty big shortcoming with Node since early on imho.


If we look at the Top 10 programming languages, I think only Ruby is community driven that has very little cooperate backing. All the other languages are driven by one (Apple;Swift), or multiple, (Javascript, Java) cooperate sponsors.

I think the balance is hard, you will need lots of resources from Documentation, VM expertise, Library, etc.


The top 10 according to Red Monk[1] are JavaScript, Java, Python, PHP, C#, C++, CSS, Ruby, C, Objective-C, Swift, TypeScript, Scala, Shell, Go, R, PowerShell, Perl, Haskell, Kotlin.

Of these, Javascript (w3), Python (Python Foundation), CSS (w3), C++ (ISO), Ruby (community), C (ISO), Shell (Posix), R (community), Perl (community), and Haskell (community) are not bound to a single company.

[1] https://redmonk.com/sogrady/2019/03/20/language-rankings-1-1...


The JS standard is not worked on my w3, but by Ecma international https://en.wikipedia.org/wiki/ECMAScript


That is correct. Thanks.


Kotlin is also no longer in the hands of a single company. https://kotlinfoundation.org/


Most people there are JetBrains and Google employees.


That’s amazing! When did this happen?


I should have included in my first post. I think rather than splitting between Community or Cooperate, a more accurate representation would be how much Market Value are depending on those Languages. If you have a company dependent on OCaml, let say it is on 30th on the list, but the company is making billions in Net profits, you could bet the company will fund the development of Ocaml, even if it was driven by a Foundation, or Community.


I agree that a clever person such as yourself can construct a metric such that Ruby is the only language that comes out.


> The top 10 according to Red Monk[1] are JavaScript, Java, Python, PHP, C#, C++, CSS, Ruby, C, Objective-C, Swift, TypeScript, Scala, Shell, Go, R, PowerShell, Perl, Haskell, Kotlin.

Top 20?


Oei, call me dany coz I cant count.


Companies pay Oracle because 1) PostgreSQL doesn't take you to lunch and 2) Oracle "just works." I mean, we all know #2 is effectively a lie but having the option to go to Oracle directly for issues (even if the response is just "pay a contractor") immensely reduces risk for executive leaders.


You can hire a Postgresql contractor for admin, bugfixes and features, and you can pay Postgresql corporate for bugfixes and features


Last time I was in a position to try, not so much. I emailed about 15 such contractors at least close to the SW US (I'm in Phoenix), and didn't get a single response. This was 5-6 years ago.


Are they paying Oracle though? A quick Google found this:

https://seekingalpha.com/article/4229086-oracle-growth-dead

If Oracle revenue is no longer growing, maybe new development leans more towards Postgres and other open source offerings?


> Revenue US$39.83 billion (2018)

Even not growing, they are indeed paying Oracle.


Isn't that mainly for integrations though? I would think straight Oracle RDBMS licensing would be on life support without some big ERP connector etc.


I'm curious what the distinction is between Rust (driven by Mozilla) and Go (driven by Google).


By my count, fewer than half of Rust's core team [1] are Mozilla employees, whereas the number is 100% for Go. Rust also has a very clear and open governance model [2], where the Go team is more closer to "we'll do what we want".

[1] https://www.rust-lang.org/governance/teams/core [2] https://www.rust-lang.org/governance


The governance stuff is interesting; are there any programming languages that are structured in between "community driven" and corporate oligarchy? ie. non-profit with dedicated Finance/HR teams?


[flagged]


What an astoundingly ignorant thing to say


It'll be that too, eventually. But not yet!


Rust has largely broken out of Mozilla already. If it can maintain its growth rate (not guaranteed, but so far so good) it will have a future. Check back in five years.


It's a very different language than Golang though, very expressive, generics, no GC, etc.


You say that like those are bad things.

Yes, the borrow checker is a PITA vs. Go, but there are compensations.


These are not bad things if you’re writing system code.


Is there ever a plan for GC?


There are garbage collection libraries in progress: rust-gc[1] and shifgrethor[2]. If you mean language support, then no, not really, though it was discussed in https://github.com/rust-lang/rfcs/issues/415

[1]: https://github.com/Manishearth/rust-gc [2]: https://github.com/withoutboats/shifgrethor


I feel like not having a GC is rust’s biggest advantage over higher level languages. It allows rust to work in environments that only languages like C, C++ can work in. (Embedded, shared libraries, etc)


I more meant "GC for those who want it", as advanced GC with Edens and mark-sweep tenured generations can handle high-allocation and large-heap scenarios that are extremely challenging for simpler MM approaches. I don't know if this really can be done as a library though.


I had a similar question, but rather, what's the difference between Go with Google deciding what goes in, and Python (a year ago) where the BDFL and a couple core devs decide what go in?

Sure you could argue that a company may have different incentives than a BDFL, but in this context, it's not clear that Go would've been more likely to accept the change you're proposing if they weren't being led by Google.


I guess the most important distinction is the “B” part (benevolent). Guido is called that because he is known (since before BDFL is a thing) to listen to other people, and adapt when they disagree strongly with his decisions. Google has never demonstrated the same attitude afaict, and in multiple occasions showed exactly the opposite.

Edit: And to answer the question, no, there’s no philosophical differences. And there’s nothing wrong with that. Python never called itself a community’s language (there are instances core devs said in no ambiguous terms that it is Guido’s project). The problem only arises if a project gives an impression that it is owned by the community when it actually isn’t.


Given that the go core team has committed to adding generics I don't think it's fair to say they don't listen to critique from the community. Is there a more contentious issue in go?!


Not really, that is the hand waving when the issue ever pops up.

Rob Pike already stated publicly that he is against the proposed idea for Go 2.0.

"Rob Pike - Go 2 Draft Specifications" - https://www.youtube.com/watch?v=RIvL2ONhFBI


I wonder if they'd ever consider adding hygienic macros instead of templates/generics. To me, that solves the problem of needing to write the same code for float32+float64 and so on. And it doesn't require so much careful thought about the type system, accidentally creating an awkward metalanguage like happened in C++.


Rust people are very glad that Rust brought high-kinded types to replace the most common uses of hygienic macros. Using macros for everything is a nightmare.

About using them as generics, how do you enforce constraints? Unconstrained generics won't lead you far (or better, will lead you far into JS's Wat territory).


IMO, Rust has a very nice macro system, and this is a good thing (although I'm not familiar with any changes they've made in the last year or two). It's a bad thing that sometimes one needs to resort to the macro system because other features in Rust don't play well together, but that's a long topic with no solution in sight.

> About using them as generics, how do you enforce constraints?

I'm really thinking about the case for numerical algorithms where the exact same code works for different types (say float32 and float64 in Go). It sucks to copy and paste hundreds of lines of code and it sucks to have a separate code generator write your file for you (essentially an external macro processor). Imagine something like the C preprocessor for Go, but without the well known flaws of the C preprocessor:

    #define IMPLEMENT_FOOBAR(NAME, TYPE) \
        void NAME(TYPE* ptr, long len) { \
           hundred lines of implementation here \
        }

    IMPLEMENT_FOOBAR(foobar32, float32)
    IMPLEMENT_FOOBAR(foobar64, float64)
That parametric polymorphic enough for a lot of use cases, and this could work with data structures too.

As for constraints, you can pass function names as arguments too. For instance:

    IMPLEMENT_SORT(sort_baz, baz, bazcompare)
Other proposed features in go, such as the "check" statement for error handling, are probably implementable as a nice macro if you had a good macro language. This means the core language wouldn't have to grow, and features like "check" could be imported from a library. Including features like this in a library means the core language isn't bound by backwards compatibility when a better idea comes along. Old code used the old library, new code uses the new one, and the language stays clean and compatible with both.


This is how Borland C++ provided support for generics before they got into the ongoing ANSI/ISO standardisation process.

For their first implementation of BIDS, initially provided with Borland C++ 2.0 for MS-DOS.

Finding out the release date is left as exercise for the reader.


I see you're reinventing C++


I guess you missed the part above where I mentioned C++ templates as a cautionary tale about accidentally creating an awkward metalanguage. Besides, Go and Rust are both clearly responses to C++, so it makes sense they would try to provide (reinvent) similar capabilities while avoiding the flaws.


Rust does not have higher kinded types.


> Rob Pike already stated publicly that he is against the proposed idea for Go 2.0.

Rob Pike is not a member of the Go team anymore, and he has not been for several years.


That's sad. Was it because of disagreements?


> That's sad. Was it because of disagreements?

No, he moved to work full-time on Upspin: https://github.com/upspin/upspin


Wow. That makes me happy. The last thing we need in Golang are generics.


Wasn't Linus the original BDFL?


Seems to have been Guido.

https://en.wikipedia.org/wiki/Benevolent_dictator_for_life

> The phrase originated in 1995 with reference to Guido van Rossum, creator of the Python programming language.


I think the B stood for something else in his case...


There are some who would argue it's a "soft B" - his recent conf outburst isn't the only example of him failing to listen and adapt.


Guido always took the role of gatekeeper and arbiter (I'll consult with the community and decide what submissions go in) rather than a true dictator (I'll decide what goes in... submissions? What submissions?).


Prometheus is a (rare) recent example of a significant, thriving open-source project that is community-based. Not quite as broad in scope as something like Elasticsearch though.


Depending on what "community-driven" means, I'd like to add Python, Blender, Jupyter, Django ...

I'd say "thriving community-based open source projects" are rare in the sense that most open source projects don't thrive (especially if you count every open-licensed repository on github), but there are tons of examples.


But it started out as a Soundcloud project...


Apache and Linux have always been the two big examples of community-driven open source projects. And Apache still hosts many community-driven open source projects, but they don't seem to be as visible as they were 10-15 years ago.


Some Apache projects, sure. But Spark is very much a Databricks project. Hadoop used to be fairly community as there were hands in it from Cloudera, Hortonworks, Microsoft, and a few others. But with the merger of Cloudera and Hortonworks, the expectation is that it will become guided by that organization.


For community driven programming languages I would say PHP, large user base, mature & very active.


I'd use this as an argument that if PHP is the gold standard for a community-driven programming language, I'd rather every popular language be backed by a large corp haha.

Actually, even ignoring PHP, I'm vaguely convinced it's generally better for a language to be backed by a company. I personally feel more secure knowing that there are people whose full-time job is to take care of the language, and I trust community backlash to deal with any errant decisions. I can't imagine Google (or Microsoft, or Apple, or Facebook) making or blocking a change in a way that kills an entire programming language while they sit idly by ignoring the community response.


Purists will agree with you. Pragmatists perhaps not so much.

I'm sad to see this opinion every time somebody mentions PHP. PHP may have its flaws. But how can anyone deny the instrumental role PHP has played in building the web as we know it today?

The open web, open source, open standards, agile were supposed to be the free market answer to all the flaws of the big old corporations. And for a large part they have succeeded in creating the new and better world we enjoy today. But it looks like we're experiencing some regression. The new big corporations of the web are becoming more like the big corporations of the past. Corporate structures, HR departments, Shareholder meetings, Management layers, system thinking are again replacing the success of uncertain organic growth models that involve chaos, diversity, agility, attitude and pragmatism. To see media outlets advertising social media handles as opposed to their web addresses. Purists are on the rise. Perhaps because everyone is seeking those comfortable high paying jobs at the big corporations?

PHP has fought and won its battles. Outfoxing many big corporate opponents along the way. It should get the respect it deserves. And if you ever find yourself at the front-lines of a new battle. PHP might still very well be your most effective weapon of choice. A worthy consideration at least.


> Purists will agree with you. Pragmatists perhaps not so much.

Golang is one of the most pragmatic languages there is.


Go is pragmatic about language design, but purist about managing community whiners.


Is modern PHP really that bad? I kind of think it makes a lot of sense in a world where almost everything, even major government IT systems, are basically java/.net on the backend and some JavaScript MVVM framework on the client.

I know a guy who works with laravel, and we’ve teased him so much about PHP over the years, because PHP. The truth is, that his backend is actually more suited for the modern world than what we currently run. .Net core is getting to where it’s competitive, but it’s still a bitch to build something like a mixed asp mvc and Vue components app, which is truly effective/productive alternative to MVVM clients or jquery/Ajax for smaller projects.


The thing I "envy" about PHP guys is that they aren't on proglang forums; they are somewhere happier making money and clients happy, and not giving a f* about the things our niche here does...


I started doing PHP dev during the 5.2, 5.3 times and since 7, it feels much better to program in. It even has RoR-like frameworks like Laravel. So, use Symfony or Laravel if you need to use PHP.

It has some historical baggage that some people can't get over. Nothing, no programming language will be perfect. If I had to start all over, I'd probably use something else but it works great for what I'm doing. (web dev with Laravel)


Visual Basic was basically(!) killed by Microsoft albeit large protest, so no, putting your trust in one company does not always work.

PHP has been developed very well the past few years as community project, there is an open RFC process with a codified voting process in place. Sure there have been some drama within the community, but that has not affected either the language nor the implementation.

What makes PHP a great fit for a community driven project is that PHP is a pragmatic language in its core. If the general goal of a project is to design a perfect & consistent language then a community driven process is maybe not the best approach.


It still lives on fine, turn on the developer tab in Excel and there is VBA 7.1 (which is basically still VB6 with a different forms engine)


Let's hope we get some form of generics because in my recent use of it, I can see the usefulness of type information for parameters and return types but not the complete inability to say that this function will return an array of a certain type; I can only say that it'll return an array (which might have anything and everything in it), which is useless.


Visual Basic lives on as VB.NET and to this day VB 6 runtime keeps being updated to run on the latest versions of Windows.


VB is de facto dead, declared legacy in 2008 & latest major release was in 1998. VB.NET is a new incompatible language, everyone invested in VB needed to retrain skills & rewrite existing software.

It was a huge uproar in the community, but MS didn't care enough & this goes against TS idea that the community can stop a major company doing this sort of thing. It can happen & it will happen again.

However that does not mean that you shouldn't invest resources in a corporate language, it just a false argument to think it can't die.

Edit: changed disappear to die


Yet on a past life I managed to migrate code without any major issues, other than components that weren't available on .NET.


Just like I said then

"VB.NET is a new incompatible language, everyone invested in VB needed to retrain skills & rewrite existing software."


> without any major issues


Visual Basic and VB.NET are two very different beasts, only sharing a name.

The VB6 runtime is indeed updated to run, but really how much update does it need beyond sticking the DLLs around? The VB4 and VB5 runtimes run perfectly fine on Win10 and those had no updates for it. It all relies on Win10's overall backwards compatibility.


They are still pretty similar, Microsoft re-introduced quite a few features back.


They are similar only on a superficial level, at their core they have not only vast differences in terms of how they work but they also have a different philosophy. It is not a matter of what you can do in terms of features, but also how you do it and how that affects the IDE, which is a core element of VB6 as opposed to VB.NET where you could be using whatever text editor or IDE you want (it isn't a coincidence that VB6 has its own IDE whereas VB.NET is using the same IDE as C# and C++).

VB6 isn't just the language, if anything the language is a minor part of it. VB6 is the entire tool, including the language, IDE and library. You cannot separate these, they are written for each other. This is also what pretty much all VB6 alternatives get wrong as they try to reuse elements designed for something else. You cannot do that and get something like VB6 beyond at a superficial level (and this is exactly what Microsoft did with VB.NET).


I used VB 3 - 5, later on did a couple of ports from VB 6 to VB.NET, and I am lost on what you actually mean.


Doesn't surprise me, you are not alone in this as others who have used classic VB do not really see the difference between classic VB and VB.NET and to some extent not even (most of) Microsoft seems to get what makes classic VB special :-P. However i'm not sure how i could describe it better than the last paragraph in my reply above as to me the difference between the two is day and night.

It is kinda similar to not understanding how something like a jury rigged Vim with a GDB, file list manager and ctags parser differs from a real IDE even after having used the latter. Usually i'd say "you need to experience the real thing" but if you do not get it after you do, then i'm at a loss of words.


Having observed the decision-making process for 6 months and thought about PHP's direction, I'd agree.

Either a foundation is needed, which sets a vision and sticks to it, or a company, or a BDFL. But with none of them, you get each language faction pulling in its own direction, bits of each added/retained, and no coherence.


Not sure if you're arguing for or against the stake at hand :P


LLVM is also an interesting examples: it was first driven by Apple but now it's driven by many different large companies. I mean it's not completely driven by community but i think it's better than dominated by single authority


Great non-language examples are Debian and KDE


Debian is 1000 developers with mostly decentralised decision making with some voting for project-wide issues using Condorcet.


> I wonder why so many companies are happily paying Oracle [...] instead of sponsoring an open source project like PostgreSQL.

Corporate world is ruled by liability. When you are working on a multi-million dollar project and the database breaks, you want to be able to put as much responsibility on the 3-rd party as much as possible.

Open Source projects come with no guarantee. If someone hacks into a system because of a flaw in the Open Source project you are screwed. If it's a software delivered by Oracle, then Oracle is responsible and needs to pay your million dollar fine.

Of course I'm simplifying, because there's probably still a lot of legal process behind it depending on the country, but it's essentially that.


> * is responsible and needs to pay your million dollar fine.

This is not really true. AFAIK there is no commercial software that has a license clause making the manufacturer liable if you loose your data due to faults in their product.

We lost a couple of TB due to bad OS/firmware in a NAS. The manufacturer did everything they knew trying to fix it, but in the end failed and we lost the data.

Once we lost a crucial virtual machine and backups due to human error. It was not the manufacturer of the virtualization solution that helped us get it back, because they did not have such tools and did not provide such services. Hackers who were reverse engineering the software and publishing their reversed code on the net helped us get the VM image back.

After these two and some other situations I am even stronger proponent for open source, because with open source you have the option to try help yourself if the manufacturer won't or can't help you. I am not just proponent, in fact if I was to be involved in decision making, it would be open-source solution throughout. Of course with support. If possible I'd pay for support services to the original developers.


> then Oracle is responsible and needs to pay your million dollar fine

Has it ever happened though? Genuinely curious.


> I wonder why so many companies are happily paying Oracle (and the likes) tons of money instead of sponsoring an open source project like PostgreSQL.

Because that are plenty of nice enterprise features that PostgreSQL still doesn't cover.


My thought was a bit deeper than that. Actually I wonder why are not more companies sponsoring PostgreSQL to get the features they need instead of paying Oracle?


Could you name some I’m pretty curious?

For my use case it’s a no brainer because only PostgreSQL have a decent GIS extension, last time I checked Oracle was lagging well behind.


- Distributed transactions across cluster nodes

- The IDE experience with PL/SQL, including graphical debugging of stored procedures

- Compiling PL/SQL to native code for better performance

- Running bare metal without an underlying OS

- Oracle RAC

- The fine tuning options on their JDBC and .NET drivers

- A proper C++ driver API


As an "enterprise" Oracle user, I'd give all those up in a heartbeat if Oracle would just support proper indexing on Json values (well CLOBS with a "is json" constraint in Oracle - bleh). Meaning that I wouldn't have to execute ddl to create a function index on each new field path within the json that I want to support. IOW I want a Postgres path ops GIN index which work beautifully.


I don't have the stats to back this up, bit that all seems very niche. I have to imagine you get downvoted because people don't recognize these as real requirements. I needed not a single one of these. Ever.


> I needed not a single one of these. Ever.

Enterprise software tends to have lots of features that the majority of folks will never encounter in their career. The enterprise market space is composed of around a thousand potential customers world wide, all of whom are large enough to have sophisticated and complex internal computing environments. They have varying norms, requirements, workloads, regulatory environments, industry standards and so on and so forth.

Each has a lot of money and rejecting the requirements of one company often means you are effectively rejecting several, or perhaps even an entire sector. So you add something to cover them and before long, your software has the union set of features required solely by enormous companies.

From a non-enterprise view a particular feature may seem like absurd overkill. But someone, somewhere, needs it and there is a long and often impressive story of how it was achieved.


Compiling SQL -> native I'm not sure deserves to be described as niche, since lots of analytical queries can benefit from that. Worth pointing out that Postgres has a JIT compiler [0].

[0] https://www.postgresql.org/docs/current/jit.html


Like automatically refreshing materialized views, by which I mean when a base table is changed, the engine uses the definition of the materialized view to run triggers to update materialized view.


This is related to default implementation details, this behavior can be achieved using trigger/materialized view on PostgreSQL as well.


My entire point is that I shouldn't have to write the triggers myself. PostgreSQL figures out the triggers from my definition of the materialized view.


The simple and sad truth:

-Nobody gets fired for buying Oracle. -It's easy .. explaining an investment in open source .. good luck


"We'll save $500k a year in licensing costs and don't need to re-negotiate a contract to update our architecture" has worked for me.


> Nobody gets fired for buying Oracle.

Nah, even when Oracle was more dominant than they are today, that wasn't entirely true:

https://www.cnet.com/news/california-cancels-oracle-contract...


> Nobody gets fired for buying Oracle

I can think of environments where you'd get fired. Oracle these days screams "legacy", and especially if you're working on low-latency projects like trading systems it would be a huge, expensive mistake.


Aside from JS/Node and maybe C++, I can't think of any languages or platforms that are nearly as community driven. Java is probably the closest.


What about Python? AFAIK it is the best example of big community-driven project.


I hurd about a thing called GNU...


>I wonder why so many companies are happily paying Oracle (and the likes) tons of money instead of sponsoring an open source project like PostgreSQL.

Well does PostgreSQL offer anything like Oracle's CDC?

Edit: Nevermind, I just read up on using a WAL replication slave with triggers.


Many like Go because it is an opinionated language. I'm not sure that a 'community' run language will create something like that because there are too many opinions. Many claim to represent the community, but not the community that doesn't share their opinion. Without clear leaders I fear technical direction and taste will be about politics which seems more uncertain/risky.

I like that there is a tight cohesive group in control over Go and that they are largely the original designers. I might be more interested in alternative government structures and Google having too much control only if those original authors all stepped down.


My thoughts exactly! It's important to have a community and to work with it, but, especially for a programming language, there has to be a clear concept of which features should be implemented and which not - just accepting community contributions for the sake of making the community feel good would be the wrong way. Otherwise you end up with a feature monster like innumerable other programming languages, and that's exactly what Go doesn't want to be.


Go is somewhere in the middle of the spectrum between Lua (dictatorship) and C++ (endless politicking).


My fear is that they end up integrating generics just to please some vocal group of java/c++ programmers.


In my opinion the way they are handling adding Generics to Go is proof of this model working.

They are actually trying to pick the implementation that solves real world issues, not just trying to tick [x] Generics in the Go spec sheet.


Parametric polymorphism is a real world issue. The fact that it wasn't checked off indicates to me that they are of the opinion that it's not as important.

It's ok to have this opinion, I just disagree with it. I do agree that it's important to think it through, I do not agree that the language should be brought to 1.0 without it.


This is the general point though. Community pressure would have produced generics under a different leadership model that wants to check the box.

Whether this is the right decision for this specific issue is a different story. But the fact that they aren't checking boxes for the sake of it is evidence of this style WAI.


WAI?


I would guess Working As Intended.


> Parametric polymorphism is a real world issue.

...what in the world makes you thing that? I love parametric polymorphism, but nothing stops you from writing the most complex computer programs you can imagine without it.


> but nothing stops you from writing the most complex computer programs you can imagine without it.

Sure, you can do that with punch cards as well, but there is a reason we've collectively moved beyond them.


> ...what in the world makes you thing that?

Go literally special-cases generic builtins because they couldn't be arsed to properly implement it but knew nobody would accept completely untyped core collections.


Go does not have generic arrays any more than C does. You cannot e.g. write a generic Go function to reverse an array.

You seem to be conflating type-parameterized collections with generics. You can use generics to implement type-parameterized collections, but it doesn't really make sense to think of type-parameterized collections as a form of generics unless you can actually abstract over the type parameters (which you can't in Go).


> Go does not have generic arrays any more than C does.

Go does have generic collections, and generic functions operating on these collections.

> You cannot e.g. write a generic Go function to reverse an array.

You can if you're part of the core team and implement them as builtins. Go doesn't have userland generics, because users of Go are peons who can't be trusted with sharp implements.

> which you can't in Go

Because the core Go team assumes and asserts users of Go should not and can not be trusted with anything more complex than a wooden cube with rounded edges large enough that it can't fit in their mouths.


Would you please drop the nasty rhetoric and not do programming language flamewars on HN? They lead to harsher, dumber discussion, and ultimately cause a forum to destroy itself. Learning from those past lessons was one of the motivations for starting Hacker News years ago, and it's not like we want to forget them now.

Edit: we've had to ask you half a dozen times in the past not to post aggressively and uncivilly on HN. Would you please fix this? Reviewing the site guidelines should make it clear what we're looking for instead.

https://news.ycombinator.com/newsguidelines.html


According to this usage, C has generic functions because you can, e.g., index into an array of ints. The whole point of generics is that the language makes available some form of abstraction over types. Go does not have this feature. It has some built-in operators that can operate on multiple types. Most languages have this. The arithmetic operators in C, for example, can take operands of many different types. This is not "generics".

>Because the core Go team assumes and asserts users of Go should not and can not be trusted with anything more complex than a wooden cube with rounded edges large enough that it can't fit in their mouths.

This can't really be the right explanation given that generics are now being added to the language. In any case, this kind of mean-spirited speculation about people's motives is borderline trolling, IMO. The Go team have publicly stated their reasons for not (initially) putting generics in the language. Unless you have some inside info suggesting that they're lying, I'd refrain from saying this kind of thing.


> The whole point of generics is that the language makes available some form of abstraction over types. Go does not have this feature.

Go absolutely has this feature. Just not for you as a user of the language.

> It has some built-in operators that can operate on multiple types.

Go has multiple builtin functions which abstract over type parameters e.g. close() can operate on any chan, append() or copy() can operate on any slice. They are not operators (symbolic or keyword).

> Most languages have this. The arithmetic operators in C, for example, can take operands of many different types. This is not "generics".

It's overloading, +(int, int) and +(double, double) are separate functions under the same symbol. It's an orthogonal feature, so much so that there are plenty of languages which do have userland generics and don't have overloading.

> This can't really be the right explanation given that generics are now being added to the language.

The core team has been saying they're considering the feature / issue pretty much since the language was first released. You'll have to excuse me if I don't hold my breath.


>Go absolutely has this feature. Just not for you as a user of the language.

That seems like a roundabout way of saying that it doesn't have the feature.

>It's overloading

You could just as well regard Go's close, append, copy etc. as overloaded.

> The core team has been saying they're considering the feature / issue pretty much since the language was first released. You'll have to excuse me if I don't hold my breath.

They've come out with a specific generics proposal. I'm not sure why you would think that they're not serious about implementing it.


> You can if you're part of the core team and implement them as builtins. Go doesn't have userland generics, because users of Go are peons who can't be trusted with sharp implements.

It looks like you are in golang core team's minds. You appear to be able to judge intent. Impressive quality you have here.


> It looks like you are in golang core team's minds. You appear to be able to judge intent.

Not at all, Rob Pike stated it fairly explicitly if in somewhat milder terms:

> The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.


> users of Go are peons who can't be trusted with sharp implements.

Pike himself is a user.


But that is exactly the point - you would have added the best proposal available to the language vs. waiting till all issues are worked out with generics. Go 1.0 has been released 7 years ago, in that time a ton of happy Go users were able to use Go as it is. All the discussions on generics clearly show, that the Go team is interested adding them, but that all proposals so far had distinct shortcomings.

Personally, I am very happy with what Go offers today, I would rather keep a small and simple language, which allows me to concentrate on doing work, rather than trying to keep up with features added to the language. I am not even sure, I want generics to be added to the language, until they come up with a really great concept which maintains the simplicity of the language.


ML (1973) and CLU (1975) introduced generics to the world, followed by a myriad of approaches to implement them across multiple languages, so plenty of time.


No one claimed, that languages with generics don't exist. But if you follow the discussion about generics in Go, Russ Cox did a thorough discussion of all the proposals on the table and why they would mean giving up some of the core traits of the Go language. As soon anyone suggests an implementation not colliding with the core Go goals, the Go team probably would pick it up quickly.

Or phrased it in another way: with all the years of experience on generics, they still got them wrong when implementing generics for Java, e.g. with the type erasure.


Not at all, he focused on how Java and C++ do it, and later on the Go 2.0 proposal admited that they were a bit closed minded to look for how other language implementations work.

"In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier."

https://go.googlesource.com/proposal/+/master/design/go2draf...


This is definitive proof that the lack of generics was a mistake from the beginning.


I'm not sure what GP meant by real world issues, but they do have some specific constraints that they want their implementation of generics to achieve, one of the core team members tried to nail down the details over a period of years but there were issues with the previous proposals before the latest one. So I don't think the issue is parametric polymorphism or not, it's more about things like keeping fast compile times, avoiding boxing value types, etc.


Parametric polymorphism is a tool to solve real world issues with.

It is not unthinkable that there could exist other programmatic tools that would be able to solve the same real world issues.


The one thing that I do like about Go not having generics early on is that it became a language for lower-level work with many good libraries. I wouldn't quite call it a systems language like they like to say but I like its positioning which filled a void.

Now when Go 2 gets generics it will be used for all kinds of applications and frameworks, which is fine but isn't really filling a void. I expect the ergonomics (e.g. wicked fast compiles to single binary) to be better than current app dev langs. I stopped using Go and look foward to trying it again. Even then I don't think it will be one of my favorites and likely used for smaller work. Long-term I want Pony to succeed. Medium term I'll take Kotlin, Elixir, or Dart.


It would objectively have made Golang harder to read. Can we agree on that? People tend to abuse generics.


Uses of https://golang.org/pkg/sync/#Map are objectively harder to read than if they allowed a library to implement a type that conforms to builtin map[K]V. Instead you have to learn method names and cast return values, and builtin maps don't even support those methods.


Let’s agree to disagree. Maybe you’re used to reading generics after years of doing it.


Is there any example of a successful large open source project that's truly lead by the community, and not a handful of people that decide what goes in and what doesn't? What would such a model even look like?


I think the key component of such a model is a clearly communicated method where the community can participate in the project direction, and evidence that the method is being respected. It's been brought up in this thread but Rust's governance/RFC process comes to mind. https://www.rust-lang.org/governance


you can see it already on github - survival of the fittest fork


In theory yes, in practice though, there's a lot of projects where the lead maintainer has vanished or doesn't spend a lot of time on it anymore making the future of the whole project and its forks debatable. Most forks aren't interested in taking the lead. The only exception I can think of was the nodejs fork, IO.js, which ended up being more of a political move and a kick up the arse for the Node team. A similar kick was given to the NPM team when Yarn started making waves.


The Rails/Murb drama a few years ago is another good example I think. A bunch of people decided they didn’t like the directions Rails was going in, created a competing framework, and after proving the concept was sound ended up introducing a lot of the unique features back into what became Rails 3.


Absolutely agree.. look what happened to C++ over the last decade(s).


Not sure - I thought it got significantly better with C++11/14? Admittedly it also became rather more complicated, but the changes were generally for the best I thought?


From my five years of learning and using C++, I still have no clear picture how move semantics and rvalue references work. (I “kinda” get it, but am not confident about it). It seemed more and more convoluted every time I tried to study about it. The complexity created by implicit and explicit copy/move constructors is just insanity for me...


> From my five years of learning and using C++, I still have no clear picture how move semantics and rvalue references work. ... The complexity created by implicit and explicit copy/move constructors is just insanity for me...

This is the best argument for move from C++ to Rust instead. No "move constructors" whatsoever, move semantics are the default and are always performed via a trivial memcpy. There are explicit .clone() operations, like in some other languages, or the move construct can implicitly copy when the type is a POD-equivalent that makes this possible (identified by the Copy "trait"). Very simple, and nothing like the whole C++ move mess.


So what if I have an object that has a pointer to another object? memcpy is not what I want in that instance.


Assuming struct A has a reference to struct B, memcpy is a fine way to move struct A, and struct B cannot be moved while borrowed.

Here's an example I put together demonstrating this: https://play.rust-lang.org/?version=stable&mode=debug&editio...


If you mean intrusive data structures, Rust just doesn't support them. Everyone still manages to write software in Rust just fine. (There's some early support for immovable data with `Pin`, but that's only exposed via async/await at the moment.)

Move constructors are one of the worst parts of C++ and being able to write movable, intrusive data structures is absolutely not worth the cost. If you do need one, Rust shows that it's better to sacrifice movability than introduce move constructors.

This is not uncommon -- there are some things you can do in C++ that you simply cannot do in Rust (either safely, or at all). Usually there's another, better way to achieve the same overall goals.


> Move constructors are one of the worst parts of C++

Move constructors fix a narrow problem, which is, when you have something like a vector append, how do you copy over all the previous elements as a "shallow" copy rather than a deep one?

In C with realloc(), it's just assumed that memcpy works for that. With C++03 and earlier copying the elements could very well end up duplicating everything on the heap for no reason, then discarding the old copy.

How does rust do this? What I am reading from googling is that every assignment is a move?


Yes, every assignment of a non-Copy type is a move. (Copy types are basically primitive ones like ints, so not vectors etc.) The compiler prevents you from using the old variable at that point.

Since Rust always enforces that a move is a memcpy, a vector reallocation is just a realloc() like in C.


Safe rust may not support them, but you can use unsafe to write them. There’s a bunch of implementations of intrusive collections on crates.io.

Also, Pin is stable but async/await is not, so you’re backwards there :)


Rust doesn't move through the pointer, it moves only the pointer, which should be perfectly fine.


Read "Effective Modern C++: 42 Specific Ways to Improve Your Use of C++11 and C++14" by Scott Meyers.

That'll clear it up for you. It's a very good book. rvalue references are a bit muddy but move semantics should be clear.

Do you have Stroustrup's blue book?


If you give Go to the community, the community will add exceptions... yuck.


Go already has panic/recover which where explicitly proposed as an exception like mechanism for go.


The convention in the Go libraries is that even when a package uses panic internally, its external API still presents explicit error return values. -- https://blog.golang.org/defer-panic-and-recover

I belive this means that using this mechanism similarly to try/except in Python is not possible (I write 20 lines in go so this is quite a wild guess)


And generics, ew


It's a dangerous type of articles that deliberately turns community against Go team, based on misunderstanding or plain false accusations.

Go team said many times that generics are technical issue, not a political one. (see [1] by rsc (Russ Cox from Go team))

There are also stories like experience report of Cloudflare outage due to the lack of monotonic clock support in Go that led to introducing one. [2]

The way how Go team handles potentially tectonic changes in language is also exemplary – very well communicated ideas, means to provide feedback, and clear explanation of how process works. [3]

Plus, many people in Go community do not want generics in Go (at least, in a way they're implemented in other languages). Their opinion also matters.

[1] https://news.ycombinator.com/item?id=9622417

[2] https://blog.golang.org/toward-go2

[3] https://go.googlesource.com/proposal/+/master/design/go2draf...


In my opinion the monotonic clock example cuts against this argument - originally the core team was extremely dismissive of the idea, even though it had been shown to cause pain for a lot of people: https://github.com/golang/go/issues/12914#issuecomment-15075...


It's a great example, as it shows the complexity of the discussed topic and attempt to justify any changes to the language/stdlib. In the above-mentioned comment rsc replies to another Googler, not to "community".

So we have

a) Google having problems with lack of monotonic clock in Go

b) Go team reluctant to break API and break promise of compatibility without really serious reason

c) community feedback in form of well written experience report, explaining how serious the issue is for the community

d) immediate reaction and efforts to find a solution (without breaking API)

Even though team was dismissive of the idea, feedback from the community made them to change their minds.


Or, you can view this from another angle, that the golang authors yet again disregarded previous established work in the industry for the sake of avoiding hard work in the language and the compiler. It's no wonder the time package in golang is garbage compared to established offerings in mature languages like Java and C#.


It's no wonder that a new language is lacking the maturity and features of an old language. Of course you can attribute it to 'avoiding the hard work', but that's the same reason you don't live in a crystal castle. A more salient criticism would highlight what they have been spending their time on, rather than pointing out that they haven't spent much time on something.


The logical thing to do is to build on what other languages did, and use established practices. Comparing what Rust did to golang when it comes to generics for example is enough to show the mentality of the golang authors refusing to look at established work.


I disagree, as I remember a lot of talks and articles from Go team members where they discuss in detail established work in other languages – on GC, on language evolution, on generics and so on – and deliberately learn from them to avoid same mistakes.


It's not a matter of agreement or disagreement. It's facts. Another user on here put it well: https://news.ycombinator.com/item?id=19979613


The fact is Go team learns from other implementations and it's clear from talks and articles. Another fact is that you're accusing them in having the "mindset of refusing to look at established work". Those two facts don't get along together, that's why I disagree.


They stuck their heads in the sand refusing to have a package manager for like 8 years and asking people to put dependencies on a vendor folder.

That's not learning from established work.


First, Go had package management – it just has been optimized for monorepos.

Second, since early days of Go, they said that acknowledge their Google monorepo bias, and can't implement package manager that works for everybody without understanding what people outside of Google need. They consciously gave time for community to grow and mature and get enough feedback before implementing proper solution, while actively studying package management solutions from other languages.

I definitely can't call it "refusing to learn from established work". Of course, they could've just copy existing suboptimal solutions without properly giving it a thought – that's what most of the languages do, after all – but that's where Go choses another path.


because implementing package manager well is not a trivial work. I had no problems with vendor (godep), later I used Dep and now modules. There are still some problems with module handling for vscode (gopls) but that will be sorted out over time. If you don't like the way Go is going, what stops you from using Java with maven, gradle or whatever...


But the implementation that rsc came up with was much better than everything proposed by the community (no API change).


Crisis is always a great opportunity as the pressure motivates people to ship, while also to do their best, to really consider any and all options, everything that might work.

Sometimes, of course, this does not work out for the best.


The article barely even talks about generics, though (and takes a favorable position towards the Go team). What are you on about? Did you read the same article I did? https://utcc.utoronto.ca/~cks/space/blog/programming/GoIsGoo...

The author's primary complaint is the way Go modules were handled, namely that one member of the Go core team overrode the entire community.


> barely even talks about generics

Yet uses it as an opening line to build the whole argument on.


He doesn't build the whole argument on it. Generics just happens to be one of the most polarizing, most talked about subjects in the Go community. It's no surprise the author alludes to it. In his own words:

> PS: I like Go and have for a fair while now, and I'm basically okay with how the language has been evolving and how the Go core team has managed it. I certainly think it's a good idea to take things like generics slowly. But at the same time, how things developed around Go modules has left a bad taste in my mouth and I now can't imagine becoming a Go contributor myself, even for small trivial changes (to put it one way, I have no interest in knowing that I'm always going to be a second class citizen). I'll file bug reports, but that's it. The whole situation leaves me with ambiguous feelings, so I usually ignore it completely.


I'm going to risk being labeled an ~incompetent dev~ or whatever but learning golang was seriously a breath of fresh air compared to literally any language I have ever tried to grok before.

Everything felt like it was there on purpose. It always seemed like there was a "proper" way to achieve something. Being told to use this opinionated formatter was like removing a 40kg bag after a bush walk. You never have to worry about if you're writing Go "the right way", because it's extensively documented what that way is.

Generics is an awesome feature, writing C# is my day job so sometimes I miss it, but I have full faith in the designers when they say it will be in the language in a "Go appropriate way". The last thing I personally want to see is Go being handed over to the community to be designed by committee.


I completely agree. When I first started writing Go (coming from Python/C#) I complained an awful lot about what felt like pointless hamstringing of functionality. Go is a simple language, and you don't get many toys. It also feels very verbose at times, and forces you to think a lot about doing things which seem automatic in other languages.

However, as time went on, I noticed a few trends. Firstly, forcing me to think more revealed that what I had thought was automatic was more automagic - Go forces you to take responsibility for what your code does to a far greater extent than other more convenient languages, albeit not to the extent that C/Rust does. Secondly, I noticed that code written in Go tends to do what I expect it to pretty much all the time (with the occasional except of async stuff). Sitting down and writing a program in Go often results in something that actually works the first time it runs, and has far fewer runtime surprises.

As painful as it is to do numerical computation in Go sometimes, I have a very high level of confidence that I can look at a program, deduce with some accuracy its runtime memory usage & footprint, multithread it easily, and reason (successfully) about possible runtime failure modes and behaviour. This is something I find difficult if not borderline impossible to do in Python, especially utilising the standard '10 layers deep' stack of numerical computing libraries.


Interesting, that I saw a similar pattern like "at first I complained, but as time went on I found some benefits" quite a lot.

It can be that your learn a language better, became more comfortable with the way it must be used: say, stopped writing code in Elixir the way your used to write in Python.

But the other thing is that it's in our human nature that we tend to look for something positive in bad situations we exposed to for a long.

Say like, PHP was a fractal of shit, but when you use it for a long you will notice that it will make you more aware of what functions to use and how not to fall into some undocumented craphole, be more responsible, and do not take it for granted that some function would work flawlessly. The obvious benefit from the shitty situation.

EDIT: Grammar


The nice thing about walking minefields is learning how to watch your step.


I like this because it could be said seriously or ironically


"If you're walking on eggshells, don't hop."

-- unknown


That's like the idea of planting a bamboo plant, then jumping over it every day. It's a nice idea, but you won't ever be able to jump over a two story house. Instead, you'll eventually catch your foot and tumble. Likewise with the minefield. The result, is that you'll eventually step on a mine. At best, you can use a simulated minefield as an exercise, then use mine detection equipment and proceed with caution.

Or, you can avoid the minefield entirely.


My enjoyment using any given language always tends to grow as I get more productive with it, even if I have a more general dislike for the language itself.

Making computers do things is fun (usually)! The programming language is (almost) immaterial - depending on the task at hand of course.

Despite myself, I've even found myself enjoying JS in the few times I had no choice to avoid it. shudder


That part about JS is pretty much the story of my career - I started out completely hating JS, was forced to use it enough to get more familiar with it, and eventually eventually started enjoying it to the point that it's now the primary language I write.

(I still hate it occasionally, but there's a lot more joy these days.)

The initial turning point was probably around the first release of jQuery...


[Javascript isn't actually that bad of a language. It really is about 90% of Scheme plus prototype inheritance, which takes some getting used to but ... eh, it's as good as any other option. The problem was that it was one of the battlefields between Microsoft and Netscape and has some really hideous scars in the landscape.]

I did not write this. My fingers did not type it. Nothing to see here. Move along. I'm a hedge.


>Javascript isn't actually that bad of a language

Well, the basic parts are not that great. Plus, it has almost nothing of Scheme (nothing more than e.g. Python has of Lisp), that's just an old wives tale. It just has closures and that's it. Scheme is a Lisp, whereas Javascript isn't [1]. Not sure what Brendan had in mind when he was inspired by Scheme, but the end product is nothing like it.

Coercion rules are crazily bad. No integer type is stupid. Prototypal inheritance nobody much cared for (where nobody = very few). An empty array is not falsy. And several other stupid decisions besides.

The only reason it wasn't that bad, is that it wasn't big enough to be bad. It was just a handful of features plus a tiny (and bad) standard library (some math, some string stuff, etc). Everything else people had to build on top (and usually the did it badly).

[1] https://journal.stuffwithstuff.com/2013/07/18/javascript-isn...


I think JS is very fun to write. It's making sure it does what I want it to do that is irritating.


>Interesting, that I saw a similar pattern like "at first I complained, but as time went on I found some benefits" quite a lot.

Isn't that also a classic example of "boiling the frog" or Stockholm Syndrome?


This. Plus folks are always comparing to their previous experience, which is likely to still be a subjective and also hard to compare at all too. It's like apples (Go) vs oranges (C#) vs broccoli (Python).


+1 for 'fractal of shit' - that is a keeper.


I read the "fractal" part as a hat tip to this rather famous article: https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/


What type of numerical computing do you do? By that, I mean what is the problem domain?


Mostly machine learning for distributed sensor networks (ie: smart meters). Deal with lots of time-series data, state space modelling, some recurrent neural nets (etc). Our shop has a 'golang only' thing going, which means that I end up having to reimplement algorithms in go sometimes from scratch.


nice area, I would be interested to learn more into this type of problems. Recently, I became for interested in power electronics / smart grids / energy, and looking for the ways to get in touch with people working on such problems, learn more and join any company on these domains.


It depends on what you want to do as this industry is HUGE. Do you care about metering and working at the solar panel or wind farm level? Or maybe on the actual energy markets that commit and dispatch all generation in a region? Or maybe the vendors that write the software for those markets? Or you could work for the utilities or IPPs that own the generators...or the state public service commission that control state plans. There is also FERC and NERC. There are companies that sell energy storage systems...the list goes on and on.


I saw on the Adacore website a success story for another company that sells smart metering products, so it is nice to see all the work in this space. There are plenty of major vendors as well with smart meter products and the accompanying software.

What company do you work for by the way if you can say?


I agree, the greatest thing about Go is all the stuff it left out. Which is still annoying sometimes coming from more expressive languages (no exceptions! no generics!) But thanks to the simplicity and the common format standard it is so easy to read and understand. If I want to know about an edge case of a library function, I just dig through the code in my IDE until I have the answer. In most other languages I'll hesitate to do that, either because it's hard to read the code, or hard to access it.

I rarely have to think much about how to write the code itself, just about the actual problem that I'm solving. Once I know where I'm going, there's really only one way to write the code for it. Reviewing and using a co-workers code is also a breath of fresh air.

I think languages fall on a spectrum with regards to both typing and expressiveness, and it's not good to be on either end (e.g. PHP vs Scala or C vs C++) the designers of Go were very disciplined in walking that line and struck a great balance. I'd hate to see that undone by turning it over to a committee which results in a million compromises that turn a language into a Swiss army knife of features. It needs that strong guiding hand and the discipline to say no most of the time. Go has become my favorite language, I just wish I get to use it more in my work.


I rarely have to think much about how to write the code itself, just about the actual problem that I'm solving.

Bingo. This is also what the designers of Smalltalk, Ruby, and Python were trying to achieve. This is the opposite of C++, where I find that I'm thinking about the how all the time. (And at least 25% of the "agile" process time is spent on this activity in explicit reviews.)


> The last thing I personally want to see is Go being handed over to the community to be designed by committee.

I'm thankful for exactly that. Go is developed by Bell Labs people, the same people who bought us C, Unix and Plan 9 (Ken, Pike, RSC, et al). They took the time to think through all their decisions, the impacts of said decisions, along with keeping things as simple as possible. Basically, doing things right the first time and not bolting on features willy-nilly simply because the community wants them.

Reminds me of Joe Armstrong's quote: '''I remember thinking “how simple, no qualms of conscience, no soul-searching, no asking "Is this the right thing to do” …''' source: http://harmful.cat-v.org/software/OO_programming/why_oo_suck...


> Go is developed by Bell Labs people, the same people who bought us C, Unix and Plan 9 (Ken, Pike, RSC, et al).

Exactly and it comes in line with other research languages, namely Newsqueak and Limbo, both relying on channels for concurrency. I hope their other work will also find their way into every day usage though.


Bell Labs — and ETH Zürich, where Robert Griesemer worked as a PhD student under Niklaus Wirth on Oberon, which had a big influence on Go [1].

The earlier languages that Rob Pike et al were involved with, Limbo and Newsqueak, were also heavily influenced by Wirth.

[1] https://talks.golang.org/2015/gophercon-goevolution.slide#15.


My experience is the same. I spent a couple of weeks playing with Go and had such an easy time with it. I can go back into the code I wrote and understand exactly what's going on. I can't say that about most languages I tried. I can even make sense of other people's code in large, complicated Golang codebases despite having little development experience.

This probably scares people whose livelihood depends on managing complexity in other languages. If anyone can get up to speed quick, anyone can potentially make the program that eliminates the need for that complexity.

I don't know that Google had this in mind while developing Golang, but they stand to benefit from commoditizing development. This is fine for someone like me who has zero interest in it as a career but does use a lot of scripts and plugins for creative work. Right now it's $10+ every time I want to do something with music/video/art where free or included stuff doesn't work or doesn't exist. If every DAW, video editing suite, and art/graphic design program had a scripting language as easy to use as Golang, I would never need to pay for add-ons.

The markets would still exist, but they wouldn't be as lucrative. Pricing would go from value to commodity.


> The last thing I personally want to see is Go being handed over to the community to be designed by committee.

There is a point about diversity to be made here. Different design models will each have their strengths and weaknesses, and the design spaces each opens up are not going to be fully explored if one model prevails. So I'm glad there's a language like golang with a coherent centrally-planned vision behind it in existence. It's also good to see more community-driven models get to do their thing. We'll see over time how each develops and what problems they best solve. It does seem to me to be a 'let 100 flowers bloom' type situation.

A bit of a bland centrist view perhaps, but with systems as complex as programming languages and their associated libraries, ecosystems and pragmatics, it's really hard to know what works. Best to experiment.


There is a point about diversity to be made here.

Strings in C++?


> Being told to use this opinionated formatter was like removing a 40kg bag after a bush walk.

This is how I feel about prettier.

> The last thing I personally want to see is Go being handed over to the community to be designed by committee.

I feel this way about many projects. You can’t beat good stewardship/vision, and sometimes it’s corpotate.


> Being told to use this opinionated formatter was like removing a 40kg bag after a bush walk.

I think the gofmt approach is becoming an unofficial standard. In the JS world 'prettier' has taken off and I think most languages now have a community anointed formatter (and new languages are likely to have an official one).


Yes, but they might be customizable. For example Rust has rustfmt but you can customize it. Which is a horrible approach imo.


Agreed. Prettier, BTW, is specifically low customization.


Strongly agree. Go feels great to write. I hesitate when designing a new project in C++ because I need to figure out the right / clever way to implement something. Go feels a lot more straight forward where I can just write it in the one way it's designed to allow. It gets me writing code a lot faster than other languages.


My experience is different. Believe it or not the type checker is actually inferior to Python + mypy. For example it is possible for variable to be nil, even when it is not a reference.

Types, it has int, int8, int16, int32, int64, uint, uint8, uint16, uint32, uint64 and also float32 and float64.

If you use anything besides int, int64 or float64 you will just have a lot of fun casting.

math.max() and math.min() only work on float64, you can easily use it with different types, and actually it is discouraged to use it with integers. So you need to roll your own if you want to work with integers. But ok, it is math so when you do math apparently you should work on floats because that's what scientists do, but then why it doesn't work with float32? You actually have to cast like

result := float32(math.max(float64(left), float64(right))

If you want to convert a string to an integer, you have nice strconv.ParseInt() where you can specify among other things a bitSize, great, but the resulting type is still int64, you will need to cast it. What about other types, using them is a nightmare, if they were not supposed to be used why not just have int and float type?

If you try to implement a data structure that stores objects, you either have to duplicate the code, use interface {} (looks like that's most common, but then you no longer get help from a type checker) or use generator (this seems best to me, but it is just automation of the first approach).

I don't understand why Go is getting so much good opinions, it is not an enjoyable language to program. The supposed killer feature which were go routines and channels are kind of meh and nothing that you couldn't replicate in other languages. Seems like people like its simplicity, does that mean the other languages are overwhelming?


It's okay, I like elixir's take on things more and I question how suitable Go is for maintainability of large projects. But it's okay. It will improve as more developer tools and language features come online.


It seems to me that you’re going to have a lot more trouble maintaining Elixir code than Go code over the long run.


What makes you say that?

I personally don't see Go and Elixir's primary domains as being equal, or one a superset of the other. So there's some argument to be made about the region where they overlap, but for something inherently based around fault-tolerance and distribution, seems to me that code written to run on the BEAM will be smaller and clearer and therefore more maintainable.


If I'm interested in building low latency and highly available web services it seems to me that both Go and Elixir are reasonable choices. How are they not the same primary domain?

But in any case, Elixir allows a lot more clever code. In my experience working on legacy software, clever code in a dynamic language is error prone and hard to refactor and maintain. Static typing can help, though, I've found this especially true in functional languages where you have a super smart developer do something clever that's hard to understand 5 years later.


What about distributed programming? The BEAM makes that sort of thing super easy.

Maybe Go does have good primitives or libraries for that, and I'm just ignorant of that. :)


This is just how I feel about clojure. I enjoy using a language with design tightly controlled by the people closest to its vision.


> I'm going to risk being labeled an ~incompetent dev~

Why is that?

I thought your comment made a lot of sense.


A common HN trope is that Go doesn't have enough features (Generics usually) and gets in the way of '10x'/'competent' programmers expressing their genius - unlike Haskell (or some other advanced language for advanced minds)


Because it is standard, in these discussions, for someone to quote Rob Pike to say that golang was designed for the lowest common denominator of developers.

Personally, I like go a lot for writing services and console applications.


What are the advantages of having a committee involved in the design of Go? In the case of C++, based on the threads that I read on HN, I see people being unhappy about the decisions taken by its committee.


I appreciate a lot of Golang, but I really wonder how they'll do generics differently than others


It's funny I feel the opposite.

I feel Go's 'opinionated' language design insults my intelligence.


wrt a "proper" way: adding item to a slice, uhmm?


A slice isn't an array. A slice is a view into an array.

You don't look through a window in your house into the backyard, and plant a tree in the backyard by fiddling with the window. It's the same with arrays and slices in Go.

If you want to insert an item into a slice, insert it into the array (by copying to a new array and adding your new element to it while copying), then creating a new slice which includes your addition.

edit: (adding for clarity) In a lot of programming languages, whether they use slices or not, arrays are of a fixed size and must be copied to a new array if you want to add elements. Some languages have some syntax that makes it feel like you are modifying an array in-place, while doing the copy to a new array behind the scenes.

edit-edit: for an implementation example of the above, see Java's ArrayList class: http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/...


I'm by no means a expert, but doesn't Go advocate using append with a slice which will create a new array? https://golang.org/pkg/builtin/#append


> edit: (adding for clarity) In a lot of programming languages, whether they use slices or not, arrays are of a fixed size and must be copied to a new array if you want to add elements. Some languages have some syntax that makes it feel like you are modifying an array in-place, while doing the copy to a new array behind the scenes.

It's that or some magic with larger-than-needed arrays that automatically grow by a bunch extra every time they hit their boundary to make appends faster, while blowing up memory use and making append performance unpredictable.

Lots of (especially) scripting language hide this behind automagic and you see tons of append-in-a-loop where it's not really necessary, as a result.

[EDIT] had insert two places I intended append. Me need coffee.


Yep, you're right, that's the transparently resizeable array thing, and it's exactly how Java's ArrayList class gives the feel of a resizeable array while it actually manages fixed-size backing arrays for you. That's why I linked the source to that class. :)


This is absolutely not best practice. It's perfectly idiomatic to insert an item into a slice (without the copy shenanigans you describe). The slice will manage the copy if necessary.


That's fine as long as you don't mind if the underlying array is modified. As the parent points out, a slice is a view into an array and there could be other views into the same array.

https://play.golang.org/p/goL1JtapY7q


    names = append(names, "Bob")
.... that's really it. Will it have the same backing array as it did before you did append? Maybe, maybe not. Should you care? Absolutely not, and if you do, you're probably doing something wrong.


Sometimes you need to care!

https://play.golang.org/p/goL1JtapY7q


I meant that go's append idiom to reallocate array behind the scenes seems to me somewhat complicated and error-prone.


append?


Security consultant here. I have audited many codebases in many languages. Go is by far the easiest language to audit: it always looks the same, it's not too verbose, there are no generics or OOP. Coincidentally it's always the most secure as well. My take on this is that it is easier to see logic problems because it is easier to read, understand and reason about. On top of that the standard library does so much for you with crypto and security.

Generics and zero-cost abstraction can and are concepts that are often abused instead of used when it makes sense. I hope thay Go will never support generics because I sincerly believe it might mean the end of the language


I'm curious, how will they end Go itself? My understanding is that they always planned to have generics, they just didn't make 1.0 and now the Go community has sort of adopted the lack of them like a badge of honor.

Also, I have no expertise in your field so forgive me if this is a stupid question but wouldn't generics be easier to check over since they allow there to be only one implementation of something for all types versus in Go, a bunch of different implementations of the same thing that you have to check and might have subtle errors?


> "My understanding is that they always planned to have generics, they just didn't make 1.0 and now the Go community has sort of adopted the lack of them like a badge of honor."

As soon as Go adopts generics the community will turn on a dime and pretend they always loved generics (and perhaps even invented them.) That's how these sort of things typically play out. See also, copy/paste on iphones. When only android had it, copy/paste was a misfeature for idiots. When iOS implemented it, copy/paste became the best thing since sliced bread.


See also: Java Generics.


Also see javascript and static typing.


I think there is generics proposal under discussion.


There is! As soon as it is implemented in the language, I will consider Go.


> it's not too verbose

that's a really puzzling statement to me, maybe aside from C, C++, and Java, (and maybe rust) Go is certainly on the "more verbose" side.


Pretty sure those are almost all of the most popular statically typed languages (absent C#, which has about the same verbosity as Java). I'm sure I'm wrong if you're willing to lower the threshold for "popular" enough.


I’ll opine that C# is much less verbose than Java in practice - language features like properties, reified generics, functional-like programming with Linq, tuples and its jilt-in support for async APIs mean you can be surprisingly succinct.


Agreed 1000%. Java is backward compared to C# - bolted on half baked features that are the opposite of elegant, a standard library that is built on the principle of 'why use 10 lines when a 1000 will do' and the tools/IDEs are a generation behind C#. As is the runtime speed.


I agree. It is very easy to learn and inspect. Sometimes I just look at function definition and it is immediately clear. This is so far the easiest to read language I've seen. I don't think generics has to be a problem if their use is very limited. I would like to see generics to work like code generators, something like using m4 to generate the similar type, sharing common methods but having a different core type in their implementation. It would be nightmware to have full C++like generics or even preprocessor macros.


Could it be because Go is newer and handles buffer overflows correctly?


Go already supports generics - the hashmap is generic, and the array is generic.

It's just you can't implement your own hashmap in Go, and make it compile time type safe.


> It's just you can't implement your own hashmap in Go, and make it compile time type safe.

Then it doesn't support generics. That is the entire point of the feature.


C also supports generics - just use void * !!

no, Go doesnt' support generics.


void * is the C's equivalent of interface {} it has little to do with generics although it can be used to work around lack of it.

Perhaps there are other ways, but in C you have parametric polymorphism functionality through macros. That's why min() and max() are not functions but macros and they work with any type that can be compared, not just float64.


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: