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

C vs GO

crypto.stanford.edu

Post reply on HN
Print view View original

171–180 of 184 posts

Re: C vs GO

#171

Post by EliRivers »

millerfung wrote: post #61
EliRivers wrote: post #28

Earlier quoted context omitted.

"any new language today should be all beginner friendly" I disagree. I think any new language should be designed to best meet the kind of problem it's being created to deal with. Making it "beginner friendly" (whatever that means - I bet there are lots of different interpretations) is a nice extra, but should not come at the expense of solving the problems.

Yes I agree that new language should be developed because of the ever rapidly changing digital world to enhance everyones experience in digital products. I am sure it is going to get more complicated, however, being a beginner friendly language should still be taken into account. In fact, only the one who is more beginner friendly will survive in the long run because in the future there might be a mismatch of demand…

"In fact, only the one who is more beginner friendly will survive in the long run"

That makes no sense to me. In any industry with a sizeable number of workers, there is a huge range of tools, from the entry level easy-to-use up to the fantastically intricate and arcane. Tools that are not "beginner friendly" are that way for a reason.

As an example, assembly code is never going away; for the obvious reason that if nobody understands it, nobody can write compilers, and also because there are cases where knowing assembly is useful and helps to make better code, whether it's taking apart the code to really, truly get every last clock-cycle of power out of the thing, or to take apart code in the search for arcane bugs and wonderfully subtle interactions causing unexpected behaviour. Assembly is old, and will never go away, and is (for most meanings of the phrase) not beginner-friendly.

The only advantage to a language being "beginner friendly" is that beginners can learn it fast. What you then get are inexperienced programmers who know just enough to be dangerous (this is not an attack on them; it's the case in any industry with a low barrier to entry, and a stepping stone to being better). One expert, experienced programmer with knowledge of a "beginner unfriendly" language is worth literally dozens of first-day coders wielding their hand-holding, garbage-collecting, counting-begins-at-one modern version of BASIC. That is never going to change, and every first-day coder wants to become that expert.

Even if somehow all the non-"beginner friendly" languages died, the very next day someone who'd been coding in this "beginner friendly" language for a decade would finally get sick of it and start designing a language she can truly express herself in without having all the hand-holding that holds her back.

Re: C vs GO

#172

Post by gouranga »

luriel wrote: post #168
gouranga wrote: post #167

Earlier quoted context omitted.

libtask looks really cool. Thanks for posting. I suppose that begs the question: if you can built it in the language, should it really be a part of the implementation?

Plan 9's libthread ( http://man.cat-v.org/plan_9/2/thread ) provides similar CSP-style concurrency to Go. Yet, the authors, after using it for many years, and after having used and built systems where it was part of the language (eg., Inferno/Limbo) decided it was important enough to make it part of the language for it to be usable. There are also other language features that make it much more usable and that are mis…

Thanks for the information - I will have a good read this evening :)

Re: C vs GO

#173

Post by papsosouid »

soc88 wrote: post #170
papsosouid wrote: post #169

Earlier quoted context omitted.

You certainly can suggest it, I already tried it though. ;) Scala ends up more like the worst aspects of haskell and go combined, rather than the best aspects of both.

Details, please.

Pretty much what I described above. The bad parts of haskell (compile time, memory usage while compiling, bad syntax, terrible dependency/package/module management) are all present in scala, and it is semantically an inferior language to haskell. Scala is certainly a whole lot closer to haskell than go is, and I certainly don't blame anyone involved in the creation of scala for its limitations, the JVM limits how good they can get. But at the end of the day, using scala would solve none of the problems I have with haskell, and leave me with a less powerful language.

Re: C vs GO

#174

Post by eeperson »

papsosouid wrote: post #173
soc88 wrote: post #170

Earlier quoted context omitted.

Details, please.

Pretty much what I described above. The bad parts of haskell (compile time, memory usage while compiling, bad syntax, terrible dependency/package/module management) are all present in scala, and it is semantically an inferior language to haskell. Scala is certainly a whole lot closer to haskell than go is, and I certainly don't blame anyone involved in the creation of scala for its limitations, the JVM limits how goo…

