Live data from Hacker News

The perfect language and why Go still isn't it

snazz.xyz

131–139 of 139 posts

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

#131
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…

I've been learning a bit of Go and I like what I've understood so far but one thing that seems somewhat lacking in the Go Eco system is mathy projects. I know there are some but I couldn't find many that were both active and to my taste. I was looking to learn and hopefully contribute. I was mostly looking for something mature for either mathematical optimization (stuff like linear, quadratic or integer programming)…

> I've been learning a bit of Go and I like what I've understood so far but one thing that seems somewhat lacking in the Go Eco system is mathy projects.

I think this has to do with golangs poor FFI performance.

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

#132
post #51

Earlier quoted context omitted.

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.

Is the JVM's sandboxing still supported, patched and believed to be secure? I had assumed they gave up on it when they removed applet and webstart support.

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

#133
post #128

Earlier quoted context omitted.

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.

It's not "bizarre", just a tradeoff explained here: https://golang.org/doc/faq#semicolons

If they thought it mattered much, they'd change it... But since the code should be formatted correctly always, it's not necessary.

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

#134
post #42
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…

> C++ too difficult/fun-less C++ would be a lot more fun without the obligation to maintain header files all the time. This is one thing that modern languages get right.

aren't header files quite useful for yourself and especially other devs as a quick summary? I've found myself wishing my IDE would automatically make a header file equivalent for my python code (VS Code actually does this, but gives a lot of other info that's extraneous in my opinion)

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

#135
post #132

Earlier quoted context omitted.

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

Is the JVM's sandboxing still supported, patched and believed to be secure? I had assumed they gave up on it when they removed applet and webstart support.

Thought it over and you're right, Spark has some SecurityManager glue I've vaguely glanced at, but HDFS relies more on Kerberos than anything in-proc with the workers. IPC into an opaque worker binary would be a lot more painful but can be made to work.

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

#136
post #27
post #18

Earlier quoted context omitted.

Ah, a young lad :) I started tinkering with Turbo Pascal 3 and even have some experience with Pascal on the Apple II. (Not because I am THAT old, but that were the only computers my school had at the end of the 80ies) The successors of Pascal are also highly interesting. I used Modula-2 quite a lot, but never got deep into Oberon. I do think one big advantage of Go is, that it so strongly draws on the Wirth languages…

Yeah, quite young indeed. :) I was initially also drawn into Go, mainly due to its Oberon-2 influence as well. Even did a couple of contribution attempts during pre-v1 days , but they weren't that good anyway. However back in the Oberon days, what I liked was the evolution that followed suit, Oberon-2, Component Pascal, Active Oberon and finally Zonnon. As such, I never appreciated the minimalism discussions around G…

Honestly, I am quite happy with the role of Go as a better C. A lot of applications still get written in C because C++ isn't making things better. And Go has a lot of higher level constructs than C, so it reaches into much further domains than C. Structs with methods and struct inheritance as well as interfaces give a surprising amount of power. Also, having first class functions and closures gives a ton of power C (and even C++) lack. Add to that the great GC, and there are surprisingly few tasks I consider Go unfit for.

I am certainly watching the work on Go 2.0, it is certainly worth to continue working on enhancing the language, but I am very happy how carefully it is done as adding too much complexity to the language would be detrimental. There are only a very few things I miss generics for and usually they can be worked around.

I might have to add the disclaimer, that my paying job is mainly about programming in Lisp, so for me there is a high-level alternative to Go, but this also shows me how Go is a great solution for a lot of problems.

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

#137

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.

Not just frameworks, but the JVM as well. Having go compile to a reasonably small statically linked binary (which can be shrunk even more by things like UPX if size really matters) is great. Needing to bring a very large, very complex virtual machine to execute your program adds a lot of “fatness” IMO.

Something that any Java developer was able to do since 2000 with commercial JDKs.

And for those that want the free beer version instead, using a fat jar with linked jvm.lib is hardly different than packing Go's runtime in an executable file.

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

#138
post #107
post #97

Earlier quoted context omitted.

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…

The one area where Java feels fat is the memory usage overhead due to 64-bit pointers being used a lot. So if you end up holding and processing a lot of data in RAM, the process allocation and the garbage collector metrics won't look awesome. That said, recently Openj9 improves on this literally by miles. I agree with all the other points - Java and its tooling are very powerful and by that nature they are enabling u…

Yes we did, HP-UX vault and Tru64 sandboxes.

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

#139

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…

> What does Docker give that you can't get with a normal VM There is a difference between Linux container (Docker underhood) and full blown Virtual Machine. In case of docker you are not running new operating system, you are just running new processes in different namespace but still using the same kernel. Linux containers are lightweight, you can start them as easy and fast as other processes, without overhead. VM (…

Yes, I know, but what does that give me? When I'm setting up the infrastructure for my company, what can I do with Docker that I can't do more easily with a standard VM and Terraform? In terms of security, isolation, orchestration of services, managing concurrency, I get everything I need with ordinary VMs and Terraform. I don't see what Docker gives me.
Post reply on HN