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

The perfect language and why Go still isn't it

snazz.xyz

Post reply on HN
Print view View original

121–130 of 139 posts

Re: The perfect language and why Go still isn't it

#121

Post by majewsky »

littlestymaar wrote: post #71
ccday wrote: post #2

Go isn’t the perfect language because it doesn’t intend to be. Likely, as this article seems to hint at, there’s no such thing and there never will be. Go has a well defined set of design goals (including simple and pragmatic) that it has achieved.

> Go has a well defined set of design goals (including simple and pragmatic) that it has achieved. If your look how much changes are proposed as part of the Go2 work, I'm not sure the Go developers agree with you.

Yet the concrete proposals keep getting shot down or reworked. If anything, this makes me more sure that the Go developers care about their core design goals. They are listening to community feedback, but they don't allow a vocal minority to bury the original vision.

Re: The perfect language and why Go still isn't it

#122

Post by mrbonner »

lkrubner wrote: post #100
mrbonner wrote: post #93

Earlier quoted context omitted.

Considering it took you that long to be a Lisp convert, I like to know more on how you came to the see the light. I’ve been doing coding for over 15 years, too. And, every time I tried to pick up a Lisp dialect (Clojure was the last) I couldn’t help but wonder what with all the buzz about this. I really wish that I could see the light someday, though.

Depends where you are coming from. What languages do you work in now? If the language you are working in now has excellent support for concurrency, then that part of Clojure is not going to impress you. Or if you currently work with a language that makes it easy to write DSLs, then that part of Clojure won't impress you.

Mostly in Java and now picking up Rust in my spare time.

Re: The perfect language and why Go still isn't it

#123

Post by ptx »

pjmlp wrote: post #78
pdpi wrote: post #37

Earlier quoted context omitted.

I think Kotlin has also leapfrogged D on this — Google blessing it for Android use and an Android community clearly hoping for something better than an aeons-old version of Java goes a very long way. The Android success story might just be what the language needs to establish itself enough that it’ll become a backend staple too

I think Kotlin's future is tied to Android's. Outside Android there are better options. On the JVM, just like any other platform, is safer to bet on the systems language of the platform than guest languages with extra debugging layers, tooling and their own wrappers for idiomatic code. Then Kotlin is trying to stretch too much, meaning that any portable Kotlin code cannot depend on any platform or needs multiple impl…

> Finally Kotlin/Native has special semantics for handling data structures, as it tries to be Swift like

If you mean Swift's issue with having to use weak references to prevent cycles, Kotlin/Native doesn't do that – they have a cycle collector, so it should behave the same as Kotlin/JVM.

It does have a different threading model though, where you can't share mutable structures between threads. Very recently they've introduced a "relaxed" mode that does allow it, but it's extremely experimental and sounds like it would be slow (since it can't defer updating reference counts).

(Also, what are you referring to with "extra debugging layers, tooling and their own wrappers" for Kotlin on the JVM? I can use IntelliJ + Maven + Spring with either Java or Kotlin. I don't see any extra layers.)

Re: The perfect language and why Go still isn't it

#124

Post by erik_seaberg »

zzzcpan wrote: post #51
threeseed wrote: post #46

Earlier quoted context omitted.

And is etcd significantly better than Zookeeper ? Not really. So not a great example for Go's supremacy. Also with GraalVM you can equally support low memory, fast startup use cases.

Sure, Go didn't turn out to be well suited for distributed systems either. But neither are JVM languages.

Sandboxed network classloaders were a big win for Hadoop and Spark.

Re: The perfect language and why Go still isn't it

#125

Post by erik_seaberg »

kolanos wrote: post #103
lkrubner wrote: post #98

Earlier quoted context omitted.

And what does it actually give that is new? What does Docker give that you can't get with a normal VM, with Terraform to spin up however many instances that you need? Put an app on an AMI, save it, if you need one instance, or a 1,000 instances, spin them up with Terraform. You get to stick with normal operating systems, such as Linux and Windows. You don't have to learn a bunch of new technologies. http://www.smashc…

Terraform is written in Go as well.

Terraform needs an extensible DSL, so Python or Groovy or Kotlin would have been much better.

Re: The perfect language and why Go still isn't it

#126

Post by ypcx »

mrbonner wrote: post #93
ypcx wrote: post #39

Well, Go seems to have enabled a new wave of software renaissance - Kubernetes, Docker, you name it - Go seems to have filled the space that Java was too fat for, JavaScript too light for, and C/C++ too difficult/fun-less to use for (which is everything). After 20 years of coding, and having just recently discovered LISP and learned Clojure, I believe the perfect language will be a Clojure compiled to native with the…

Considering it took you that long to be a Lisp convert, I like to know more on how you came to the see the light. I’ve been doing coding for over 15 years, too. And, every time I tried to pick up a Lisp dialect (Clojure was the last) I couldn’t help but wonder what with all the buzz about this. I really wish that I could see the light someday, though.

I wish I had a good answer to this. I suppose I've never looked at anything else than what I was working with (C, C++, Java, JavaScript and much later CoffeeScript) out of "religious" reasons. I guess being really good at what you do can do that to you. I hold CoffeeScript in a very high regard. It has freed me from two things - the spaghetti verbosity of JavaScript, and the abrupt syntax changes of ECMA spec introduced in the recent versions, ones I don't particularly see as a positive development of the language, _especially_ compared to the timeless cleanliness of CoffeeScript. So and I think that CoffeeScript may have thawed me a little towards LISP-like syntax and behavior. I don't know. I think at some point, you realize that you have written (and managed) enough of C/Java-like verbose code and that it's time to try something completely different. So and then it hits you - programming should be data-centric, not language-construct-centric. And that a too big codebase must be a result of ill-specified project scope, more often than not.

Re: The perfect language and why Go still isn't it

#127

Post by apta »

saganus wrote: post #97
delusional wrote: post #85

Earlier quoted context omitted.

> Java was too fat for I think it should always be mentioned when people call java fat, that the core language is usually fast enough. What makes java "fat" is the mentality of "Frameworks". For me, Go seems like java, but without the fucking frameworks.

I have been wondering for some time now, when exactly is a language "fat" or "light"? The idea seems to be there and "obvious" in a way, but haven't been able to pinpoint exactly what it is. Is it a feeling or an actual metric? e.g. When I work with Java in IntelliJ, things don't feel significantly slower than developing Node in WebStorm. Is it perhaps the way the code looks, in terms of verbosity? I do agree that fr…

It's just that some people repeat what others say without fully comprehending them (this is especially evident in the golang community). People parrot what the golang authors claim, even though many of such claims are baseless and incorrect.

Re: The perfect language and why Go still isn't it

#128

Post by apta »

lazyjones wrote: post #55
networkimprov wrote: post #31

Earlier quoted context omitted.

Zig might become the perfect language, assuming OOP is not must-have :-) https://ziglang.org/

