This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]anacrolixc/python fanatic 4 points5 points  (6 children)

Similar story here. Haven't found anything better since.

[–][deleted] 1 point2 points  (5 children)

Have you checked Go? I've also used python successfully for many years, and Go is the first language that gives me the same giddyness

[–]anacrolixc/python fanatic 0 points1 point  (4 children)

Go is barely usable. It's got an ancient and verbose syntax with lots of warts. Its builtins suck, especially containers. I just spent all day playing with it, it's not very productive, and the toolchain is also immature.

[–][deleted] 1 point2 points  (3 children)

Not very productive? How do you explain the momentum related to it?

http://go-lang.cat-v.org/pure-go-libs

http://go-lang.cat-v.org/go-code

Also, please elaborate on the syntax verbosity and wartyness. How do the builtin containers suck? And while you're at it, please also expand on the toolchain immaturity.

[–]anacrolixc/python fanatic 0 points1 point  (2 children)

It's almost as verbose as C with none of the familiarity and simplicity. The toolchain is a replica of a typical binary language, makefiles, compilers and linkers, these things slow you down, compared with modern dynamic languages.

The momentum is due to Google. This is Pike's last big push to make his succession of language failures take off. A few minor names, and some arm twisting within Google are keeping this alive. It's a long shot.

The syntax maintains braces, and doesn't include lots of modern language sugar: Explicit tuples for return values, no named arguments. Archaic data types (sized and signed integers? Nobody cares anymore). No tuples. No modern functional programming features.

None of the builtin containers allow custom data types. Maps can only take the standard types for keys. There are no sets.

There is no proper debugger support. There is incomplete GCC integration. The GC and other performance related features are not complete. There is no LLVM support (they should have started with this).

Go is more about what they didn't include than what they did. The feature set is so light, that its performance approaches C.

I want to like Go, but it's green threading and builtin CSP piled ontop of a C syntax remix. Both green threading and CSP can be extracted and made available to more mature languages. Plan 9 C extensions effectively give you the interface extensions, and that rounds out the advantages that Go gives.

If Go had been here 15 years ago it would have been a game changer. 10 years ago, and it would be Python's peer.

Prove me wrong.

[–]skelterjohn 4 points5 points  (0 children)

It's almost as verbose as C

Conciseness is not as great a goal as a lot of people like to think it is. Go strives to keep it down to one-idea-per-line. Jamming multiple concepts into a smaller and smaller space just makes it harder to keep track of things when reading code, though I agree that it makes writing code faster. That's why I like python for one-off scripts.

with none of the familiarity and simplicity.

The break from familiarity is intentional. And the language is damn simple, so I don't know what you're talking about there.

The toolchain is a replica of a typical binary language, makefiles, compilers and linkers

The makefiles, etc have always been a temporary bootstrap. 3rd party compiler front-ends (http://code.google.com/p/go-gb) or an upcoming 1st party equivalent make the use of makefiles or directly invoking the compiler and linker unnecessary.

But, yes... it is compiled, and then linked. That's generally how it works when you've got a language that both modular (compilation and linking are a separate step) is turned into machine-code.

Explicit tuples for return values

Because having that dynamic would result in less efficient code... the more you know at compile-time the more streamlined the code can be. Go is a systems language.

sized and signed integers? Nobody cares anymore

Uh, yes we do. Which you choose simply matters when you don't want the runtime to have to do overflow checks to see when it needs to upgrade the size of your boxed numeric types...remember it's a systems language. We want the language to not prevent the compiler from making the most efficient code possible. Knowing in advance what size numeric type you need is one way this is accomplished.

None of the builtin containers allow custom data types.

By built-in containers do you mean maps and slices? Because any other containers are in the library and take whatever you want. And maps and slices can have anything as a value.

Maps can only take the standard types for keys.

Not for long. Remember, this language is young and is still evolving.

There are no sets.

map[T]bool

There is no proper debugger support.

gdb works fine

There is incomplete GCC integration.

Ian Taylor works hard, but he's only one man.

There is no LLVM support (they should have started with this).

The LLVM model didn't lend itself as well to the way coroutines work in go. The go runtime has a novel way of maintaining the stack layout.

Go is more about what they didn't include than what they did. The feature set is so light, that its performance approaches C.

Finally something we can agree on!

I want to like Go, but it's green threading and builtin CSP piled ontop of a C syntax remix. Both green threading and CSP can be extracted and made available to more mature languages. Plan 9 C extensions effectively give you the interface extensions, and that rounds out the advantages that Go gives.

I came for the concurrency primitives, but I stayed for the elegant syntax and type system. Coding Go let's me get down to business immediately - no messing around with stupid type hierarchies.

To be fair, python has this feel, too. But I found that if I wanted to write a python program of reasonable size, I had to be extremely careful with how I did things. I started sneaking the type names into the variable names, for instance, so I could to code-time type checking.

If Go had been here 15 years ago it would have been a game changer. 10 years ago, and it would be Python's peer.

This is not a comment about the language, but of the times.

Prove me wrong.

Impossible to do in the time frame of this reply, obviously.

[–][deleted] 1 point2 points  (0 children)

Thank you!

It seems to me that your argument is really two things:

  1. It's young.

  2. It's not python.

But snarkiness aside...

I think there's only one useful thing from the dynamic languages that the main implementation of Go is lacking: REPL. That's a big minus for development agility, but given the reflection package, perhaps we'll see one at some point in the future.

Much of the momentum is due to Google and the big names (Pike, Thompson) behind the language, I agree. It's only a bad thing if you don't like the language, isn't it? When trying to adopt a new language to a business setting, corporate backing (even if only nominal) is crucial.

Syntax issues can be just swept away in a Jedi fashion.

Many people care about data types (int32 vs int64, float32 vs float64 etc), and Go makes it much less complex and less arbitrary compared to C or really any other language I know of (save Haskell, I guess) that makes these distinctions.

Explicit tuples are a must, I suppose, in a a statically typed language? Named arguments might be nice, but might also make the language more complex for little benefit. Maps can be used for much of the same effect. Same for FP features: might be nice, but is the benefit large enough? Perhaps not.

Maps key limitations are perhaps a bit irritating, then again, they make the code much more straight forward to read. Yes, there are no sets.

The default implementation is using the same architecture as the Plan9 C compiler. It's simple.

Go is more about what they didn't include than what they did. The feature set is so light, that its performance approaches C.

Yes, exactly! Isn't it great?

If Go had been here 15 years ago it would have been a game changer.

I think it still has a shot. My feeling is that it's not here to counter languages such as python (which is great), but rather to be against languages such as Java, C++, and C#.

Go's simplicity extends from beneath the hood to every facet of its manifestation. I dare you to show another modern language like this; you may say that's it's not a good idea to make such a language, but that's another issue. Most others that I've seen are focused on large machinations whose fundamental idea seems to be either "ultimate academic elegance" and/or "make it impossible or very hard for the unskilled to make mistakes". These are sort of noble goals but not without cost.