Hacker News new | comments | ask | show | jobs | submit login

I am only a beginner in Go, but what I have done so far, I have loved. It's a great alternative to your typical scripting languages like PHP, Perl, Python, Ruby, Node, etc, etc, etc... And simpler and funner to use than C/C++ IMO.

I really hope it keeps gaining momentum.




It will - it's too compelling a proposition.


I doubt it will ever make a dent on the enterprise over the JVM/.NET/C++ stacks, unless a compelling library requiring its use shows up.


It will tend to make a dent one program at a time - like etcd, docker, nsq. Soon, a significant fraction of your installables will have to be compiled with Go.

This was reason enough for C to get popular.


> It will tend to make a dent one program at a time - like etcd, docker, nsq. Soon, a significant fraction of your installables will have to be compiled with Go.

Only if commercial UNIX and Windows also get rewritten in Go.

> This was reason enough for C to get popular.

C got popular because UNIX was adopted by the enterprise and C was the system language.

I doubt C would ever been popular without UNIX.


This is correct. C was dying off in the mid-1980s until UNIX-based workstations were invented, causing a resurgence in C's popularity.


(Don't know why I can't reply to the leaf nodes in the conversation...)

>What was taking its place at that time?

Pascal was fairly heavily used, but was dying out. LISP was hot because it was the middle of the Great AI Boom, Modula-2 was supposed to replace Pascal and be a systems programming language, and ADA was supposed to be the next great thing. Apple had created Object Pascal. Self was the big research language. Nothing really took hold until C++ in the latter part of the 1980s.


Sorry, but that's just plain wrong. Everything was being implemented in C from embedded control to PC apps with C++ just around the corner.


I might be off, but I think C still would have been popular. It's such a simple language, very easy to learn, easy to reason about, close to the machine but provides enough abstraction to easily write complicated code. C's merits as a language are self-evident beyond its usage in Unix. Of course, some other language with this set of properties might have taken C's role if it had not been for unix, so maybe that's what you meant.


> It's such a simple language, very easy to learn...

Mhm.

> ... easy to reason about...

So very much no. There is nothing about the stateful nature of C-programming, its syntax or the patterns people use that is easy to reason about. You're comparing it to what, exactly? C++? C is an amazing language but comparing it to the languages that were around when it became popular it's not even close to relatively easy to reason about. Even less so nowadays.

> provides enough abstraction to easily write complicated code

This strikes me as a weird thing to list in "pros". Complicated is the opposite of good. Abstractions should let you write simple code, not complicated code. I feel like you've either misunderstood the word "complicated", massively mischaracterized C or you have a very weird view on abstraction.

> Of course, some other language with this set of properties might have taken C's role if it had not been for unix, so maybe that's what you meant.

I'd like to point out that your assumption that people use programming languages because they are better than the alternatives is pretty naive. The most popular languages are decent, no doubt, but have you noticed how every really good language suffers from a pretty huge lack of users? We all know these languages are better, but it's never been an issue of "You're not good enough for people to use you".

If there was ever any indicator for a good language it'd be "What do people choose when they have the freedom, knowledge and opportunity to choose anything without any outside influence?". That scenario is so wildly scarce to observe and anyone who is in that situation likely suffers from biases acquired earlier on his programming journey.


I honestly think it will. Especially for high-performance applications it's going to start making serious inroads. Financial and scientific applications will start the trend and once some infrastructure and best practices get established, it will start seeping into the mainstream. Having a big name like Google behind it is a lot more assuring to businesses than hacker-driven projects like nodejs or academic-driven ones like Scala. Go is built for industry.


> ... academic-driven ones like Scala ...

The UK financial sector seem to like academic stuff then.


Could you go into detail on your experiences for Go compared to JS or Ruby?


Takes me about 10-20% longer to do trivial things in go than ruby, but the results are much faster and bigger refactorings are also much faster to complete (nice type system). The ability to really max your perf out in short amount of time is also delightful