Out of curiosity, what make the Go dependency management so good? I'm not terribly familiar with this aspect of Go. Based on a what I've read, it doesn't seem dramatically different than what you would do for Scala (except it is packaged with the language rather than an external tool like SBT). Is there something I am missing?

Re: C vs GO

#175

Post by Graphon »

heretohelp wrote: post #104
Graphon wrote: post #99

People suggesting that Go is a potential replacement for Python, Lua or Ruby are missing the point. IMO, Go isn't designed to compete with those existing languages for existing opportunities. The key opportunity in the future is smart devices everywhere. Embedded, connected intellgence, everywhere. Everything is a communication device. Today your phone and your car; tomorrow: Your shoes, your office, the grocery stor…

Go is highly inappropriate in embedded environments so your pipedream betrays a naivete to systems programming.

Today's embedded is not tomorrow's embedded.

In 10 years your sunglasses will have more compute power and memory than today's smartphone .

Re: C vs GO

#176

Post by soc88 »

papsosouid wrote: post #173
soc88 wrote: post #170

Earlier quoted context omitted.

Details, please.

Pretty much what I described above. The bad parts of haskell (compile time, memory usage while compiling, bad syntax, terrible dependency/package/module management) are all present in scala, and it is semantically an inferior language to haskell. Scala is certainly a whole lot closer to haskell than go is, and I certainly don't blame anyone involved in the creation of scala for its limitations, the JVM limits how goo…

Well, I guess will have to agree to disagree here.

From my perspective Scala solves a lot of problems with Haskell:

- Working module system (From my experience, especially people coming from OO languages are surprised that this is such a huge unsolved problem in Haskell, because all the languages they know have come up with a working solution.) It will be interesting if some OCaml-style module system as currently discussed makes it into Haskell.

- It is much easier to reason about space consumption.

- It benefits from the best general-purpose VM with its superior garbage collection algorithms. (I agree that the lack of VM features is deeply annoying.)

- Tons of tools for monitoring.

- Debuggers. I'm not certain that Haskell will ever have decent debugging capabilities, taking its approach to laziness and compilation into account.

- Exceptions which don't leave the developer wondering where exactly an error has occurred. (Stack-traces, anyone?)

- Libraries for basically everything. Even if you don't use them, you can have a look at how other developers have approached a certain problem.

- Tool support. The Scala IDE alone has 10 people working on it. Compare it to Leksah and EclipseFP.

- Commercial support. Scala has Typesafe (> 30 people) and dozens of partners, consultancies, etc. In Haskell, there is Well-Typed, which is more or less payed by the “Industrial Haskell Group” (which consists of Galois and Amgen).

- The REPL is just a lot more usable.

I don't have any problems with the compile time. When developing in Eclipse there is just no delay between pressing “Run” and the execution of the program. It is instantaneous.

Syntax ... well, that's a completely subjective topic.

“terrible dependency/package/module management” ... SBT delivers a top-notch experience here. Have dependencies as source on sites like GitHub? SBT will fetch and build them without problems. Need to deploy artifacts into the local repo, to Maven Central or other services? SBT will happily do that. Need to cross-compile to different versions? Easy. Want to build software for Android? SBT will compile, jar, proguard, dex and install it on your device in seconds. I would love to hear what you would like to see here!

“semantically an inferior language”: Well, I guess every language is inferior to Haskell. I appreciate the hard work done in Haskell to track side-effects and other things. While I don't think these exact approaches will ever see much adoption, it leads the way to more manageable approaches. I'm pretty sure computer science will come up with some great solution in the next decade and Haskell will play its part here.

“less powerful language”: Well, it depends on what you mean with “Haskell”. “Haskell” == the Haskell standard? Scala is a lot more powerful than that. “Haskell” == GHC with all its proprietary extensions enabled: Yes, probably.

I don't think Go is really comparable with Scala or Haskell. It feels a bit like it was designed in an ivory tower. It is certainly a nice language if you ignored the last 20 years of progress in language design and have never used anything except C.

Let me know what you think and if I missed something!

Re: C vs GO

#177

Post by millerfung »

EliRivers wrote: post #171
millerfung wrote: post #61

Earlier quoted context omitted.