But it has pointless semicolons. No, thanks. ;-)

golang puts semicolons behind the scenes anyway, resulting in bizarre behaviors like not being able to write braces that follow "if" or "for" on separate lines.

Re: The perfect language and why Go still isn't it

#129

Post by pjmlp »

ptx wrote: post #123
pjmlp wrote: post #78

Earlier quoted context omitted.

I think Kotlin's future is tied to Android's. Outside Android there are better options. On the JVM, just like any other platform, is safer to bet on the systems language of the platform than guest languages with extra debugging layers, tooling and their own wrappers for idiomatic code. Then Kotlin is trying to stretch too much, meaning that any portable Kotlin code cannot depend on any platform or needs multiple impl…

> Finally Kotlin/Native has special semantics for handling data structures, as it tries to be Swift like If you mean Swift's issue with having to use weak references to prevent cycles, Kotlin/Native doesn't do that – they have a cycle collector, so it should behave the same as Kotlin/JVM. It does have a different threading model though, where you can't share mutable structures between threads. Very recently they've i…

Yep, I mean the semantic model for data structures.

Try to call idiomatic Kotlin code from Java and see how it looks like. Specially when co-routines and similar higher level constructs get added, or having to deal with compatibility between Java streams and Kotlin sequences, which don't build on top of Java ones.

When Loom arrives, it will be a similar story, Java proper fibers and Kotlin co-routines and how they might interoperate.

Nothing unique to Kotlin per se, all guest languages happen to have similar bumps. Calling Scala or Clojure from Java leads to similar lists.

Then one is required to buy into JetBrains tooling for Kotlin, and get an additional license for Clion as means to have a graphical debugger for Kotlin/Native.

There is an Eclipse plug-in, which is kind of 2nd tier, and none at all for Netbeans.

With Java it is just ready set go, no matter which IDE, with just one IDE for Java and native, alongside mixed mode debugging (a feature JetBrains doesn't see a value supporting) and not all Java shops are into InteliJ idolatry.

Re: The perfect language and why Go still isn't it

#130

Post by marcus_holmes »

casion wrote: post #82
marcus_holmes wrote: post #40

Earlier quoted context omitted.

I don't really understand how a REPL would help with coding Go. I think I use tests to do what I think people use REPLs for, and I don't get why I'd change that to a REPL if I could - having those tests permanent is a good thing. What would a REPL bring to the party?

A REPL allows you to work in real-time with the system as it's written. It's nothing like unit testing. It's like running around in the system able to poke-prod things as you go. Particularly important is that it doesn't mean working in a console. Most REPL-based dev is done in the source code file itself, and you send code from the document to the REPL process. Code is written in a file as usual, and you utilize the…

yeah that would be interesting to try out, thanks for the link :)

I meant that I use tests as a way of poke-prodding things - because Go compiles so fast, and you can run individual tests, it's easy to tool around in test code setting up specific state in code and seeing what happens.

Post reply on HN