My experience with Go was bizarre -- I loved programming in it, but I don't understand why!

For example, Go has no REPL. (It's difficult for statically-typed languages to provide one.) It's commonly believed that a REPL is valuable and increases productivity. So if you were offered the choice, is there any circumstance in which "no REPL" is equally powerful as having one? Well, the vast majority of great hackers seem to agree that it's always superior to have a REPL than to be forced to live without.

Lots of people love programming in Golang (I especially love to write distributed systems with it!) yet it probably won't ever offer us a REPL. That must mean one of two possibilities are true, both of which are bizarre: either 1) we love Go in spite of being limited by not having a REPL, or 2) having a REPL isn't as big of a deal as everyone thought.

So I'd like to ask all of you: Do we love Go in spite of being held back by it? If so, then what are the factors that cause us to decide that using Go is worth giving up programming power? After all, each of us are choosing to use Go in lieu of more powerful languages. So why do we choose to give up programming power?

Or do you believe in the other possibility: having a REPL doesn't matter as much as everyone thought? That seems plausible. It's at least as plausible as "it's a good idea to give up REPLs for static typing."

Go is wonderful to work with. But I'm so confused why it feels wonderful to me. I know I love programming in it, but once I start thinking about the implications, I start to wonder: Isn't giving up power a bad thing, and therefore choosing to use Go == choosing to be forever held back by its deficits, and therefore it's a bad decision? Or is it true that having every possible language feature available to you ("maximum potential programming power," i.e. as far above Blub as possible) isn't as big a deal as we all thought?

This pg essay talks about why it's worthwhile to have as much power as possible: http://www.paulgraham.com/avg.html (search for Blub Paradox) .... So either he's wrong, or we're ignoring him even though he's right. Which is it?

EDIT: There are other limitations besides lacking a REPL, e.g. there's no dynamic typing. It seems like we should try to figure out why it's a good idea to give up any programming power at all.


I see go as essentially a polished and robust glue language. It's not particularly well suited to data processing because its lack of functional constructs and generics makes transforming lists verbose, but it's perfect for wiring up databases, apis, system calls, sockets, queues, and the like in a way that's safe, performant, and concurrent by default.

Given this focus, it sort of makes sense why you might not miss a repl as much in go (though personally I do still miss it). Repls are most useful for exploring and experimenting with complex data, while I think go's focus is more on streamlining and bulletproofing all the machinery surrounding the data than doing a whole lot with the data itself.

I don't mean this as a criticism and I'm not trying to say that you can't do serious data processing in go, just that it's not a core strength like it is in functional languages. I think the majority of applications out there actually have fairly light data processing needs and heavy glue needs, so go's set of tradeoffs make it a great candidate for tons of projects.


> It's difficult for statically-typed languages to provide one.

No, it's not. As long as you have a way to polymorphically print a return value, which there are ways around (in Go, with reflection; in Haskell, with typeclasses; in Java, with Object's toString), there is nothing semantically difficult about a REPL for statically typed languages.

> there's no dynamic typing

Yes, there is, through `interface{}`.


The main thing stopping Go having a REPL (when there are ones for C, for example) is that Go can't yet compile to, or load, dynamic libraries. This stops each bit of REPL being compiled up and executed, which would otherwise be simple.


And most likely never will, given the Go's team stance on dynamic linking.


Golang is like a touring car. It's fast, but doesn't have the fastest engine. It's got some nice features, and it's comfortable (at least for the driver), but it doesn't have every bell and whistle. But: the handling is amazing; it's a monster in the corners.

You could give a BMW M3 a faster engine, or a more full-featured Bluetooth sound system, but it's the way the steering wheel feels that makes people love that car. Same with Golang. They did an extraordinary job balancing the language, especially if you're the kind of programmer (a systems developer) that appreciates that kind of balance.


Normally, if I see a car analogy applied to programming languages (which hackers seem to do a lot), I instantly brace myself for petty debate on the semantics of the analogy itself (which hackers seem to do a lot).

