221–230 of 235 posts
Earlier quoted context omitted.
Go is more a better Python. Even simpler syntax. Types and compiles to native (as they are all the fashion now). Rust is the best bet we have at a better C (and a better low-level C++). High level C++ competes with D and Go. Rust is a little too specifically targetted at the low level "systems" programming.
Go has far more in common with Java than it does with python. Arcane APIs that are incredibly difficult to use correctly while having a very simple base language.
It is, to a degree a matter of taste, of course, but Go APIs tend to be rather simple, whereas Java libraries seem to often have FileOpenDialogStyleTemplateProcessorFactoryFactory-type interfaces.
The major problem I have with Go currently is lack of function overloading, which means you either have to convert your data around a lot or have many similar functions for different data types that do the same thing (basically), but have different names.
I think the comparison with Python is quite fitting, because both languages encourage a certain way to think about and implementing things. For Python it's called pythonic, in Go it's called idiomatic.
Earlier quoted context omitted.
> I'm not really sure that they target C++ or aim to replace it, unlike D. The evolution of both Go's and Rust's strategies as "replacement" languages is actually pretty interesting. While Go's official marketing no longer calls it a systems language, the use of that phrase when Go was originally released does indicate that that they envisioned Go to be a "better C" in a sense (perhaps specifically in the sense of be…
> old versions of Rust absolutely intended to replace C++ is that true? Old versions of Rust looked like Go, IMO.
Earlier quoted context omitted.
D is like Go if Go had actually been a "systems" programming language. Rust is difficult to compare to other stuff.
Go is still a systems programming language, in the original sense of how Rob Pike explained it in the introductory presentation video about Go from 2009.
Silly me, I was under the impression that gdc was already part of gcc... Well, so at least now I am no longer mistaken. ;-) I have tried to learn D repeatedly over the last couple of years, but I was usually scared off by how complex this language is. Even so, the syntax is far cleaner than C++[1]. Also, the last time I gave it a try, something finally clicked. I am not all there yet, but I am beginning to like it. T…
I was pleased to see that C++ finally gave up on trigraphs.
Never having written a compiler, I can only imagine how tedious supporting those must have been; and I would be willing to bet that trigraphs weren't even used much, because, among other reasons, hardly anyone knew of them, so it must have been really frustrating for people to support them. An Exercise in futility.
Earlier quoted context omitted.
I don't think a "better Python" can be statically typed - dynamic typing, and all the associated runtime tricks that you can do with it, is kinda part of what makes Python distinctive (whether for good or bad, opinions differ there).
Go has this "interface" thing which lets you do duck-typing, and it's checked at run-time, as the types in Python.
Earlier quoted context omitted.
> I'm not really sure that they target C++ or aim to replace it, unlike D. The evolution of both Go's and Rust's strategies as "replacement" languages is actually pretty interesting. While Go's official marketing no longer calls it a systems language, the use of that phrase when Go was originally released does indicate that that they envisioned Go to be a "better C" in a sense (perhaps specifically in the sense of be…
> While Go's official marketing no longer calls it a systems language, the use of that phrase when Go was originally released does indicate that that they envisioned Go to be a "better C" in a sense Rob Pike uses the phrase within the first 5 minutes or so of the very first presentation video announcing Go, and explicitly mentions that they mean "systems" in the sense of webservers and the like. Since then, Go being…
(I'm aware of Caddy, but my understanding is that it's aiming for ease of use over performance.)
Earlier quoted context omitted.
I think I'd rather not have GC in my OS. Oberon was a pretty small language, so perhaps the pauses were more acceptable.
It even supported live video editing. Pauses weren't an issue for users' productivity.
This is basically the work of one tireless man; Iain Buclaw. Many thanks to him for putting in so much time and energy into this. It took 6 years from first submission to get it in. Here are the slides from his 2017 DConf talk about the work that went into making this happen: http://dconf.org/2017/talks/buclaw.pdf
Just goes to show how one person, with relentless persistence, can still make a huge difference these days. Congratulations, Iain!