Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Leaving Go

jozefg.bitbucket.org

Post reply on HN
Print view View original

111–120 of 220 posts

Re: Leaving Go

#111

Post by nostrademons »

astine wrote: post #66
Dewie wrote: post #22

Earlier quoted context omitted.

Maybe it turns out that the sociological side of programming trumps the technical side; that languages that forces or fosters a common vocabulary will always "win" over languages where you have so much power that you can easily diverge from the mainstream dialect, and there is not much culture of restraining this freedom. On the other hand, these dialects are embedded DSLs; specialized languages created and hosted by…

I think that part of the problem is that more 'powerful' languages often more concept heavy than more 'pragmatic' languages and that makes them harder to learn for a lot of programmers. Take Clojure for example. A lot of people including myself like this language a lot, but to be productive in it, you have to get used to the JVM, Lisp s-expressions, a heavily functional programming style with few side effects, a sign…

I think it's actually a third-order effect resulting from this: being harder to learn means that fewer people learn it, which means that there are fewer libraries and less community support available for the language. That means that even experienced, highly-skilled practitioners who could easily pick up the new language in a weekend are less productive in it.

I've written Haskell, I've written Scheme, I picked up Go in a couple weeks, and learning a new functional language shouldn't take me more a few weeks. Nevertheless, if I were starting a project now, I would probably pick some combination of Python/Java/C++. Why? Because their library support & ecosystem far outweighs any productivity boosts I could get with Go, Node.js, Clojure, Erlang, Haskell, etc. And yeah, I know you can use Java classes with Scala/Clojure, but there's an impedance mismatch mapping the concepts and existing library structure onto a functional language that doesn't exist with Jython.

Re: Leaving Go

#112

Post by Jtsummers »

pron wrote: post #91
pnathan wrote: post #74

Earlier quoted context omitted.

I don't even understand your question. My internet is filled with half-baked webapps with bad errors and riddled with stupid security vulnerabilities, many of which can be defined to not occur in an adequately designed tech stack. Desktop programs work through dint of manpower, crufty testing environments, and users-as-QA. What exactly are you looking for? Web app frameworks? they exist. database connectors? they exi…

> Sophisticated programs running sophisticated systems? They exist Not really. Well, far less than in all those horrible, unusable languages. All I'm saying is, if Haskell makes writing correct code so easy, where is it? There should be tons of it now. It should be practically everywhere. In fact, it should be financially stupid to do anything in any language other than Haskell. So where are all the companies making…

Not Haskell, but its relative (cousins of some sort I hear), OCaml, is used at Jane Street [1]. They seem to be making money.

[1] https://www.janestreet.com/technology/

Re: Leaving Go

#113

Post by piokuc »

bookwormAT wrote: post #95
piokuc wrote: post #36

I think people gave Go a lot of credit just because it was designed at Google. People have high respect for Google engineers and so they assume what Googlers have designed must be flawless. So they take for granted ideas like lack of exceptions or lack of operators' overloading being a good thing, even though I'm quite sure they would be quick to criticize such BS if that was a feature in a language not coming from G…

I think people gave Go a lot of attention because it was designed by Rob Pike and Ken Thompson.

I have a feeling that the attention would be much more modest if they happened not to be on Google payroll when they designed the language. Anyway, whether it's because of Ken or Rob, or Google brand, it doesn't change the point I was trying to make.

Re: Leaving Go

#114

Post by webkike »

pcwalton wrote: post #108
tptacek wrote: post #107

Earlier quoted context omitted.

x = append(x, foo) is a common C idiom too; in fact, it's been awhile since I had to work with STL containers, but I think it was common there too. I love Golang namespacing rules. They do exactly what I need them to do to allow me to call into other people's code using the right function calls, and nothing else . I think Golang's namespacing is a high point of the language.

> x = append(x, foo) is a common C idiom too; in fact, it's been awhile since I had to work with STL containers, but I think it was common there too. No, vector::insert() is the common idiom and mutates in place. It'd be written `x.insert(x.end(), foo.begin(), foo.end());` For single elements, vector::push_back() is the common idiom, and also mutates in place.