This one is perfect however, and really explains my feelings towards Go (and recently, C, oddly enough).


>especially if you're the kind of programmer (a systems developer) that appreciates that kind of balance.

Go really failed to appeal to a lot of systems programmers, despite their intentions. Go is picking up people who used untyped languages and still didn't accept that static typing does not mean java. They finally have a simplistic statically typed language that isn't java to use.


This is more "Internet article of faith" than actual fact; it's something people say because it was said in some blog post once. For whatever it's worth to you, I've been a systems programmer since ~1995. The lingua franca of systems programming is C; Golang's type system is strictly superior to C.


It is more "direct observation" than "internet article of faith". I know one person who likes C and go. Every other go convert I know came from a scripting language. Golang's type system is strictly inferior to D.


Go makes it very easy to create tools on top of it. And its fast compiler enables doing things almost as if it's a dynamic language.

I've made a live editor [1] for Go that I use very happily (and I keep working on a 2nd generation version, rewritten in Go, which will be more user-friendly to install and use).

There are other REPL-like tools like [2] and [3].

[1] https://github.com/shurcooL/Conception#demonstration

[2] https://github.com/sriram-srinivasan/gore

[3] https://github.com/shurcooL/goe#examples


Statically typed languages don't necessarily not have a REPL, most functional languages are statically typed and yet they general have a REPL. OCaml, Haskell, F# and the like.


Another example would be Scala. It has a command-line REPL and the IDE has a worksheet[1]. I find both tremendously useful.

[1] https://github.com/scala-ide/scala-worksheet/wiki/Getting-St...


> Or do you believe in the other possibility: having a REPL doesn't matter as much as everyone thought?

The importance of REPL is very exaggerated. Neither Java, C#, C++ nor C have one (and together, these four languages probably make up for 95% of programming languages).

There is nothing that prevents any of these languages to get one (Scala has one, a bunch of these exist for other statically typed languages), it's just not that useful when you have powerful IDE's at your disposal.

Most of the time I need REPL-like functionalities, I need it in the heart of my application, with all its structures and state initialized and in the middle of a breakpoint. I hardly ever need to type snippets of code with zero context around them, which is what REPL's offer.


The REPL and IDEs are somewhat orthogonal. IDEs are extremely limited in fact, as they can only rely on static-type info to infer meaningful stuff about how your software will behave. A REPL on the other hand is a runtime instance of your software that you can touch and interact with.

Btw, in regards to needing initialized state - code that can't be initialized easily, smells badly. And in Python and Ruby for example, you can stop the execution at any point in your software and initialize the REPL, having complete access to the current context.

In Ruby it's as easy as:

   require 'ruby-debug'; debugger
In Python it's as easy as the following (add IPython to the mix for extra awesomeness):

   import pdb; pdb.set_trace()
I'm working with Scala lately and doing the above is a little painful, but I still work with the REPL a lot, in spite of also using IntelliJ IDEA as an IDE.

It's true that Java, C# or C/C++ don't have a REPL, but that's why I don't use Java, C# or C/C++ (or Go).


Huh. The Visual Studio Immediate window [1] has existed since the days of Visual Basic [2]. What are you guys seeing as a REPL that I'm not?

[1] http://msdn.microsoft.com/en-us/library/f177hahy(v=vs.71).as...

[2] http://msdn.microsoft.com/en-us/library/aa716276(v=vs.60).as...


Well, it's difficult to see what a REPL is or does, if you're calling Visual Studio's "Immediate Mode" a REPL. It's not. It can evaluate simple expressions, but you can't type arbitrary code in it and hence you can't do arbitrary development in it, so it's not a REPL.

The closest thing C# has to a REPL is the Mono C# Shell, built on top of Mono's C# Eval and it's pretty cool, but it's pretty new and raw and needs Mono.


> The closest thing C# has to a REPL is the Mono C# Shell, built on top of Mono's C# Eval and it's pretty cool, but it's pretty new and raw and needs Mono.