Yes I agree that new language should be developed because of the ever rapidly changing digital world to enhance everyones experience in digital products. I am sure it is going to get more complicated, however, being a beginner friendly language should still be taken into account. In fact, only the one who is more beginner friendly will survive in the long run because in the future there might be a mismatch of demand…

"In fact, only the one who is more beginner friendly will survive in the long run" That makes no sense to me. In any industry with a sizeable number of workers, there is a huge range of tools, from the entry level easy-to-use up to the fantastically intricate and arcane. Tools that are not "beginner friendly" are that way for a reason. As an example, assembly code is never going away; for the obvious reason that if n…

That's a very good argument, I will accept this :) hopefully, at the end, there is a language that is easy to understand at first and therefore people could easily pick it up, like English?

Re: C vs GO

#178

Post by papsosouid »

soc88 wrote: post #176
papsosouid wrote: post #173

Earlier quoted context omitted.

Pretty much what I described above. The bad parts of haskell (compile time, memory usage while compiling, bad syntax, terrible dependency/package/module management) are all present in scala, and it is semantically an inferior language to haskell. Scala is certainly a whole lot closer to haskell than go is, and I certainly don't blame anyone involved in the creation of scala for its limitations, the JVM limits how goo…

Well, I guess will have to agree to disagree here. From my perspective Scala solves a lot of problems with Haskell: - Working module system (From my experience, especially people coming from OO languages are surprised that this is such a huge unsolved problem in Haskell, because all the languages they know have come up with a working solution.) It will be interesting if some OCaml-style module system as currently dis…

Most of what you listed as "solved" by scala isn't a problem in haskell in the first place. The JVM is a problem, not a solution to the problem haskell has of "actually working". Listing "our possible semantics are gimped by java" as a feature seems rather bizarre. Debugging? Have you ever tried debugging haskell? It works just fine.

>Tool support. The Scala IDE alone has 10 people working on it. Compare it to Leksah and EclipseFP.

I don't think insulting the people working on the scala eclipse plugin is very productive. Yes they have more people, and yes it is annoying that it is still not as good as haskell's eclipse plugin, but give them some time.

>The REPL is just a lot more usable.

In what way? The fact that it is way slower? You seem to be just listing random things as if you've never tried haskell.

>SBT delivers a top-notch experience here

You are the first person I've ever seen make that claim. Hell, people use maven because SBT is so bad.

>I don't think Go is really comparable with Scala or Haskell. It feels a bit like it was designed in an ivory tower

You might want to look up what "ivory tower" means. That is the most backwards characterization of go I've ever seen.

Re: C vs GO

#179

Post by papsosouid »

eeperson wrote: post #174
papsosouid wrote: post #173

Earlier quoted context omitted.

Pretty much what I described above. The bad parts of haskell (compile time, memory usage while compiling, bad syntax, terrible dependency/package/module management) are all present in scala, and it is semantically an inferior language to haskell. Scala is certainly a whole lot closer to haskell than go is, and I certainly don't blame anyone involved in the creation of scala for its limitations, the JVM limits how goo…

Out of curiosity, what make the Go dependency management so good? I'm not terribly familiar with this aspect of Go. Based on a what I've read, it doesn't seem dramatically different than what you would do for Scala (except it is packaged with the language rather than an external tool like SBT). Is there something I am missing?

SBT just fails to work correctly on a semi-regular basis. Quite a few scala people ended up resorting to maven instead, which says a lot.

Re: C vs GO

#180

Post by eeperson »

papsosouid wrote: post #179
eeperson wrote: post #174

Earlier quoted context omitted.

Out of curiosity, what make the Go dependency management so good? I'm not terribly familiar with this aspect of Go. Based on a what I've read, it doesn't seem dramatically different than what you would do for Scala (except it is packaged with the language rather than an external tool like SBT). Is there something I am missing?

SBT just fails to work correctly on a semi-regular basis. Quite a few scala people ended up resorting to maven instead, which says a lot.

That has not been my experience at all. SBT has always worked correctly for me.

When was the last time you used Scala and/or SBT? I know a lot of the tools in the Scala ecosystem were unstable prior to Scala 2.8. However, now they have become pretty good. Even the, previously notoriously bad, Eclipse plugin has become good.

Post reply on HN