vector::insert() is certainly not a C idiom. In can never be a C idiom because that is C++ code. the x = append(x, foo) idiom can be seen all over C, most obviously with the use of realloc, which is often called to resize an array via x = realloc(x, newsize).

Re: Leaving Go

#115

Post by bsdetector »

Donch wrote: post #31

The example could have been simplified: func abs(x Top) Top { switch v := x.(type) { case int32: if v

This isn't simpler, it's smaller. In fact it's more complicated, since instead of 4 completely separate cases you have 4 half-cases and a default.

For instance, pass a positive int16 and you get the right answer, but pass a negative int16 and you get a useable but wrong answer instead of nil from the original.

Re: Leaving Go

#116

Post by pjmlp »

tdees40 wrote: post #12
taylorlapeyre wrote: post #8

I just wanted to point out that the author of this article is a high school student. http://jozefg.bitbucket.org/about.html

Wow, "writing lots of compilers and type checkers" definitely wasn't on my radar screen when I was in high school.

I did an informatics technical degree on high school back in the early 90's in Portugal.

We had introduction to parsing and basic language processing.

Re: Leaving Go

#117

Post by chc »

mseepgood wrote: post #93
tptacek wrote: post #80

Earlier quoted context omitted.

There are C REPLs too.

I know, I didn't say otherwise.

I think tptacek may have implying that, like all the REPLs for C, the REPLs for Go are more curiosities than anything anyone would want to use.

Re: Leaving Go

#118

Post by shurcooL »

Every design decision has trade offs. Since the author only covers the more obvious negative aspects of those 2 features, I'd like to cover the more subtle positives.

> Extensibility

One really great thing about that is how consistent it is. Every func in Go has a unique identifier: the package import path and the func name pair. This makes it possible to build tools like godoc.org and the `doc` command that let me look up the exact behavior of (unfamiliar) code.

In this case, I can go to godoc.org/math/big#NewInt or type `doc big.NewInt` and see:

  // NewInt allocates and returns a new Int set to x.
  func NewInt(x int64) *Int
In fact, it's so predictable that I don't have to think. As long as it's Go code, if I ever run into an unfamiliar func F of package P, I can always go to godoc.org/P#F or `doc P.F`. No searching, just an instant lookup. If I need to do 30 such lookups to solve a task, it makes a big difference. This applies to _all_ 3rd party Go packages. That is big.

On the other hand, something like `x + y` is magic to me. I know that computers work with bytes at low level, and I want to be _able_ to understand what happens on that level. I understand and accept such magic for built in types. But I certainly wouldn't want to be reading a 3rd party Go library code that says `x + y` on its custom types. Where would I go to find out what that custom plus operator does? How does one make an unexported version of a plus operator? There'd be less consistency, more exceptions and rules, more variations in style and less tools that can be built to assist/answer questions about Go code.

> The Type System

I don't have time to cover this atm, but there are some advantages to the explicitness and verboseness of Go's approach. Can you think of any?

I'm not suggesting it's the best it could ever be, just that there are both advantages and disadvantages that should be considered.

Re: Leaving Go

#119

Post by rwallace »

personZ wrote: post #60

These sorts of posts are profoundly boring. I know people will up arrow it -- some sort of spiteful "Down with Go!" contrarian thing, when they aren't talking up rust -- but it isn't because the content is interesting or illuminating, but rather as some sort of activist thing. This particular piece (by a high school student, as an aside) starts off trying to create a surrogate for generics in Go. Don't . Here's the t…

Generic abs is an unrealistic toy example, sure. A much better example is an extensible array (a.k.a. vector a.k.a. list). This is the most basic data structure in all of programming, the first data structure needed in almost every program I write, and to be honest, I am of the opinion that a programming language that doesn't provide this has no reason to exist in the twenty-first century unless it was grandfathered in from the twentieth.

Re: Leaving Go

#120

Post by pjmlp »

xioxox wrote: post #35
herokusaki wrote: post #20

Earlier quoted context omitted.

Can you elaborate why?

I was interested until I discovered Julia doesn't have a useful form of OOP inheritance. Ok, you don't always need it, but for some things it's indispensable (e.g. using widget/window systems).

There are lots of ways of doing OOP, the Java/C# world isn't the only way,
Post reply on HN