So what?! Languages and implementations are not the same thing.


Err, what?

So languages are plagued with implementation-specific schematics and in truth, all languages grow up at the same time with their reference implementation and it's the reference implementation that defines that language.

Basically, I don't care what the ideal implementation for a language X might look like in 10 years from now, what I care about is (1) what am I able to do with it right now and (2) what's the community's culture like?

Lately I've been learning some Clojure. I'm fascinated by how Clojure developers work with the source-code. Emacs is an extremely capable editor, but for Clojure it's a full-fledged IDE and a shell for the REPL and it can do anything you'd expect from an IDE. And the whole workflow is basically typing code, sending that piece of code for evaluation in the REPL, typing in the REPL some quick invocations to see how it works, rinse and repeat. The learning experience is also completely awesome, as for some reason you end up reading a lot of the standard library's implementation - coupled with the REPL on the other side in which to quickly type what you read - the workflow is amazing (though Smalltalk developers are probably laughing at me right now).


> So languages are plagued with implementation-specific schematics and in truth, all languages grow up at the same time with their reference implementation and it's the reference implementation that defines that language.

Reference implementations only define languages that lack a proper ANSI/ISO/ECMA standard.

> though Smalltalk developers are probably laughing at me right now

Yes we are. :)

Emacs is a light version of a Lisp Machine. Now imagine how would your OS be, if everything would be as customizable as Emacs.

Sadly, Lisp machines and Smalltalk environments died on the mainstream.


LinqPad isn't bad.


> Most of the time I need REPL-like functionalities, I need it in the heart of my application, with all its structures and state initialized and in the middle of a breakpoint. I hardly ever need to type snippets of code with zero context around them, which is what REPL's offer.

This is why we Lisp developers have networked REPLs -- I can start up a remote JVM, in communication with other services, connected to my local vim session. I can dynamically load code into it, start and stop my application, etc, all from my editor.

https://github.com/clojure/tools.nrepl


That's a very large blanket statement right there. I code in five main languages Objective-C, Java, Python, Ruby, and a bit of Javascript. I do back-end web system type of dev work (Python, Ruby, JavaScript, Java) and front end UI (iOS, Android, and JavaScript (Backbone, Angular, Ember). I use Intellij and sublime as my ide/code editor. The most productive, easiest to use, and for me most fun to develop in environments are Django, Rails, Node, and front-end JavaScript. That is almost completely because of the application aware REPL. Django's manage.py shell command, Rails rails console command, and Chrome's dev tools are three of the most important developer tools I've ever discovered. I'd LOVE to find an iOS tool with the same power.


> Neither Java, C#, C++ nor C have one (and together, these four languages probably make up for 95% of programming languages).

C# ==> http://www.mono-project.com/CsharpRepl

C++ ==> http://root.cern.ch/drupal/content/cint

C ==> http://www.softintegration.com/demos/chstandard/interactiveC...

Java ==> http://www.javarepl.com/console.html

People, please pay attention in compiler design classes and don't mix languages with implementations.


Also, the "Display" tab in Eclipse lets you execute random code while you are attached to a JVM via debugging, in the current breakpoint context - that is like 95% of a repl, imho. Many people don't know this one, and its very useful.


There is a c/c++ repl http://root.cern.ch/drupal/content/cling .

For java there is bean shell/groovysh which isn't quite as good.

There is a mono repl and there is linqpad for c#. Ive used linqpad and it is very usefull.

scala worksheets are also very cool.


I routinely initialize quite complex states in the repl during development. If anything, it's even more important in that situation since it can often take a long time to get to that state-point in the program.


Like another commenter posted, REPLs are best suited for exploration. When you've got data and you're not quite sure what to make of it, or you want to do with it yet. IDEs, while also having their place, do not really fill that gap in any way.

I often find myself exploring in a language with a good REPL and then implementing the findings in a language that does not.


> The importance of REPL is very exaggerated.

I constantly use REPLs to experiment, verify output of functions, etc. In the case of Go I open the Go Playground at least once a day, often much more.


