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

The March Towards Go

zef.me

Post reply on HN
Print view View original

211–217 of 217 posts

Re: The March Towards Go

#211

Post by NateDad »

_yosefk wrote: post #31
enneff wrote: post #25

Earlier quoted context omitted.

The hundreds of high quality Go packages that do handle errors are an existence proof against your argument. Look at nearly anything on godoc.org. You didn't cite that quote. I am certain whoever said it is doing something silly.

I did cite it - it's from my parent comment's link: http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-r... Are you saying that: * Getenv doesn't return an empty string for a non-existent env var? * Go JSON parser doesn't return an empty list given an empty string? That you can handle errors without exceptions needn't have an existence proof... The question is how many errors are silenced. Stats will be hard…

That post is a piece of garbage. He's clearly angling for a language like Rust or Haskell that has a very complex type system for preventing errors in the code, and no other language would succeed with the way he was writing code (which was completely inane). It's like he jumped in a plane, hit full throttle ahead and complained the plane crashed into the ocean instead of landing him safely in Seattle.

Re: The March Towards Go

#212

Post by NateDad »

cgag wrote: post #19
jackyb wrote: post #13

Earlier quoted context omitted.

As far as I know, Go already has a really strong static type system (int32 cannot be assigned to int for example). Which parts are weak?

No generics (parametric polymorphism), no algebraic data types. You should learn some Haskell or Ocaml even if you don't plan on using it in production. Go's type system is weak. Edit: I don't think there's anything like type classes either but I'm not 100%.

I don't understand why all the ML-lovers have to bash Go for not being OCaml or Haskell or Rust. It's like bashing Python for not having static typing. Go is not one of those ML languages with a complicated type system. It has a simple type system. This is a feature for Go, just as dynamic typing is a feature for python. Neither is right or wrong or backwards. They're different design choices. If you don't like it, that's fine, don't use it. But it's not an inherently bad choice.

Re: The March Towards Go

#213

Post by NateDad »

DCKing wrote: post #66
otikik wrote: post #60

Earlier quoted context omitted.

> Go's type system is weak. It is strong enough for me. I see the lack of algebraic data types and type classes as a feature, honestly. It means I can learn the things I need and start working in 2 days instead of in 2 weeks or a month. I sometimes need generics, but not frequently enough to miss them. You think Go's type system is weak. I think Haskell's type system is overcomplicated. So, there.

Go's type system being weak is a factual statement. Haskell's type system being overcomplicated is an opinion. One might prefer a weak type system over a strong type system, but that's a different discussion. The parent clearly expressed that he wants a static strong type system.

Factual implies correct. But you are incorrect that it is weak. You're looking for objective and subjective.

Re: The March Towards Go

#214

Post by andrewvc »

stcredzero wrote: post #199
andrewvc wrote: post #195

Earlier quoted context omitted.

I agree that callback hell sucks, and promises are a vast improvement, but still shitty. Coroutines and channels are not obviously 'just what's needed' in my opinion however. I think they're part of a larger picture. Mature languages should have multiple concurrency models available for different tasks. Clojure, for instance, supports coroutines, threads, and multiple other flavors of concurrent programming. There is…

> polyglot concurrency is the future most likely. One kind of "polyglot concurrency" was the precisely problem of the past! In fact Rich Hickey says himself: You can do concurrency in Java with semaphores and such, but you end up doing some sentinel-thing that's somewhat specialized for your particular subsystem. Then you have to interface with this other subsystem...implement this new feature...then several months l…

Agreed that you shouldn't mix concurrency models excessively, but many problems do call for a mix. I don't think Rich was referring to what I am. He was talking about the trouble composing Java concurrency using locks and such, which is just hard.

On the other hand with clojure, a standard mix is to use non blocking IO to multiplex a large number of connections, then delegate work to a threadpool (using clojure refs/atoms etc.). Such a system has a much smaller chance of deadlocks and other issues.

A great example of polyglot concurrency is the clojure reducers framework that lets you delegate work to a fork/join pool. Most people don't need it, but it's nice to have a safe, seamless interface to such an advanced concurrency tool.

Re: The March Towards Go

#215

Post by anko »

pjmlp wrote: post #115
anko wrote: post #100

Earlier quoted context omitted.

.NET isn't a language. The languages you list really suck compared to Go. They are ridiculously verbose. Goroutines in particular are really quite nice.

> .NET isn't a language. It is easier to name the eco-system than all the languages with available compilers targeting .NET. > The languages you list really suck compared to Go. They are ridiculously verbose. Except they embrace the last 30 years of language research. > Goroutines in particular are really quite nice. Goroutines are nothing new. Modula-2 already had them.

Gosh this reply is ridiculous.

We're talking about languages and .net isn't a language. The differences between visual basic and f# are vast.

Are you saying the last 30 years of language research dictate that languages should be more verbose?

Comparing go-routines to modula-2 is disingenuous at best. Multiprogramming is nothing like multithreading.

Re: The March Towards Go

#216

Post by facepalm »

adamlett wrote: post #201
dccoolgai wrote: post #126

Earlier quoted context omitted.

I've been working with JS professionally for the last 3 years...priorto that, spent many years with C++/SQL/etc...the statements that people get "burned" by JS (pesumably because of the weird coercion or floating-point comparisons?) I've never understood...maybe I just write my code in a weird way that insulates me from those things...I've never experienced more than a "minor surprise" in dev - certainly never been "…

> maybe I just write my code in a weird way that insulates me from those things Maybe you do. I certainly strive to. But don't you sometimes have to work with other people's code too? I recently inherited a 10 years old codebase written by people who had not heard of implied global and didn't use the var keyword. In my previous job I had to educate several frontend developers about the dangers of using parseInt witho…

How do you "get burnt" by parseInt without radix? Yes, I made that mistake before, too. But it's usually in a situation where you detect your error immediately. Then I add the radix, problem solved.

I don't know the libraries of other programming languages by heart either. I would be making lots of mistakes in other languages if I wouldn't look up the correct API all the time.

Re: The March Towards Go

#217

Post by BrendanEich »

adamlett wrote: post #77
facepalm wrote: post #42

Earlier quoted context omitted.

There are minor details wrong with JavaScript. Normally you don't encounter them in daily use. Apart from that JavaScript is brilliant. Few other languages can match it's simplicity. Python falls through because it doesn't have real lambda.

> There are minor details wrong with JavaScript. Normally you don't encounter them in daily use. If you really believe that, I can only assume that you either don't have very much experience with Javascript and haven't yet been burned (or haven't yet discovered that you've already been burned), or that you don't have any experience outside of Javascript and therefore are not aware that languages exist that have all t…

> In fact Brendan Eich has stated that his intention was to create Scheme for the browser

No. Read https://brendaneich.com/2008/04/popularity/. "Come to Netscape, do Scheme in the browser!" was the bait. When I got to Netscape, it "had to look like Java". And given timing both internal and due to MS coming after Netscape, it had to be done really, really quickly.

/be

Post reply on HN