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

81–90 of 139 posts

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

#81

Post by pjmlp »

mhd wrote: post #52
analognoise wrote: post #5

This already exists, but it isn't trendy. It's FreePascal. Nobody believes me, but we have perfection already. No crap you don't need. No crazy corner cases. No C++ templated metaprogramming lambda auto pointer garbage. No "I can't write a linked list without a Grimoire" Rust. It's great. You get a ton done, and simply ignore the language wars. No VM trash (Java). No web trash (JavaScript/"Webasm"). No crap. Try all…

I'm a big fan of the Wirthian language family, and while I think FP is eminently usable, I still think Modula-3 would be a better fit for Gophers. A M3 frontend for FPC would be a great combination...

A few devs kept developing CM3 and they are also experimenting with a LLVM backend.

https://github.com/modula3/cm3

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

#82

Post by casion »

marcus_holmes wrote: post #40
Dylan16807 wrote: post #38

Earlier quoted context omitted.

From the article? Not at all. It doesn't matter if it's easy or difficult, because it only needs to be coded once. And it's not a request to change the language at all, just the tooling.

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 REPL to massage the system as you want.

Though it's Clojure-based, you might want to watch this talk: https://vimeo.com/223309989

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

#83

Post by 0x445442 »

geofft wrote: post #73
Retric wrote: post #70

Earlier quoted context omitted.

Usually, people start building demo’s or other side projects at their main job using whatever new tech they want to pad to their resume. This is bad for the company and your coworkers, but for people jumping ship every 2-3 years leaving a mess has few downsides. A more ethical approach is to simply learn at work during downtime over browsing the web. It even looks like work, so few people complain.

Building demos to pad your resume is bad for the company, but building demos to achieve unmet business needs is good for the company, and usually there are plenty of those lying around.

What I've noticed is in a lot of big enterprise shops that are playing "Agile" there is a big gap in support/tooling software; that is, software that makes developers more productive by automating repetitive tasks. Since this type of software doesn't exist to management because it won't fit nicely onto a Jira board or it can't be bent to fit a specific OKR, it's the perfect type of software to explore other languages.

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

#84

Post by zinclozenge »

slx26 wrote: post #64

Go and Rust are the latest languages I started to use. Neither is perfect, both are awesome, but more importantly, both are a step forward, both get a lot of things very right, and for the rest, most are at least acceptable. When I code, most of my frustrating moments come from underlying problems with cross compatibility, access to hardware, graphics, encodings, etc, which are rarely problems caused by languages the…

Go has some great 'under the hood' features, ie ones provided by its runtime, but man the language syntax makes it really annoying to take advantage of them. The sweet spot for me would be something between Go and Rust, ie a language with generics, algebraic data types, pattern matching, garbage collection, good concurrency primitives with a good work stealing scheduler.

So I'm basically asking for OCaml with multithreading.

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

#85

Post by delusional »

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…

> 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.

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

#86

Post by cpuguy83 »

lossolo wrote: post #68
zzzcpan wrote: post #49

Earlier quoted context omitted.

> Well, Go seems to have enabled a new wave of software renaissance - Kubernetes, Docker Go turned out to be a pretty bad choice for container tech due to its awful multithreaded runtime. Things could have been different if it focused on a single threaded runtime or provided control over OS threads, but it did neither. Also neither of those projects were enabled by Go. One is a pretty low quality but strategic push i…

> Go turned out to be a pretty bad choice for container tech due to its awful multithreaded runtime. What you mean by that? What makes it a bad choice in context of containers ? I ask because I know how Go is using M:N threading model in its runtime and what linux containers really are, but I can't find a reason in which I would use word awful to describe using Go in this context.

Because container tech is often per-thread which you have no control over in Go.

There is runtime.LockOSThread(), but then if something happens to spin up a new groutine from there it will be done on a new os thread and not running in the container context.

It's not totally impossible to work around, however it does make many things incredibly frustrating.

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

#87

Post by cpuguy83 »

_0w8t wrote: post #58
zzzcpan wrote: post #49

Earlier quoted context omitted.

> Well, Go seems to have enabled a new wave of software renaissance - Kubernetes, Docker Go turned out to be a pretty bad choice for container tech due to its awful multithreaded runtime. Things could have been different if it focused on a single threaded runtime or provided control over OS threads, but it did neither. Also neither of those projects were enabled by Go. One is a pretty low quality but strategic push i…

Modern Go solved the problem of control over native threads threads. But it is puzzling indeed that it took almost 10 years despite popularity with containers.

Only partially... what's available at least prevents leaking the context unexpectedly to other goroutines (due to thread re-use), however anything that spins up a new goroutine from the locked goroutine will end up in a new thread in a totally different context.

Even stdlib spins up new goroutines.

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

#88

Post by patientplatypus »

The frustrating thing about Go for me is that it lacks generics but is strictly typed, which encourages the passing of empty interfaces which can cause problems at runtime. You have to be very careful about storing all your data properly in structs or you face a big foot gun.

Which, like, fair enough. It's not perfect. But it's still really really good. I mean, people still use Java...

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

#89

Post by cpuguy83 »

otterley wrote: post #67
zzzcpan wrote: post #49

Earlier quoted context omitted.

> Well, Go seems to have enabled a new wave of software renaissance - Kubernetes, Docker Go turned out to be a pretty bad choice for container tech due to its awful multithreaded runtime. Things could have been different if it focused on a single threaded runtime or provided control over OS threads, but it did neither. Also neither of those projects were enabled by Go. One is a pretty low quality but strategic push i…

> Go turned out to be a pretty bad choice for container tech due to its awful multithreaded runtime. Can you please elaborate on this? My experience with Go is that it is able to fork/exec programs and manage cgroups via sysfs on Linux at least as well as any other programming language can.

You pretty much need to do everything from a separate process, which is the main issue.

Certain things like setns(mountns) will straight up fail in a multithreaded program, so there are some nasty hacks in runc to handle such things in C prior to the go runtime firing up.

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

#90

Post by cpuguy83 »

twic wrote: post #75
coldtea wrote: post #59

Earlier quoted context omitted.

> Well, Go seems to have enabled a new wave of software renaissance - Kubernetes, Docker, you name it Let's name it. I wouldn't call either of these a "software renaissance". Docker is a wrapper on top of Linux kernel containers, and Kubernetes is a 10000 pound gorilla on top (and port of a C++ app, some say even through a Java rewrite/transpile to Go). Go was just at the peak of being fashionable at the time (and ha…

Docker is a bad design. It is monstrously overcomplicated for what it does. In historico-aesthetic analogies, it's baroque, not renaissance.

This sounds like dogma. While I do agree there are some pieces which are over complicated or just plain bad code, on the whole it's more that the API's aren't quite right specifically for people who want to integrate with it rather than use it. containerd exists pretty much because of this observation.
Post reply on HN