Safe bet statically typed languages?

[carcajou]

Hi guys.

So this summer I wanted to start learning new programming language. "Old school" way, buying a good book and going step by step.

My experience is primary related to dynamic languages (Ruby and Lisp). I code just for fun, as a hobby (I'm not developer and my day job is business administration - so no programming at all). I wanted to change a focus from dynamic to statically typed languages, but it is a wide range of choices. The last time I programmed in statically typed language, it was almost 20 years ago in a high school using Pascal. I apologize for asking such general question here, but I do not participate at other tech related and relevant communities.

There is no specific domain. Just something general purpose and to go with the flow. Also, I do not care about trends and hypes, because I will most probably not use it professionally.

I initially considered to keep it simple and go with the plain C, however, I am not sure I would actually ever go low-level and use it's manual memory management features (or downsides).

I see there's a huge "hype" around Rust, but it is difficult for me to make a distinction between PR and actual technical advantages. Additionally, language seem intimidatingly enormous (in terms of size - C++ way).

Also, the language should be supported in Gentoo.

I would appreciate a feedback, recommendation and maybe a tip on the book. Thank you.

[pa4wdh]

In my opinion you can't go wrong with C. C in itself is still widely used and many languages take inspiration from C. Don't worry about the downsides, you will encounter them , and there's also value in learning that.

I personally avoid rust wherever I can
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world

My shared code repository: https://code.pa4wdh.nl.eu.org
Music, Free as in Freedom: https://www.jamendo.com

[Leonardo.b]

C. I think it is like a LEGO game: you combine routines from various libraries to build new programs. I like it.

I started by reading K&R, a classic.
This guide also:
https://beej.us/guide/bgc/

There are a lot of real-world programs, easy to read and tweak even for a beginner.

[spica]

Starting a complex programming language is difficult and time-consuming, and the initial mood can end before there is any result.
Back in 2012 I wanted to learn Ruby and started a pet project on Rails. The performance of the application was not enough according to pagespeed, and I rewrote it in Golang.
Golang is simple, easy, and you will not spend too much time learning it. In my opinion it is like C with batteries, the work with strings is easy, in most cases no need to specify pointers* explicitly, simple parallelization, good for writing microservices, can be built statically.
There's a tutorial with sandbox on their site.

When I was learning C, I wrote own emulator of Z80, but that was really time consuming.

[miket]

I second Spica's recomendation of Go. Like C, it is a simple language that compiles quickly into executables that run quickly. Go's syntax improves on C's syntax. It treats strings as a primitive type and handles allocation and garbage collection for you.

Go is safer. C offers you many ways to shoot yourself in the foot (buffer overflows, out-of-bounds array access, and misuse of pointers and casts, to name a few); like Pascal, Go catches most of those errors at compile time and the rest at run time. Go does this with a syntax that is much less fussy than that of Pascal.

Indeed, Go programs have a syntax that tends to be as uncluttered as the syntax of interpreted languages but with full type checking and with much better runtime performance.

Go has some fancier features that you are better off ignoring as you learn the language. Stay away from goroutines and channels until you have a solid foundation--and only then if you have measurable reason to use them.

Take a look at A Tour of Go as a good starting point.

[mv]

I would recommend one of (probably in this order)

1. Java
2. C++
3. Go

In no case, I would recommend pure C.

Let me give reasons why: Java is a really old-school typed language. In particular, it has a rich set of libraries (especially if you use guava), compiles extremely fast and runs almost as fast as C, C++, and Go. It is perhaps the best way to learn “clean” programming. It does all the nasty memory management for you. The disadvantage is that especially on Unix you cannot expect everybody to have a java code interpreter and its libraries installed, so distributing java on Unix is a bit nasty.

When you want to program a bit closer to the machine and also learn about pointers and the problems involved with it, C++ is the way to go: It contains all of pure C as a subset (so you can use all the advantages of pure C) (for the experts: yes, there are few subtle differences in some corner cases, but in practice these play no role), but for simple things like strings (but also more complex data structures like maps which you will need sooner or later) you can keep things simple: The STL (the C++ standard library) has “practically” automatic memory management and “feels” a bit like java, although underneath lies ”manual” memory management (but it is hidden by the well-thought libraries).

Go is the new hype: It has the convenience of java (no pointers, full memory management), but is still a bit faster than java, because it compiles into a true binary which does not need to be interpreted (although with JIT compilation of java the advantage is not much). Also some of the clumsy notation of java (and even more of C++) is avoided in go. The main disadvantage is that it is so new and so the set of available libraries is not very rich yet. Another disadvantage is that you will not really learn about classical concepts like pointers (as in C), and so if for some reason eventually you want really full speed (and not a garbage collection kick in in the wrong moment), you cannot get it with go. Another problem with go (the same with rust) is that it is available only on a few architectures. For instance, current gcc-12.1.1_p20220625 cannot compile a go compiler on x86, but nobody seems to care much about it (and it is not the first time that this happened).

[Goverp]

FWIW, I'd avoid antiques like C and C++. There are plenty of more modern static-typed languages. I'd plump for Rust (even though I've yet to write anything in it myself). It would probably be harder to learn, but the skills acquired would be more valuable, and the programs produced on the way far more secure... C lets you make far too many mistakes (the static typing just makes one small subset of errors harder, but you can find how to defeat it all over stackoverflow.com). What C++ tried to do 40+ years ago, Rust does far better today.

I guess if you want an old-style static-typed language that's easy to learn, you could try BASIC.
_________________
Greybeard

[C5ace]

Go with "C".

I started in 1985 with assembler on the first Japanese IBM clone i received as a gift using the "Debug" that was on the IBM DOS floppy. Then tried Turbo Pascal and ran against a wall. Finally changed to Turbo C and was able to earn some money with coding.

I recommend the book "C for Dummies" to learn the practical basics of "C". Also study the documentation of www.gnu.org/software/libc/ and the sources of "sys-libs/glibc".

CodeBlocks "dev-miscs/codeblocks" is a very easy to use IDE. Emerge with "contrib" flag enabled.
_________________
Observation after 30 years working with computers:
All software has known and unknown bugs and vulnerabilities. Especially software written in complex, unstable and object oriented languages such as perl, python, C++, C#, Rust and the likes.

[xineg]

++ for C
It's outstanding the support C is getting here. I confess my love for C.
Many of the other languages we use are also written in C (like python). Linux is written in C.
Rust is written in C and C++. And of course Real men use C!

[pa4wdh]

I generally avoid go and any project written in it.
It's a google language and i don't trust google anywhere near my devices
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world

My shared code repository: https://code.pa4wdh.nl.eu.org
Music, Free as in Freedom: https://www.jamendo.com

[miket]

I have some of quibbles re. the dismissal of Go.

[mv]

[mv]

[Etal]

[GDH-gentoo]

Well, I'm biased towards C++, so I'll state my reasons to try to compensate for it

• As already stated, it has a large subset that is compatible with C.
  
• It is possible to both write high-level, object-oriented style programs that look like Java, and low-level, procedural-style programs that look like C (see this). Plus this, which I don't know if it is available in any other language, but that's probably advanced use.
  
• Shares with C the same execution environment model (only augmented to specify object construction and destruction details).
  
• Has both reference types, which sort of can be used like in Java, and true pointer types like C.
  
• Supports automatic storage duration like C, not just static and dynamic / allocated storage duration, which enables programming techniques that avoid both manual memory management and use of garbage collection (see the "local objects" part).
  
• "What you don't use, you don't pay for".
  
• On the implementation side, also as already stated, good compiler and architecture support, unlike Go and Rust. Yes, IMO getting Rust support in GCC would be a significant improvement, but that day has not arrived yet ("arrive" = be available in e.g. Gentoo's amd64 stable branch).
  
• Available compilers produce machine code. So no interpreters, no middle layer between code and actual hardware like the Java virtual machine, no nothing.
  
• The only "extra luggage" on both [GNU/]Linux and the BSDs produced by available compilers when compiling a simple C++ program, compared to a simple C program, is getting linked to a C++ standard library implementation (like GCC's libstdc++ or LLVM's libc++). Reasonable price for all the added functionality if you ask me.
  
• Last but not least, I like how the creator of C++ thinks and reasons

[Hu]

mrustc is an external project run by someone who wanted a less crazy way to bootstrap Rust. Since it is external, it doesn't keep up with the breakneck pace of Rust feature dependence, which is why it is already 8 releases behind. I think it is useful that mrustc offers a way to bootstrap without going all the way to the beginning, but since it is external and does keep falling behind, I can't let its existence excuse the way the core Rust community handles the bootstrap process. (Although if I had to pick a single reason to avoid Rust, it's how painful it is to parse. Even reading well commented Rust code where I know from the comments what it should do, I can't see how the line noise on my screen results in the compiler producing the claimed program.)

Yes, compilers written in the language they compile are common, but the degree of backward compatibility varies widely. Haskell and Java on Linux have always been a pain in part because of their messy bootstrap process. Compare this to gcc, which historically could be built with any C89 compiler you had on hand, and would then handle bootstrapping itself the rest of the way. Even now, a fairly current gcc (gcc-10) only requires an mpfr from 2011 or newer. According to Prerequisites for GCC:

• <gcc-4.8 could be bootstrapped with a C89 compiler. =gcc-4.8.0 was released 2013-03-22. This suggests you could use a compiler from the early 1990s up through 2012 (gcc 4.7 released 2012-03-22) and expect it to work.
• <gcc-11 could be bootstrapped with a C++98 compiler. =gcc-11.1 was released 2021-04-27. =gcc-10.x saw gcc-10.4 released 2022-06-28, and presumably still can be built with a C++98 compiler.
• >=gcc-11 requires a C++11 compiler, so you will need something from within the roughly 10 years before gcc-11 was released.

If I read that right, you can go from a bare C89 compiler (if you can even find one that lacks everything newer anymore) to gcc-4.7. gcc-4.7 had substantial, but not total, support for C++11, so let's call it only a C99/C++98 compiler and not a C++11 compiler. Using gcc-4.7, you can then build gcc-10, which gets you a full C++11 compiler. Per the prerequisites page, a C++11 compiler can build gcc-11 and later, with no upper bound documented, which presumably means that gcc-13 (still in development) can be built using a C++11 compiler. Therefore, using any random C89 compiler you can find, you can perform two intermediate hops to reach the cutting edge compiler, crossing more than 2 decades of development.

Compare that to Rust, where the official position is that you usually need the most recent release. As I write this, Rust 1.62 is current, and was released June 30 2022. The preceding release, Rust 1.61 was released May 19 2022. The most recent Rust that mrustc can handle is 8 versions ago, and goes back only to July 29 2021. If you want to avoid mrustc and use the official bootstrap process, then crossing the roughly 7 years since Rust 1.0 was released on May 15 2015 will require ~62 steps. It might be worse, since Rust 1.0 probably cannot be built with just a C89 compiler. I could not quickly find documentation on how to build Rust 1.0.

C can cross decades with two intermediate hops. Rust can cross about a year with 8 intermediate hops and the aid of an external project.

Of course, no discussion of the Rust release process would be complete without at least one dishonorable mention of their recommended install instructions, a curlpipesh:

[pjp]

[Leonardo.b]

[Goverp]

I once stood next to a coffee-break discussion between Edsger Dijkstra, Bjarne Stroustrup and Donald Knuth. It didn't make me like C++ any more.
_________________
Greybeard

[mv]

[mv]

[Etal]

[Dr.Willy]

[carcajou]

Guys, thank you very much for all the feedback and suggestions.

I will go with either Go or Haskell (actually an interesting proposal I haven't thought about before).

[eohrnberger]

The most useful capabilities in an IDE / programming language that I've experienced is the ability to set a break point on a line of code, see that that line of code wasn't resulting in what you needed from that line of code, backup the 'next statement to be executed' (IP) a few lines, revise the code below that point, and step forward a line at a time through the revised code to see if the code changes you've made get the results that you need.

If not, backup the 'next statement to be executed' (IP) a few lines, tweak the code below that point again, and then single step to see if your code changes get the results you need.

An 'immediate' window, where you can type / copy paste in lines of code, using the variables currently in the debugger's scope, to see what the results of those lines of code would result in.

Rinse, lather repeat as needed. All rather 'interactive' if you will.

This isn't a typical capability of complied languages, and you have to make code changes, save the source file, recompile, and re-execute to your break point and try again. What I'm describing eliminates those intermediate steps, which may or may not be available in an interpreted programming language.

What I'd be looking for is a programming language / IDE for Linux which would harken back to MS Office's VBA or Visual Basic version 3 or version 3.5, where what I describe above was the common place method of development and refining code to do what you needed.

That and easy language syntax and robust and easy to understand object model would seem to be a winner. Throw in interoperability to multiple desktop applications and their automation, well, that'd be a more than generous bonus, wouldn't it?

Nothing like that available in Linux at all? Anyone? I surely don't know of one, but where should I look?