> It's commonly believed that a REPL is valuable and increases productivity

A REPL is a nice learning tool, but actually not that useful for productive programming. Go has a playground for learning and experimenting.


I do almost all of my most productive programming in a REPL (Python/JavaScript programmer here) and I have done for nearly 10 years now.


Depends on the language and the programmer. I find a properly configured REPL amazingly productive at nearly any point in a development life cycle.


You may not find it useful, but that doesn't mean it is a universal truth. I always have ghci open.


Less is often more! I prefer the Go Playground over a REPL, especially since I can easily see others' code snippets running using the Playground's Share feature. My 2nd favorite thing about Go (after its runtime speed) is its compiler and excellent error messages that let me quickly realize what mistake I made.


Perl and PHP are also open source languages were people don't use repls often. Java and C# don't have repls either. I don't think everyone has ever thought they needed a REPL for any reasonable definition of everyone.


C# from Microsoft doesn't have a REPL, but C# with Mono does: http://www.mono-project.com/CsharpRepl


re.pl is invaluable to the modern Perl programmer (as is cpanm).


I don't think it's invaluable to the modern perl developer. I don't know whether I disagree with your concept of invaluable or your concept of modern perl developer or both. I tried searching "perl repl" on twitter and google to see if there's much talk about it and there doesn't seem to be much. AFAICT it just isn't a big part of the perl workflow, modern or not. Most of the people who like it could manage just fine without it. I don't think the same is the case with python or ruby. Some pythonistas and rubyists use the repl for everything.

I use small files instead of repls most of the time. There's no program that's too short to be stored in a file.


The best place to search (for Perl REPL's) is on CPAN - https://metacpan.org/search?q=repl

The current grandaddy is Devel::REPL - https://metacpan.org/release/Devel-REPL

The new kid on the block is Reply - https://metacpan.org/release/Reply

PS. I do find using a Perl REPL invaluable for me.


You don't really need a REPL when compiles take literally only a second or two. It's only the fact that C++ had a static type system where programs took (literally) hours to compile that made dynamic typing look so great in comparison. "Poorly designed static type systems drive people to dynamic typing," as Rob Pike said.


And yes, REPL is still helpful even if the compilation is fast; amusingly most languages that have REPL features fast compilation (at least those not based on JVM). The benefit of REPL is that it preserves state which one can experiment on, and sometimes that state can be cumbersome/take long to acquire.


Most languages that have "traditionally" shipped with a REPL don't feature compilation at all. So yeah-- I guess that's fast? (Before you start, I'm not interested in pedantic arguments about how any language can be compiled. I know.)

If it's "cumbersome" to acquire the state you need for testing, then that sounds like a design problem that you should fix. The best kind of tests are reproducible and part of a test suite anyway.


One of the languages that originally featured REPL, Lisp, was always compiled, both to machine code or byte code. Ditto smalltalk. I am not even sure which "traditional" languages you are talking about.

When I mentioned state, I did not mean testing. Sure, a properly designed system will have all it's computaional parts abstracted in a functional way so it will be trivially tested compiled or not. However, REPL is incredibly useful during the development process when the abstractions required are not yet clear, so it allows one to easily explore design possibilities without committing signficant effort of implementing a correct compilable module.


Dynamic typing has nothing to do with compilation speed. Furthermore, static typing is not orthogonal to dynamic; rather static type system is just another utility language on top of the actual language which helps to prove the correctness of the program. Such type systems can event be optional, see e.g. Clojure or Erlang.


Yea everything takes me longer to make, but you end up with a better, faster application.


I know Ruby and some Go and never really understood why people compare them so much. Very different languages.


On HN there's a lot of people who went from writing Ruby to writing Go. If all you have are a hammer and a screwdriver, everything looks like a blog post comparing the two tools you've tried.


I think it's because people use them for similar things. I have met many developers that have rewritten Ruby web services in Go (with good results).


+1




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

Search: